데이터베이스 성능 튜닝

데이터베이스에서 성능 조정을 수행하는 것은 모든 데이터베이스 관리자(DBA)가 지속적이고 정기적으로 수행해야 하는 가장 일반적이면서도 가장 중요한 활동 중 하나입니다. 전문가들은 데이터베이스를 정기적으로 미세 조정하여 성능을 최적화할 것을 권장합니다. 미세 조정을 통해 사용자는 보고서 및 쿼리를 더 빠르게 실행하고 더 빠르게 결과를 얻을 수 있습니다. 이 게시물은 Oracle® 데이터베이스 문제 해결 및 조정을 위한 몇 가지 기술을 공유합니다.

조정 단계

먼저 문제가 발생한 영역을 식별해야 합니다. 문제를 유발할 수 있는 영역에는 운영 체제, 데이터베이스, 메모리 부족 등이 있습니다. 문제 영역을 식별한 후 최대 이점을 위해 영역 조정을 진행할 수 있습니다. 이 블로그는 성능 조정에만 중점을 둡니다.

Oracle은 DBA에게 문제 진단 및 성능 문제 해결에 도움이 되는 몇 가지 도구를 제공했습니다. 이러한 도구에는 문제가 있는 기간 동안 생성하고 분석에 사용할 수 있는 자동 데이터베이스 진단 모니터(ADDM) 및 자동 작업 부하 저장소(AWR) 보고서가 포함됩니다. 왜곡되거나 조정 가능한 구성 요소를 찾으려면 도구를 사용해야 합니다.

AWR 보고서의 주요 시간 이벤트

AWR은 특정 인스턴스의 메모리 사용량을 통계 형식으로 요약한 보고서를 생성할 수 있는 도구입니다. AWR 보고서를 생성하려면 sqlplus 프롬프트에서 다음 파일을 실행하십시오.

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

사전 저장된 템플릿을 사용하여 HTML 형식의 AWR 보고서를 생성합니다. AWR 보고서를 생성한 후 Top TimedEvents를 빠르게 볼 수 있습니다. 다음 이미지와 같이 문제 영역을 식별하는 AWR 보고서의 섹션:

ADDM 조정 세션

일반적으로 문제가 보고되면 DBA는 해당 영역만 해결하거나 특정 문제를 해결할 수 있습니다. 그러나 문제를 올바르게 식별하고 해결하지 않으면 향후 더 큰 문제가 발생할 수 있습니다. DBAcan은 여기서 더 큰 그림을 놓칠 수 있습니다. DBA가 데이터베이스 문제에 대한 더 크고 완전한 그림을 얻을 수 있도록 Oracle은 DBA를 위한 또 다른 도구인 ADDM을 제공했습니다. ADDM 조정 세션은 수동 조정 세션과 유사한 절차를 따릅니다. 다음 이미지는 비교를 보여줍니다.

이미지 출처:Oracle 11G Performance Tuning 교육 매뉴얼

SQL을 사용하거나 OEM(Oracle Enterprise Manager)을 통해 ADDM 보고서를 검색합니다. 다음 이미지는 샘플 SQL을 보여줍니다.

잘못된 SQL 및 실행 계획

AWR 또는 ADDM 보고서가 잘못된 SQL/SQLID 섹션을 식별한 후 DBMS_XPLAN을 사용하여 이에 대한 추가 정보를 수집할 수 있습니다. DBMS_XPLAN 패키지는 실행(exec) 계획을 검색하고 표시하는 데 사용할 수 있는 다음 테이블 함수를 제공합니다.

DISPLAY
DISPLAY_AWR
 select plan_table_output from table (DBMS_XPLAN.DISPLAY_AWR('fs22b3fgfh8xc'));
DISPLAY_CURSOR

다음 이미지는 EXPLAIN PLAN의 샘플 출력을 보여줍니다. 명령을 실행하고 쿼리가 전체 테이블 스캔을 사용하는지 또는 일부 인덱스를 사용하여 데이터 범위를 좁히는지 식별합니다.

