ORACLE/ADMIN2009. 8. 25. 11:23

언두테이블스페이스(undo tablespace) 용량 증가로 UNDOTBS변경

반응형

1. 새로운 undo tablespace를 다음과 같이 생성한다.

CREATE UNDO TABLESPACE UNDOTBS2
DATAFILE '/oradata/undotbs02.dbf' SIZE 2048M;

2. undo tablespace의 이름을 변경하려면 다음과 같이 실행한다.

ALTER SYSTEM SET UNDO_TABLESPACE = UNDOTBS2;

3 기존 undo tablespace 를 drop한다.

DROP TABLESPACE "UNDOTBS1" INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS;

4. drop 한 undo datafile을 지운다





반응형
저작자표시 비영리

'ORACLE > ADMIN' 카테고리의 다른 글

ORACLE TABLESPACE 관리  (0) 2009.09.15
The National Character Set in Oracle 9i, 10g and 11g  (0) 2009.09.11
Table생성 스크립트 파일 뽑아내기  (0) 2009.08.12
인덱스의 유효성 검사  (6) 2009.07.03
SPFILE 사용  (0) 2009.06.29
Posted by [PineTree]
ORACLE/11G2009. 8. 25. 08:00

기준선 및 개선된 계획

반응형


 

실행 계획을 최적화하기 위해 Oracle Database 11 g 의 SQL 계획 관리 기능 사용

 

제대로 작동하던 데이터베이스 쿼리의 성능이 갑자기 떨어지는 상황이 발생한 적이 있습니까? 여러분의 십중팔구는 실행 계획의 변경사항에서 그 원인을 찾으려 했을 것입니다. 더 자세한 분석에서는 이러한 성능 변화가 해당 쿼리에서 참조한 테이블과 인덱스에 대해 새로 수집된 옵티마이저 통계 때문인 것으로 밝혀졌을 수도 있을 것입니다.

 

이런 상황에 당황하여 통계 수집을 중단하기로 성급하게 결정한 적이 있으십니까? 그러한 조치는 실행 계획을 해당 쿼리에 대해 거의 동일하게 유지시키지만 다른 것들은 더욱 악화시킬 수 있습니다. 오래된 통계를 통해 생성된 차선의 실행 계획은 다른 쿼리의 성능 또는 다른 술어(WHERE 절)를 가진 동일한 쿼리의 성능을 악화시킵니다.

 

다음에 어떤 조치를 취하든 여기에는 일부 위험이 따르기 마련입니다. 따라서 어떻게 하면 위험을 완화하고, 옵티마이저 통계가 정기적으로 수집되고, 모든 SQL문을 크게 변경하지 않고도(힌트 추가 등) 제대로 수행할 수 있는 정상적인 환경을 유지하면서, 생성된 SQL문에 대한 실행 계획을 최적으로 유지할 수 있겠습니까? 여러분 중에는 저장된 개요를 사용하여 계획을 유지하려 하는 분도 있을 것입니다. 하지만 그러한 행동은 옵티마이저가 도움이 될만한 실행 계획을 생성하는 것을 방해할 뿐입니다.

 

Oracle Database 11g에서는 새로운 SQL 계획 관리 기능을 사용하여 실행 계획이 계속해서 어떻게 변하는지 확인하고, 실행 계획을 사용하기 전에 먼저 데이터베이스에서 실행하여 계획을 확인하며, 통제된 방식으로 계획이 더 나아지도록 점차 개선할 수 있습니다.

 

SQL 계획 관리

 

SQL 계획 관리를 사용하는 경우, 옵티마이저는 특별 저장소인 SQL 관리 베이스에 생성된 실행 계획을 저장합니다. 특정 SQL문에 대해 저장된 모든 계획은 해당 SQL문의 계획 내역의 일부가 됩니다.

 

내역의 일부 계획은 "수락됨(Accepted)"으로 표시될 수 있습니다. SQL문이 재분석될 경우 옵티마이저는 내역 중 수락된 계획만을 고려합니다. 해당 SQL문에 대해 수락된 계획 세트를 SQL 계획 기준선 (SQL Plan Baseline) 또는 줄여서 기준선 (Baseline)이라고 합니다.

 

그러나 옵티마이저는 계속해서 더 나은 계획을 생성하기 위해 노력합니다. 옵티마이저가 새로운 계획을 생성한 경우, 계획 내역에 해당 계획을 추가하지만, 이 계획이 기준선의 수락된 모든 계획보다 더 나은 경우가 아니라면 SQL을 재분석할 때 고려하지 않습니다. 따라서 SQL 계획 관리를 사용하면 SQL문이 갑자기 효과가 떨어지는 계획을 가져와서 성능이 떨어지는 결과를 초래하는 현상이 발생하지 않습니다.

SQL 계획 관리를 사용하면 SQL문의 계획 내역에서 사용 가능한 모든 계획을 검사하고, 상대적인 효율성을 비교할 수 있습니다. 또한 특정 계획이 수락 상태로 되도록 하기도 하며 심지어 계획을 영구(고정) 계획이 되게 할 수도 있습니다.

 

이 문서에서는 SQL문의 최적 성능을 보장하기 위해 명령 행에서 Oracle Enterprise Manager 및 SQL을 사용하여 기준선의 캡처, 선택 및 개선을 포함한 SQL 계획 기준선의 관리 방법에 대해 알아봅니다.

 

캡처

 

SQL 계획 관리의 캡처 기능은 SQL문에서 사용한 다양한 옵티마이저 계획을 캡처합니다. 기본적으로 캡처 기능은 비활성화되어 있습니다. 즉, SQL 계획 관리에서 분석 또는 재분석중인 SQL문의 내역을 캡처하지 않습니다.

 

한 세션에서 파생된 몇몇 SQL문 예제에 대한 기준선을 캡처해 보겠습니다. 여기서는 Oracle Database 11 g 과 함께 제공된 샘플 스키마(SH)와 SALES 테이블을 사용할 것입니다.

 

먼저 세션에서 기준선 캡처 기능을 활성화합니다.

 

alter session <br /> set optimizer_capture_sql_plan_baselines = true;<br />

 

이제 이 세션에서 실행된 모든 SQL문이 해당 최적화 계획과 함께 SQL 관리 베이스에 캡처됩니다. SQL문의 계획은 변경될 때마다 계획 내역에 저장됩니다. 이를 확인하려면 목록 1에 표시된 스크립트를 실행해 보십시오. 이 스크립트는 완전히 동일한 SQL을 다른 환경에서 실행합니다. 먼저, SQL이 모든 기본값으로 실행됩니다(암시적 기본값 optimizer_mode = all_rows 포함). 다음 실행 시, optimizer_mode 매개 변수 값은 first_rows로 설정되어 있습니다. SQL의 세 번째 실행 전에 테이블 및 인덱스에 대한 새로운 통계를 수집합니다.

 

코드 목록 1: SQL 계획 기준선 캡처

alter session set optimizer_capture_sql_plan_baselines = true;<br /> -- First execution. Default Environment<br /> select * /* ARUP */ from sales<br /> where quantity_sold &gt; 1 order by cust_id;<br /> -- Change the optimizer mode<br /> alter session set optimizer_mode = first_rows;<br /> -- Second execution. Opt Mode changed<br /> select * /* ARUP */ from sales<br /> where quantity_sold &gt; 1 order by cust_id;<br /> -- Gather stats now<br /> begin<br /> dbms_stats.gather_table_stats (<br /> ownname =&gt; 'SH',<br /> tabname =&gt; 'SALES',<br /> cascade =&gt; TRUE,<br /> no_invalidate =&gt; FALSE,<br /> method_opt =&gt; 'FOR ALL INDEXED COLUMNS SIZE AUTO',<br /> granularity =&gt; 'GLOBAL AND PARTITION',<br /> estimate_percent =&gt; 10,<br /> degree =&gt; 4<br /> );<br /> end;<br /> /<br /> -- Third execution. After stats<br /> select * /* ARUP */ from sales<br /> where quantity_sold &gt; 1 order by cust_id;<br />

 

목록 1의 SQL 실행마다 계획이 변경될 경우, 해당 SQL문의 계획 내역에 다른 계획이 캡처됩니다. (/* ARUP */ 코멘트는 공유 풀의 특정 SQL문을 쉽게 식별합니다.)

계획 내역을 확인하는 가장 쉬운 방법은 Oracle Enterprise Manager를 사용하는 것입니다. Database 기본 페이지에서 Server 탭을 선택한 다음 SQL Plan Control을 클릭합니다. 페이지에서 SQL Plan Baseline 탭을 선택합니다. 그림 1처럼 해당 페이지에서 ARUP 이름이 포함된 SQL문을 검색합니다. 그러면 화면의 하단부에 SQL문에 대한 계획 내역이 표시됩니다.

 

그림 1: SQL 계획 내역

SQL 계획 이름(예: SYS_SQL_PLAN_27a47aa154bc8843)을 클릭하면 계획 내역에 저장된 계획의 세부 정보를 확인할 수 있습니다. 화면의 중요한 열은 다음과 같습니다.

  • Enabled는 계획의 활성 여부를 나타냅니다.
  • Accepted는 옵티마이저에서 계획을 고려하는지 여부를 나타냅니다. 하나 이상의 계획이 수락된 경우 옵티마이저는 최적의 계획을 선택합니다.
  • Fixed는 계획이 해당 SQL문에 영구적으로 사용될 것인지 여부를 나타냅니다. 하나 이상의 계획이 고정된 경우 옵티마이저는 최적의 계획을 선택합니다.
  • Auto Purge는 계획이 사용되지 않는 경우, 일정 기간 후에 계획 내역에서 해당 계획이 자동으로 삭제되는지 여부를 나타냅니다. 자동 삭제가 활성화된 경우, 지정한 기간 후에 계획 내역에서 사용되지 않는 계획이 자동으로 삭제됩니다. 사용되지 않는 계획이 삭제되도록 지정한 기간은 그림 1의 Plan Retention(Weeks) 레이블 옆에 표시되어 있습니다. 이 경우 53주로 설정되어 있지만 Configure 버튼을 클릭하여 변경할 수 있습니다.

또한 Settings 섹션에서 적절한 링크를 통해 이 Oracle Enterprise Manager 화면에서 SQL 계획 기준선의 캡처 및 사용을 활성화할 수도 있습니다.

 

커서 캐시 또는 SQL 튜닝 세트에서 SQL 계획 기준선에 계획을 로드할 수도 있다는 것을 참고하십시오. 계획을 SQL 계획 기준선에 수동으로 로드한 경우, 이 로드된 계획은 수락된 계획으로 추가됩니다. 자세한 내용은 Oracle Database Performance Tuning Guide의 15장 "Using SQL Plan Management"를 참조하십시오.

 

기준선 사용

 

SQL 계획 기준선을 캡처한 경우, 옵티마이저를 활성화하여 해당 기준선을 사용할 수 있습니다.

 

alter session set <br /> optimizer_use_sql_plan_baselines = true;<br />

 

기준선 사용이 활성화된 경우, 옵티마이저가 SQL문을 재분석할 때 해당 SQL문의 기준선에 저장된 계획을 검사하고 최적의 계획을 선택합니다. 이것이 바로 기준선의 가장 중요한 이점입니다. 또한 옵티마이저는 SQL문을 계속 재분석하며(기준선의 존재가 이를 방해하지 않음), SQL의 계획 내역에 새로 생성된 계획이 없는 경우, 이 계획을 추가하지만 “Accepted” 상태로 추가하지는 않습니다. 따라서 새로 생성된 계획이 더 나쁜 경우에도 그 계획은 사용되지 않기 때문에 SQL 성능은 영향을 받지 않습니다. 그러나 데이터 배포 및 애플리케이션 논리에 관한 개인적인 지식에 따라 새 계획이 더 낫다고 결정하는 경우도 있습니다. 예를 들어, 테이블이 실제로 비어 있을 때 계획이 캡처됐다고 가정해 봅시다. 이 경우 옵티마이저는 인덱스 검색을 선택합니다. 그러나 여러분은 나중에 SQL문을 호출하기 전에 애플리케이션이 테이블을 채운다는 것과 전체 테이블 검색이 계획에는 결국에는 더 좋다는 것을 알고 있습니다. 이런 상황에서는 새 계획을 검사하여 더 나은 경우 이를 수락할 수 있습니다. 그리고 옵티마이저는 그 후에 이 계획을 고려하게 됩니다. 이 경우 좋은 점은 항상 좋은 계획이 사용되고, 옵티마이저가 더 나은 계획을 생성한 경우에는 비교하여 사용할 수 있다는 것입니다.

SQL문의 기준선의 계획을 사용하지 않고자 하는 경우에는 SQL문을 호출하기 전에 세션에서 다음과 같은 문을 사용하여 기준선 사용을 비활성화할 수 있습니다.

 

alter session set <br /> optimizer_use_sql_plan_baselines = false;<br />

 

목록 2에서는 동일한 쿼리를 두 번 실행합니다. 먼저 기준선을 활성화하여 실행한 다음, 기준선을 비활성화하고 실행합니다. 여기서 기준선을 비활성화한 후 계획이 어떻게 변경되는지 확인할 수 있습니다. 맨 처음 옵티마이저는 SALES_TIME_BIX 인덱스에서 BITMAP INDEX FULL SCAN을 선택했습니다. 기준선을 비활성화한 후에는 계획이 SALES 테이블의 TABLE ACCESS FULL로 바뀌었습니다. 이는 이 계획이 옵티마이저 통계와 옵티마이저에 지금 당장 영향을 미치는 다른 변수를 기준으로 최적의 계획으로 여겨지기 때문입니다. 먼저 기준선을 활성화한 경우에서는 옵티마이저가 기준선에 저장된 수락된 계획 세트에서 최적의 계획을 선택했습니다.

코드 목록 2: SQL 계획 기준선 사용

