소개

DB2 optimizer는 매우 정교한 비용 기반 최적화 프로그램이다. 하지만 최적화 결정은 데이터베이스 환경, 쿼리 특성 및 데이터 자체를 포함한 다양한 속성을 고려하여 이루어지는 복잡한 기능이다. 이러한 다양한 독립 인수의 상호 작용으로 인해 드물기는 하지만 최적화 프로그램에서 최적 실행 플랜에 미치지 못하는 플랜이 선택될 수도 있다. 데이터베이스 설정이나 데이터의 기본 특성을 항상 변경할 수 있는 것은 아니기 때문에 사용자가 플랜 선택에 영향을 주어 고유 설정 특성을 보완할 수 있는 도구가 필요하다. 최적화 가이드라인은 발생 가능성이 있는 성능 문제를 해결하기 위해 테이블 액세스 방법, 인덱스 선택, 조인 방법 및 조인 순서를 포함한 주요 실행 플랜 속성에 영향을 줄 수 있는 강력한 메커니즘이다. 최신 DB2 9.7(Linux, UNIX 및 Windows용 DB2 버전 9.7) 릴리스에서는 새로운 XML 관련 가이드라인을 지원하고 XML 연산자를 포함하도록 기존 가이드라인의 범위를 확장하도록 최적화 가이드라인 인프라가 향상되었다.

이 기사에서는 DB2 pureXML 사용자에게 최적화 가이드라인 인프라를 소개한 후 SQL/XML 및 XQuery 워크로드를 위해 최적화 가이드라인을 설정, 사용 및 관리에 필요한 모든 단계를 설명한다. 최적화 가이드라인을 사용하여 구현 작업을 성공적으로 수행하는 데 필요한 모든 도구 및 정보와 함께 다양한 문제점 해결 팁 및 리소스가 포함되어 있다.

위로

이 기사에서 사용하는 데이터베이스 설정

TPoX(Transaction Processing over XML)는 재무 애플리케이션 시나리오 특히, 증권 거래를 기반으로 하는 애플리케이션 레벨 XML 데이터베이스 벤치마크이며 실제 XML 스키마를 사용하여 증권 거래 트랜잭션과 관련된 데이터를 모델링한다. 다양한 조정 매개변수를 통해 데이터 분배, 워크로드 구성 등을 수정할 수 있으므로 유연성도 뛰어나다. 이 기사에서는 약간 수정된 형태의 TPoX 벤치마크를 사용하여 최적화 프로그램 플랜에 영향을 주기 위해 XML 가이드라인 인프라에서 사용할 수 있는 다양한 옵션을 보여 준다. 단순성을 유지하기 위해 이 기사의 샘플 쿼리에서는 TPoX XML 데이터에 있는 네임스페이스를 무시한다. (TPoX에 대한 자세한 정보는 참고자료를 참조하기 바란다.)

이 기사에서는 DDL을 사용하여 작성된 수정된 TPoX 테이블을 사용한다(Listing 1 참조).

create table security (security_id int, security_type varchar(10), SDOC XML);
create table custacc (CDOC XML);
create table order (security_id int, ODOC XML);

이러한 테이블에는 다음과 같은 관계형 인덱스가 작성되었다.

create index sec_type on security?security_type);

이러한 테이블에는 다음과 같은 XML 인덱스가 작성되었다.

create index sec_industry on security(sdoc) generate key using 
  xmlpattern '/Security/SecurityInformation/StockInformation/Industry' as SQL varchar(30);

create index sec_symbol on security(sdoc) generate key using 
  xmlpattern '/Security/Symbol' as SQL varchar(30);

create index sec_name on security(sdoc) generate key using 
  xmlpattern '/Security/Name' as SQL varchar(100);

create index acc_currency on security(sdoc) generate key using 
  xmlpattern '/Customer/Accounts/Account/Currency' as SQL varchar(3);

위로

프로파일 인프라 개요

최적화 프로파일은 최적화 가이드라인이 포함된 XML 문서이다. 최적화 가이드라인에는 다음과 같은 두 가지 범주가 있다.

• 최적화 프로파일이 적용되는 동안 모든 명령문에서 고려되는 액세스 플랜 매개변수를 지정하는 글로벌 가이드라인
• 특정 명령문에만 적용되는 플랜 속성을 지정하는 명령문 레벨 가이드라인

각 명령문 레벨 가이드라인에는 다음과 같은 항목이 포함되어 있다.

• 영향을 받을 액세스 플랜이 있는 명령문을 식별하는 명령문 키
• 원하는 액세스 플랜을 지정하는 조치

"XML 가이드라인 사용 시나리오" 섹션에서 최적화 프로파일에 대해 자세히 설명한다.

최적화 프로파일을 사용하면 애플리케이션 또는 데이터베이스 구성을 변경하지 않고서도 플랜에 영향을 줄 수 있다. 애플리케이션과 프로파일이 분리되어 있으면 두 요소를 독립적으로 개발할 수 있다. 사용자는 단지 XML 프로파일 문서를 작성하고 데이터베이스에 삽입한 후 최적화 프로그램에 해당 프로파일을 사용하도록 지시하기만 하면 된다. 프로파일이 활성화되면 최적화 프로그램이 자동으로 최적화 가이드라인을 적절한 명령문에 일치시킨다. 프로파일에 지정된 가이드라인은 플랜에 있는 모든 연산자의 자세한 스펙을 포함하지 않아도 된다. 쿼리에 포함된 특정 테이블에 대한 인덱스 스펙이나 한 쌍의 테이블에 대한 조인 순서와 같이 실행 플랜의 일부 속성에만 영향을 주는 가이드라인을 정의할 수 있다. 최적화 프로그램은 지정된 가이드라인에 따라 프로파일에 지정된 플랜의 일부를 구현한 후 경쟁 플랜에 대한 비용 기반 결정을 통해 지능적으로 플랜의 나머지 부분을 채운다.

위로

최적화 프로파일을 설정하고 사용하는 단계별 방법

다음 단계에 따라 최적화 프로파일을 사용해야 한다.

1. XML 프로파일 파일을 작성한다.
2. 최적화 가이드라인의 쿼리에서 테이블을 참조하는 방법을 익힌다.
3. OPT_PROFILE 테이블을 작성한다.
4. OPT_PROFILE 테이블에 프로파일을 로드하거나 삽입한다.
5. 프로파일을 활성화한다.
6. 쿼리를 실행한다.
7. 프로파일이 적용되었고 원하는 액세스 플랜이 달성되었는지 확인한다.

