DB2 튜닝 가이드 Part 6: 튜닝과 트러블슈팅(2) CPU 병목
대부분의 DB2 시스템은 '성능 전개(performance evolution)' 과정을 거친다. 시스템을 배포한 후 시스템 모니터링을 하고, 만약 문제점이 발생되면 문제해결 과정을 거친다. DB2 튜닝 가이드는 단계별로 최상의 성능을 위한 최적의 설정을 제시함으로써, DB2 시스템 성능이 최상을 유지하도록 도와준다. 이번 회에서는 성능 튜닝과 트러블슈팅 과정 중 CPU 병목 상태에서의 해결 방안을 살펴본다.<연재순서>
DB2 튜닝 가이드 Part 1: 최상의 성능을 위한 시스템 구성
DB2 튜닝 가이드 Part 2: 최상의 성능을 위한 DB 구성 (1)
DB2 튜닝 가이드 Part 3: 최상의 성능을 위한 DB 구성 (2)
DB2 튜닝 가이드 Part 4: 시스템 성능 모니터링
DB2 튜닝 가이드 Part 5: 튜닝과 트러블슈팅(1) 디스크 병목
DB2 튜닝 가이드 Part 6: 튜닝과 트러블슈팅(1) CPU 병목
시스템 병목상태 > CPU 병목상태
CPU 병목상태는 크게 두 가지로 나타난다.
1. 전체 CPU 포화상태
시스템의 모든 프로세서가 사용 중이다. 이는 일반적으로 vmstat 또는 perfmon 명령을 사용하여 표시되는 사용자 CPU 시간과 시스템 CPU 시간의 합계로 측정된다. CPU 활용률이 95%가 넘으면 포화된 것으로 간주된다.
2. 개별 CPU 포화상태
한 프로세서는 완전히 포화되었지만 다른 프로세서가 부분적으로 또는 완전히 유휴 상태인 시스템 로드에 해당된다. 이는 일반적으로 시스템에 단 한 개의 과중한 애플리케이션 또는 문이 실행중인 경우 발생한다. 사용 가능한 CPU 용량이 있음에도 불구하고 시스템이 해당 용량을 사용할 수 없으며 따라서 애플리케이션 또는 문의 속도가 사용량이 높은 프로세서 코어 한 개의 성능에 의해 제한된다.또한 사용자 모드와 시스템 모드 CPU 소비 사이의 차이점도 고려해야 한다.
사용자 CPU 시간은 프로세서가 애플리케이션 또는 Linux용 DB2와 같은 미들웨어 소프트웨어를 운영체체 커널 외부에서 실행하는 동안 누적된다.
시스템 CPU 시간은 운영체제 커널에서 실행되는 동안 누적된다. 이러한 양은 개별적으로 보고되며 둘 사이의 배분에 따라 CPU 병목상태의 원인을 확인하는데 도움을 줄 수 있다.
사용자 대시스템 CPU 시간 비율은 일반적으로 3:1과 4:1 사이다.병목상태인 시스템에서 사용자 대 시스템 CPU 시간의 균형이 이보다 높으면 증가된 사용자 CPU 시간에 대한 가능한 원인을 먼저 조사해야 한다.
시스템 병목상태 > CPU 병목상태 > 사용자 CPU 병목상태
DB2 서버에서 사용자 CPU 병목상태 원인의 대부분은 스냅샷과 문 이벤트 모니터를 통해 진단될 수 있다. 애플리케이션 스냅샷을 사용하여 또는 SYSIBMADM.SNAPAPPL 관리 뷰를 쿼리하여 어떤 사용자가 CPU 시간을 대부분 소비하는지 드릴다운하여 찾는다.
마찬가지로 동적 SQL 스냅샷에서 또는 다음과 같이 SYSIBMADM.SNAPDYN_SQL 관리 뷰를 쿼리하여 어떤 SQL 문이 대부분의 CPU 시간을 사용하는지 확인할 수도 있다.
일반적으로 CPU의 ‘공평한 몫 이상'을 소비하는 하나 이상의 문을 찾아야 한다. 이러한 문은 TOTAL_USR_CPU_TIME 및 TOTAL_USR_CPU_TIME_MS의 높고 증가하는 값으로 나타난다.동시에 정적 SQL 문도 고려한다. 위에서 언급한 바와 같이 정적 SQL 문은 스냅샷 모니터로 처리되지 않기 때문에 문 이벤트 모니터 또는 WLM 활동 이벤트 모니터를 사용하여 이데 대한 CPU 사용 정보를 수집해야 한다. 다음 단계를 사용하면 문 이벤트 모니터 오버헤드를 최소화할 수 있다.
- 이벤트 모니터에 대한 기본 BUFFERSIZE는 4페이지다. 성능을 향상하려면 512페이지로 증가시켜야 한다.
- 문 이벤트 모니터 테이블을 개별 테이블 스페이스에 만든다. 이렇게 하면 문 이벤트 모니터 데이터와 다른 테이블 간에 I/O 충돌을 방지한다. 또한 더 큰 페이지 크기를 선택할 수 있는 기회가 제공되어 SQL 문의 잘림을 최소화할 수 있다(아래 참조).
- CREATE EVENT MONITOR 문에서 TRUNC 옵션을 사용한다. 이 옵션은 SQL 문 텍스트가 개별 LOB 열에 저장되는 것이 아니라 다른 문 메트릭(예: 경과된 시간, CPU 시간 등)과 같은 행에 저장되게 한다. 이렇게 되면 SQL 문이 이벤트 모니터 출력에서 잘릴 수 있다. 이런 식으로 저장될 수 있는 SQL 문의 부분은 문 이벤트 모니터 테이블에 사용되는 페이지 크기에 따라 다르다(예: 4KB 페이지에서 약 3500바이트).
- WHERE 절을 사용하여 연결 또는 애플리케이션의 하위 세트에 대한 모니터링에 집중한다. 모니터링되는 연결에 일부 추가 오버헤드가 발생한다 하더라도 WHERE 절을 사용하면 이벤트 모니터링으로 인한 총 시스템 오버헤드가 감소된다.
이들을 모두 종합하고 LIST APPLICATIONS에서 관심 있는 연결의 애플리케이션 ID를 가져오면 다음과 같은 작업을 수행할 수 있다.
WLM 활동 모니터의 경우 원리는 유사하다. 대형 BUFFERSIZE, 개별 테이블 스페이스 및 TRUNC 옵션은 모두 오버헤드를 줄이기에 좋은 아이디어다. 활동 모니터는 WHERE 절을 지원하지 않지만 대신 활동 모니터가 정의된 워크로드 또는 서비스 클래스의 활동에 암시적으로 집중한다.WHERE 절과 마찬가지로 이러한 집중은 성능 오버헤드와 수집된 데이터의 양을 줄이는 매우 효과적인 방법이다. 활동 모니터에서 WITHOUT DETAILS 절을 사용하면 필요한 기본 CPU 소비 정보를 제공한다. WITH DETAILS 또는 WITH DETAILS AND VALUES를 증가시키면 유용할 수 있는 추가 정보를 제공하지만 현재 환경에서 모니터링 오버헤드가 문제가 되는 경우 일반적으로 WITHOUT DETAILS로 시작하여 추가 정보가 필요한 경우 DETAILS 또는 VALUES를 사용하는 것이 가장 좋다.
시스템 병목상태 > CPU 병목상태 > 사용자 CPU 병목상태 > 높은 CPU SQL
제공된 SQL 문이 소비하는 CPU의 양을 항상 감소시킬 수는 없지만 영향을 줄 수 있는 몇 가지 경우가 있다.1. 자주 실행되는 버퍼 내부 풀 테이블 스캔이 작은 핫 테이블을 쿼리하거나 조인에 참가하지만 적합한 인덱스가 없는 경우 상당한 양의 CPU 시간을 소비할 수 있다.증상은 다음과 같다.
- 상대적으로 짧은 문 실행 시간
- 실행 시간과 대략 같은 사용자 CPU 소비
- 설명 플랜(explain plan)에서의 관계 스캔
- db2pd -tcbstats에서 증가하는 스캔 수
- 문에 대한 버퍼 풀 물리적 데이터 읽기의 낮은 또는 매우 낮은 수
이러한 유형의 문은 일반적으로 병목상태로 간주되지 않지만 잦은 실행 및 높은 CPU 소비가 문제를 일으킬 수 있다. 이 경우 옵티마이저에 테이블 스캔에 대한 대체를 제공하는 인덱스를 만들어서 해결할 수 있다. 올바른 인덱스 정의는 쿼리에서 분명히 드러날 수 있지만 그렇지 않은 경우 디자인 관리자(Design Advisor)가 이를 도와줄 수 있다.2. SQL 문을 실행하는 애플리케이션이 문에서 생성하는 행의 일부만을 소비하는 경우 OPTIMIZE FOR n ROWS(OFnR) 또는 FETCH FIRST n ROWS ONLY(FEnRO) 절을 사용하면 CPU를 포함하여 모든 유형의 리소스 소비를 줄이는 데 도움이 될 수 있다. 특히 OFnR 및 FFnRO는 SQL 액세스 플랜을 최적화하여 호출하는 애플리케이션에 대한 결과 세트에 있는 전체 행의 반환을 최적화하기 보다는 결과 세트의 초기 행을 가장 효율적으로 반환할 수 있게 한다. OFnR만 사용하는 경우 런타임 시 n이 초과될 수 있다. 하지만 FFnRO는 애플리케이션에서 n 이상의 행을 반환하려고 해도 반환되지 못하게 한다.3. 위의 구성 섹션에서 언급한 바와 같이 유니코드 코드 페이지를 사용하여 문화적으로 올바른 데이터 정렬을 사용하면 특히 CPU 소비에 있어 상당한 양의 오버헤드를 발생시킬 수 있다. 오버헤드의 양은 SQL 문이 수행하는 문자열 비교(예: 술어 또는 ORDER BY 절로 인한 정렬에서) 수와 직접 관련되어 있기 때문에 문이 수행하는 비교 수를 줄이면 이에 따른 CPU 소비가 줄어 든다. 비교 수의 감소는 주로 술어 평가 및 결과 세트 순서 지정 모두에 대한 인덱스 사용을 장려하여 성취할 수 있다. 디자인 관리자는 테이블 스캔 및 정렬을 최소화하도록 적절한 인덱스를 디자인하는 데 매우 유용할 수 있다.4. 잠금 문제는 주로 충돌과 대기 시간 측면에서만 고려되지만 충돌이 없거나 조금 있는 경우라고 해도 잠금의 획득 또는 해제 과정에서 상당한 양의 CPU 시간을 소비할 수 있다. 테이블에 있는 많은 행을 검사하지만 자체적으로 실행되거나, 참조하는 테이블에 배타적으로 액세스하거나, 또는 동시에 실행되는 모든 애플리케이션이 테이블을 읽기 전용 모드로만 사용하기 때문에 잠금 충돌을 거의 일으키지 않는 애플리케이션 또는 문을 생각해 보자. 이와 같은 경우 테이블 레벨 잠금을 사용하면 CPU를 감소시키면서 필요한 수준의 격리를 달성할 수 있다.CPU 사이클을 대량으로 소비하는 것으로 보이는 개별 SQL 문이 없는 경우 CPU 사용을 전반적으로 증가시킬 수 있는 좀더 광범위한 잠재적인 문제가 있는 것이다.
시스템 병목상태 > CPU 병목상태 > 사용자 CPU 병목상태 > 매개변수 마커가 없는 동적 SQL
대부분의 애플리케이션은 매개변수 마커를 사용하는 것이 아니라 문 단편과 리터럴 값을 연결하여 SQL 문을 ‘즉석에서' 작성한다. (배포 통계와 함께 테이블을 쿼리하는 복합 SQL 문의 경우 포함된 리터럴이 SQL 옵티마이저로 하여금 더 나은 액세스 플랜을 선택하게 할 수 있다. 여기서는 포함된 리터럴의 혜택이 없는 경량의 문에 초점을 맞춘다.)
이런 식으로 생성된 문의 문자열이 문자열에 포함된 리터럴 값에서만 서로 다르다고 하더라도 애플리케이션이 쿼리를 준비하는 경우 DB2 시스템이 해당 문자열을 동적 SQL 캐시에서 찾는 것이 아니라 매번 컴파일해야 한다. 컴파일 비용이 매우 낮은 대단히 간단한 문인 경우에도 높은 문 볼륨에 대한 집계 비용은 상당할 수 있다.
이러한 문제에 대한 증상은 다음과 같이 나타날 수 있다.
- 동적 SQL 스냅샷에 있는 많은 수의 유사하지만 동일하지 않은 문. 이 문은 문에 포함된 리터럴 값에 의해서만 차이가 드러난다.
- 시스템이 안정된 상태에 이른 후에도 계속 증가하는 패키지 캐시 삽입의 값(SYSIBMADM.SNAPDB.PKG_CACHE_INSERTS).
이러한 오버헤드를 방지하는 가장 좋은 방법은 애플리케이션에서 간단한 동적 SQL 문에 대해 매개변수 마커를 사용하도록 하는 것이다.
시스템 병목상태 > CPU 병목상태 > 사용자 CPU 병목상태 > 유틸리티 실행 중
DB2 유틸리티는 확장이 잘 되며 시스템 리소스를 활용하여 가능한 한 빨리 작업을 수행하도록 디자인되었다. 이에 따라 유틸리티가 실행 중인 동안 CPU 소비가 상당히 증가할 수 있다. Load와 runstats는 주로 CPU 소비를 높이는 유틸리티의 좋은 예이지만 적절한 환경에서는 다른 유틸리티도 마찬가지로 작동할 수 있다. 어떤 유틸리티가 현재 실행 중인지 확인하려면 LIST UTILLITIES SHOW DETAIL 명령을 사용한다.유틸리티가 실행 중인 경우 다음과 같이 드릴다운하여 해당 CPU 소비를 확인할 수 있다. UNIX와 Linux 시스템의 경우 DB2 버전 9.5에 스레드된 엔진이 도입되기 전에는 간단한 ps 명령을 사용하여 유틸리티가 사용한 다양한 작업자 프로세스를, 예를 들어 해당 CPU 소비와 함께 볼 수 있었다. DB2 버전 9.5에서는 db2pd edus 명령으로 DB2 엔진 내부의 모든 스레드(DB2 프로세스 모델 참조)를 해당 사용자와 시스템 CPU 사용과 함께 표시할 수 있다. 이 명령은 작업자 스레드가 CPU 병목상태 배후에 있는지 확인하는 데 매우 유용하다.UTIL_IMPACT_PRIORITY를 설정하면 backup 및 runstats 유틸리티가 시스템에 미치는 영향의 양을 제한하는 데 유용할 수 있다. 또한 runstats의 오버헤드와 런타임은 이 정보가 알려져 있고 runstats 샘플링으로 활용하는 경우 SQL 술어와 관련계를 수집함으로써 축소할 수 있다. 후자에 대한 권장사항은 최적의 성능을 위한 쿼리 쓰기 및 튜닝에 포함되어 있다.기본적으로 LOAD 명령은 각 CPU에 대한 포맷터 스레드(db2lfrm)를 만들지만 CPU PARALLELISM N 옵션을 사용하면 포맷터의 수를 N으로 줄일 수 있어 보다 많은 CPU 용량을 시스템의 나머지에 돌려 준다. 일반적으로 UTIL_IMPACT_PRIORITY 또는 CPU PARALLELISM으로 유틸리티를 억제하면 유틸리티의 런타임이 조화롭게 확장된다.
시스템 병목상태 > CPU 병목상태 > 사용자 CPU 병목상태 > 임시 개체 정리 오버헤드
시스템 임시 테이블이 더 이상 필요하지 않아 삭제할 때 DB2 시스템은 버퍼 풀에서 필요하지 않은 페이지를 제거해야 한다. 이 작업이 자주 발생하고 임시 테이블이 일반 사용자 데이터와 함께 버퍼 풀을 공유하는 경우 충돌을 해결하고 페이지를 처리하는 데 추가 CPU 사이클을 소비할 수 있다. 이러한 문제는 복합 쿼리보다는 트랜잭션 처리를 수행하는 시스템에서 보다 일반적이다. 많은 양의 임시 테이블이 만들어지고 제거되는 것으로 테이블 스냅샷에 나타나는 경우 해당 버퍼 풀에 임시 테이블 스페이스를 배치하는 것이 좋다. 이렇게 하면 추가 충돌과 프로세싱 오버헤드를 제거하고 CPU 소비를 줄일 수 있다.
시스템 병목상태 > CPU 병목상태 > 시스템 CPU 병목상태
사용자 CPU는 대부분의 CPU 바인딩된 환경에서 지배적인 요소가 되는 경향이 있지만 때로는 시스템 CPU 시간이 지배적인 요소가 될 수 있다. 하지만 이 경우 진단과 해결할 수 있는 문제의 수는 매우 적다.DB2 시스템과 관련하여 높은 시스템 CPU 시간에 대한 하나의 원인은 운영체제의 높은 컨텍스트 스위치 비율이다. 컨텍스트 스위치는 OS가 처리해야 하는 다른 작업 사이를 교차하는데 사용된다. 또한 OS의 여러 다른 규칙으로 발생하며 일반적으로 시스템이 처리해야 하는 모든 작업의 원만한 진행을 제공한다. 하지만 컨텍스트 스위치가 너무 자주 일어나면 자체적으로 현저한 양의 CPU 시간을 소비하게 될 수 있다. UNIX 시스템의 경우 컨텍스트 스위치는 vmstat 명령을 사용하여 ‘CS' 열에서 볼 수 있다. 초당 컨텍스트 스위치 비율이 75,000에서 100,000 이상인 경우 매우 높은 것으로 간주된다.
시스템 병목상태 > CPU 병목상태 > 높은 시스템 CPU > 높은 컨텍스트 스위치
DB2 시스템에서 높은 컨텍스트 스위치 비율의 일반적인 원인은 데이터베이스 연결의 수가 매우 많은 것이다. 각 연결에는 이를 위해 하나 이상의 데이터베이스 에이전트가 실행되기 때문에 특히 짧은 트랜잭션으로 연결이 활성화되는 경우 높은 컨텍스트 스위치 비율과 높은 시스템 CPU 소비가 발생할 수 있다. 이를 방지하기 위한 한 가지 방법은 DB2 연결 집중 장치를 사용하도록 설정하는 것이다. 이렇게 하면 여러 연결이 한 개의 에이전트를 공유할 수 있기 때문에 에이전트 수를 줄이고(메모리 공간을 절약하고) 컨텍스트 스위치 비율을 감소할 수 있다.장치 인터럽트도 시스템 CPU 시간을 높이는 원인이 될 수 있다. 인터럽트는 네트워크 어댑터와 같은 장치가 OS로부터 ‘주의'를 요할 때 발생한다. 개별 인터럽트의 비용은 높지 않지만 인터럽트 비율이 너무 높이 올라가면 시스템의 집계 로드가 상당할 수 있다. 다행히 현대의 네트워크 및 디스크 어댑터는 OS로부터 매우 독립적이어서 불과 몇 년 전의 장치에 비하여 훨씬 적은 인터럽트를 발생시킨다. 디스크 인터럽트로 인한 큰 오버헤드는 드물지만 네트워크 집약적인 클라이언트/서버 환경(예: 대부분의 SAP R/3 설치)의 경우 네트워크 인터럽트로 인해 부과되는 로드가 꽤 높을 수 있다. 서버에서 네트워크 기반 오버헤드를 줄이기 위해 취할 수 있는 단계가 있지만 이러한 유형의 튜닝은 본 글의 범위에서 벗어난다. 이 경우 네트워크 관리자가 관여하여 문제를 확인하고 해결하는 것이 가장 좋다.애플리케이션 로직(특히 긴 트랜잭션의 경우)을 SQL 저장 프로시저에 포함시킬 수 있는 경우 컨텍스트 스위치 및 네트워크 트래픽을 줄일 수 있다. 컨텍스트 스위치 측면에서만 애플리케이션 로직을 서버에 가져오는 것이 아니라 로직을 DB2 에이전트에 바로 밀어 넣는다. 이렇게 하면 에이전트와 클라이언트 애플리케이션 사이의 SQL 호출, 결과, 컨텍스트 스위치의 앞뒤 흐름이 제거된다.
시스템 병목상태 > CPU 병목상태 > 높은 시스템 CPU > 높은 장치 인터럽트
DB2 시스템에서는 가능한 한 사용되지 않는 시스템 메모리가 거의 없도록 함으로써 시스템 메모리를 활용하도록 노력한다. 유감스럽게도 메모리를 과도하게 할당하는 경우, 즉 DB2 또는 다른 소프트웨어가 시스템에 있는 물리적인 메모리 양보다 더 많이 사용하도록 잘못 구성된 경우 페이징으로 인하여 시스템 CPU 오버헤드(및 디스크 오버헤드)가 발생할 수 있다. 이러한 상황은 UNIX 기반 시스템의 경우 vmstat에서 보고되는 낮은 사용 가능한 메모리와 높은 페이지 인 또는 페이지 아웃 활동(각각 free, pi, po 열)으로 확인된다. 이것은 메모리 할당을 페이징이 시작되는 지점 아래로 축소하여 해결할 수 있다.이를 약간 어렵게 만들 수 있는 한 가지 경우는 파일 시스템 캐싱으로 인해 소비되는 메모리다. 일반적으로 OS는 ‘사용 가능한' 메모리를 사용하여 디스크로부터 데이터를 버퍼링함으로써 I/O를 방지한다. 파일 시스템 캐시에서 사용하는 메모리를 필요한 경우 DB2 데이터베이스에서 사용할 수 있지만 일반적으로는 DB2 데이터베이스와 파일 시스템이 메모리를 둘러싸고 ‘경쟁'이 일어나는 경우를 방지하려고 한다. 파일 시스템 캐시 프로세싱 자체는 사용자 모드에서 발생하지만(즉 시스템 CPU의 소비자가 아님) 관련된 가상 메모리 관리도 시스템 시간을 끌어 올릴 수 있다. DB2에서 파일 시스템 캐싱 영향을 방지하는 방법에 대한 권장사항은 본 글의 이전 DB2 구성 섹션에 설명되어 있다. AIX의 경우 vmo 매개변수 LRU_FILE_REPAGE=0(위에서도 설명됨)을 사용하여 심지어 DB2 외부에서도 파일 시스템 캐시 오버헤드를 제어할 수 있다.
시스템 병목상태 > CPU 병목상태 > 높은 시스템 CPU > 메모리의 과도한 할당
물리적 메모리가 매우 많은 서버(100GB 이상)는 시스템이 대형 메모리 페이지를 사용하도록 구성되지 않은 경우 추가 CPU 오버헤드를 발생시킬 수 있다. OS는 메모리를 페이지 레벨 단위로 관리한다. OS 메모리 페이지는 DB2 페이지와 다르다. 일반적인 페이지 크기는 4KB로 100GB RAM이 있는 시스템의 경우 OS가 2억 5000만 개의 페이지 테이블 항목을 관리해야 한다. 대부분의 운영 체제는 대형 페이지 크기를 지원하여 가상 메모리 관리의 오버헤드를 감소시킨다. 예를 들어 AIX 운영 체제의 경우 실제로는 거의 사용되지 않지만 최대 16GB까지의 대형 페이지를 지원한다. DB2 데이터베이스는 시스템에서 사용하도록 설정된 경우 자동으로 64KB 페이지를 사용하며 수동으로 다른 크기를 선택할 수 있다(더 자세한 내용은 64비트 환경에서 대형 페이지 지원 사용 참조).대부분의 대형 메모리 시스템(AIX 시스템)에서는 64KB 페이지를 사용하도록 설정하여 DB2 시스템에서 이를 사용할 수 있게 하는 것이 좋다. 이것이 최상의 성능과 대형 페이지 크기를 사용함으로써 발생할 수 있는 부작용 사이의 최선의 절충이다. Linux 시스템의 경우 DB2 데이터베이스에 대 수동으로 활성화해야 한다.AIX 시스템에서 vmstat P ALL을 사용하면 사용할 수 있는 페이지 크기와 시스템에서 사용 중인 페이지 크기가 표시된다. 시스템에 64KB 페이지가 활성화되어 있고 DB2 데이터베이스를 실행 중인 경우 vmstat P ALL에서 DB2 데이터베이스 매니저가 메모리를 할당한 64KB 페이지의 대형 할당이 표시되어야 한다. 그렇지 않고 시스템에 많은 양의 RAM이 있으면 이로 인해 정상보다 높은 시스템 CPU가 소비될 수 있다.
시스템 병목상태 > CPU 병목상태 > 높은 시스템 CPU > 작은 메모리 페이지
시스템 CPU 병목상태: 전체 그림
필자소개
Steve Rees:DB2 성능 품질관리 선임 매니저
Thomas Rech:DB2 SAP Center of Excellence 선임 컨설턴트
Gang Shen:IBM Data Servers 기술 영업 전문가
Roman B. Melnyk:DB2 Information Development
출처 : KDUG (http://www.kdug.kr/)제공 : DB포탈사이트 DBguide.net