SQL&gt; explain plan for select * /* ARUP */ from sales<br /> 2 where quantity_sold &gt; 1 order by cust_id;<br /> Explained.<br /> SQL&gt; select * from table(dbms_xplan.display(null, null, 'basic'));<br /> PLAN_TABLE_OUTPUT<br /> ---------------------------<br /> Plan hash value: 143117509<br /> --------------------------------------------------------------<br /> | Id | Operation | Name |<br /> --------------------------------------------------------------<br /> | 0 | SELECT STATEMENT | |<br /> | 1 | SORT ORDER BY | |<br /> | 2 | PARTITION RANGE ALL | |<br /> | 3 | TABLE ACCESS BY LOCAL INDEX ROWID| SALES |<br /> | 4 | BITMAP CONVERSION TO ROWIDS | |<br /> | 5 | BITMAP INDEX FULL SCAN | SALES_TIME_BIX |<br /> --------------------------------------------------------------<br /> -- Now disable baselines and look at the latest plan<br /> SQL&gt; alter session set optimizer_use_sql_plan_baselines = false;<br /> Session altered.<br /> SQL&gt; explain plan for select * /* ARUP */ from sales<br /> 2 where quantity_sold &gt; 1 order by cust_id;<br /> Explained.<br /> SQL&gt; select * from table(dbms_xplan.display(null, null, 'basic'));<br /> PLAN_TABLE_OUTPUT<br /> ----------------------------<br /> Plan hash value: 3803407550<br /> --------------------------------------<br /> | Id | Operation | Name |<br /> --------------------------------------<br /> | 0 | SELECT STATEMENT | |<br /> | 1 | SORT ORDER BY | |<br /> | 2 | PARTITION RANGE ALL | |<br /> | 3 | TABLE ACCESS FULL | SALES |<br /> --------------------------------------<br />

 

관리 및 개선

 

특정 SQL문에 대한 기준선을 만든 후, 그림 1에 표시된 Oracle Enterprise Manager 화면에서 연관된 계획 이름을 클릭하여 (Oracle Enterprise Manager -> SQL Plan Control page -> SQL Plan Baseline tab) 기준선을 검사하고 계획의 세부 정보를 확인할 수 있습니다. 특정 계획이 좋아지지 않을 경우, Disable 버튼을 클릭하여 계획을 완전히 비활성화할 수 있습니다. 나중에 생각이 바뀔 경우에는 다시 Enable 버튼을 클릭할 수 있습니다.. Drop 버튼을 사용하면 SQL 관리 베이스에서 계획이 완전히 삭제됩니다. 계획이 사용되지 않고 보관 기간이 경과하면 해당 계획은 자동으로 삭제된다는 점을 참고 하십시오.

 

현재 기준선의 계획이 최적이 아니고 계획 내역의 다른 계획이 더 낫다고 생각되는 경우, 진화 함수(Evolve Function)를 사용하여 계획의 성능을 비교해볼 수 있습니다(Oracle Enterprise Manager -> SQL Plan Control page -> SQL Plan Baseline 탭 또는 명령 행에서 DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE 함수 사용). 진화 함수를 사용하려면 그림 1의 Oracle Enterprise Manager 화면에서 비교할 계획을 선택한 다음 Evolve 버튼을 클릭합니다. 그러면 옵티마이저가 선택한 최고의 계획과 여러분이 선택한 계획 간의 비교가 수행됩니다. 이 기능으로 목록 3에서 보여지는 것과 같은 보고서가 생성됩니다. 목록 상단의 다음 행을 주목하십시오:

 

코드 목록 3: 기준선 개선 보고서

-----------------------------------------------------<br /> Evolve SQL Plan Baseline Report<br /> -----------------------------------------------------<br /> Inputs:<br /> ----<br /> PLAN_LIST = SYS_SQL_PLAN_27a47aa15003759b<br /> TIME_LIMIT = DBMS_SPM.AUTO_LIMIT<br /> VERIFY = YES<br /> COMMIT = YES<br /> Plan: SYS_SQL_PLAN_27a47aa15003759b<br /> ----------------------<br /> Plan was verified: Time used 41.06 seconds.<br /> Failed performance criterion: Compound improvement ratio &lt; .36<br /> Baseline Plan Test Plan Improv. Ratio<br /> -------------- --------- ------------- <br /> Execution Status: COMPLETE COMPLETE<br /> Rows Processed: 0 0<br /> Elapsed Time(ms): 5036 1033 4.88<br /> CPU Time(ms): 254 700 .36<br /> Buffer Gets: 1728 43945 .04<br /> Disk Reads: 254 22 11.55<br /> Direct Writes: 0 0<br /> Fetches: 49 22 2.23<br /> Executions: 1 1<br /> --------------------------------------------------------------------<br /> Report Summary<br /> --------------------------------------------------------------------<br /> Number of SQL plan baselines verified: 1.<br /> Number of SQL plan baselines evolved: 0.<br /> Failed performance criterion: <br /> Compound improvement ratio &lt; .36. <br />

 

이 행에서는 새로 고려된 계획이 원래 계획보다 성능이 떨어지는 것으로 표시됩니다. 따라서 옵티마이저의 최적 계획 선택을 위한 대체 항목으로서 거부되었습니다. 비교로 인해 개선 요인이 1보다 큰 것으로 드러나면 SQL 계획 관리에서는 해당 계획을 옵티마이저가 고려할 후보로 수락했을 것입니다.

진화 함수를 통한 결정이 정확하지 않다고 생각되어 옵티마이저가 한 특정 계획을 사용하도록 하고 싶은 경우에는 어떻게 하시겠습니까? 이는 계획이 기준선에 고정되도록 함으로써 할 수 있습니다. 목록 4처럼 dbms_spm 패키지에서 alter_sql_plan_baseline 함수를 실행하여 계획이 고정되게 할 수 있습니다.

 

코드 목록 4: 계획 기준선 고정

declare<br /> l_plans pls_integer;<br /> begin<br /> l_plans := dbms_spm.alter_sql_plan_baseline (<br /> sql_handle =&gt; 'SYS_SQL_f6b17b4c27a47aa1',<br /> plan_name =&gt; 'SYS_SQL_PLAN_27a47aa15003759b',<br /> attribute_name =&gt; 'fixed',<br /> attribute_value =&gt; 'YES'<br /> );<br /> end;<br /> -- Now examine the plan:<br /> SQL&gt; explain plan for select * /* ARUP */ from sales<br /> 2 where quantity_sold &gt; 1 order by cust_id;<br /> Explained.<br /> SQL&gt; select * from table(dbms_xplan.display(null, null, 'basic'));<br /> Plan hash value: 143117509<br /> --------------------------------------------------------------<br /> | Id | Operation | Name |<br /> --------------------------------------------------------------<br /> | 0 | SELECT STATEMENT | |<br /> | 1 | SORT ORDER BY | |<br /> | 2 | PARTITION RANGE ALL | |<br /> | 3 | TABLE ACCESS BY LOCAL INDEX ROWID| SALES |<br /> | 4 | BITMAP CONVERSION TO ROWIDS | |<br /> | 5 | BITMAP INDEX FULL SCAN | SALES_PROMO_BIX |<br /> --------------------------------------------------------------<br />

출력 결과로부터 새로운 계획에서 이전 계획에서 사용되었던 (그리고 목록 2에서 보여진) SALES_TIME_BIX 인덱스 대신 SALES_PROMO_BIX 인덱스를 사용한 것을 알 수 있습니다. 이제 새 계획이 고정됩니다.

그렇다면 고정된 계획을 어디서 사용할 수 있을까요? SQL문의 계획이 최적이 아니며 (예를 들어, 계획이 SALES_TIME_BIX 인덱스를 사용할 경우 더 효율적일 수 있는데 SALES_PROMO_BIX 인덱스를 사용하는 계획) 코드를 변경하여 힌트를 배치할 수 없는 상황을 가정해 보십시오. 이 경우 다음 단계를 수행할 수 있습니다.

 

1. 다른 세션에서 optimizer_mode 매개 변수를 목록 1에서 보여진 것처럼 원하는 계획을 생성하는 값으로 변경합니다.

2. SQL문을 실행하고, 목록 1처럼 기준선을 캡처한 다음, 세션의 연결을 끊습니다.

3. 목록 4에서 보여진 것처럼 SALES_TIME_BIX 인덱스를 사용하여 계획을 고정으로 표시합니다. SQL 핸들과 계획 이름을 여러분의 케이스에 해당하는 이름으로 바꾸는 것을 기억하십시오.

 

계획이 고정으로 표시되고 나면 SQL문은 옵티마이저가 생성한 계획이 아닌 해당 계획만을 사용하게 됩니다. 하나 이상의 고정된 계획이 존재하는 경우, 옵티마이저는 최적의 계획을 선택합니다.

 

동일한 방법을 사용하여 데이터베이스 업그레이드 중 SQL문의 안정적인 실행 경로를 보장할 수도 있습니다. 먼저 시스템 매개 변수 optimizer_capture_sql_plan_baselines를 true로 설정하여 데이터베이스에서 모든 SQL문에 대한 기준선을 수집한 다음, 중요한 SQL문마다 하나의 계획만 고정으로 표시되도록 합니다. 그런 다음 점진적으로 계획을 "고정 해제"하고 진화 함수를 사용하여 다른 최적의 계획이 있는지 확인합니다. 옵티마이저가 나중에 생성한 계획이 더 나쁠 경우에는 항상 이전의 고정된 계획으로 되돌릴 수 있습니다.

 

결론

 

저장된 개요 또한 계획을 안정적으로 만들지만 융통성이 없게 합니다. 옵티마이저는 SQL문에 대한 개요가 있는지 확인하고 새로운 계획 생성을 중지합니다. 한편 기준선은 옵티마이저가 새로운 계획을 생성하는 것을 절대 중단하지 않습니다.

 

SQL 계획 관리 기능을 사용하면 SQL문에 대한 검증된 계획이나 잘 알려진 계획을 기준선의 형식으로 저장할 수 있습니다. 그러면 갑작스런 성능 저하를 진단할 때 매우 유용합니다. 기준선(및 해당 계획)이 저장소에 저장되기 때문에 기준선 및 계획을 비교하여 가장 효율적으로 사용할 수 있도록 결정할 수 있습니다.

 

필자소개

 

Arup Nanda ( arup@proligence.com ) 는 성능 조정에서 보안 및 재해 복구에 이르기까지 모든 데이터베이스 관리 측면을 관리하는 Oracle DBA로서 14년 이상 근무해 왔습니다. 그리고 2003년 Oracle Magazine에 의해 올해의 DBA로 선정된 바 있습니다

 

출처 : 한국 오라클

제공 : DB포탈사이트 DBguide.net

반응형
저작자표시 비영리

'ORACLE > 11G' 카테고리의 다른 글

11g： 스케줄러 유지 관리 작업 또는 자동작업 (문서 ID 1534329.1)  (0) 2014.06.14
oracle 11g에 추가된 파티션  (0) 2013.08.20
ADR  (0) 2013.05.19
11g 데이타베이스 에러수집방법  (0) 2012.05.11
Oracle Advanced Compression  (0) 2009.04.02
Posted by [PineTree]
DBMS2009. 8. 24. 09:26

오라클 데이터베이스 10g 릴리즈 2편 - 성능 항목별 DBMS 3종 비교 분석

반응형
오라클은 올 4월 오라클 데이터베이스 10g의 TPC-C 결과를 발표하며 32개 프로세스 부분에서 1분에 160만 트랜잭션을 처리해 세계 신기록을 기록했다고 밝힌 바 있다. 이러한 수치가 우리에게 의미하는 바는 무엇이며 오라클 10g가 다른 DBMS 제품과 차별화되는 점은 무엇인지 성능 측면에서 살펴본다.

많은 DBMS 업체들이 자사 제품 성능의 우수함을 주장하기 위해 공신력 있는 기관의 벤치마크 결과를 인용한다. 이때 많이 근거로 제시되는 것이 바로 가장 객관적이라고 알려진 TPC (Transaction Processing Performance Council)이다. TPC는 TPC-C와 TPC-D라는 기준을 가지고 지속적으로 벤치마크 결과를 발표하는데, 전자는 TPC에 의해 기획된 OLTP(OnLine Transaction Processing, 실시간 데이터 처리) 벤치마크 테스트로 여기서 세계 신기록을 수립했다는 것은 32-프로세스 등 해당 부분에서 가장 좋은 성능을 가진 DBMS임을 의미한다. 마치 수영이나 육상 등의 시합에서 100m를 얼마만에 주파했는지 시간 기록이 있듯이 TPC-C도 처리 속도에 분당(tpmC) 혹은 비용($/tpmC) 대비 DBMS의 기록인 셈이다.

<표 1>은 각 데이터 볼륨 사이즈별 TPC-H의 결과치와 시간당 처리 쿼리(QphH) 순으로 상위 3위를 정리한 것이다. TPC-H는 의사결정 벤치마크 결과로, 복잡한 질의를 실행하고 중대한 비즈니스 질문에 대한 답변을 주는 의사결정 지원 시스템을 선택하는 기준으로 활용되곤 한다. <표 1>에서 볼 수 있듯이 100GB에서 QphH의 수치는 MS SQL 서버 2005가 가장 뛰어난 성능을 보인다. 그러나 300GB 이상의 데이터 볼륨의 경우 오라클 데이터베이스 10g의 성능이 가장 뛰어난 처리능력을 보여주는 것을 알 수 있다. 즉 오라클은 중대형으로 올라가면 올라갈수록 진가를 발휘하는 셈이다. 실제로 시장에서는 MS SQL은 중소형 DBMS, 오라클은 대형 DBMS라는 인식이 형성돼 있다.

그렇다면 왜 오라클은 중대형 서버에서 제 성능을 발휘하는 것일까. 지금부터 실제 주요 DBMS와 오라클을 직접 비교해보자. 기능 비교는 DBMS의 성능을 결정하는 핵심 요인을 중심으로 이루어지며 구체적으로는 동시성 모델과 인덱싱, 파티셔닝, 병렬 실행, 클러스터링 등을 살펴볼 예정이다.

① 동시성 모델 : 데이터베이스의 Locking 메커니즘을 비교하기 위한 것으로, 얼마나 많은 사용자가 동시에 같은 데이터 읽기 일관성을 유지하는가가 관건이다.

② 파티셔닝 : 대량의 데이터를 처리하는데 있어서 파티셔닝, 즉 특정 값을 기준으로 데이터를 분할하는 방법

③ 병렬 실행 : 멀티 CPU 환경에서 CPU 별로 균등하게 작업을 분배해 전체 처리 성능을 높인다.

④ 클러스터링 : 복수의 노드를 단일 노드처럼 처리하여 성능과 고가용성을 높이는 요인이 된다.