이후 섹션에서는 이러한 각 단계를 설명한다.

XML 프로파일 파일 작성하기

최적화 프로파일은 각 릴리스의 DB2 LUW Information Center에 게시된 "COPS"(Current Optimization Profile Schema)를 따라야 하는 XML 파일로 작성된다(참고자료 참조). 최적화 프로파일 파일에는 영향을 받아야 하는 액세스 플랜이 포함된 모든 SQL 쿼리 세트가 있다.

        
<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
  <!--
       Global optimization guidelines section.
       Optional but at most one.
  -->
  <OPTGUIDELINES>
    <REOPT VALUE="ALWAYS"/>
  </OPTGUIDELINES>

  <!--
       Statement profile section.
       Zero or more.
  -->
  <STMTPROFILE ID="Sample Optimization Profile">
    <STMTKEY SCHEMA="TPOX">
      <![CDATA[SELECT * 
               FROM security
               WHERE XMLEXISTS('$SDOC/Security/SecurityInformation/StockInformation
                                               [Industry = "Software"]') AND
                     XMLEXISTS('$SDOC/Security/Symbol[.<>"IBM"]')]]> 
    </STMTKEY>
    <OPTGUIDELINES>
      <XANDOR TABLE="SECURITY"/>
    </OPTGUIDELINES>
  </STMTPROFILE>

각 XML 프로파일은 사용 중인 COPS의 버전을 나타내는 속성과 같은 메타데이터가 포함된 OPTPROFILE 태그로 시작된다.

Listing 3에서는 글로벌 최적화 가이드라인 섹션에 있는 하나의 가이드라인의 예제를 보여 준다. 이 예제의 가이드라인에서는 REOPT 바인드 옵션 값을 ALWAYS로 설정하도록 지정한다. REOPT 바인드 옵션은 매개변수 표시문자 또는 호스트 변수가 포함된 명령문의 최적화에 영향을 준다. REOPT를 ALWAYS로 설정하면 명령문이 각 실행마다 다시 컴파일된다. 유효한 프로파일에는 최대 1개의 글로벌 최적화 섹션이 있을 수 있다.

명령문 프로파일 섹션은 선택적이다. 이 섹션을 지정한 경우에는 STMTPROFILE 태그를 사용하여 하나 이상의 명령문 프로파일을 포함할 수 있고 특정 SQL 쿼리에 적용되는 가이드라인을 포함할 수 있다. 각 명령문 프로파일은 다음과 같은 요소로 구성되어 있다.

• 가이드라인을 적용해야 하는 명령문을 식별하는 STMTKEY 요소
• 가이드라인 자체를 설명하는 OPTGUIDELINES 요소

STMTKEY 요소에 정의된 명령문은 영향을 받아야 하는 액세스 플랜이 있는 명령문과 정확히 일치해야 한다(공백의 차이 허용). STMTKEY는 명령문 그룹에 영향을 주는 와일드카드를 지원하지 않는다. 영향을 받아야 하는 각 명령문에는 별도의 STMTPROFILE 섹션이 있어야 한다. 두 개 이상의 STMTPROFILE 섹션이 실행 명령문과 일치하는 경우에는 먼저 발생한 가이드라인이 선택되어 적용된다. Listing 3에서는 STMTKEY의 쿼리에 대해 XANDOR(XML Index Anding and Oring) 플랜을 선택하도록 지정한다.

STMTKEY 요소의 명령문에 특수 XML 문자인 < 및 >가 있기 때문에 위의 Listing 3에서 보듯이 <![CDATA[로 시작하고 ]]>로 끝나는 CDATA 섹션으로 쿼리 텍스트를 묶어야 한다.

최적화 가이드라인의 쿼리에서 테이블을 참조하는 방법

최적화 프로파일의 가이드라인 섹션에서 사용자는 특정 테이블에 대한 조치(예: 해당 테이블에 대한 액세스 방법)를 지정하거나 테이블이 조인의 외부 또는 내부 레그로 참여하는지 등을 나타낼 수 있다. 영향을 줄 테이블을 올바르게 식별하는 것이 중요하다. db2exfmt 도구에 의해 생성된 실행 플랜에서 보여 주는 최적화된 SQL 명령문에서 이름 또는 한정자 번호를 이용하여 테이블을 식별할 수 있다. 테이블 이름을 사용하는 방법이 더 간단하기는 하지만 테이블 ID를 사용하는 방법이 더 강력한 메커니즘이다. 왜냐하면 'xmlexists' 조건부와 같은 파생 한정자를 참조할 수 있기 때문이다.

• 이름으로 테이블 식별하기

  다음과 같은 간단한 쿼리를 가정해 보자.

  SELECT * FROM security WHERE XMLEXISTS('$SDOC/Security/SecurityInformation/StockInformation[Industry= "OfficeSupplies"]')

  이 예제에서 표시된 테이블 이름은 'SECURITY'이다. 이 쿼리에 대한 가이드라인에서는 이 표시된 이름을 지정해야 한다. 예를 들어, 다음과 같이 'SEC_INDUSTRY' 인덱스를 사용하는 XML 인덱스 액세스를 지정할 수 있다.

  <XISCAN TABLE='SECURITY' INDEX='SEC_INDUSTRY'/>

  이제 테이블 이름에 대한 별명으로 'sec'를 사용하는 다음 쿼리를 살펴보자.

  SELECT * FROM security sec WHERE XMLEXISTS('$SDOC/Security/SecurityInformation/StockInformation[Industry= "OfficeSupplies"]')

  표시된 테이블 이름이 'SEC'이므로 아래와 같이 인덱스 가이드라인도 표시된 이름을 참조하도록 변경해야 한다.

  <XISCAN TABLE='SEC' INDEX='SEC_INDUSTRY'/>
• TABID로 테이블 식별하기

  쿼리가 DB2에 제출될 때 쿼리는 최적화에 가장 적합한 양식으로 다시 작성된다. "최적화된 SQL"인 다시 작성된 쿼리는 db2exfmt 명령을 사용하여 명령문을 설명할 때 표시된다. 최적화된 SQL은 db2exfmt 출력의 'Optimized Statement' 섹션에 있다. 예를 들어, Listing 4의 쿼리를 살펴보자.

  
  
  Listing 4. 쿼리
  

  SELECT * FROM order, security WHERE order.security_id = security.security_id AND XMLEXISTS('$SDOC/Security/Symbol[.="IBM"]');

  
  

  최적화된 명령문은 다음과 같다.

  
  
  Listing 5. 최적화된 명령문
  

  SELECT Q3.ID AS "ID", Q3.SECURITY_ID AS "SECURITY_ID", Q3.ODOC AS "ODOC", Q2.ID AS "ID", Q2.SECURITY_ID AS "SECURITY_ID", Q2.SDOC AS "SDOC" FROM $INTERNAL_FOR$ ((TABLE ($INTERNAL_XPATH$ ('(($INTERNAL_XMLTOXML_NIEO$(Q2.SDOC))[ $INTERNAL_EBV_BOOLEAN$(Security/Symbol[(. = "IBM")])])(:-->$C0:)'))) AS Q1), TPOX.SECURITY AS Q2, TPOX.ORDER AS Q3 WHERE (Q3.SECURITY_ID = Q2.SECURITY_ID)

  
  

  SECURITY 테이블의 내부 번호는 Q2이며 ORDER의 내부 번호는 Q3이다. 원래 쿼리의 XMLEXISTS 조건부는 내부 번호 Q1을 사용하여 참조할 수 있는 복합 표현식으로 변환된다. Listing 6의 가이드라인에서는 xmlexists 조건부를 SECURITY 테이블에 먼저 적용한 후 ORDER 테이블과 함께 해시 조인을 수행하도록 지정한다.
  
  Listing 6. 이름 및 ID로 테이블 참조하기
  

  <?xml version="1.0" encoding="UTF-8"?> <OPTPROFILE VERSION="9.7.0.0"> <STMTPROFILE ID="Identifying the exposed name of a table"> <STMTKEY SCHEMA="TPOX"> SELECT * FROM order, security WHERE order.security_id = security.security_id AND XMLEXISTS('$SDOC/Security/Symbol[.="IBM"]') </STMTKEY> <OPTGUIDELINES> <HSJOIN> <NLJOIN FIRST='TRUE'> <ACCESS TABLE='SECURITY'/> <ACCESS TABID='Q1'/> </NLJOIN> <ACCESS TABID='Q3' /> </HSJOIN> </OPTGUIDELINES> </STMTPROFILE> </OPTPROFILE>

  
  

  Listing 6을 보면 테이블 이름과 테이블 ID가 함께 포함될 수도 있다는 것을 알 수 있다. 테이블 이름은 XML 속성 TABLE을 사용하여 지정하는 반면 테이블 ID는 XML 속성 TABID를 사용하여 지정한다.

OPT_PROFILE 테이블 작성하기

최적화 프로파일은 SYSTOOLS.OPT_PROFILE 테이블에 저장해야 한다.

이 테이블은 다음 두 가지 방법으로 작성할 수 있다.

• DB2에는 다음과 같이 OPT_PROFILE 테이블을 작성하거나 삭제할 수 있는 SYSINSTALLOBJECTS라는 시스템 정의 저장 프로시저가 있다.

  db2 "call sysinstallobjects('opt_profiles', 'c', '', '')"

  
  

  SYSINSTALLOBJECTS 프로시저는 다양한 도구에 필요한 데이터베이스 오브젝트를 작성하거나 삭제한다. 첫 번째 인수는 사용자가 최적화 프로파일 테이블을 작성하는 데 관심이 있음을 지정한다. 두 번째 인수는 원하는 사용자 조치가 최적화 프로파일 테이블을 작성하는 것임을 지정한다. 기본 스키마 SYSTOOLS 및 테이블 이름 OPT_PROFILE이 사용되기 때문에 스키마 이름과 오브젝트 이름을 지정하는 세 번째 및 네 번째 인수는 공백으로 두어야 한다. SYSINSTALLOBJECTS 프로시저는 모든 시스템 프로시저와 마찬가지로 SYSPROC 스키마에 있다.

• 또는 다음 DDL 명령문을 명시적으로 실행하여 OPT_PROFILE 테이블을 작성할 수 있다.

  
  
  Listing 7. OPT_PROFILE 테이블을 작성하는 DDL 명령문
  

  create table systools.opt_profile ( schema varchar(128) not null, name varchar(128) not null, profile blob (2m) not null, primary key (schema, name) )

  
  

  schema 열은 최적화 프로파일에 대한 스키마 이름을 지정하는 데 사용된다. 스키마 이름은 영숫자 문자열이어야 하고 해당 DB2 LUW 릴리스의 스키마 이름에 대한 모든 이름 지정 규칙을 따라야 한다.

  name 열에는 최적화 프로파일의 이름이 있으며 최대 128자의 영숫자 문자열을 포함할 수 있다.

  profile 열은 최적화 프로파일이 포함된 XML 문서가 있다.

프로파일 로드하기

최적화 프로파일을 사용하려면 먼저 최적화 프로파일에 고유한 스키마 한정 이름을 연결한 후 SYSTOOLS.OPT_PROFILE 테이블에 저장해야 한다. INSERT 명령문, IMPORT 유틸리티 또는 LOAD 유틸리티를 사용할 수 있다. Listing 8에서는 최적화 프로파일을 OPT_PROFILE 테이블에 삽입하는 방법을 보여 준다. 프로파일에는 SECURITY 테이블에 대한 단일 XISCAN 가이드라인이 있다.

insert into systools.opt_profile values
      ('TPOX','PROFILE1',
        CAST('<?xml version="1.0" encoding="UTF-8"?>
              <OPTPROFILE VERSION="9.7.00">
	        <STMTPROFILE ID="Listing 3">
                  <STMTKEY><![CDATA[SELECT * FROM security 
                              WHERE XMLEXISTS(''$SDOC/Security/SecurityInformation/
                              StockInformation[Industry="OfficeSupplies"]'')]]>
                  </STMTKEY>
                  <OPTGUIDELINES> 
                    <XISCAN TABLE="SECURITY"/>
                  </OPTGUIDELINES> 
                 </STMTPROFILE>
               </OPTPROFILE>' as blob));

또는 사용자가 IMPORT 유틸리티를 사용하여 XML 파일에 저장된 최적화 프로파일을 가져올 수도 있다.

다음 예제에서는 weekly_report_profile.xml 및 scientist_queries_profile.xml 파일에 있는 두 프로파일을 SYSTOOLS.OPT_PROFILE 테이블로 가져오는 방법을 보여 준다. 두 개의 프로파일 파일이 현재 디렉토리에 있다고 가정하자. 구분 형식 입력 파일(예: 'profiledata', Listing 9 참조)에는 프로파일 스키마, 프로파일 이름 및 XML 파일 이름이 있다. 각 프로파일은 별도의 행에 있어야 한다.

   "TPOX","PROFILE1","weekly_report_profile.xml"
   "TPOX","PROFILE2","scientist_queries_profile.xml"

이제 IMPORT 명령을 사용하여 프로파일을 OPT_PROFILE 테이블로 가져올 수 있다.

   import from profiledata of del
     modified by lobsinfile
     insert into systools.opt_profile

프로파일 활성화하기

프로파일은 OPT_PROFILE 테이블에 무제한으로 로드할 수 있다. 하지만 한 번에 최대 하나의 프로파일만 사용할 수 있다. 여러 쿼리에 영향을 주어야 하는 경우에는 여러 명령문 프로파일을 단일 최적화 프로파일에 포함시킨다. 그런 다음 패키지 레벨에서 OPTPROFILE 바인드 옵션을 사용하거나 세션 레벨에서 CURRENT OPTIMIZATION PROFILE 특수 레지스터를 사용하여 최적화 프로파일을 활성화한다. CLI 애플리케이션에서 클라이언트 구성 옵션 CURRENTOPTIMIZATIONPROFILE을 사용하여 연결에 대한 특수 레지스터를 설정할 수 있다.

예를 들어, 사용자가 다음과 같은 명령을 실행할 수 있다.

db2 "set current optimization profile='TPOX.PROFILE1'"

이 명령을 실행하면 현재 세션이 끝날 때까지 TPOX 스키마의 PROFILE1이 유효 프로파일로 사용된다. 언제라도 set 명령을 사용하여 특수 레지스터의 값을 수정할 수 있다.

다음 명령을 사용하여 최적화 프로그램에서 최적화 프로파일을 사용하지 않도록 지정할 수 있다. 최적화 프로그램은 비용 기반 결정을 사용하여 최선의 플랜을 리턴한다.

db2 "set current optimization profile=''"

다양한 옵션의 우선 순위는 다음과 같다.

• OPTPROFILE 바인드 옵션은 다른 설정에 상관 없이 모든 정적 명령문에 적용된다.
• 동적 명령문의 경우, CURRENT OPTIMIZATION PROFILE 특수 레지스터의 값은 다음과 같은 순서로 결정된다.
• 애플리케이션 내의 마지막 SET CURRENT OPTIMIZATION PROFILE 명령문(가장 높은 우선 순위)
• 설정된 경우, CURRENTOPTIMIZATIONPROFILE 클라이언트 구성 옵션
• 지정된 경우, OPTPROFILE 바인드 옵션

쿼리 실행하기

필수 프로파일을 활성화한 후 사용자는 변경 작업 없이 워크로드를 실행할 수 있다. 활성 프로파일과 일치하는 쿼리의 경우 최적화 프로그램은 최선의 작업을 수행하여 가이드라인에서 요청한 플랜을 생성한다. 가이드라인과 일치하지 않는 프로파일의 경우에는 일반 비용 기반 액세스 플랜이 선택된다.

가이드라인이 적용되었는지 확인하기

DB2 Explain 기능은 프로파일이 쿼리에 성공적으로 일치되었는지 여부를 결정하는 데 유용한 도구이다. 적용 가능한 최적화 프로파일 이름 및 명령문 프로파일 이름이 Explain 출력의 "Profile Information" 섹션에 표시된다.

Listing 11. 프로파일 정보

OPT_PROF: (Optimization Profile Name)
        TPOX.PROFILE1
STMTPROF: (Statement Profile Name)
        Listing 3

db2exfmt 출력의 "Profile Information" 섹션은 올바른 최적화 프로파일 및 명령문 프로파일이 현재 쿼리에 적용되었는지를 확인하는 데 사용할 수 있다.

가이드라인을 적용할 수 없을 경우 최적화 프로그램은 이유 코드 13이 포함된 경고 437을 리턴한다.

SQL0437W Performance of this complex query may be sub-optimal. Reason code: "13". SQLSTATE=01602

그런 다음에는 가이드라인과 관련된 문제점을 해결하기 위해 쿼리를 설명하고 db2exfmt 출력을 검사하여 자세한 진단 정보를 확인할 수 있다. 예를 들어, db2exfmt는 참조된 테이블 이름이 없고, 따라서 가이드라인이 적용되지 않은 경우 다음과 같은 출력을 생성한다.

Diagnostic Identifier: 	1
Diagnostic Details: 	EXP0009W  Invalid access request. The table
			reference identified by the TABLE attribute could
			not be found. Line number "1", character number
			"60".

경고 메시지나 진단 메시지가 발생하지 않았다는 것은 최적화 프로그램이 가이드라인을 적용했음을 나타낸다. db2exfmt 출력을 검사하여 요청된 액세스/조인 방법이 사용되고 있음을 확인할 수 있다.

위로

XML 가이드라인의 사용 시나리오

액세스 방법에 영향 주기/강제로 XML 인덱스 액세스 적용하기

이 가이드라인은 단일 XML 인덱스 스캔을 사용하여 지정된 테이블에 액세스함을 지정한다. 최적화 가이드라인에 다음과 같은 XISCAN 요소를 포함시켜서 'SEC_INDUSTRY' 인덱스를 사용하여 'SECURITY' 테이블에 액세스해야 함을 지정할 수 있다.

<XISCAN TABLE='SECURITY' INDEX='SEC_INDUSTRY' FIRST="TRUE"/>

• TABLE 또는 TABID 속성은 테이블 이름 또는 tabid(액세스 중인 db2exfmt 출력의 최적화된 SQL에서 살펴본 테이블 ID. 필수 속성임)이다.
• INDEX 속성은 선택적이며 인덱스 이름을 지정하는 데 사용할 수 있다. 지정한 경우, 이 속성은 이 특정 XML 인덱스에 대한 XISCAN 연산자를 사용하여 액세스 플랜을 요청한다. 인덱스 이름을 지정하지 않은 경우에는 최적화 프로그램이 가장 간단한 단일 XML 인덱스 액세스 플랜을 선택한다.
• FIRST 속성도 선택적이다. 지정한 경우, 이 속성은 'TRUE' 값을 사용하여 지정된 테이블이 조인 쿼리에서 가장 먼저 액세스해야 하는 테이블이어야 함을 나타낸다. FROM 절에 나열된 모든 테이블에는 'FIRST' 속성을 가진 최대 하나의 액세스 또는 조인 요청이 있을 수 있다.

Listing 13의 예제에서는 완성된 최적화 프로파일 컨텍스트에서의 XISCAN 가이드라인을 보여 준다. Listing 14의 예제에서는 인덱스 이름이 없는 XISCAN 가이드라인을 사용하여 'SECURITY' 테이블에 액세스하기 위해 사용 가능한 가장 간단한 XML 인덱스를 사용해야 함을 나타낸다.

<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
<STMTPROFILE ID="Example 1"> 
  <STMTKEY SCHEMA="TPOX">
    SELECT *
    FROM security 
    WHERE XMLEXISTS('$SDOC/Security/SecurityInformation
      /StockInformation[Industry= "OfficeSupplies"]')
  </STMTKEY>
  <OPTGUIDELINES>
    <XISCAN TABLE='SECURITY' INDEX='SEC_INDUSTRY'/>
  </OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>

<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
<STMTPROFILE ID="Example 2"> 
  <STMTKEY SCHEMA="TPOX">
     SELECT *
     FROM security 
     WHERE XMLEXISTS('$SDOC/Security/SecurityInformation
            /StockInformation[Industry= "OfficeSupplies"]')
  </STMTKEY>
  <OPTGUIDELINES>
     <XISCAN TABLE='SECURITY' />
  </OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>

이 가이드라인은 XANDOR 연산자에서 적용 가능한 모든 XML 인덱스를 사용하여 지정된 테이블에 액세스하도록 지정한다. TABLE 또는 TABID 속성과 FIRST 속성은 XISCAN 가이드라인에서 설명한 것과 같은 의미를 갖고 있다.

Listing 15의 예제 가이드라인은 적용 가능한 모든 XML 인덱스로 구성된 XANDOR를 사용하여 'SECURITY' 테이블에 액세스해야 함을 지정한다. 'Industry' 및 'Symbol' 요소에 대한 XML 인덱스가 있을 경우 DB2는 각 인덱스에 대한 XISCAN 연산자를 사용하여 양방향 XANDOR를 생성한다. 관계형 인덱스는 XANDOR 방법에서 사용할 수 없기 때문에 사용되지 않는다. 하나의 XML 인덱스만 사용할 수 있을 경우 DB2는 이 가이드라인을 적용하지 않고 대신 가장 간단한 대체 플랜을 생성한다.

<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
<STMTPROFILE ID="Example 3">
  <STMTKEY SCHEMA="TPOX">
    SELECT *
    FROM security
    WHERE security_type = 'Bond Fund'
      AND XMLEXISTS('$SDOC/Security/SecurityInformation
           /StockInformation[Industry= "Software"]')
      AND XMLEXISTS('$SDOC/Security/Symbol[.="IBM"]')
  </STMTKEY>
  <OPTGUIDELINES>
     <XANDOR TABLE='SECURITY' /> 
  </OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>

ACCESS 가이드라인(모든 액세스 요청)을 사용하면 최적화 프로그램에서 액세스 방법을 선택할 수 있다. 이 가이드라인은 일반적으로 액세스 방법이 아닌 조인 순서가 중요할 때 사용된다. 목표 테이블 참조가 파생된 테이블인 경우에는 ACCESS 요소를 사용해야 한다.

ACCESS 요소에는 TABLE, TABID, FIRST, TYPE, INDEX 및 ALLINDEXES 속성이 있을 수 있다. 또한 ACCESS 요소에는 하나 이상의 INDEX 하위 요소가 있을 수 있다.

TABLE 또는 TABID 속성과 FIRST 속성은 XISCAN 가이드라인에서 설명한 것과 같은 의미를 갖고 있다.

TYPE 속성은 선택적이며 'XMLINDEX' 값을 사용할 수 있다. 이 속성은 최소 하나의 XML 인덱스 레그가 있는 XISCAN, XANDOR 또는 IXAND나 최소 하나의 XML 인덱스 레그가 있는 RIDSCN(인덱스 ORing)과 같은 XML 인덱스 액세스 방법을 사용하여 테이블에 액세스해야 함을 나타낸다. 이 속성을 지정하지 않은 경우에는 최적화 프로그램이 비용 기반 결정을 수행하여 지정된 테이블에 대한 액세스 플랜을 선택한다.

INDEX 속성은 선택적이며 TYPE이 'XMLINDEX'로 지정된 경우에만 인덱스 이름을 지정할 수 있다. 이 속성을 지정한 경우 최적화 프로그램이 다음 중 하나를 선택할 수 있다.

• 지정된 XML 인덱스를 사용하는 XISCAN 플랜
• 적용 가능한 모든 XML 인덱스가 있는 XANDOR 플랜
• 지정된 XML 인덱스가 IXAND의 선행 인덱스인 IXAND 플랜. 최적화 프로그램이 비용 기반 결정에 따라 IXAND 플랜에 인덱스를 추가할 수 있다.
• 비용 기반 XML 인덱스 ORing 플랜. 인덱스 ORing 플랜에 대한 db2exfmt 출력은 두 개 이상의 XISCAN 연산자를 입력으로 사용하는 RIDSCN 연산자를 보여 준다.

선택적 INDEX 요소는 ACCESS 요소의 TYPE 속성이 'XMLINDEX'일 경우 두 개 이상의 XML 인덱스 이름을 제공할 수 있다. INDEX 요소가 지정된 경우 최적화 프로그램이 다음 중 하나를 선택할 수 있다.

• 적용 가능한 모든 XML 인덱스가 있는 XANDOR 플랜
• 지정된 XML 인덱스가 지정된 순서대로 사용되지만 추가 인덱스가 포함되어 있지 않은 IXAND 플랜
• 비용 기반 인덱스 ORing(RIDSCN) 플랜

인덱스 속성과 하나 이상의 인덱스 요소가 지정된 경우에는 인덱스 속성이 무시된다.

ALLINDEXES 속성은 선택적이며 'TRUE' 값만을 사용할 수 있다. 이 속성은 TYPE이 'XMLINDEX'로 지정된 경우에만 지정할 수 있다. 이 속성을 'TRUE'로 설정하는 것은 비용에 관계 없이 적용 가능한 모든 관계형 및 XML 인덱스를 사용하여 테이블에 액세스해야 함을 나타낸다. 그런 다음 최적화 프로그램이 다음 플랜 중 하나를 선택한다.

• XANDOR 연산자 아래에 표시되는 적용 가능한 모든 XML 인덱스가 있는 XANDOR 플랜
• IXAND 연산자 아래에 표시되는 적용 가능한 모든 관계형 및 XML 인덱스가 있는 IXAND 플랜
• 인덱스 ORing 플랜
• 테이블에 단일 인덱스만 정의되어 있고 XML 유형인 경우 XISCAN 플랜

Listing 16의 예제 가이드라인에서는 일부 XML 인덱스를 사용하여 SECURITY 테이블에 액세스하도록 지정한다. 최적화 프로그램은 비용 기반 분석을 사용하여 XISCAN, IXAND, XANDOR 또는 RIDSCN 플랜을 선택할 수 있다.

<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
<STMTPROFILE ID="Example 4"> 
  <STMTKEY SCHEMA="TPOX">
     SELECT *
     FROM security 
     WHERE XMLEXISTS('$SDOC/Security/SecurityInformation
            /StockInformation[Industry= "OfficeSupplies"]')
  </STMTKEY>
  <OPTGUIDELINES>
</OPTPROFILE>
     <ACCESS TABLE='SECURITY' TYPE='XMLINDEX' />
  </OPTGUIDELINES>
</STMTPROFILE>

Listing 17의 예제 가이드라인에서는 SECURITY 테이블의 적용 가능한 모든 관계형 및 XML 인덱스가 사용됨을 지정한다. 액세스 방법은 최적화 프로그램에서 선택하며 XMLEXISTS의 두 조건부에 대해 SEC_INDUSTRY 및 SEC_SYMBOL이라는 두 개의 XML 인덱스가 있는 경우에는 최적화 프로그램이 XANDOR 또는 IXAND 플랜 중 하나를 사용하도록 선택한다. 최적화 프로그램은 비용 기반 분석을 사용하여 두 액세스 방법 중 하나를 선택한다.

<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
<STMTPROFILE ID="Example 5">
  <STMTKEY SCHEMA="TPOX">
    SELECT *
    FROM security
    WHERE XMLEXISTS('$SDOC/Security/SecurityInformation
             /StockInformation[Industry= "Software"]')
    AND XMLEXISTS('$SDOC/Security/Symbol[.="IBM"]')
  </STMTKEY>
  <OPTGUIDELINES>
    <ACCESS TABLE='SECURITY' TYPE='XMLINDEX' ALLINDEXES='TRUE' />
  </OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>

IXAND 액세스 요청 요소는 최적화 프로그램에게 인덱스 앤딩(index anding)을 사용하여 테이블에 액세스하도록 지시한다. ACCESS 가이드라인과 마찬가지로 IXAND 요소에는 TABLE, TABID, FIRST, TYPE, INDEX 및 ALLINDEXES 속성이 있을 수 있다. 또한 IXAND 요소에는 하나 이상의 INDEX 하위 요소가 있을 수 있다. IXAND 가이드라인에는 다음과 같은 규칙이 적용된다.

• TYPE 속성에서는 'XMLINDEX' 값을 사용하여 하나 이상의 XML 인덱스가 포함된 인덱스 앤딩 액세스 플랜을 선택할 수 있다.
• INDEX 속성은 선택적이며 'IXAND' 플랜에서 선행 인덱스로 사용할 인덱스 이름을 지정하는 데 사용할 수 있다. 최적화 프로그램이 비용을 기반으로 하여 IXAND에 인덱스를 추가한다.
• INDEX 요소는 지정된 순서대로 'IXAND' 플랜에 사용할 두 개 이상의 인덱스를 선택적으로 지정할 수 있으며 최적화 프로그램은 IXAND에 인덱스를 추가하지 않는다.
• INDEX 속성 또는 INDEX 요소는 TYPE이 'XMLINDEX'로 지정된 경우에만 XML 인덱스를 지정할 수 있다.
• ALLINDEXES 속성은 비용에 관계 없이 적용 가능한 모든 관계형 및 XML 인덱스를 강제로 사용하려는 경우에 설정할 수 있다.
• INDEX 속성과 하나 이상의 INDEX 요소가 지정된 경우에는 INDEX 속성이 무시된다.

Listing 18의 예제에서는 최적화 가이드라인의 IXAND 요소가 SEC_INDUSTRY 및 SEC_SYMBOL이라는 두 XML 인덱스를 사용하여 SECURITY 테이블에 액세스해야 함을 지정한다. 최적화 프로그램이 두 개의 인덱스를 지정된 순서대로 IXAND 플랜의 레그로 사용하여 IXAND 플랜을 생성한다.

<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
<STMTPROFILE ID="Example 6"> 
  <STMTKEY SCHEMA="TPOX">
    SELECT *
    FROM security 
    WHERE security_type = 'Bond Fund'
      AND XMLEXISTS('$SDOC/Security/SecurityInformation
          /StockInformation[Industry= "Software"]')
      AND XMLEXISTS('$SDOC/Security/Symbol[.="IBM"]')
  </STMTKEY>
  <OPTGUIDELINES>
    <IXAND TABLE='SECURITY' TYPE='XMLINDEX'>
      <INDEX IXNAME='SEC_INDUSTRY'/>
      <INDEX IXNAME='SEC_SYMBOL'/> 
    </IXAND> 
  </OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>

Listing 19의 예제에서는 최적화 가이드라인의 IXAND 요소가 적용 가능한 모든 관계형 및 XML 인덱스를 사용하여 SECURITY 테이블에 액세스해야 함을 지정한다. SECURITY_TYPE 열에는 관계형 인덱스가 있고 INDUSTRY 및 SYMBOL에는 XML 인덱스가 있으므로 세 인덱스는 모두 최적화 프로그램에서 선택한 순서대로 AND 연산되어야 한다.

<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
<STMTPROFILE ID="Example 7"> 
  <STMTKEY SCHEMA="TPOX">
    SELECT *
    FROM security 
    WHERE security_type = 'Bond Fund'
    AND XMLEXISTS('$SDOC/Security/SecurityInformation
         /StockInformation[Industry= "Software"]')
    AND XMLEXISTS('$SDO?/Security/Symbol[.="IBM"]')
  </STMTKEY>
  <OPTGUIDELINES>
    <IXAND TABLE='SECURITY' TYPE='XMLINDEX' ALLINDEXES='TRUE' />
  </OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>

Listing 20의 예제에서 IXAND 가이드라인은 IXAND 플랜을 사용하여 SECURITY 테이블에 액세스해야 하고 XML 인덱스 SEC_INDUSTRY가 IXAND 아래의 첫 번째 인덱스여야 함을 지정한다. 최적화 프로그램이 비용 기반 결정에 따라 IXAND 플랜에 대한 추가 인덱스를 선택한다. 관계형 인덱스를 SECURITY_TYPE 열에서 사용할 수 있고 XML 인덱스를 SYMBOL에서 사용할 수 있기 때문에 최적화 프로그램의 비용 기반 분석에서 장점이 많은 것으로 밝혀질 경우 이러한 인덱스 중 하나 또는 둘 다가 IXAND의 레그로 표시될 수 있다.

<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
<STMTPROFILE ID="Example 8"> 
  <STMTKEY SCHEMA="TPOX">
    SELECT *
    FROM security 
    WHERE security_type = 'Bond Fund'
      AND XMLEXISTS('$SDOC/Security/SecurityInformation
             /StockInformation[Industry= "Software"]')
      AND XMLEXISTS('$SDOC/Security/Symbol[.="IBM"]')
  </STMTKEY>
  <OPTGUIDELINES>
    <IXAND TABLE='SECURITY' TYPE='XMLINDEX' INDEX='SEC_INDUSTRY' /> 
  </OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>

XML 쿼리의 조인 순서 및 조인 방법에 영향 주기

모든 기존 최적화 가이드라인은 XML 데이터 유형이 있을 경우 정상적으로 작동한다. JOIN, MSJOIN, NLJOIN 및 HSJOIN과 같은 관계형 가이드라인은 조인 순서와 조인 유형을 지정하는 데 사용할 수 있다. 이 기사에서 소개한 새로운 XML 액세스 가이드라인은 모두 조인의 내부 또는 외부 레그를 지정하기 위해 이러한 관계형 조인 가이드라인 내에서 중첩될 수 있다.

Listing 21의 예제 가이드라인에서는 XML 인덱스 SEC_NAME을 사용하여 SECURITY 테이블에 액세스하도록 지정한다. 'SECURITY' 및 'ORDER' 테이블 간의 조인을 수행하기 위해 해시 조인 방법이 요청된다. TABLE='SECURITY'가 설정된 XISCAN 요소가 TABLE='ORDER'가 설정된 ACCESS 요소 앞에 지정되어 있기 때문에 결과 플랜에서는 'SECURITY' 테이블을 해시 조인의 외부 레그로 사용하고 'ORDER' 테이블을 내부 레그로 사용한다.

<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
<STMTPROFILE ID="Example 9"> 
  <STMTKEY SCHEMA="TPOX">
     SELECT *
     FROM order, security
     WHERE order.security_id = security.security_id 
         AND XMLEXISTS('$SDOC/Security/Name[.="International Business Machines"]')
  </STMTKEY>
  <OPTGUIDELINES>
      <HSJOIN>
        <XISCAN TABLE='SECURITY' INDEX='SEC_NAME'/>
        <ACCESS TABLE='ORDER' />
      </HSJOIN>  
  </OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>

Listing 22의 예제 최적화 가이드라인에는 ACCESS와 XANDOR라는 두 개의 요소가 있다. ACCESS 가이드라인 요소의 FIRST 속성은 FROM 절의 테이블이 조인될 때 CUSTACC 테이블이 가장 외부에 있는 테이블로 나타나야 한다고 지정한다. 또한 ACCESS 요소는 일부 XML 인덱스를 사용하여 CUSTACC 테이블에 액세스해야 한다고 지정한다. XANDOR 요소는 XANDOR 플랜을 사용하여 ORDER 테이블에 액세스해야 한다고 지정한다. 최적화 프로그램은 XANDOR 플랜의 모든 적용 가능한 XML 인덱스를 사용하며 인덱스의 순서를 결정한다.

<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
<STMTPROFILE ID="Example 10"> 
  <STMTKEY SCHEMA="TPOX">
     SELECT ordqty, orddate, ordid, security, lasttrade 
     FROM order, security, custacc,
       XMLTABLE('$ODOC/FIXML/Order' 
          COLUMNS ordid VARCHAR(10) PATH '@ID', 
                  orddate date PATH '@TrdDt', 
                  ordqty float PATH 'OrdQty/@Qty') AS T1, 
       XMLTABLE(' $SDOC/Security' 
          COLUMNS security varchar(50) PATH 'Name', 
                  lasttrade float PATH 'Price/LastTrade') AS T2 
       WHERE XMLEXISTS('
         $SDOC/Security[Symbol/fn:string(.) 
             = $ODOC/FIXML/Order/Instrmt/@Sym/fn:string(.)]') 
       and XMLEXISTS(
         '$ODOC/FIXML/Order[@Acct/fn:string(.) 
              = $CADOC/Customer/Accounts/Account/@id/fn:string(.)]') 
        and XMLEXISTS('$CADOC/Customer[@id = 1011]') 
       ORDER BY ordqty desc
  </STMTKEY>
  <OPTGUIDELINES>
      <ACCESS TABLE='CUSTACC' TYPE='XMLINDEX' FIRST='TRUE' /> 
      <XANDOR TABLE='ORDER' /> 
  </OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>

XQuery 지원

모든 최적화 가이드라인은 XQuery 언어로 작성된 쿼리에도 적용할 수 있다.

Listing 23의 최적화 프로파일에는 소프트웨어를 엔화로 거래하는 회사의 고객 계정 번호를 리턴하는 XQuery 표현식이 있다. 이 가이드라인은 SECURITY 테이블이 조인의 외부 테이블이어야 하고 XML 인덱스 SEC_INDUSTRY를 사용하여 SECURITY 테이블에 액세스해야 한다고 지정한다. 이 가이드라인은 또한 CUSTACC 테이블이 조인의 내부 테이블이어야 하고 XML 인덱스 ACC_CURRENCY를 사용하여 CUSTACC 테이블에 액세스해야 한다고 지정한다.

<?xml version="1.0" encoding="UTF-8"?>
<OPTPROFILE VERSION="9.7.0.0">
<STMTPROFILE ID="Example 11"> 
  <STMTKEY SCHEMA="TPOX">
    <![CDATA[ xquery
     for $s in db2-fn:xmlcolumn("SECURITY.SDOC")/Security[
                SecurityInformation/StockInformation/Industry="Software"]
     for $c in db2-fn:xmlcolumn("CUSTACC.CADOC")/Customer
               /Accounts/Account[Currency="YEN"]
     where $s/Symbol = $c/Holdings/Position/Symbol
     return <yenaccount> {$c} </yenaccount> ]]>
  </STMTKEY>
  <OPTGUIDELINES>
    <JOIN> 
      <ACCESS TABLE='SECURITY' TYPE='XMLINDEX' INDEX='SEC_INDUSTRY'/>
      <ACCESS TABLE='CUSTACC'  TYPE='XMLINDEX' INDEX='ACC_CURRENCY'/>
    </JOIN>
  </OPTGUIDELINES>
</STMTPROFILE>
</OPTPROFILE>

위로

문제점 해결 팁 및 간단한 방법

• 이 기사의 모든 단계를 수행하여 프로파일을 활성화했지만 요청된 플랜이나 SQL0437W 경고 메시지가 나타나지 않은 경우에는 다음을 수행한다.
  • 특수 레지스터, 클라이언트 구성 옵션 또는 바인드 옵션을 적절하게 사용하여 올바른 최적화 프로파일을 활성화했는지 확인한다.
  • 프로파일 이름이 영숫자 문자만 포함하고 128자를 초과하지 않는지 확인한다.
• IXAND 또는 ACCESS 가이드라인을 사용하여 특정 선행 인덱스를 지정할 때 요청된 플랜을 얻을 수 없는 경우에는 다음 사항을 확인한다.
  • 가이드라인 내에서 INDEX 속성과 INDEX 요소를 동시에 지정하지 않았는지 확인한다. INDEX 속성과 하나 이상의 INDEX 요소를 동시에 지정한 경우에는 INDEX 속성이 무시된다.
• 별명을 사용하는 쿼리에서 요청된 플랜을 얻을 수 없는 경우에는 다음 사항을 확인한다.
  • 기본 테이블 이름이 아닌 별명이 최적화 가이드라인의 TABLE 속성에 지정되어 있는지 확인한다. 예를 들어, 다음 쿼리에 대한 XML 인덱스 액세스를 요청하는 경우를 가정해 보자.

    SELECT * FROM security sec WHERE ...

    이 경우 가이드라인에서는 다음과 같이 지정해야 한다.

    <XISCAN TABLE='SEC' INDEX='SEC_INDUSTRY'/>

    다음은 잘못된 방법을 보여 준다.

    <XISCAN TABLE='SECURITY' INDEX='SEC_INDUSTRY'/>.

위로

결론

XML 최적화 가이드라인은 플랜 선택에 영향을 주고 데이터베이스 환경의 고유 특성으로 인한 성능 저하를 보완할 수 있는 강력한 도구이다. 가이드라인은 강력한 데이터베이스 설계에 대한 대안이 아니며 현명하게 사용하는 것이 중요하다. DB2 pureXML에 권장되는 베스트 프랙티스를 따르는 것이 좋다. 실행 플랜 문제점이 발생할 경우, 가이드라인을 사용하여 최적화 프로그램 플랜에 영향을 주고 성능 문제점을 완화할 수 있다.

참고자료

교육

• The DB2 pureXML Cookbook(IBM Press, 2009년 8월): DB2 pureXML에 대한 자세한 정보를 볼 수 있다.
  
  
• "15가지 베스트 프랙티스: DB2의 pureXML 성능 향상"(developerWorks, 2009년 5월): DB2에서 최대 XML 성능을 얻기 위한 몇 가지 XML 관련 성능 팁에 대해 알아보자.
  
  
• "Exploit XML indexes for XML query performance in DB2 9"(developerWorks, 2009년 7월): XML 인덱스를 사용하여 XML 쿼리의 속도를 향상시키는 방법에 대해 알아보자.
  
  
• pureXML wiki: DB2의 XML 기술에 대한 최신 정보를 볼 수 있다.
  
  
• DB2 LUW Information Center: 최신 COPS 스키마를 확인할 수 있다.
  
  
• TPoX(Transaction Processing over XML) 웹 사이트: TPoX XML 벤치마크에 대한 정보를 볼 수 있다.
  
  
• developerWorks Information Management 영역: Information Management에 대한 추가 정보를 제공한다. 기술 자료, 사용법 기사, 교육, 다운로드, 제품 정보 등을 찾아볼 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
  
  

제품 및 기술 얻기

• developerWorks에서 직접 다운로드할 수 있는 IBM 시험판 소프트웨어를 사용하여 후속 개발 프로젝트를 구현해 보자.
  
  

토론

• 포럼에 참여하기.
  
  
• developerWorks 포럼 & 블로그와 My developerWorks community에 참여하자. 이러한 커뮤니티에서는 사용자의 개인 프로파일과 사용자 정의 홈 페이지를 통해 관심을 가지고 있는 developerWorks의 여러 주제를 추적할 수 있으며 다른 developerWorks 사용자들과 의견을 나눌 수도 있다.
  
  

필자소개

Priya Baliga는 산호세 소재의 Silicon Valley Labs에 있는 DB2 LUW XML Optimizer 팀 소속의 Software Engineer이다. 컴퓨터 과학 석사 학위를 받은 이후 2004년부터 IBM과 함께 일하고 있다. 다양한 데이터베이스 개발 역할을 맡아왔던 그녀의 최근 역할은 WebSphere Federation Server의 보안 개발 팀장이다. Priya는 데이터베이스 관리 및 보안의 다양한 영역과 관련된 특허 및 저서를 보유하고 있다.

Anjali Betawadkar-Norwood는 WebSphere Federation Server의 검색 최적화와 컴파일과 관련하여 팀을 이끌고 있다. 6년 동안 이 제품과 관련한 일을 해왔다. 검색 최적화와 병렬 검색 프로세싱에 관심을 갖고 있다. Indian Institute of Technology (IIT)(인도, Kanpur)에서 Master of Technology를 받았다.

아티클 순위

의견

위로

목차

• 소개
• 이 기사에서 사용하는 데이터베이스 설정
• 프로파일 인프라 개요
• 최적화 프로파일을 설정하고 사용하는 단계별 방법
• XML 가이드라인의 사용 시나리오
• 문제점 해결 팁 및 간단한 방법
• 결론
• 참고자료
• 필자소개
• 의견