ADDM 보고서는 새 인덱스를 생성하여 성능상의 이점을 얻을 수 있는지 여부를 반영합니다. OEM에서 SQL Tuning Advisor를 실행하여 쿼리를 미세 조정하고 더 나은 실행 계획을 사용할 수도 있습니다. 대부분의 경우 문제가 있는 SQL에 대해 더 나은 계획을 사용하면 주요 성능 문제가 해결됩니다.

SQL 튜닝 어드바이저

SQL Tuning Advisor는 SQL 권한 부여 ID(SQLID)를 사용하여 분석하고 솔루션을 제안함으로써 SQL 문을 분석하고 성능 권장 사항을 얻는 데 도움이 됩니다. SQL Tuning Advisor는 다음 소스를 분석합니다.

상위 활동:현재 활성인 상위 SQL 문을 분석합니다.
SQL 튜닝 집합:제공한 SQL 문 집합을 분석합니다.
기록 SQL(AWR):AWR 스냅샷으로 수집된 명령문에서 SQL 문을 분석합니다.

다음 스크린샷은 몇 가지 예를 보여줍니다.

장기 실행 요청

Oracle eBusiness Suite 데이터베이스에서 장기 실행 요청 문제는 대부분 몇 가지 동시 요청이 계속 실행되는 곳에서 발생합니다. 이 문제를 해결하려면 동시 요청과 관련된 데이터베이스 세션에 대한 추가 정보를 수집해야 합니다. 다음 이미지는 이를 수집하는 단계를 보여줍니다.

정보:

오라클 데이터베이스 메모리 매개변수

AWR 보고서를 검토한 후 DBA는 해당 캐시의 캐시 적중률이 다른 캐시보다 낮기 때문에 미세 조정이 필요한 캐시를 쉽게 식별할 수 있습니다. 다음 이미지는 인스턴스 전체 메모리 조정을 위해 고려해야 하는 몇 가지 상위 데이터베이스 매개변수를 보여줍니다.

이미지 출처: https://ora-performance-tuning.blogspot.com/2014/02/automatic-shared-memory-management.html

일반적으로 관찰되는 대기 이벤트

다음 표는 몇 가지 일반적인 대기 이벤트와 가능한 원인을 보여줍니다.