오라클 데이터베이스 10g vs. SQL 서버 2005
먼저 오라클의 가장 최신 버전인 오라클 데이터베이스 10g 릴리즈 2와 마이크로소프트(이하 MS)의 SQL 서버 최신 제품인 SQL 서버 2005의 기술적인 차이점을 성능과 확장성 관점에서 비교해보자.
동시성 모델
동시성 모델(Concurrency Model)은 멀티-유저 환경에서 특정 사용자에 의해 수행된 데이터 업데이트가 다른 사용자에게 영향을 미치는지 여부를 알 수 있는 매우 중요한 지표다. 오라클 데이터베이스 10g와 SQL 서버 2005는 동시성 모델의 구현 방법에서 차이를 보이는데 주요 차이점은 <표 2>와 같다.
<표 1> 볼륨 사이즈별 TPC 상위 3위
100GB 결과
기업 시스템 vQphH 가격/
QphH		 System
Availability		 데이터베이스 운영체제 Date
Submitted		 클러
스터
hp Hp ProLiant DL585 G1 4P 12,600 9.43$ 11/07/05 MS SQL 서버 2005
엔터프라이즈X64 에디션		 MS 윈도우
서버 2003
엔터프라이즈
64 에디션		 11/04/05 N
IBM IBM e서버 325 12,216 70.68$ 11/08/03 IBM DB2 UDB 8.1 수세 리눅스
엔터프라이즈
서버 8		 07/29/03 Y
썬 SunFire V890 10,487 46.29$ 08/15/05 썬 사이베이스
IQ 12.6 싱글		 썬 솔라리스 10    

300GB 결과
기업 시스템 vQphH 가격/
QphH		 System
Availability		 데이터베이스 운영체제 Date
Submitted		 클러
스터
hp HP BladeSystem ProLiant BL25p Cluster 8P DC 18,725 27.97$ 11/11/05 오라클 10g
엔터프라이즈
에디션 R2 w/ Partioning		 레드햇
엔터프라이즈
리눅스4 ES		 11/11/05 Y
hp HP BladeSystem ProLiant BL25p Cluster 8P 13,284 34.20$ 10/31/05 오라클 데이터베이스 10g릴리즈 2 엔터프라이즈 에디션 레드햇 엔터프라이즈 리눅스 4 ES 09/16/05 Y
IBM IBM e서버 325 13,194 65.44$ 11/08/03 IBM DB2 UDB 8.1 수세 리눅스 07/29/03 엔터프라이즈 서버 8 07/29/03 Y

1000GB 결과
기업 시스템 vQphH 가격/
QphH		 System
Availability		 데이터베이스 운영체제 Date
Submitted		 클러
스터
hp HP Intergrity
Superdome
엔터프라이즈 서버		 68,100 59.00$ 01/18/06 오라클 데이터베이스 10g R2 엔터프라이즈 에디션 w/Partitioning HP UX 11.i V2 64비트 08/08/05 N
IBM IBM 2서버
xSeries 346		 53,451 32.80$ 02/14/05 IBM DB2 UDB 8.2 수세 리눅스 엔터프라이즈 서버 9 02/14/05 Y
hp HP ProLiant Dl585 Cluster 48P 35,141 59.93$ 10/21/04 오라클 10g RAC/ with Partitioning 레드햇 엔터프라이즈 Linux AS 3 10/22/04 Y

10000GB 결과
기업 시스템 vQphH 가격/
QphH		 System
Availability		 데이터베이스 운영체제 Date
Submitted		 클러
스터
썬 Sun fire E25K
server		 108,099 53.80$ 01/23/06 오라클 10g 엔터프라이즈 에디션 R2 w/Partitioning 썬 솔라리스 10 11/29/05 N
IBM IBM e서버
p5 575		 104,100 61.17$ 08/15/05 IBM DB2 UDB 8.2 IBM AIX 5L
V5.3		 05/20/05 Y
hp HP Integrity
Superdome
엔터프라이즈 서버		 86,282 161.24$ 04/06/05 오라클 데이터베이스 10g 엔터프라이즈 에디션 HP UX 11.i
V264비트		 10/07/04 Y

오라클 데이터베이스에서 구현되는 멀티-버전 읽기 일관성(multi-version read consistency)은 예를 들면, 트랜잭션에 의해 업데이트가 발생한 경우 기존 데이터 값은 데이터베이스의 언두(undo) 레코드에 기록이 되기 때문에 트랜잭션이 커밋되기 전까지 언두 레코드에 저장된 이전 버전의 정보를 사용자에게 반환하고 따라서 데이터의 읽기 일관성을 보장한다.

반면 SQL 서버 2005가 기본적으로 제공하는 격리(isolation) 모델은 읽기 작업에 대해 공유 읽기 잠금(shared read lock)을 사용한다. 즉 공유 잠금이 적용된 경우 현재 읽기 작업이 수행되고 있는 데이터에 대한 업데이트가 불가능하다. 이러한 모델은 읽기/쓰기 작업이 동시에 발생하는 환경에서 동시 요청을 처리하는데 성능상 불리할 수밖에 없다. 또한 애플리케이션이 점유하는 잠금의 수가 점차 증가함에 따라 잠금 에스컬레이션(lock escalation, 잠금의 확대, 예를 들어 row 레벨 락에서 테이블 락으로 확대되는 현상)이 발생해 동시성이 한층 더 제약되고 데드락(두 세션이 각각 상대방에 대해서 lock을 잡고 있는 상태)으로 연결될 가능성도 있다. 이러한 문제 때문에 MS SQL 서버 2005에서는 이러한 문제에 대응하기 위해 구문 레벨 읽기 일관성(read committed with snapshots), 트랜젝션 레벨 읽기 일관성(snapshot isolation) 등 두 가지 격리 수준을 추가했다.
<표 2> 오라클 10g와 MS SQL 서버 2005의 동시성 모델 비교

오라클 데이터베이스 10g SQL 서버 2005
멀티 버전 읽기 일관성
(Multi-version read Consistency)		 향상 가능 디폴트 아님.
기능의 사용을 위해 활성화해야 함
로우 레벨 잠금의 에스커레이션 잠금
(Non-escalating row-level locking)		 지원 지원 안됨
(Locks escalate)

<표 3> 인덱스 유형 비교
인덱스 유형 오라클 데이터베이스 10g SQL 서버 2005
B-트리 인덱스 지원 지원
B-트리 클러스터 인덱스 지원 지원하지 않음
해시 클러스터 인덱스 지원 지원하지 않음
리버스 키 인덱스 지원 지원하지 않음
비트맵 인덱스 지원 지원하지 않음
비트맵 조인 인덱스 지원 지원하지 않음
기능 기반 인덱스 지원 지원하지 않음. 계산된 컬럼(computed Column)에 대해 서도 인덱스를 생성할 수 있지만 해당 컬럼이 테이블 내에 실제로 존재하고 있어야 함.
도메인 인덱스 지원 지원하지 않음
IOT 지원 지원(clustered index)

<그림 1> 비트맵 조인 인덱스

이 두 가지 격리 수준은 각각 오라클에서 예전부터 지원해 온 READ COMMITTED와 SERIALIZABLE 격리 수준에 대응된다. 이 두 가지 격리 수준에서는 특정 읽기 작업이 동일한 데이터에 접근하는 다른 읽기/쓰기 작업을 블로킹하지 않으며 쓰기 작업 역시 읽기 작업을 블로킹하지 않는 것이 특징이다. 먼저 트랜젝션 레벨 읽기 일관성은 로우 버저닝(row versioning)을 기반으로 하고 있다. 이는 커밋된 데이터 로우를 포함하고 있는 여러 버전들의 링크드 체인(linked chain), 즉 원래의 데이터 위치를 추적함으로써 읽기 일관성을 보장하는 방법이다. 링크드 체인은 tempdb라는 임시 스토어드 프로시저(temp stored procedure)와 기타 임시 작업을 위한 데이터베이스 저장공간에 위치한 별도의 버전 저장소(version store)에 저장된다.

이러한 SQL 서버 2005의 트랜젝션 레벨 읽기 일관성은 혁신적인 기술로 보기 힘들다. SQL 서버 2000에서는 지원되지 않았기 때문에 이전 버전보다 개선된 것은 사실이나 오라클은 이미 오래 전부터 멀티-버전 읽기 일관성을 기본으로 지원해왔기 때문이다. 이 외에도 SQL 서버 2005는 동시성 모델에 있어서 다음과 같은 한계들을 갖는다.

① 관리자는 데이터베이스 레벨에서 명시적으로 설정한 경우에만 read-com mitted with snapshot 또는 snaption isolation이 활성화된다(기본적으로는 성능상의 이유 때문에 ‘disable’되어 있다).

② 기존에 운영 중이던 SQL 서버 애플리케이션의 경우 이 모드를 구현하려면 SQL 서버 애플리케이션을 오라클 환경으로 이전하는 것과 동등한 수준의 수정 작업이 요구된다. 왜냐하면 SQL 서버 2000에서는 이러한 기능이 지원되지 않았기 때문이다. 읽기 잠금을 이용하는 애플리케이션에 멀티-버전 읽기 일관성을 적용하기 위해서는 일정 수준의 재설계와 재개발 작업이 불가피하다.




인덱싱
인덱스가 데이터에 대한 신속한 접근을 제공하기 위해 생성되는 중요한 기능 중에 하나라는 것은 데이터베이스를 사용하는 사람들에게는 상식적인 이야기다. 인덱스를 이용하면 디스크 I/O 작업을 크게 줄이고 데이터 인출 성능을 개선할 수 있으며 성능 향상을 기대할 수 있다. 그렇다면 오라클 데이터베이스 10g와 MS SQL 서버 2005의 인덱싱은 어떠한 차이가 있을까. <표 3>은 두 제품이 지원하는 인덱싱 메커니즘의 차이를 요약한 것이다.

오라클과 SQL 서버 2005는 모두 고전적인 B-트리 인덱스 구조를 지원한다. B-트리 인덱스는 순차적으로 정렬된 키 값을, 실제 값이 저장된 테이블 로우의 저장 위치와 연계한 형태로 구성된다. B-트리 인덱스는 별도의 인덱스 영역에 키 값을 기준으로 정렬되어 있고 이 인덱스 영역은 실제 데이터의 위치 정보(RowID)를 가지고 있다. 또한 두 제품 모두 IOT(Index-Organized Table)을 지원한다(MS는 clustered index라는 용어를 사용한다). IOT는 테이블 로우를 프라이머리 키 인덱스의 리프 노드에 저장하고 있기 때문에 프라이머리 키를 기준으로 한 조건 및 영역 검색에서 뛰어난 성능을 보여준다. IOT의 대표적인 성격은 모든 테이블의 데이터를 인덱스처럼 저장하는 것이다. 즉 인덱스 입력 항목의 두 번째 요소로 행의 RowID를 가지지 않고 실제 데이터 행이 B-트리 인덱스에 저장된다.

게다가 오라클은 스태틱 비트맵 인덱스(static bitmap index)와 비트맵 조인 인덱스(bitmap join index)를 추가로 지원한다. 이 두 가지 인덱스는 데이터 웨어하우징 환경의 로드/쿼리 작업에서 좋은 성능 효과를 보여준다. 비트맵 인덱스는 RowID와 값에 대해 BIT 값으로 저장을 함으로써 나이, 성별, 지역처럼 전체 레코드 건수에 비해 카디널리티(선택도)가 낮은 속성들과 OR, AND 연산시에 효과적으로 사용할 수 있는 인덱스 구조이다. 또한 오라클 9i부터 지원되는 비트맵 조인 인덱스는 두 개 이상의 테이블에 조인 인덱스를 생성함으로써 질의 처리를 위한 조인에서 오는 부하를 피하고 그만큼 성능 향상을 가져올 수 있다.

비트맵 인덱스는 테이블 로우의 저장 위치 목록 대신 각 키 값에 대한 비트맵(또는 비트 벡터)을 사용한다. 비트맵의 각 비트는 테이블의 로우에 대응한다. 테이블의 로우가 키 값을 포함하고 있는 경우에 해당 비트가 설정된다. 로우의 저장 위치를 저장하는 방식과 비교했을 때 비트맵 표현 방식은 매우 많은 비용 절감 효과를 제공한다. B-트리 인덱스는 실제로 조건이 비교되는 컬럼 값에 대한 테이블의 원시 값과 Row의 물리적인 주소인 RowID를 인덱스 블럭에도 저장하므로 데이터의 중복 저장에 따른 공간낭비가 발생한다. 반면 비트맵 인덱스는 저장공간에 인덱스 컬럼 값이 아닌 1과 0의 비트값이 저장되고, 스캔에 의한 데이터 추출이 아닌 비트 연산에 의한 데이터 추출을 하기 때문에 성능을 높일 수 있다. 특히 선택도(cardinality)가 낮은 데이터가 사용되는 경우 효과적이다.

비트맵 인덱스는 AND, OR 등 고속의 불리언(Boolean) 연산을 통해 서로 다른 인덱스의 비트맵을 조합하는 형태로도 활용된다. 여러 개의 조건에 대한 연산을 수행하기 위해 각 조건에 대응되는 인덱스들을 WHERE절 내에서 효과적으로 조합한다. WHERE절 내의 모든 조건을 만족하지 않는 로우는 테이블에 대한 액세스가 수행되기 전에 필터링되며 상황에 따라 극적인 성능 개선도 기대할 수 있다.

오라클 데이터베이스에서는 IOT에 대한 비트맵 인덱스를 생성하고, IOT를 데이터 웨어하우징 환경을 위한 팩트 테이블(fact table, 다차원 모델에서 중심이 되는 테이블)로 활용하는 것이 가능하다. 비트맵 조인 인덱스는 두 개 이상의 테이블을 조인(join)하기 위해 사용되는 비트맵 인덱스이다. 이를 이용하면 실제 테이블을 조인할 필요가 없으며 제약 조건을 미리 실행함으로써 실제로 조인되는 데이터의 양을 크게 줄일 수 있다. 또한 비트 단위 연산을 통해 Bit map join index를 이용하는 쿼리의 실행 속도도 개선할 수 있다.

<그림 1>은 비트맵 조인 인덱스의 대표적인 사례다. 조건절을 통해 Customer 테이블과 Sales 테이블 사이의 조인을 미리 계산하는(precomputation) 역할을 하게 되므로 두 개의 테이블 질의 시 비트맵 조인 인덱스를 통하게 되면 하나의 테이블에만 접근하면 된다. 게다가 비트맵 조인 인덱스는 다수의 디멘션 테이블을 포함하고 있으므로 비트 단위 연산이 필요치 않다(실제로 단일 테이블에 비트맵 인덱스의 형태로 스타 스키마를 적용한 경우에는 비트 단위 연산이 반드시 필요하다). 다양한 형태의 스타 스키마(Star Schema, 데이터 웨어하우징에서 복잡한 정보를 모델링하는 표준형 기술로, 중심이 되는 Fact 테이블을 중심으로 디멘전(dimension) 테이블이 붙어있는 형태이다)에 대한 쿼리 테스트를 수행해 보면 비트맵 조인 인덱스를 사용한 쿼리가 실제 성능 개선 효과를 제공한다는 사실을 확인할 수 있다.

파티셔닝
파티셔닝(Partitioning)은 테이블, 인덱스 등 대규모 데이터베이스 구조를 더 작고 관리하기 쉬운 단위로 분해하는 기능이다. 주로 관리성과 가용성을 개선하기 위해 활용되지만 성능 측면에서도 몇 가지 혜택을 제공한다.
<그림 2> 스타 스키마 모델

파티셔닝은 애플리케이션 시나리오 별로 다양한 파티셔닝 테크닉을 고려할 수 있다. 예를 들어 레인지 파티셔닝(Range Partition ing)은 일정 영역의 컬럼 값을 이용해 로우를 파티션에 맵핑한다. 이 옵션은 히스토리(history) 데이터베이스 즉 이력 데이터에 특히 유용하게 활용되며 데이터 웨어하우스 환경의 롤링 윈도우(rolling window, 주기적으로 새로운 데이터가 추가되면서 오래된 데이터는 데이터 웨어하우스에서 삭제되는 것) 지원을 위한 이상적인 파티셔닝 방법으로 이용되기도 한다.

해시 파티셔닝(Hash Partitioning)은 파티션된 컬럼에 해시 함수를 적용해서 데이터를 분산시키는 방법으로 균일하게 분포된 데이터에 효과적이다. 즉 이력 데이터의 범위 분할 적용에서 나타나는 단점인, 각 범위(Bound)가 포함하는 데이터의 양이 일정하지 않아 분포도가 일정하지 않고 각 파티션의 크기가 다르게 나타나는 점을 개선한다. 이를 통해 일정한 분포를 가진 파티션으로 나누고 균등한 데이터 분포도를 이용한 병렬처리로 성능을 높인다.

리스트 파티셔닝(List Partitioning)은 로우를 파티션으로 맵핑하는 방법을 관리자가 명시적으로 설정할 수 있다. 관리자는 파티셔닝 컬럼을 위한 값의 리스트를 정의하는 방법으로 맵핑 방법을 설정한다. 컴포짓 파티셔닝(Composite partitioning)은 사용자가 다양한 파티셔닝 테크닉을 조합할 수 있도록 지원한다. 첫 번째 방법을 이용해서 테이블을 먼저 파티셔닝한 후 두 번째 방법을 통해 각 파티션을 다시 서브파티션으로 분할하는 것이다. 이때 인덱스는 크게 3가지 종류로 구분할 수 있다.

① 로컬 인덱스(Local Index) : 하부 파티션 테이블과 동일한 파티션 방법을 사용하여 파티셔닝된 테이블에 생성된 인덱스이다. 로컬 인덱스의 각 파티션은 하부 테이블의 특정 파티션에 맵핑된다.

② 글로벌 파티션드 인덱스(Global Partitioned Index) : 테이블의 서로 다른 파티셔닝-키를 이용해 파티션된 테이블이나 파티셔닝되지 않은 테이블에 생성된 인덱스를 가리킨다. 파티셔닝되지 않은 테이블의 인덱스와 동일한 형태로 구성되며 이때 인덱스 구조는 파티셔닝되지 않는다.


<표 4>는 오라클과 SQL 서버의 파티셔닝 옵션을 비교한 것이다. 오라클이 지원하는 다양한 파티셔닝 옵션을 확인할 수 있으며 실제 기능에 있어서도 <표 5>처럼 차이가 있음을 알 수 있다.
병렬 실행과 클러스터링
SQL 작업은 병렬 실행을 통해 대량의 데이터가 수반되는 작업의 성능을 크게 개선할 수 있다. 특히 의사결정 시스템 또는 데이터 웨어하우스 등의 대규모 데이터베이스에서 데이터 집중적인 작업을 수행할 때 응답시간 개선에 도움이 된다. 예를 들어 오라클 사용자가 SQL문에 대한 병렬 처리를 수행하고자 한다면 오라클 서버는 사용자의 요청에 따라 가용 가능한 CPU 개수 만큼 병렬 처리를 수행한다. 4개의 CPU를 가진 서버에서의 병렬 처리를 수행한다면 3개의 CPU에서 실 SQL문에 대해 균등하게 작업을 할당하여 처리하고 나머지 1개의 CPU에서 이를 병합하는 작업을 수행한다. 오라클 데이터베이스는 파티셔닝된 데이터베이스 오브젝트 또는 파티셔닝되지 않은 데이터베이스 오브젝트에 액세스하는 과정에서 INSERT, UPDATE, DELETE, MERGE 등의 구문을 병렬적으로 실행한다. 반면 SQL 서버 2005의 INSERT, UPDATE, DELETE 구문은 순차적으로 실행된다.

클러스터는 사설 네트워크를 통해 연결된 다수의 독립적인 서버 또는 노드들이 마치 하나의 시스템인 것처럼 협력하여 동작하는 환경을 의미한다. 단일 노드 시스템이 갖는 확장성의 한계를 극복하고 대형 서버의 성능을 뛰어넘는 부하 처리를 가능케 한다. 오라클 RAC(Real Application Cluster)이 바로 이런 역할을 지원하는 솔루션으로 DBMS에 대한 요구사항이 증가함에 따라 단순히 노드를 추가함으로써 확장할 수 있는 것이 특징이다.

SQL 서버 2000은 제품문서에 명시된 것처럼 이러한 형태의 클러스터링을 지원하지 않는다. 이것은 SQL 서버 2005에서도 마찬가지인데 대신 ‘Federated Database Server’라는 새로운 방식을 지원한다. 두 접근법은 매우 큰 차이를 갖고 있어 애플리케이션의 성능과 확장성에 큰 영향을 미칠 수 있다.

Federated Database Server는 독립적인 데이터베이스들로 구성되며 공통 데이터 딕셔너리와 글로벌 인덱스를 지원하지 않는다. 이 때문에 성능과 확장성 면에서 많은 제약이 따른다. 또한 SQL 서버 2005의 접근법은 실제 애플리케이션 환경에서 적용이 매우 힘들다. 실제로 SAP, 피플소프트 등의 비즈니스 애플리케이션은 일반적으로 수천 개의 테이블로 구성되는데 SQL 서버 2005의 Feder ated Database Server를 구현하려면 모든 테이블을 파티셔닝하거나 각 노드로 복제해야 한다. 이처럼 거대한 애플리케이션을 포팅하는 것은 복잡할뿐만 아니라 많은 비용을 필요로 한다.
<표 4> 오라클 SQL 서버의 파티셔닝 옵션 비교
파티셔닝 옵션 오라클 데이터베이스 10g 릴리즈 2 SQL 서버 2005
Range 지원 지원
Hash 지원 지원하지 않음
List 지원 지원
Composite 지원(Range-hashRange-list) 지원하지 않음
Local Index 지원 지원
Global Index 지원 지원

<표 5> 오라클 SQL 서버의 최대 파티션 수
  오라클 데이터베이스 10g 릴리즈 2 SQL 서버 2005
테이블 당 최대 파티션 수 1024K(100만 개 이상) 1000

반면 오라클 RAC는 상대적으로 포괄적인 애플리케이션 호환성을 제공한다. 대표적인 기업용 애플리케이션들을 효과적으로 확장할 수 있으며 클러스터링 환경을 위한 커스터마이즈 작업도 필요치 않다. 즉 데이터 액세스 패턴이 데이터 블럭 핑을 감소 또는 어렵게 하더라도 애플리케이션을 분할할 필요가 없다. 단일 노드의 오라클 서버에서 확장성 있는 애플리케이션은 멀티 노드의 RAC 상에서도 확장성이 있다. 이 때문에 기존 애플리케이션을 재설계하거나 코드를 수정할 필요가 없으며 애플리케이션을 명시적으로 분할하거나 데이터를 파티셔닝할 필요도 없다.

또한 SQL 서버는 파티션을 실제로 소유한 노드만이 해당 파티션에 대한 읽기 작업을 수행할 수 있다. 프로세싱 파워는 테이블이 포함된 노드의 프로세싱 파워로 한정된다. 그러나 오라클 데이터베이스에서는 이러한 제약이 존재하지 않으며 심지어 전체 시스템의 프로세싱 파워, 다시 말해 모든 병렬 실행 서버의 리소스를 이용해 하나의 파티션에 대한 처리 작업을 수행하는 것도 가능하다.



오라클 데이터베이스 10g vs. IBM DB2 UDB
지금까지 최근에 새로운 버전을 발표한 MS SQL 서버 2005와 오라클 데이터베이스 10g에 대해서 비교해 보았다. 이번엔 오라클과 IBM의 DB2를 역시 성능 관점에서 비교해보자. 두 제품을 본격적으로 비교하기에 앞서 여기서 사용되는 DB2, DB2 UDB 등의 용어는 모두 DB2 UDB ESE(엔터프라이즈 서버 에디션) Version 8.2를 가리킨다. 또한 오라클, 오라클 데이터베이스, 오라클 데이터베이스 10g는 모두 오라클 데이터베이스의 최신 버전인 오라클 데이터베이스 10g 엔터프라이즈 에디션 릴리즈 2를 의미한다.
동시성 모델
비교 항목은 역시 앞서 진행했던 것과 동일하다. 먼저 동시성 모델을 보면 오라클 데이터베이스와 IBM DB2는 동시성 컨트롤의 구현 방식에서 <표 6>과 같은 차이를 보인다. 오라클의 경우 쿼리와 업데이트가 동시에 발생하는 혼합형 워크로드 환경을 지원하며 쓰기 작업이 읽기 작업을 차단하거나 읽기 작업이 쓰기 작업을 차단하는 상황이 발생하지 않는다. 반면 DB2는 사용자가 정확성(accu racy)과 동시성(concurrency)의 두 가지 중 하나를 양자택일할 수밖에 없다. 즉 읽기 일관성을 보장하기 위해 쓰기 작업을 블로킹하거나 쓰기 작업을 차단하지 않는 대신 더티 리드(dirty read)로 인한 부정확한 결과를 감수해야 한다. 여기서 더티 리더란 언커밋 리더라고도 한다. 사용자가 변경시키고 있는 commit되지 않은 데이터를 다른 사용자가 읽는 현상을 말한다. 예를 들어서 A라는 사용자가 공유되어 있는 문서파일을 저장하지 않고 작성 중에 B 사용자가 이를 열어서 보는 현상을 들 수 있다.

오라클의 기본적인 아키텍처는 대용량 트랜잭션을 고려해 설계돼 있다. 이는 오라클이 특허를 보유한 논-에스컬레이팅 로우-레벨 락킹(non-escalating row-level locking) 기능(row에 대한 잠금을 가지는 lock이 이 잠금의 개수를 줄이기 위해서 상위 테이블 lock 등으로 확대시키지 않는 현상) 지원이 있기에 가능한 것인데, 애플리케이션에 연결되는 사용자의 수가 늘어나고 처리해야 하는 트랜잭션의 양이 증가해도 오라클 데이터베이스가 일관된 성능을 유지할 수 있는 것도 이 때문이다. Winter Corporation의 조사 결과 전세계적으로 가장 규모가 큰 상위 10개 유닉스 데이터베이스가 모두 오라클 기반으로 운영되고 있는 것 역시 효율적인 동시성 모델에 기인한 바가 크다.

DB2의 경우 락 정보의 추적을 위해 사용되는 메모리 구조의 용량이 제한되어 있기 때문에 트랜잭션 규모가 증가할 경우 리소스 사용량을 줄이기 위한 방편으로 로우 락(row lock)을 테이블 락(table lock)으로 에스컬레이션한다. 따라서 불필요한 경합이 발생하고 처리 성능의 저하가 일어날 수 있다.

오라클과 DB2 데이터베이스의 구현 방식은 멀티유저 환경에서 일반적으로 발생하는 다음과 같은 문제들을 방지하는 메커니즘에서도 큰 차이를 보인다. 참고로 여기서 non-repeatable read는 해당 트랜잭션 중 바로 전에 읽은 데이터가 다시 읽고 난 후 변경된 상태로, 첫 읽기 후 해당 데이터가 다른 트랜잭션에 의해 커밋된 상태를 의미한다. 또한 Phantom Read는 해당 트랜잭션 중 조건을 만족하는 튜플들을 리턴하는 쿼리를 재실행한 후 변경된 튜플들이 리턴될 때를 가리킨다.

◆ 트랜잭션이 커밋되지 않은 변경사항을 읽는 시점에 더티 리드(dirty read) 또는 언커밋트 리드(uncommited read)가 발생한다.

◆ 트랜잭션이 방금 전에 읽어 들인 데이터를 다시 읽는 과정에서 해당 데이터가 다른 커밋된 트랜잭션에 의해 수정되거나 삭제됐음을 확인했을 때 non-repeatable read가 발생한다.

◆ 트랜잭션이 검색 조건을 만족하는 일련의 로우를 반환하는 쿼리를 2차례 반복 실행하고 다른 애플리케이션에 의한 INSERT 작업으로 인해 두 번째 쿼리에서 (첫 번째 쿼리에서는 반환되지 않은) 추가적인 로우가 반환되었을 때 phantom read가 발생한다.
<표 6> 오라클과 DB2의 동시성 모델 기능 차이
오라클 데이터베이스 10g DB2 UDB
멀티-버전 읽기 일관성
(multi-version read consistency)		 지원되지 않음
리드 락이 사용되지 않음 더티 리드를 방지하려면 리드 락이 필요
더티 리드를 사용하지 않음 리드 락을 사용하지 않는 경우 더티 리드 발생
로우-레벨 락(low-level locking)이 에스컬레이션 되지 않음 락이 에스컬레이션 발생
읽기 작업은 쓰기 작업을 블로킹하지 않음 읽기 작업이 쓰기 작업을 블로킹
쓰기 작업은 읽기 작업을 블로킹하지 않음 쓰기 작업이 읽기 작업을 블로킹
높은 부하에서 데드락이 전혀 발생하지 않음 높은 부하에서 데드락으로 인한 심각한 문제가 발생할 수 있음