데이터베이스 성능 튜닝 (

표 출처:Oracle Performance Tuning 11G OCP 교육 매뉴얼, 20장, 24페이지

상위 10가지 조정 문제

고객은 일반적으로 다음과 같은 10가지 조정 문제에 직면합니다.

잘못된 연결 관리: 개발자는 응용 프로그램의 데이터베이스에 연결하는 코드를 작성하거나 데이터베이스에서 데이터를 가져오는 쿼리를 실행합니다. 데이터를 가져오고 더 이상 필요하지 않으면 코드에서 데이터베이스에 대한 연결을 닫아야 합니다. 그러나 이것은 종종 발생하지 않으므로 데이터베이스의 비활성 세션 수가 증가합니다. 이러한 세션은 다른 활성 연결에 사용될 수 있는 귀중한 리소스를 사용합니다.
커서 및 공유 풀의 잘못된 사용: 커서는 대부분 사용되지 않는 개발자 무기고의 도구입니다. 커서가 없으면 Oracle은 실행할 때마다 코드를 하드 파싱해야 합니다. 이는 반복적으로 실행되는 SQL 쿼리의 성능에 큰 영향을 미칩니다. DBA는 인스턴스 효율성 백분율 - Execute to Parse %를 조사하여 이 문제를 식별할 수 있습니다. AWR 보고서 섹션.
잘못된 SQL: SQL 쿼리가 작성되는 방식(데이터를 가져오기 위한 조인 조건 포함)은 실행된 후 해당 SQL의 성능에 상당한 영향을 미칩니다. 큰 테이블에 대한 전체 테이블 스캔을 피해야 합니다. SQL이 준비된 후 개발자와 DBA는 데이터베이스에서 SQL을 실행하는 비용을 이해하기 위해 해당 SQL에 대한 설명 계획을 실행해야 합니다. 커서, 바인드 변수, 인덱스를 사용하여 효율성을 높일 수 있습니다.
비표준 초기화 매개변수 사용: DBA는 항상 표준 또는 권장 초기화 매개변수만 사용해야 합니다. Oracle SR(서비스 요청)에서 제안한 경우에만 비표준 초기화 매개변수를 사용하십시오.
데이터베이스 I/O 오류 발생: 데이터베이스 하드웨어를 선택하는 DBA가 여러 디스크에 데이터베이스를 배포하고 데이터베이스 서버에서 최종 사용자에게 데이터가 이동하는 속도에 대해 네트워크 팀을 토론에 참여시켜야 할 때. DBA는 병목 현상이나 성능 문제를 피하기 위해 네트워크 스위치와 라우터의 속도를 고려해야 합니다.
리두 로그 설정 문제: 재실행 로그는 재실행 버퍼의 데이터를 저장하는 데 필요하므로 충돌이 발생한 경우 Oracle이 트랜잭션을 재실행할 수 있습니다. 리두 로그 크기가 적절하지 않으면 데이터베이스에서 여러 스위치가 발생하여 성능 문제를 일으킬 수 있습니다. 이것은 또한 아카이브 생성에 대한 부하를 증가시킵니다.
버퍼 캐시의 데이터 블록 직렬화: 이는 사용 가능한 목록 그룹 또는 실행 취소 세그먼트의 부족으로 인해 발생합니다. 이러한 상황은 활성 사용자 기반이 많지만 실행 취소 세그먼트가 적은 삽입 작업이 많은 데이터베이스에서 발생하여 궁극적으로 성능 문제로 이어집니다.
전체 테이블 스캔: Explain Plan을 실행하여 쿼리에서 전체 테이블 스캔을 확인하십시오. 일반적으로 전체 테이블 스캔을 수행하는 쿼리는 잘못된 SQL 디자인을 반영하며 인덱스를 사용하고 필요한 데이터를 좁혀 수정할 수 있습니다. 소수의 경우, 특히 작은 테이블의 경우 전체 테이블 스캔이 도움이 될 수 있습니다.
재귀 SQL: 재귀 SQL은 올바르게 사용하면 개발자에게 도움이 될 수 있지만 양날의 검이 될 수 있습니다. 올바르게 수행하면 출력을 효율적으로 제공합니다. 그렇지 않으면 데이터베이스 성능에 큰 영향을 미칩니다.
디스크 내 정렬: 디스크 내 정렬은 데이터베이스에 대해 매우 비용이 많이 드는 작업입니다. 이는 SQL 설계가 불량하고 최적화가 잘못되었음을 나타냅니다. 인스턴스 활동 통계 – 정렬(디스크)에서 문제를 식별할 수 있습니다. AWR 보고서 섹션.

결론

DBA는 성능 조정을 위해 다양한 영역을 고려해야 하지만 데이터베이스 세계에서 성능 조정은 데이터베이스 및 애플리케이션 설계 단계에서 시작됩니다. 성능 조정 관점을 염두에 두고 설계된 데이터베이스 및 애플리케이션은 성능 조정을 고려하지 않고 설계된 애플리케이션보다 훨씬 확장성이 뛰어납니다.

이 블로그에서 다루는 성능 조정 사항은 빙산의 일각에 불과합니다. 동료 DBA가 데이터베이스 성능을 전반적으로 관리하기 위해 이 주제에 대해 계속해서 읽을 것을 권장합니다.

피드백 탭을 사용하여 의견을 남기거나 질문하십시오.

데이터베이스 서비스에 대해 자세히 알아보십시오.

Rackspace는 Oracle 제품에 대한 광범위한 지식을 보유하고 있습니다. Oracle 투자를 극대화할 수 있는 방법에 대해 자세히 알아보십시오.