오라클은 트랜잭션에 업데이트가 발생할 경우 기존 데이터는 데이터베이스의 언두 레코드에 저장된다. 데이터베이스가 읽기 작업을 수행하는 동안 데이터 변경을 방지하기 위해 또는 쿼리가 커밋되지 않은 변경 데이터를 읽는 것을 방지하기 위해 오라클은 락을 사용하는 대신 언두 레코드에 저장된 기존 정보를 이용하여 테이블 데이터에 대한 읽기 일관성을 확보한다. 반면 DB2는 멀티-버전 읽기 일관성을 제공하지 않는다. 대신 다양한 레벨의 격리 모델을 통해 읽기 잠금(read lock)을 사용하거나 더티 리드를 허용하는 방법을 사용한다. 읽기 잠금은 동시 수행 중인 트랜잭션에 의해 변경 중인 데이터를 읽을 수 없도록 차단하기 때문에 다수의 읽기/쓰기 작업이 동시에 발생하는 환경에서 서비스 동시 요청을 처리하는 능력이 제한될 수밖에 없다.

오라클이 지원하는 로우-레벨 락은 정교한 수준의 락 관리 방식으로 높은 데이터 동시성을 제공한다. 로우-레벨 락은 테이블의 특정 로우에 대한 업데이트 과정에서 해당 로우만을 잠금 처리하며 다른 모든 로우는 동시 작업이 가능하다. 오라클은 디폴트 동시성 모델로 로우-레벨 락을 사용하며 락 정보를 실제 로우 내부에 저장하고 이를 통해 데이터베이스의 로우 또는 인덱스 엔트리 숫자만큼 로우-레벨 락을 관리할 수 있게 해 데이터 동시성을 높였다.

DB2 역시 로우-레벨 락을 디폴트 동시성 모델로 지원한다. 그러나 DB2의 이전 버전에서는 로우-레벨 락이 기본 잠금 모드가 아니었고 후에 로우-레벨 락을 추가적으로 지원하는 과정에서 ‘락 리스트(lock list)’라는 별도의 메모리 구조가 필요하게 됐다. 이 메모리는 제한된 용량을 가지고 있으며 이 때문에 데이터베이스에서 지원할 수 있는 최대 락의 숫자 또한 제약된다. 이 때문에 애플리케이션과 트랜잭션 볼륨에 접근하는 사용자의 수가 증가하면 DB2는 메모리 절약을 위해 로우-레벨 락을 테이블 락(table lock)으로 에스컬레이션한다. 이는 결국 데이터에 동시 접근할 수 있는 사용자의 수가 줄어들게 됨을 의미하는데 그만큼 대기 시간이 길어질 가능성이 있다.
<표 7> 오라클과 DB2의 인덱싱 기능 비교
기능 오라클 DB2
Stored Compressed Bitmap Indexes 지원 -
비트맵 조인 인덱스 지원 -
다이나믹 비트맵 인덱스 지원 지원
IOT 지원 -
리버스 키 인덱스 지원 -
기능 기반 인덱스 지원 부분적으로 지원

실제로 DB2 매거진의 한 기사(www.db2mag.com/db_area/ archives/1999/q2/99sp_yevich.shtml)는 ‘락 에스컬레이션은 ERP 환경에서 가장 심각한 성능 저하 요인의 하나로 꼽힌다’고 지적하고 락 에스컬레이션을 비활성화할 것을 권고한 바 있다(그러나 이러한 작업은 OS/390 플랫폼의 DB2에서만 가능하며 유닉스와 윈도우 기반 DB2에서는 비활성화가 불가능하다).



인덱싱
오라클과 DB2는 모두 고전적인 B-트리 인덱싱 메커니즘을 지원한다. 이미 살펴본 것처럼 오라클은 이 밖에도 스태틱 비트맵 인덱스와 비트맵 조인 인덱스를 지원할 뿐만 아니라 여러 개의 파티션에 대한 글로벌 인덱스를 지원해 OLTP 환경의 파티셔닝된 테이블에서 유용하다. 반면 DB2는 B-트리 인덱스와 다이내믹 비트맵 인덱스 만을 지원한다. 두 제품의 인덱싱 기능 차이는 <표 7>과 같다.

오라클의 경우 인덱스는 대상 테이블의 하나 또는 그 이상의 컬럼에 대한 함수로 생성될 수 있다. 함수 기반 인덱스(function-based index)는 함수 또는 표현식의 결과를 미리 계산해 인덱스에 저장하며 B-트리 인덱스 또는 비트맵 인덱스로 생성할 수 있다. DB2의 generated column 기능의 경우 표현식을 기반으로 생성된 컬럼의 값을 유도한 결과가 인덱스에 저장된다. 그러나 유도된 값을 테이블 형태로 저장한다는 점에서 오라클의 함수 기반 인덱스만큼 효율적이지 못하다.

IOT는 테이블 로우를 프라이머리 키 인덱스에 저장하며 프라이머리 키에 대한 조건과 영역 검색을 수반하는 쿼리에서 높은 성능을 나타낸다. IOT를 이용하는 경우 중요 컬럼이 테이블과 프라이머리 키 인덱스에 이중으로 저장되지 않으므로 공간을 절약할 수 있고 일반적인 테이블에서 로우의 주소를 저장하고 인덱스 값과 로우 데이터에 대한 링크를 제공하는 용도로 사용되는 RowID를 위해 추가적인 공간을 할당할 필요도 없다. IOT는 기본키 인덱스 구조로 모든 데이터를 저장하므로 기본키 인덱스 스캔 만으로 모든 작업을 종료할 수 있다. 일반 테이블은 기본키를 사용하여 인덱스 스캔하여 해당 테이블로 랜덤 액세스를 수행하므로 IOT보다 성능 저하가 발생할 수 있다. 따라서 빠른 조회를 요구하는 OLTP 업무에서 IOT는 클러스터 테이블과 더불어 그 성능을 발휘한다.

IOT는 RowID pseudo-column, LOB, 2차 인덱스, range/hash 파티셔닝, 오브젝트 지원, 병렬 쿼리 등 일반적인 테이블에서 지원되는 모든 기능을 지원한다. IOT에 비트맵 인덱스를 생성하고 데이터 웨어하우징 환경의 팩트 테이블로 활용하는 것도 가능한데 이러한 기능은 오라클 데이터베이스 10g에서만 제공되는 기능이다.
파티셔닝
이미 살펴본 것처럼 파티셔닝은 대규모 데이터베이스를 관리하기 쉬운 단위로 분할하기 위해 사용되며 파티션 프루닝(partition pruning)이라 불리는 테크닉을 활용하는 경우 성능의 개선을 기대할 수 있다. 파티션 프루닝은 필요한 데이터가 존재하는 파티션에 대해서만 작업이 실행되도록 제한하는 기능을 말한다. 작업 과정에서 필요한 데이터를 포함하지 않은 파티션들은 검색 과정에서 제외된다. 이를 통해 디스크로부터 인출되는 데이터의 양과 프로세싱 시간을 크게 줄이고 쿼리 성능과 리소스 사용률을 개선할 수 있다.

파티셔닝 환경에서 partition-wise join 테크닉을 사용해 멀티-테이블 조인 작업의 성능을 개선할 수도 있다. 이것은 두 개의 테이블이 함께 조인되고 조인 키(join key)를 기준으로 두 테이블이 파티셔닝된 경우에 적용되는데 대규모 조인 작업을 각 파티션 별로 작은 크기의 조인 작업으로 분할하고 전체 조인 작업에 소요되는 시간을 단축하는 효과가 나타난다. 따라서 순차/병렬 작업 환경에서 성능 개선 효과를 기대할 수 있다. 마지막으로 파티셔닝 환경에서 DML 작업의 병렬 실행 기능을 활성화함으로써 데이터 집중적인 작업이 수반되는 대규모 의사결정 시스템이나 데이터 웨어하우스 환경의 응답시간을 단축할 수 있다.

이미 오라클에서 제공하는 파티셔닝은 살펴보았으므로 여기서는 DB2 UDB의 파티셔닝을 중점적으로 살펴보자. <표 8>은 두 제품의 파티셔닝 옵션을 비교한 것이다. DB2는 해시 파티셔닝만을 지원(ftp.software.ibm.com/ps/products/db2/info/vr8/pdf/letter/ db2s2e80.pdf)하기 때문에 오라클과 차이가 있음을 알 수 있다. 레인지 파티셔닝 또는 리스트 파티셔닝과 달리 해시 파티셔닝은 일부 쿼리에 대해 파티션 프루닝을 지원하지 않는다. 따라서 데이터 웨어하우스를 최신 상태로 유지하려면 새로운 데이터를 로드하고 오래된 데이터를 삭제하는 작업을 지속적으로 반복해야 하는 번거로움이 있다. 해시 파티셔닝이 적용된 DB2 환경에서는 전체 파티션에 대한 재분배 작업이 불가피하며 결과적으로 새로운 데이터를 로드하는데 더 많은 시간이 소요되고 데이터 재분배 과정의 테이블 잠금으로 인해 가용성이 저하될 가능성이 있다.

또한 DB2는 테이블과 인덱스 간의 ‘equi-partitioning’(인덱스가 같은 칼럼에 대해 같은 값으로 파티션되어 있는 것)을 요구하며 따라서 글로벌 인덱스의 생성이 불가능하다. 이러한 제약은 개별 레코드에 대한 효율적인 액세스를 위해 글로벌 인덱스를 빈번하게 활용해야 하는 OLTP 환경에서 심각한 문제를 야기할 가능성이 있다. 이처럼 DB2 기반의 애플리케이션 설계 과정에서는 파티셔닝 환경의 유연한 인덱스 구성이 어렵다(www-128.ibm.com/ developer works/db2/library/techarticle/dm-0405wilkins/ index.html).



클러스터
RAC은 오라클 데이터베이스 10g에 포함된 하드웨어 클러스터 지원 옵션이다. 이는 공유 디스크(shared disk) 방식을 채택하고 있는데 공유 디스크 아키텍처에서 데이터베이스 파일은 다수의 노드에 의해 논리적으로 공유되며 각 시스템의 인스턴스는 모든 데이터에 대한 접근이 허용된다. RAC 역시 오라클이 특허를 보유한 캐시 퓨전(Cache Fusion) 아키텍처를 기반으로 하고 있다. 캐시 퓨전은 상호 연결된 캐시를 이용해 OLTP, DSS, 패키지 애플리케이션 등 다양한 애플리케이션에 대한 데이터베이스 클러스터 기능을 지원한다. 사용자의 쿼리는 로컬 캐시 또는 다른 노드의 원격 캐시를 통해서도 처리할 수 있으며 업데이트 작업 과정에서 로컬 노드는 다른 클러스터 노드의 데이터베이스 캐시로부터 필요한 블럭을 직접 가져오므로 동기화를 위한 별도의 읽기/쓰기 작업을 수행할 필요가 없는 점도 특징이다.

반면 DB2는 Shared-Nothing 접근 방식을 사용한다. 이 아키텍처에서는 데이터베이스 파일이 파티셔닝을 통해 클러스터를 구성하는 각 노드의 인스턴스에 분산된 형태로 존재한다. 각 인스턴스 또는 노드는 일정 범위의 데이터만을 보유하며 해당 데이터를 배타적으로 점유하고 있다. 즉 Shared-Nothing 시스템은 파티셔닝을 통해 워크로드를 다수의 노드에 분산하는 효과를 제공하며 이것은 노드의 데이터 소유권이 자주 변경되지 않는 경우에 효과적이다(단 데이터베이스 재편성, 노드 장애시 데이터 소유권이 변경될 수 있다).

표면적으로는 Shared-Nothing 시스템이 분산형 데이터베이스와 유사하게 보인다. 그러나 Shared-Nothing 데이터베이스는 하나의 데이터 딕셔너리를 가진 하나의 물리적 데이터베이스라는 점에서 분산형 데이터베이스와는 근본적인 차이가 있다.

이미 살펴본 것처럼 오라클 데이터베이스 10g RAC은 패키지 애플리케이션을 별도의 수정 과정없이 단일 시스템에서 클러스터 구성으로 마이그레이션할 수 있다. 반면 DB2 데이터베이스를 DB2 UDB EEE로 마이그레이션하려면 데이터 파티셔닝 작업과 추가적인 개발 작업이 불가피하다. <표 9>는 두 제품의 아키텍처가 갖는 성능과 확장성 면에서의 차이를 비교한 것이다.
<표 7> 오라클과 DB2의 인덱싱 기능 비교
기능 오라클 DB2
레이지 파티셔닝 지원 -
리스트 파티셔닝 지원 -
해시 파티셔닝 지원 지원
컴포짓 파티셔닝 지원 -
로컬 인덱스 지원 지원
글로벌 파티션드 인덱스 지원 -
그로벌 넌 파티션드 인덱스 지원 -

오라클 데이터베이스 10g RAC은 트랜잭션을 실행 중인 노드에 로그를 기록하는 작업이 완료되는 즉시 커밋을 수행할 수 있다. 트랜잭션이 클러스터의 다른 노드에 의해 수정된 데이터를 접근해야 하는 경우에도 추가적인 디스크 I/O를 수반하지 않고 고속 연결을 통해 블럭을 전송한다. 로그의 쓰기 작업이 완료되지 않은 상태에서도 블럭을 전송할 수 있어 SAP SD 벤치마크처럼 집중적인 INSERT 작업이 수반되는 벤치마크 환경에서도 로그 쓰기 작업으로 인해 전송이 지연되는 경우가 5% 이하인 것으로 나타났다.

반면 DB2 시스템은 하나의 트랜잭션을 통해 두 개 이상의 파티션의 데이터가 변경된 경우 트랜잭션의 정합성을 보장하기 위해 two-phase 커밋 프로토콜(커밋 시점의 두 단계 커밋의 첫 번째 시점에 준비 레코드를 기록해야하며, 첫번째 단계를 완료해야 두 번째 단계를 진행하는 것)이 반드시 수행돼야 한다. DB2 트랜잭션은 커밋 시점에 쓰기 작업을 수행할 레코드를 미리 준비한 후 two-phase commit의 첫번째 단계를 완료한 이후에 두 번째 단계를 수행하며 이는 OLTP 애플리케이션의 응답시간을 저하시키는 결과를 초래할 수 있다.

RAC은 GCS(global cache service, 데이터가 필요하고 캐시에 여유 공간이 있는 RAC이 수정된 데이터를 독립적으로 캐시할 수 있게 해주는 서비스. 이 데이터에 대한 추가 액세스는 메인 메모리 속도로 수행할 수 있다)를 사용해 캐시 일관성을 보장한다. GCS는 RAC가 간헐적으로 변경되는 데이터를 여러 노드의 캐시에 동시에 저장하고 캐시를 위한 공간을 확보하기 때문에 이후 데이터에 대한 접근이 발생하는 경우 메인 메모리의 전송 속도에 준하는 응답시간을 나타낸다.

반면 DB2는 마지막 액세스가 발생한 이후 데이터가 변경되지 않은 경우에도 노드 간의 통신을 통해 다른 파티션의 데이터에 대한 접근을 처리한다. DB2는 인덱스와 테이블을 동일하게 파티셔닝하기 때문에 쿼리를 수행하는 과정에서 다수의 파티션에 대한 검색 작업이 불가피하다. 예를 들어 직원 테이블이 직원 번호를 기준으로 파티셔닝돼 있고 직원 이름을 기준으로 한 인덱스가 생성되어 있다면 직원 이름을 조회하는 쿼리를 수행하려면 모든 파티션을 동시에 검색해야 한다. 직원의 이름을 기준으로 한 조회 작업은 파티션의 수가 많으면 많을수록 높은 부하를 수반하게 된다.

또한 DB2 시스템은 특정 노드에 대한 부하 집중의 위험도가 높아 데이터가 전체 파티션에 균등하게 분산되어 있지 않을 수 있다. 예를 들어 금융계의 최근 거래내역의 빈번한 조회라든지 특정 데이터 영역대의 과도한 조회 업무에 따라 특정 파티션의 데이터가 집중적으로 조회될 가능성이 있다.
반면 RAC 환경에서는 개별 노드가 데이터를 점유하지 않으며 모든 노드가 동일한 데이터에 접근하므로 부하 분산의 불균형이 발생하지 않는다. 트랜잭션을 클러스터의 특정 노드군으로 라우팅함으로써 RAC의 성능을 더 높일 수 있으며 이를 통해 데이터 친화도(data affinity, 다량의 서로 다른 데이터에서 서로의 유사한 패턴)를 높이고 노드 간의 통신을 줄일 수 있다. 라우팅은 오라클 넷의 서비스 네임을 통해 간단하게 설정할 수 있다. 반면 DB2의 경우 트랜잭션에 의해 접근되는 데이터의 위치 정보가 별도로 필요하므로 트랜잭션의 라우팅이 훨씬 까다롭다. 또 데이터의 재분배 작업을 수행하지 않은 상태에서 다수의 논리적 노드에 트랜잭션을 수행해야 하므로 성능 저하 현상이 발생할 수 있고 부하의 변화에 유연하게 대처하지 못할 가능성이 높다.

<화면 1> ADDM을 통한 자가 튜닝 보고서

<화면 2> 튜닝 어드바이스
<표 9> 성능과 확장성 측면에서 오라클과 DB2 비교
오라클과 데이터베이스 10g RAC DB2 EEE
two-plase 커밋 불필요 two-plase 커밋 필요
데이터는 다수 노드의 캐시에 저장됨 다른 파티션에 접근하려는 경우 IPC 필요
데이터를 단 한 차례만 조회 다수의 파티션에 대해 데이터 조회
균등한 부하 분배 부하가 특정 노드에 집중될 가능성 높임

<표 10> 성능 관리 관련 기능 비교
  오라클 데이터베이스 10g DB2
성능 관련 관리 기능 - Automatic Workload Repository
- Automatic Database Diagnostic Monitor
- Automatic SQL Tuning		 유사한 기능이 존재하지 않음

RAC은 애플리케이션의 바인드 값(bind value)를 기반으로 미들웨어가 요청을 라우팅하도록 구성되기도 한다. 예를 들어 사용자의 로그인 정보를 기반으로 메일 서버가 이메일 연결을 라우팅하도록 설정하는 식이다. 최적의 성능을 위해서는 레인지나 리스트 파티셔닝을 이용해 바인드 값을 기준으로 한 파티셔닝을 수행하는 것이다. 반면 DB2는 데이터의 위치를 사용자가 직접 결정할 수 없으므로 이와 같은 방식을 구현하기 힘들다.



셀프 튜닝과 성능 관련 기능
마지막으로 오라클과 DB2는 진단 및 셀프-튜닝 기능 측면에서도 차이가 있다. 오라클 데이터베이스 10g는 성능 모니터링 작업을 단순화하고 성능 문제의 진단과 해결을 자동화하기 위한 다양한 툴을 기본으로 지원해 이를 통해 시스템 리소스의 사용 상황에 따라 데이터 매개변수를 자동으로 조정한다. 관리자가 만일 어떠한 원인으로 일어날 수 있는지에 대한 시나리오를 시뮬레이션할 수 있는 인텔리전트 어드바이스 기능도 제공하는데 index advisory, summary advisory, memory advisory, MTTR advisory, table/index usage advisory 등이 대표적이다.

DB2 역시 일부 셀프-튜닝 기능과 어드바이스 기능을 제공하고 있지만 여전히 관리자에게 상당한 수준의 데이터베이스 지식을 요구한다. 예를 들어 DB2의 Control Center는 실시간 모니터링에 필요한 다양한 성능지표를 제공하지만 시스템의 전반적인 상태를 확인하기 위해 어떤 성능지표를 참고해야 하는지에 대한 정보는 알려주지 않는다. 알 수 없는 이유로 시스템의 성능이 저하된 경우 DB2 관리자는 전적으로 자신의 개인적인 지식에 의존해서 문제 해결 작업을 수행해야 하는 것이다. 반면 오라클은 어드바이스 기능을 이용하여 관리자에 대한 가이드를 제공하고, 도움말과 드릴다운을 통해 문제의 근본원인을 분석할 수 있도록 지원한다.

<표 10>은 오라클이 데이터베이스 튜닝 관련 정보를 제공하고 튜닝 프로세스 자동화를 위해 제공하는 기능을 요약한 것이다. AWR (Automatic Workload Repository)은 데이터베이스 작업에 관련한 성능 데이터와 통계를 저장하기 위해 활용되는 공간이다. 오라클 데이터베이스는 중요한 통계 정보와 워크로드 정보의 스냅 샷을 일정 주기로 생성하고 이를 AWR에 저장한다. 수집/처리된 통계정보는 오라클 데이터베이스 10g에 의해 사전 예방적/사후 대응적 모니터링을 위한 진단 데이터로 활용된다. 그러나 DB2는 이와 유사한 기능을 제공하지 않는다.

ADDM(Automatic Database Diagnostic Monitor)은 시스템 상태를 확인하기 위해 AWR에 캡처된 데이터를 분석하는 데이터베이스 자가진단 엔진이다. ADDM은 시스템의 어느 부분이 가장 많은 ‘DB time’을 사용하는지 분석하고 해결 방안을 제안하거나 SQL Access Advisor와 같은 다른 솔루션을 제안함으로써 DB time을 최소화하는 것을 기본 목적으로 하고 있다. ADDM은 표면적인 현상에 초점을 맞추는 대신 드릴다운을 통해 문제의 근본 원인을 확인하고 문제로 인한 시스템의 전반적인 영향에 대해 리포트를 제공한다. 또한 제시된 해결방안이 제공하는 기대효과를 정량화하고 성능에 문제가 없는 또는 튜닝이 불필요한 시스템 영역에 대한 보고서를 <화면 1>처럼 제공한다.

오라클 데이터베이스 10g는 SQL 구문의 튜닝 과정을 상당 부분 자동화했다. Automatic SQL Tuning은 Automatic Tuning Optimizer를 기반으로 구현된 기능으로, Oracle Query Optimizer는 자동 튜닝 모드에서 튜닝 프로세스에 필요한 조사와 검증 작업에 더 많은 시간을 할애한다. 이와 같은 추가적인 시간을 통해 다이내믹 샘플링, 부분 실행(partial execution) 등 일반 운영 모드에서는 시간적인 제약으로 인해 적용될 수 없었던 테크닉이 사용되며 비용, 선택성(selectivity)과 확률에 대한 검증 작업을 수행하는 것이 가능하다.

Automatic Tuning Optimizer에 의해 얻어진 결론은 SQL Tuning Advisor를 통해 튜닝 어드바이스의 형태로 사용자에게 전달된다. 어드바이스는 하나 또는 그 이상의 권고사항으로 구성되며 각 권고사항 별로 근거와 예상 효과가 명시된다. 어드바이스에는 새로운 인덱스의 추가, SQL 구문의 재작성, 또는 SQL 프로파일의 구현과 같은 내용이 포함될 수 있으며 사용자는 어드바이스의 이행 여부를 단순히 선택해 SQL 구문의 튜닝 과정을 완료할 수 있다. 반면 DB2는 SQL 관련 문제를 진단하기 위한 쉽고 편리한 방법을 제공하지 않으며 (오직 트레이스 기능만 제공) SQL 구문의 재작성을 통해 튜닝을 수행하는 툴 또한 제공하지 않는다.



오라클은 어렵다?
오라클 데이터베이스는 다양한 업계 표준/ISV 벤치마크를 통해 그 성능을 인정받고 있으며 이것은 가장 최근에 출시된 오라클 데이터베이스 10g 역시 예외는 아니다. 필자 역시 기존 버전 제품에서의 변화보다 더 많은 변화를 몸소 느끼고 있다.

이번 글에서는 다른 DBMS와 차이점을 중심으로 살펴보았지만 오라클 역시 타 DBMS에서 좋은 점들을 벤치마킹하기 위해 노력하고 있고 실례로 기존 버전에서 쉽게 손댈 수 없는 SQL 튜닝, 메모리 튜닝 등 자동화된 관리 기능은 초보자들도 쉽게 다룰 수 있도록 배려한 것으로 볼 수 있다. 즉 ‘오라클은 어렵다’는 등식도 점점 깨져가고 있는 것이다. 현재 국내에서 가장 널리 사용되고 있는 RDBMS인 오라클의 진화를 필자는 흥미진진한 마음으로 지켜보고 있다.



제공 : DB포탈사이트 DBguide.net

반응형
저작자표시 비영리

'DBMS' 카테고리의 다른 글

오라클 티베로 컬럼갯수 제한  (0) 2018.07.18
Oracle 사용자를 위한 DB2 Conversion 프로젝트, Part 4: DB2 애플리케이션  (0) 2010.08.09
오라클 자료형과 MSSQL 자료형  (0) 2009.10.07
플랫폼 다변화를 이끄는 오픈소스 오픈소스 DBMS 라이선스의 이해  (0) 2009.07.16
Posted by [PineTree]
ORACLE/SQL2009. 8. 21. 10:34

Oracle 널값(null)에 대하여 정리

반응형

1. NULL값 정의

 

RDBMS에서 NULL은 0 이나 공백이 아닌 값을 알수가 없다의 의미입니다.

이말은 값이 없다 입니다. 이는 Oracle 상에서 수치를 계산할때 문제가 됩니다.

null이 포함된 수식 계산에서는 무조건 null이 출려되어 잘못된 결과가 나오기 때문입니다.

특히 수치계산일때는 테이블 생성시 not null로 해주거나 nvl()함수로 제대로 치환해줘야

합니다.

 

2. NULL값 잘못된 처리

 

숫자의 경우

 

create table jun1(

a number,

b number);

insert into jun1 values(null,12);

select a+b from jun1;

 

라고 한다면 12가 나올것 같지만 null값이 포함된 계산식은 무조건 null이 나옵니다.

그래서 nvl()를 사용하거나 not null을 사용하는게 좋습니다.

 

문자열의 경우

create table jun2(

a varchar2(10),

b varchar2(10));

insert into jun2 values(null,'11');

select concat(a,b) from jun2;

 

라고 한다면  11이 나옵니다. mysql에서는 문자열도 null이지만 oracle에서는

문자열은 null이 들어가도 null로 출력되지 않고 그대로 연결됩니다.

 

''(빈공백)을 null로 인식하는 오라클 테스트 예제

 

create table test

(

 a varchar2(10),

 b varchar2(10)

)

 

insert into test values ('',null);

insert into test values ('test','test');

commit;

 

select count(*) from test where a = '';
--0개출력

select count(*) from test where a is null;
--1개출력

select count(*) from test where b = '';
--0개출력

select count(*) from test where b is null;

--1개출력

 

※ 오라클에서는 ''(빈공백)을 NULL값으로 인식합니다.

※ 오라클에서는 '' 을 null로 인식하며 '' 는 = '' 가 아닌 IS NULL 로 조회해야 검색가능하다.

※ 오라클에서는 NULL값이나 ''(빈공백)값은 널연산자외에 연산자로는 조회 불가능합니다.

이말은 널연산자외에 연산자에서는 널값을 조회대상에서 제외한다는 애기입니다.

 

3.많은 양의 null처리

 

상당히 많은 양의 레코드에 null이 있다면 계산하는데 문제가 많다.

update table_name set num=0 where num is null; -- 정수의 경우

update table_name set num=' ' where num is null; -- 문자열의 경우

와 같이 null값을 지정된 숫자로 일괄로 바꾸어준다.

 

table을 만들시에 모든컬럼에 not null 제약조건을 주는게 좋습니다.

 

※nvl()함수를 이용한다.

null이면 지정된 값으로 출력합니다. 실제 데이타는 바뀌지 않으며 단지 출력용입니다.

 

select nvl(comm,0) from emp;

--comm컬럼의 값이 null이면 0을 출력하고 값이 있다면 해당 값을 출력한다.

select nvl(hiredate,'01-JAN-97') from emp;--hiredate컬럼의 값이 null이면 01-JAN-97을 출력하고 값이 있다면 해당 값을 출력한다.

select nvl(job,'not') from emp;

--job컬럼의 값이 null이면 job을 출력하고 값이 있다면 해당 값을 출력한다.

select ename,sal,comm,(sal*12)+nvl(comm,0) from emp;

--수치계산에서는 null이 포함되면 결과는 null이지만 nvl()로 처리되어 모두 계산되어진다.

select ename,sal,comm,(sal*12)+comm from emp;

--수치계산에서는 null이 포함되면 결과는 null이다 그래서 comm에 null이 포함된 레코드는

--결과값이 null로 나옵니다.

 

4.mysql과 다른 oracle의 범위

 

mysql에서는 select * from table_name where name is null하면 실제 컬럼에 null이 들어가고 공백이나 실제로 값이 있는 컬럼은 빼고 검색하지만

oracle에서는 select * from table_name where name is null하면 실제컬럼에 공백이나 빈공간이 null로 인식되어 검색됩니다.

 

※name은 예를든 컬럼

mysql null범위

1.데이타값이 null인값 -> ''의 문자값은 = ''로 비교를 해야하고 name is null로 하면 안됩니다.

 

oracle null범위

1.데이타값이 빈공간이나('') 값  -> '' 의 문자값은 = ''로 비교가 안되고 name is null로 합니다.

 

5. 널값은 비교대상이 될수 없다.

 

SELECT '널값' test FROM dual WHERE '' <> '널값';

-- 아무것도 출력안됨

-- 오라클에서 ''은 null입니다. null은 비교 대상이 될수 없으므로 is not null 연산자를

-- 이용해서 비교해야 정상적으로 자료가 출력됩니다.

-- 한마디로 널값은 =, <> 등으로 비교할 수 없습니다.

 

SELECT '널값' test FROM dual WHERE nvl('','널값') <> '널값';

-- 널값

-- 널값을 nvl 함수로 치환후 비교하면 정상출력됨

 

SELECT '널값' test FROM dual WHERE '' is null;

-- 널값

-- is null 연산자를 이용해서 정상출력됨

반응형
저작자표시 비영리

'ORACLE > SQL' 카테고리의 다른 글

char 와 varchar 그리고 VARCHAR2 와 NVARCHAR2  (0) 2009.09.11
ROLLUP , CUBE , GROUPING  (0) 2009.09.02
SELECT문 및 연산자  (0) 2009.08.10
DBMS에 따른 날짜포맷 변환  (0) 2009.08.07
CUBE 함수  (0) 2009.07.08
Posted by [PineTree]
ORACLE/ORACLE TOOL2009. 8. 21. 09:45

Toad 에서 null 값 노란색으로 표시하기

반응형

출처 : http://applejara.tistory.com

가끔 보면 행이 null인지 아니면 공백인지 구분이 안될때가 있다. 오라클 사용자는 대부분 Toad같은 툴을 사용하기 때문에 Toad를 기준으로 null값을 확인하는 방법을 알아보자.

일단 기본적인 화면에선 null은 표시되지 않는다. 그럼 null값을 표시하는 설정을 확인해 보자. 위치는 view -> toad options -> datahttp://cfs.tistory.com/static/admin/editor/spacer.gif grids , visual 이다. 필자는 toad 9.6을 사용하므로 버젼에 따라 조금씩의 차이가 있을 수 있다.


최 하단에 null columns가 있는데 여기에 옵션을 선택할 수 있다. 필자는 노란색으로 표시하기로 했지만, null이란 문자로 출력하게 바꿀수도 있다.


설정 후 null값은 노란색 배경으로 출력됨을 확인할 수 있다.

반응형
저작자표시 비영리

'ORACLE > ORACLE TOOL' 카테고리의 다른 글

Orange-국내 기술로 개발된 오라클 개발 지원 및 튜닝 도구  (0) 2009.11.23
SQL * Plus 명령어 & 환경 시스템 변수  (0) 2009.09.04
Oracle DB로 보는 데이터베이스 인터페이스의 발전  (0) 2009.07.10
toad 에서 explain plan 보기  (1) 2009.03.27
SQL Developer 문서화와 모니터링, 그리고 관리  (0) 2008.11.11
Posted by [PineTree]
ORACLE/ADMIN2009. 8. 12. 20:54

Table생성 스크립트 파일 뽑아내기

반응형
Table생성 스크립트 파일 뽑아내기 

 

작성자 : 한준희

출처 : www.en-core.com 질문과 답변 게시판..




[질문]


현재 DB에 존재하는 Table에 대하여

Create Table .. Storage부분 포함하여

스크립파일로 뽑아낼수 있는 방법이 있나요?





[답변] 


방법은 있습니다.


일단 스텝을 알려드릴테니 한번 해보시길...

( 어제도 이 작업을 통해 스크립트를 뽑았는데..^^)


스크립팅할 유저명과 패스워드를 scott/tiger라 하겠습니다.




1) export를 할때 데이터는 만들지 않고 schema image만 뽑아냅니다.

  (만약 export를 받은 파일이 이미 있으시다면 1번 항목은 생략하셔도 됩니다.)

   

   exp scott/tiger file=exp.dmp compress=n rows=n





2) 1번 스텝과 같이 해서 성공한 export dump파일을 이용하여 create script를 만드는 방법입니다. 

   이 방법은 import라는 유틸리티를 사용하여 작업을 합니다.


   imp scott/tiger file=exp.dmp indexfile=create_table.sql full=y




   

3) 요렇게 하면 create_table.sql이라는게 생성됩니다.

   vi나 편집기로 여시면 REM이라는 코멘트로 앞부분이 막혀 있을 겁니다.

   이걸 모두 없애시면 그야말로 DBMS내에 있는 형태 그대로 만들어진 Table Create Scripts입니다.
반응형
저작자표시 비영리

'ORACLE > ADMIN' 카테고리의 다른 글

The National Character Set in Oracle 9i, 10g and 11g  (0) 2009.09.11
언두테이블스페이스(undo tablespace) 용량 증가로 UNDOTBS변경  (0) 2009.08.25
인덱스의 유효성 검사  (6) 2009.07.03
SPFILE 사용  (0) 2009.06.29
Oracle DBLink Script  (0) 2009.06.11
Posted by [PineTree]
ORACLE/SQL2009. 8. 10. 15:37

SELECT문 및 연산자

반응형


SELECT문은 데이터베이스로부터 저장되어 있는 데이터를 검색하는데 사용합니다.

[Syntax]


 · DISTINCT : 중복되는 행을 제거하는 옵션입니다.
 · *            :  테이블의 모든 column을 출력 합니다.
 · alias       :  해당 column에 대해서 다른 이름을 부여할 때 사용합니다.
 · table_name :  질의 대상 테이블명
 · WHERE    :   조건을 만족하는 행들만 검색
 · condition :  column, 표현식, 상수 및 비교 연산자
 · ORDER BY :   질의 결과 정렬을 위한 옵션(ASC:오름차순(Default),DESC내림차순)



 ☞ SQL문의 작성 방법

  - SQL 문장은 대소문자를 구별하지 않습니다.

  - SQL 문장은 한 줄 또는 여러 줄에 입력될 수 있습니다.

  - 일반적으로 키워드는 대문자로 입력합니다.
     다른 모든 단어, 즉 테이블 이름, 열 이름은 소문자로 입력합니다.(권장) 

  - 가장 최근의 명령어가 1개가 SQL buffer에 저장됩니다.

  - SQL문 마지막 절의 끝에 ";"를 기술하여 명령의 끝을 표시 합니다.
 

SQL>SELECT empno 사번, ename 성명
       FROM   emp
       WHERE  deptno = 10

      사번      성명
---------- ---------------
      7782      CLARK
      7839      KING
      7934      MILLER



empno와 ename 은 각각 사번과 성명이라는 컬럼 별칭(alias)으로 만들어 출력했습니다.
alias를 사용할 때 as라는 키워드를 사용해도 되고, 생략할수도 있습니다.


▒ WHERE절에 사용될 수 있는 SQL 연산자

 연산자

 설      명

 BETWEEN a AND b

 a와b사이의 데이터를 출력 합니다.(a, b값 포함)

 IN  (list)

 list의 값 중 어느 하나와 일치하는 데이터를 출력 합니다.

 LIKE

 문자 형태로 일치하는 데이터를 출력 합니다.(%, _사용)

 IS NULL

 NULL값을 가진 데이터를 출력 합니다.

 NOT BETWEEN a AND b

 a와b사이에 있지않은 데이터를 출력 합니다.(a, b값 포함하지 않음)

 NOT IN  (list)

 list의 값과 일치하지 않는 데이터를 출력 합니다.

 NOT LIKE

 문자 형태와 일치하지 않는 데이터를 출력 합니다.

 IS NOT NULL

 NULL값을 갖지 않는 데이터를 출력 합니다.



▣ IN, NOT IN 연산자


IN 연산자

SQL> SELECT empno, ename
         FROM  emp
         WHERE  empno IN (7900, 7934) ;

--> 사번이 7900, 7934번인 사원의 사번과 성명 출력

    EMPNO    ENAME
 --------- -------------
     7934      MILLER
     7900      JAMES

2 개의 행이 선택되었습니다.

 

NOT IN 연산자

SQL> SELECT empno, ename
         FROM  emp
         WHERE  empno NOT IN (7900, 7934);

--> 사번이 7900, 7934번이 아닌 사원의 사번과 성명 출력

     EMPNO ENAME
-------- --------------
    7369 SMITH
    7499 ALLEN
    7521 WARD
    7566 JONES 
    7654 MARTIN
    7698 BLAKE
    ............................
13 개의 행이 선택되었습니다.



BETWEEN연산자(AND를 이용해 두 조건을 결합한 검색과 같은 결과값을 보여줍니다.)

BETWEEN 연산자

SQL>  SELECT empno, ename
          FROM  emp
          WHERE  sal BETWEEN  3000 AND 5000 ;

--> 급여가 3000에서 5000사이인 사원만 보여줍니다.

     EMPNO ENAME
   ---------- ------
      7788 SCOTT
      7839 KING
      7902 FORD  
3 개의 행이 선택되었습니다.



LIKE 연산자

 - 검색 STRING 값에 대한 와일드 카드 검색을 위해서 LIKE연산자를 사용 합니다.
 - % :  여러개의 문자열을 나타내는 와일드 카드
 - _ : 단 하나의 문자를 나타내는 와일드 카드
 - ESCAPE : 와일드 카드 문자를 일반문자 처럼 사용하고 싶은 경우에 사용합니다.
   ☞ WHERE name LIKE ’%a\_y%’ ESCAPE ’\’ ;

구 분

설 명

LIKE ’A%’

컬럼이 ’A’로 시작하는 데이터들만 검색됩니다.

LIKE ’%A’

컬럼이 ’A’로 끝나는 테이터들만 검색됩니다.

LIKE ’%KIM%’

컬럼에 ’KIM’ 문자가 있는 데이터 들만 검색됩니다.

LIKE ’%K%I%’

컬럼에 ’K’ 문자와 ’I’문자가 있는 데이터 들만 검색됩니다.

LIKE ’_A%’

컬럼에 ’A’문자가 두 번째 위치한 데이터 들만 검색됩니다.


- LIKE 연산자는 대소문자를 구분합니다.
- Upper()함수를 이용해 대소문자 구분없이 출력할수 있습니다.


SQL>SELECT empno, ename
        FROM  emp
        WHERE  UPPER(ename) like ’%K%’;

EMPNO ENAME
------- -----------
   7698 BLAKE
   7782 CLARK
   7839 KING

’K’ 문자가 들어있는 사원 정보를 보여줍니다.
upper()라는 함수는 k가 들어가 있는 것도 대문자 ’K’로 인식하기 때문에 데이터들을 보여줍니다.



※ ’_’를 이용한 LIKE검색

SQL>SELECT empno, ename
        FROM  emp
        WHERE  UPPER(ename) like ’_I%’

  EMPNO ENAME
------- ----------
   7839 KING
   7934 MILLER

※ ’_’는 한 문자를 나타냅니다.
   ’I’ 문자가 두 번째 문자에 위치한 사원들의 정보를 보여줍니다.

 



ORDER BY (ASC[오름차순], DESC[내림차순])
  ORDER BY 절은 데이터의 정렬을 위해 사용합니다.  

SQL> SELECT empno, ename
         FROM  emp
         WHERE  deptno = 30
         ORDER BY ename ASC;

   EMPNO ENAME
-------- ---------
    7499 ALLEN
    7698 BLAKE
    7900 JAMES
    7654 MARTIN
    7844 TURNER
    7521 WARD

SQL> SELECT empno, ename
         FROM  emp
         WHERE  deptno = 30
         ORDER BY 2

위 두 개의 쿼리는 동일한 결과를 가져 옵니다.
 

  ================================================
    * 데이터베이스 정보공유 커뮤니티 oracleclub.com
    * 강좌 작성자 : 김정식 (oramaster _at_ naver.com)
  ================================================
반응형
저작자표시 비영리

'ORACLE > SQL' 카테고리의 다른 글

ROLLUP , CUBE , GROUPING  (0) 2009.09.02
Oracle 널값(null)에 대하여 정리  (0) 2009.08.21
DBMS에 따른 날짜포맷 변환  (0) 2009.08.07
CUBE 함수  (0) 2009.07.08
ROLLUP 함수  (0) 2009.07.08
Posted by [PineTree]
ORACLE/SQL2009. 8. 7. 10:46

DBMS에 따른 날짜포맷 변환

반응형

Oracle - MS SQL - DB2 UDB 의 서로 다른 날짜 형식을 맞추기위한 SQL문

DBMS 별 시간, 날짜 조회 쿼리

Oracle

select sysdate from dual; 날짜+시분초 까지 조회가능

select current_timestamp from dual;  날짜+밀리초+시간존 까지 조회

MS SQL

 

select getdate()    날짜 + 밀리초 단위까지 조회가능

 

DB2 UDB

select current timestamp from sysibm.sysdummy1  날짜+밀리초까지 조회 가능

select current date from sysibm.sysdummy1    날짜만 조회

select current time from sysibm.sysdummy1     밀리초 단위의 시간만 조회

 

DBMS 별 default date format

Oracle

YY/MM/DD  (한글)

DD-MON-YYYY  (영어)  

MS SQL

YYY/MM/DD HH:MI:SS   (한글)

MM-DD-YYYY HH:MI:SS   (영어)

DB2 UDB

YYYY-MM-DD-HH:MI:SS.MMMMMM (TIMESTAMP 타입)

YYYY-MM-DD (DATE 타입)

HH:MI:SS.MMMMMM (TIME 타입)

 

날짜 포맷 변환표

   

형식  

RDBMS

변환 문법

 

Oracle

TO_CHAR(date_exp, 'YYYY.MM.DD')

'YYYY.MM.DD'

MSSQL

CONVERT(VARCHAR, date_exp, 102)

 

DB2

REPLACE(CHAR(DATE(date_exp),ISO), '-', '.')

 

Oracle

TO_CHAR(date_exp, 'HH:MI:SS')

'HH:MI:SS'

MSSQL

CONVERT(VARCHAR, date_exp, 108)

 

DB2

CHAR(TIME(date_exp) , JIS )

 

Oracle

TO_CHAR(date_exp, 'YYYY/MM/DD')

'YYYY/MM/DD'

MSSQL

CONVERT(VARCHAR, date_exp, 111)

 

DB2

REPLACE(CHAR(DATE(date_exp), ISO), '-', '/')

 

Oracle

TO_CHAR(date_exp, 'YYYYMMDD')

'YYYYMMDD'

MSSQL

CONVERT(VARCHAR, date_exp, 112)

 

DB2

CHAR(DATE(date_exp))

 

Oracle

TO_CHAR(date_exp, 'HH24:MI:SS')

'HH24:MI:SS'

MSSQL

CONVERT(VARCHAR(8), date_exp, 114)

 

DB2

CHAR(TIME(date_exp) )

 

Oracle

TO_CHAR(date_exp, 'YYYY.MM.DD HH24:MI')

'YYYY.MM.DD HH24:MI'

MSSQL

CONVERT(VARCHAR, date_exp, 102) + ' ' + CONVERT(VARCHAR(5), date_exp, 114)

 

DB2

REPLACE(CHAR(DATE(date_exp), ISO), '-', '.') || CAST( TIME(date_exp) AS CHAR(5))

 

Oracle

TO_CHAR(date_exp, 'YYYY/MM/DD HH24:MI:SS')

'YYYY/MM/DD HH24:MI:SS'

MSSQL

CONVERT(VARCHAR, date_exp, 111) + ' ' + CONVERT(VARCHAR(8), date_exp, 114)

 

DB2

REPLACE(CHAR(DATE(date_exp), ISO), '-', '/') || CAST( TIME(date_exp))
반응형
저작자표시 비영리

'ORACLE > SQL' 카테고리의 다른 글

Oracle 널값(null)에 대하여 정리  (0) 2009.08.21
SELECT문 및 연산자  (0) 2009.08.10
CUBE 함수  (0) 2009.07.08
ROLLUP 함수  (0) 2009.07.08
Oracle sum() over() - 누적계산  (0) 2009.06.12
Posted by [PineTree]
HARDWARE/Network2009. 8. 6. 13:52

랜케이블(UTP케이블)의 종류와 그 제작 방법

반응형

 

 

 
네트워크 구성을 위해 사용하는 여러 가지 랜 케이블 중 가장 일반적인 UTP케이블에 대해 알아보겠습니다.

▶ UTP케이블이란?

UTP케이블은 Unshielded Twisted Pair의 약자로 내부 보호막이 없이 쌍으로 꼬여 있는 케이블을 말합니다.  보통 UTP는 2개씩 꼬여 진체로 총 4쌍, 8가닥이 들어 있습니다.  케이블의 끝은 전화선잭과 비슷하지만 약간 큰 RJ-45커넥터를 통해 랜카드나 허브로 연결이 됩니다.  총 8가닥의 케이블중 실제로 쓰여지는 것은 4가닥(1,2,3,6번케이블) 만이 스여집니다.  송신용2가닥, 수신용2가닥이지요.  

<UTP케이블>
 

▶ UTP케이블의 종류

UTP케이블은 케이블링 방법에 따라 Direct케이블과 Cross케이블이 있습니다.  다이렉트 케이블이란 말그대로

양 케이블 끝을 그대로 연결한 것으로 허브에서 PC로 연결될 때 쓰여지고, 반대로 크로스 케이블은

허브에서 허브, PC에서 PC로 연결할 때 쓰여지는 케이블입니다.

 

 

 

▶ UTP케이블의 제작 방법
1. 다음과 같은 재료와 공구를 준비합니다.
    (아래에 사용된 이미지는 웹상의 이미지를 내려받아 가공하여 제작하였습니다.)



RJ45와 보호부트
 

UTP케이블
 

스트리퍼
 

니퍼

UTP 툴 

UTP 테스터기
 

2. 크로스 케이블과 다이렉트 케이블 중 어떤 것을 만들지 결정하고 UTP케이블을 알맞은 길이로 자른 후 그림과 같이 피복을 벗겨냅니다.

3. 색상별로 꼬여있는 선을 풀어 놓습니다.

4. 풀은 선을 그림과 같이   (흰주, 주황, 흰녹, 파랑, 흰파, 녹, 흰갈, 갈색)의 순서대로 반듯하게 펴 놓습니다.
 다이렉트 케이블일 경우 다른 한쪽도 똑같은 방법으로 제작하면 되고, 크로스 케이블일 경우 다른 한쪽을 (흰녹, 녹, 흰주, 파랑, 흰파, 주황, 흰갈, 갈색)으로 제작합니다.

5. 펴놓은 선을 사진과 같이 모은 후 니퍼로 끝을 일직선으로 자릅니다.

6. RJ45잭의 평평한 부분을 위로 하여 사진과 같이 끝까지 힘을 주어 끼워 넣습니다. (끝 선이 맞지 않으면 불량 상태가 됨)

7. UTP 툴에 끼우고 꽉 눌러서 고정시킵니다.

8. 케이블이 잘 만들어 졌는지 테스터기로 확인해 봅니다.
 (위 준비된 Tester 형식인 경우 보편적으로 Tester의 중간포트인 568B 포트에 넣으면  1,2,3,4 번으로 램프가 점멸되며, Cross Cable인 경우 한쪽은 1,2,3,4 다른한쪽은 1,3,2,4로 점등됩니다.)

 
반응형
저작자표시 비영리

'HARDWARE > Network' 카테고리의 다른 글

UNICORN UA-1160K  (0) 2010.01.18
NAS ＆ SAN  (0) 2007.11.13
Catalyst 3500 Series 사용자 매뉴얼  (0) 2006.06.26
Posted by [PineTree]
ORACLE/INSTALL2009. 8. 4. 16:33

LINUX ORACLE 10G 패키지

반응형
(아래 설정은 최소값임으로 더 높게 설정되어 있다면 수정할 필요가 없습니다.)

- OS
  o RHEL AS/ES 3.0 (Update 4 or later) 2.4.21-27.EL or higher
  o RHEL AS/ES 4.0 2.6.9-5.0.5.EL or higher
  o RHEL AS/ES 5.0 or higher
  o SuSE SLES9 2.6.5-7.201 or higher

- OS Kernel
 
  SuSE SLES9:
    SEMMSL 250
    SEMMNS 32000
    SEMMNI 128
    SEMOPM 100
    SHMMAX RAM times 0.5
    SHMMNI 4096
    SHMALL = SHMMAX/pagesize (Note 301830.1)
    FILE-MAX 65536
    IP_LOCAL_PORT_RANGE 1024 65000
    RMEM_DEFAULT 1048576
    RMEM_MAX 1048576
    WMEM_DEFAULT 262144
    WMEM_MAX 262144
 
  Other Linux OS:
    SEMMSL 250
    SEMMNS 32000
    SEMMNI 128
    SEMOPM 100
    SHMMAX RAM times 0.5
    SHMMNI 4096
    SHMALL = SHMMAX/pagesize (Note 301830.1)
    FILE-MAX 65536
    IP_LOCAL_PORT_RANGE 1024 65000
    RMEM_DEFAULT 262144
    RMEM_MAX 262144
    WMEM_DEFAULT 262144
    WMEM_MAX 262144


  RHEL 5  or OEL5(oracle enterprise linux5)
   kernel.shmmni = 4096
   kernel.sem = 250 32000 100 128
   fs.file-max = 65536
   net.ipv4.ip_local_port_range = 1024 65000
   net.core.rmem_default = 1048576
   net.core.rmem_max = 1048576
   net.core.wmem_default = 262144
  net.core.wmem_max = 262144


- OS Patch List
 
  RHEL3:
    gcc-3.2.3-34
    glibc-2.3.2-95.20
    make-3.79.1
    openmotif21-2.1.30-8
    compat-db-4.0.14.5
    compat-gcc-7.3-2.96.128
    compat-gcc-c++-7.3-2.96.128
    compat-libstdc++-7.3-2.96.128
    compat-libstdc++=devel-7.3-2.96.128
    setarch-1.3-1
    XFree86 (Spatial only)
    XFree86-devel (Spatial only)
 
  RHEL4:
 
    binutils-2.15.92.0.2-10.EL4
    compat-db-4.1.25-9
    compat-libstdc++-296-2.96-132.7.2
    compat-libstdc++-33-3.2.3-47.3
    control-center-2.8.0-12
    gcc-3.4.3-9.EL4
    gcc-c++-3.4.3-9.EL4
    glibc-2.3.4-2
    glibc-common-2.3.4-2
    gnome-libs-1.4.1.2.90-44.1
    libstdc++-3.4.3-9.EL4
    libstdc++-devel-3.4.3-9.EL4
    make-3.80-5
    pdksh-5.2.14-30
    sysstat-5.0.5-1
    xscreensaver-4.18-5.rhel4.2
    openmotif21-2.1.30-11.RHEL4.2 (required to install Oracle demos)
    libaio-0.3.96
 
  RHEL 5(X86)
     gcc-c++-4.1.1-52.el5.i386.rpm 
     gcc-4.1.1-52.el5.i386.rpm
     libstdc++-devel-4.1.1-52.el5.i386.rpm
     glibc-devel-2.5-12.i386.rpm
     glibc-headers-2.5-12.i386.rpm
     libgomp-4.1.1-52.el5.i386.rpm
     libXp-1.0.0-8.i386.rpm
     compat-libstdc++-33-3.2.3-61.i386.rpm
     compat-gcc-34-3.4.6-4.i386.rpm
     compat-gcc-34-c++-3.4.6-4.i386.rpm
     sysstat-7.0.0-3.el5.i386.rpm




  RHEL 5(X86_64):
   gcc-c++-4.1.1-52.el5.x86_64.rpm     
   libstdc++-devel-4.1.1-52.el5.x86_64.rpm
   glibc-headers-2.5-12.x86_64.rpm
   glibc-devel-2.5-12.x86_64.rpm
   libgomp-4.1.1-52.el5.x86_64.rpm
   gcc-4.1.1-52.el5.x86_64.rpm
   glibc-devel-2.5-12.i386.rpm
   compat-gcc-34-c++-3.4.6-4
   compat-libstdc++-33-3.2.3-61 (x86_64)
   compat-libstdc++-33-3.2.3-61(i386)
   libXp-1.0.0-8 (i386)
   sysstat-7.0.0-3.el5.x86_64.rpm


  OEL 5:
   gcc-c++-4.1.1-52.el5.i386.rpm
   libstdc++-devel-4.1.1-52.el5.i386.rpm
   gcc-4.1.1-52.el5.i386.rpm
   glibc-devel-2.5-12.i386.rpm
   glibc-headers-2.5-12.i386.rpm
   libgomp-4.1.1-52.el5.i386.rpm
   libXp-1.0.0-8.i386.rpm
   compat-db-4.2.52-5.1.i386.rpm
   compat-libstdc++-296-2.96-138.i386.rpm
   compat-libstdc++-33-3.2.3-61.i386.rpm
   sysstat-5.0.5-1.i386.rpm
 

  OEL 5(X86_64):
   gcc-c++-4.1.1-52.el5.x86_64.rpm
   libstdc++-devel-4.1.1-52.el5.x86_64.rpm
   glibc-headers-2.5-12.x86_64.rpm
   glibc-devel-2.5-12.i386.rpm
   glibc-devel-2.5-12.x86_64.rpm
   libgomp-4.1.1-52.el5.x86_64.rpm
   gcc-4.1.1-52.el5.x86_64.rpm
   compat-db-4.2.52-5.1.i386.rpm
   compat-db-4.2.52-5.1.x86_64.rpm
   compat-libstdc++-33-3.2.3-61.i386.rpm
   compat-libstdc++-33-3.2.3-61.x86_64.rpm
   libXp-1.0.0-8.i386.rpm
   sysstat-7.0.0-3.el5.x86_64.rpm





 SuSE SLES9:
 
    default-RPMs (see Note 386391.1)
    glibc-devel-2.3.3-98.47.i586.rpm
    gcc-3.3.3-43.34.i586.rpm.
    libstdc++-devel-3.3.3-43.34.i586.rpm
    gcc-c++-3.3.3-43.34.i586.rpm
    db1-1.85-85.1.i586.rpm
    orbit-0.5.17-330.1.i586.rpm
    gnome-libs-1.4.1.7-671.1.i586.rpm.
    plotutils-2.4.1-575.1.i586.rpm
    gnuplot-3.7.3-256.1.i586.rpm
    sysstat-5.0.1-35.4.i586.rpm.


- Set the session limits for Oracle user(RHEL5 or OEL5)

 Add the following lines to the /etc/security/limits.conf file

   oracle soft nproc 2047
   oracle hard nproc 16384
   oracle soft nofile 1024
   oracle hard nofile 65536
 
 
 Add the following line in the /etc/pam.d/login file

   session required pam_limits.so
 
 
 Add the following lines to the /etc/profile.
  Change this accordingly if the oracle user has a different shell

if [ $USER = "oracle" ]; then
  if [ $SHELL = "/bin/ksh" ]; then
    ulimit -p 16384
    ulimit -n 65536
  else
    ulimit -u 16384 -n 65536
  fi
fi



- JDK & JRE : JDK 1.4.2_08 is installed
             
             
- Disk Space : 1.2G Database
               1.5 to 3.5G Install
              
              

- RAM :  1GB

- Swap:  If RAM = 1024MB to 2048Mb then 1.5 times RAM
         elseif RAM > 2048MB and < 8192MB then match RAM
         else RAM > 8192MB then .75 times RAM
        
- TMP :  400 M
        
- oracle user (dba group) 생성
        
- unzip, cpio 여부               
          
- xhosts 설정여부 (oracle user로 xclock 명령어실행 가능)

반응형
저작자표시 비영리

'ORACLE > INSTALL' 카테고리의 다른 글

Oracle과 한글 그리고 UTF-8 <두번째>  (0) 2009.09.04
Oracle과 한글 그리고 UTF-8 <첫번째>  (0) 2009.09.04
LINUX ORALCE 10G설치  (0) 2009.08.04
solaris10 oracle install 9i 설정값  (0) 2009.05.27
오라클 삭제 방법  (0) 2009.03.18
Posted by [PineTree]

티스토리툴바