데이터베이스 관리자를 위한 개념

이 페이지의 스크립트 콘텐츠는 탐색 용도로만 사용되며 어떤 방식으로든 콘텐츠를 변경하지 않습니다.

이 부분에서는 데이터베이스 관리자를 위한 업무, 도구 및 필수 지식에 대해 설명합니다.

데이터베이스 관리자의 업무

DBA(데이터베이스 관리자)의 주요 업무는 유저가 엔터프라이즈 데이터를 사용할 수 있도록 하는 것입니다.

DBA는 개발자와 긴밀히 협력하여 응용 프로그램이 데이터베이스를 효율적으로 사용하고 시스템 관리자와 협력하여 물리적 리소스가 적절하고 효율적으로 사용되도록 해야 합니다.

Oracle DBA는 Oracle AI Database 아키텍처 및 데이터베이스 작동 방식을 이해해야 합니다. DBA는 다음 작업을 수행할 수 있습니다.

유저 유형과 롤 및 책임은 데이터베이스 환경에 따라 다릅니다. 작은 데이터베이스에는 하나의 DBA가 있을 수 있습니다. 초대형 데이터베이스는 보안 관리자, 백업 운영자 및 응용 프로그램 관리자와 같은 여러 전문가로 DBA 업무를 나눌 수 있습니다.

참조:

데이터베이스 관리자용 도구

Oracle은 데이터베이스 관리에 사용할 수 있는 여러 가지 도구를 제공합니다.

이 절에서는 일반적으로 사용되는 몇 가지 도구에 대해 설명합니다.

Oracle Enterprise Manager

Oracle Enterprise Manager(Enterprise Manager)는 Oracle 데이터베이스, Exadata 데이터베이스 시스템, Fusion Middleware, Oracle 애플리케이션, 서버, 스토리지, 비Oracle 하드웨어 및 소프트웨어의 관리를 제공하는 웹 기반 시스템 관리 도구입니다.

Oracle Enterprise Manager Cloud Control

Oracle Enterprise Manager Cloud Control(Cloud Control)은 관리자에게 Oracle 기술 스택 및 비Oracle 구성 요소 전반에 대한 완벽한 모니터 기능을 제공하는 웹 기반 인터페이스입니다.

FAN(빠른 응용 프로그램 통지) 구성 요소를 사용할 수 없거나 성능 문제가 발생할 수 있습니다. 이 경우 Cloud Control은 관리자가 적절한 Recovery 작업을 수행할 수 있도록 자동으로 생성된 Alert를 표시합니다.

Cloud Control의 구성 요소는 다음과 같습니다.

참조:

Oracle Enterprise Manager Database Express 12c

Oracle Enterprise Manager Database Express(EM Express)는 Oracle 데이터베이스에 내장된 웹 관리 제품입니다. 특별한 설치 또는 관리가 필요하지 않습니다.

EM Express에는 Cloud Control의 주요 성능 관리 및 기본 관리 페이지가 포함되어 있습니다. 이 페이지에는 다음과 같은 항목이 포함됩니다.

EM Express 콘솔을 통해 온라인으로, Active Reports 기술을 통해 오프라인으로 이러한 기능에 액세스할 수 있습니다. 아키텍처 측면에서 EM Express에는 미드티어나 미들웨어 구성 요소가 없으므로 데이터베이스 서버의 오버헤드가 무시할 수 있습니다.

EM Express를 사용하여 유저 보안 관리, 데이터베이스 메모리 및 저장 영역 관리 등의 관리 작업을 수행할 수 있습니다. 데이터베이스에 관한 성능 및 상태 정보를 볼 수도 있습니다.

참조: Oracle AI Database Get Started with Performance Tuning EM Express를 사용하여 데이터베이스를 관리하는 방법 학습

SQL*Plus

SQL*Plus는 모든 Oracle AI Database 설치에 포함된 대화식 일괄 처리 질의 도구입니다.

이 툴에는 데이터베이스에 접속할 때 클라이언트 역할을 하는 명령행 사용자 인터페이스가 포함되어 있습니다. SQL*Plus에는 자체의 명령과 환경이 있습니다. SQL, PL/SQL, SQL*Plus 및 운영 체제 명령을 입력 및 실행하여 다음과 같은 작업을 수행할 수 있습니다.

SQL*Plus를 사용하여 보고서를 대화형으로 생성하거나 일괄 처리 프로세스로 생성하고, 결과를 텍스트 파일이나 화면으로 출력하거나 인터넷에서 찾아볼 수 있게 HTML 파일로 출력할 수 있습니다. HTML 출력 기능을 사용하면 보고서를 동적으로 생성할 수 있습니다.

참조: SQL*Plus에 대한 자세한 내용은 SQL*Plus User's Guide and Reference를 참조하십시오.

데이터베이스 설치 및 구성 도구

Oracle은 Oracle AI Database 소프트웨어 설치 및 구성 작업을 간소화하는 몇 가지 도구를 제공합니다.

다음 표에서는 지원되는 도구에 대해 설명합니다.

데이터베이스 설치 및 구성을 위한 표 1 도구

도구 설명 자세히 알아보기
Oracle Universal Installer(OUI) OUI는 Oracle AI Database 소프트웨어를 확인, 설치 및 제거할 수 있는 GUI 유틸리티입니다. 설치 과정을 안내하는 온라인 도움말을 사용할 수 있습니다. 설치 과정을 안내하는 온라인 도움말
DBUA (Database Upgrade Assistant) DBUA는 대화식으로 데이터베이스 업그레이드를 안내하고 새 릴리스에 맞게 데이터베이스를 구성합니다. DBUA는 일반적으로 수동으로 수행하는 모든 작업을 수행하여 업그레이드를 자동화합니다. DBUA는 테이블스페이스 및 온라인 리두 로그와 같은 구성 옵션에 대한 권장 사항을 제공합니다. Oracle AI Database 2일 DBA - DBUA를 사용하여 데이터베이스를 업그레이드하는 방법 학습
DBCA(Database Configuration Assistant) DBCA는 데이터베이스 생성 및 구성을 위한 그래픽 인터페이스와 안내식 워크플로우를 제공합니다. 이 툴을 사용하여 Oracle 제공 템플리트에서 데이터베이스를 생성하거나 고유의 데이터베이스 및 템플리트를 생성할 수 있습니다. Oracle AI Database Administrator's Guide - DBCA를 사용한 데이터베이스 생성 방법 학습

Oracle Net 구성 및 관리 도구

Oracle Net Services는 이기종의 분산 환경에서 전사적 접속 솔루션을 제공합니다. Oracle Net Services의 구성 요소인 Oracle Net은 클라이언트 응용 프로그램에서 데이터베이스로 네트워크 세션을 사용으로 설정합니다.

다음 툴을 사용하여 Oracle Net Services를 구성 및 관리할 수 있습니다.

참조:

데이터 이동 및 분석 도구

Oracle AI Database에는 데이터 이동 및 분석을 지원하는 여러 유틸리티가 포함되어 있습니다.

예를 들어, 데이터베이스 유틸리티를 사용하여 다음을 수행할 수 있습니다.

표 2 데이터 이동 및 분석 작업

태스크 자세히 알아보기
운영 체제 파일에서 Oracle AI Database 테이블로 데이터 로드 "SQL*Loader"
데이터베이스 간에 데이터 및 메타 데이터 이동 "Oracle Data Pump 익스포트 및 임포트"
SQL 인터페이스를 통해 리두 로그 파일 질의 "Oracle LogMiner"
Oracle AI Database 데이터 관리 "ADRCI(ADR Command Interpreter)"

다른 작업에는 DBVERIFY를 사용하여 오프라인 데이터베이스나 데이터 파일에 대해 물리적 데이터 구조 무결성 검사를 수행하거나 DBNEWID 유틸리티를 사용하여 운영 데이터베이스의 DBID(데이터베이스 식별자) 또는 데이터베이스 이름을 변경하는 작업이 포함됩니다.

참고:

참조:

SQL*Loader

SQL*Loader는 데이터 파일(내부 데이터베이스 데이터 파일과 혼동하지 않음)이라는 외부 파일에서 데이터베이스 테이블로 데이터를 로드합니다. SQL*Loader에는 데이터 파일의 데이터 형식을 거의 제한하지 않는 강력한 데이터 구문 분석 엔진이 있습니다.

SQL*Loader를 사용하여 다음을 수행할 수 있습니다.

일반적인 SQL*Loader 세션은 SQL*Loader 콘트롤 파일과 하나 이상의 데이터 파일을 입력하는 데 사용됩니다. 출력은 Oracle 데이터베이스, 로그 파일, BAD 파일 및 폐기 파일일 수 있습니다. 다음 그림은 일반적인 SQL*Loader 세션의 흐름을 보여줍니다.

그림 1: SQL*Loader 세션

그림 cncpt271.gif에 대한 설명

또한 다음 예제와 같이 SQL*Loader 명령에서 table 파라미터를 지정할 때 활성화되는 SQL*Loader express 모드를 사용할 수도 있습니다.

% sqlldr hr table=employees

콘트롤 파일은 허용되지 않으므로 SQL*Loader의 사용이 쉬워집니다. SQL*Loader는 Control File의 구문을 분석하는 대신 테이블 열 정의를 사용하여 입력 데이터 유형을 확인합니다. SQL*Loader는 문자 집합, 필드 구분자 및 데이터 이름, 로그 파일 및 BAD 파일을 비롯한 몇 가지 기본 가정을 수행합니다. 명령행 파라미터를 사용하여 대부분의 기본값을 재정의할 수 있습니다.

참조:

Oracle Data Pump 엑스포트 및 임포트

Oracle Data Pump를 사용하면 데이터베이스 간에 데이터와 메타 데이터를 빠르게 이동할 수 있습니다.

이 기술은 다음과 같은 Oracle AI Database 데이터 이동 유틸리티의 기반이 됩니다.

Oracle Data Pump는 다음과 같은 개별 부분으로 구성됩니다.

다음 그림은 Oracle Data Pump가 SQL*Loader 및 External Table과 통합되는 방식을 보여줍니다. 표시된 것과 같이, SQL*Loader는 External Table API 및 Data Pump API와 통합되어 External Table로 데이터를 로드합니다. Oracle Enterprise Manager Cloud Control(Cloud Control) 및 Transportable 테이블스페이스와 같은 클라이언트는 Oracle Data Pump Infrastructure를 사용할 수 있습니다.

그림 2: Oracle Data Pump 구조

그림 cncpt261.png에 대한 설명

참조:

Oracle LogMiner

Oracle LogMiner에서는 SQL 인터페이스를 통해 리두 로그 파일을 query할 수 있습니다.

리두 로그 파일에 포함된 데이터를 사용할 수 있는 용도는 다음과 같습니다.

LogMiner는 명령행 인터페이스 또는 Enterprise Manager의 일부인 Oracle LogMiner Viewer GUI를 통해 액세스할 수 있습니다.

참조: LogMiner에 대한 자세한 내용은 Oracle AI Database Utilities를 참조하십시오.

ADRCI(ADR Command Interpreter)

ADRCI는 문제를 조사하고, 건전성 검사 보고서를 보고, 첫번째 실패 데이터를 패키지화하여 Oracle Support에 업로드할 수 있는 명령줄 유틸리티입니다.

이 유틸리티를 사용하여 ADR(자동 진단 저장소)에서 추적 파일의 이름을 확인하고 경보 로그를 볼 수도 있습니다. ADRCI에는 대화식 또는 스크립트에서 사용할 수 있는 다양한 명령 집합이 있습니다.

참조:

데이터베이스 관리자 항목

이 절에서는 DBA에게 가장 중요하고 설명서에 있는 다른 부분에서 다루지 않은 내용을 다룹니다.

백업 및 복구

백업 및 복구는 매체 고장 또는 사용자 오류로 인한 데이터 손실로부터 데이터베이스를 보호하는 데 관련된 개념, 절차 및 전략 집합입니다.

백업은 데이터의 복사본입니다. 백업에는 데이터 파일, 서버 매개변수 파일 및 제어 파일과 같은 데이터베이스의 중요한 부분이 포함될 수 있습니다. 샘플 백업 및 Recovery 시나리오는 데이터 파일이 손실되는 장애가 발생한 디스크 드라이브입니다. 손실된 파일의 백업이 있으면 복원하고 Recovery할 수 있습니다. 손실 전 상태로 데이터를 복원하는 것과 관련된 작업을 매체 복구라고 합니다.

이 단원에서는 다음 항목을 다룹니다.

참조:

백업 및 Recovery 기술

Recovery Manager 또는 사용자 관리 기법을 사용하여 Oracle 데이터베이스를 백업, 복원 및 Recovery할 수 있습니다.

두 접근 방식의 주요 차이점은 다음과 같습니다.

참조:

Recovery Manager 구조

RMAN과 Oracle Secure Backup은 명령행과 Enterprise Manager Cloud Control(Cloud Control)에서 모두 액세스할 수 있습니다.

Cloud Control은 RMAN을 위한 그래픽 프론트 엔드 및 스케줄링 기능을 제공합니다. 작업 매개변수를 입력한 다음 작업 스케줄을 지정합니다. Cloud Control은 지정된 시간이나 지정된 반복 간격으로 RMAN을 실행하여 백업 및 recovery 작업을 수행합니다. Cloud Control은 일련의 마법사를 통해 RMAN에 액세스할 수 있도록 합니다. 이러한 마법사는 데이터베이스 분석, 사용 가능한 백업 및 데이터 Recovery 목표에 따른 다양한 Recovery 절차를 안내합니다.

Cloud Control을 사용하면 이 설명서에 설명된 보다 간단한 복원 및 Recovery 시나리오를 수행할 수 있습니다. 또한 Point-in-time Recovery 및 Oracle Flashback 작업과 같은 보다 정교한 복원 및 Recovery 기술을 사용하여 Media Failure와 유저 오류를 효율적으로 복구할 수 있습니다. 종종 Cloud Control 사용이 RMAN 명령행 클라이언트보다 간단합니다.

다음 그림은 샘플 RMAN 구조를 보여줍니다. Cloud Control을 통해 액세스할 수 있는 RMAN 클라이언트는 Target Database의 서버 세션을 사용하여 데이터를 디스크나 테이프에 백업합니다. RMAN은 백업 메타 데이터로 External Recovery Catalog를 갱신할 수 있습니다.

그림 3: RMAN 구조

그림 cncpt318.gif에 대한 설명

어떤 백업 및 복구 기술을 사용하든 Oracle은 빠른 복구 영역을 구성할 것을 권장합니다. 이 데이터베이스 관리 디렉토리, 파일 시스템 또는 Oracle ASM 디스크 그룹은 활성 제어 파일, 온라인 및 아카이브된 리두 로그 파일, 백업 등 백업 및 복구 파일을 중앙 집중화합니다. Oracle AI Database 복구 구성요소는 빠른 복구 영역과 상호 작용하여 데이터베이스 복구 가능성을 보장합니다.

참조:

데이터베이스 백업

데이터베이스 백업은 물리적 또는 논리적일 수 있습니다.

백업 및 Recovery 전략에서 가장 중요한 문제인 물리적 백업은 물리적 데이터베이스 파일의 복사본입니다. RMAN 또는 운영 체제 유틸리티를 사용하여 물리적 백업을 만들 수 있습니다.

반대로 논리적 백업에는 테이블, 내장 프로시저 및 기타 논리적 데이터가 포함됩니다. 데이터 펌프 엑스포트와 같은 Oracle AI Database 유틸리티를 사용하여 논리적 데이터를 추출하고 이진 파일에 저장할 수 있습니다. 논리적 백업은 물리적 백업을 보완할 수 있습니다.

물리적 백업은 큰 세분성과 제한된 전송 가능성을 가지고 있지만 매우 빠릅니다. 논리적 백업은 세분성과 완벽한 전송 가능성을 갖지만 물리적 백업보다 속도가 느립니다.

전체 및 부분 데이터베이스 백업

전체 데이터베이스 백업은 데이터베이스에 있는 모든 데이터 파일과 제어 파일의 백업입니다. 완전 데이터베이스 백업은 가장 일반적인 백업 유형입니다.

부분 데이터베이스 백업은 개별 테이블스페이스 또는 데이터 파일의 데이터베이스 하위 집합을 포함합니다. 테이블스페이스 백업은 테이블스페이스 또는 여러 테이블스페이스에 있는 모든 데이터 파일의 백업입니다. 복원된 테이블스페이스를 나머지 데이터베이스와 일관성 있게 만드는 데 리두가 필요하므로 테이블스페이스 백업은 데이터베이스가 ARCHIVELOG 모드로 작동하는 경우에만 적합합니다.

일관된 백업 및 일관되지 않은 백업

Whole Database Backup은 일관성 있거나 일관성이 없습니다.

일관성 있는 백업에서 모든 읽기/쓰기 데이터 파일과 제어 파일은 동일한 체크포인트 SCN을 가지므로 이러한 파일에 이 SCN까지의 모든 변경 사항이 포함됩니다. 이러한 유형의 백업은 복원된 후 recovery할 필요가 없습니다.

일관성 있는 데이터베이스 백업은 일관성 있는 종료 후에만 가능하며 NOARCHIVELOG 모드에서 작동하는 데이터베이스에 대해 유효한 유일한 백업 옵션입니다. 다른 백업 옵션에는 일관성을 위한 Media Recovery가 필요하며 아카이브된 리두 로그 파일을 적용하지 않으면 이를 수행할 수 없습니다. 주: 리두를 적용하지 않고 일관성 있는 완전 데이터베이스 백업을 복원하는 경우 백업 이후 수행된 모든 트랜잭션이 손실됩니다.

일관성 없는 백업에서 데이터 파일 및 제어 파일의 읽기/쓰기는 동일한 체크포인트 SCN을 가지지 않으므로 변경 사항이 누락될 수 있습니다. 백업이 발생하는 동안 데이터 파일을 수정할 수 있으므로 모든 온라인 백업은 반드시 일관성이 없습니다.

일관성 없는 백업은 데이터베이스를 완전히 보호하는 백업을 만들기 위해 데이터베이스를 종료할 필요가 없기 때문에 뛰어난 가용성을 제공합니다. 데이터베이스가 ARCHIVELOG 모드로 실행되고 아카이브된 리두 로그 및 데이터 파일을 백업하는 경우 일관성 없는 백업이 올바른 백업 및 복구 전략의 기초가 될 수 있습니다.

참조:

백업 집합 및 이미지 복사본

RMAN BACKUP 명령은 이미지 복사본 또는 백업 셋을 생성합니다.

백업 유형은 다음과 같이 다릅니다.

참조: 백업 셋 및 이미지 복사본에 대한 자세한 내용은 Oracle AI Database Backup and Recovery User's Guide를 참조하십시오.

데이터 수리

몇 가지 문제로 인해 데이터베이스의 정상적인 작동이 중단되거나 I/O 작업에 영향을 줄 수 있지만, DBA의 개입과 데이터 복구가 필요한 문제도 있습니다.

일반적으로 다음과 같은 경우에 데이터 복구가 필요합니다.

일반적으로 앞의 문제를 해결하는 방법은 여러 가지가 있습니다. 이 절에서는 이러한 솔루션 중 일부를 요약합니다.

참조:

Oracle Flashback 기술

Oracle AI Database는 Oracle Flashback Technology로 알려진 기능 그룹을 제공합니다. 이 기술은 백업을 복원할 필요 없이 데이터의 과거 상태를 확인하고, 데이터를 제때 앞뒤로 감을 수 있습니다.

Flashback 기능은 데이터베이스 변경 사항에 따라 Media Recovery보다 불필요한 변경 사항을 더 빨리 되돌리고 가용성에 미치는 영향을 줄일 수 있습니다. 다음 Flashback 기능은 백업 및 Recovery와 가장 관련성이 높습니다.

참조:

블록 Media Recovery

Block Media Recovery는 데이터 파일이 온라인 상태인 동안 손상된 데이터 블록을 복원 및 Recovery하기 위한 기법입니다.

블록 손상은 인식된 Oracle 형식이 아니거나 내용이 내부적으로 일치하지 않는 데이터 블록입니다. 블록 손상을 감지한 경우 몇 개의 블록만 손상된 경우 데이터 파일 Recovery보다 블록 Recovery를 사용하는 것이 좋습니다.

참조:

데이터 파일 복구

데이터 파일 Recovery는 손실되거나 손상된 현재 데이터 파일 또는 콘트롤 파일을 복구합니다. 또한 테이블스페이스가 OFFLINE NORMAL 옵션 없이 오프라인 상태가 되면 손실된 변경 사항을 복구할 수 있습니다.

데이터 파일 또는 콘트롤 파일의 백업을 복원하거나 데이터 파일이 OFFLINE NORMAL 옵션 없이 오프라인 상태가 될 경우 Media Recovery가 필요합니다. 온라인 데이터 파일에 Media Recovery가 필요하거나 Media Recovery가 필요한 데이터 파일이 Media Recovery가 완료될 때까지 Media Recovery가 필요한 데이터 파일을 온라인으로 가져올 수 있으면 데이터베이스를 열 수 없습니다.

데이터 파일 또는 콘트롤 파일의 물리적 백업을 복원하려면 해당 파일을 재구성하고 Oracle AI Database에서 사용할 수 있도록 해야 합니다. 백업을 복구하려면 아카이브된 리두 로그 파일을 적용하여 손실된 변경 사항을 재구성합니다. 또한 RMAN은 이전 백업 이후에 수정된 데이터 블록만 포함하는 Incremental 백업을 사용하여 데이터 파일을 Recovery할 수 있습니다.

온라인 파일에 변경 사항을 자동으로 적용하는 Instance Recovery와 달리 Media Recovery는 유저가 호출해야 하며 아카이브된 리두 로그 파일을 복원된 백업에 적용합니다. 데이터 파일 Media Recovery는 데이터베이스 Instance가 열지 않은 데이터베이스의 오프라인 데이터 파일 또는 데이터 파일에 대해서만 작동할 수 있습니다.

데이터 파일 Media Recovery는 모든 변경 사항이 적용되는지에 따라 다릅니다.

참조:

Zero Data Loss Recovery Appliance

일반적으로 Recovery Appliance라고 하는 클라우드 규모의 Zero Data Loss Recovery Appliance는 엔터프라이즈 내 모든 Oracle 데이터베이스에 대한 데이터 손실 및 백업 오버헤드를 크게 줄이는 엔지니어드 시스템입니다.

RMAN과 통합된 Recovery Appliance는 클라우드 규모의 내결함성 하드웨어 및 스토리지를 사용하여 다수의 데이터베이스에 대해 중앙 집중식 백업 및 복구 전략을 배포합니다. Recovery Appliance는 복구 가능성을 위해 백업을 지속적으로 검증합니다.

Recovery Appliance의 이점

중앙 집중식 Recovery Appliance는 대부분의 데이터베이스 백업 및 복원 처리를 수행하여 백업의 스토리지 활용도, 성능 및 관리 효율성을 높입니다.

주요 이점은 다음과 같습니다.

Recovery Appliance 환경

보호된 데이터베이스는 Recovery Appliance에 데이터를 백업하는 클라이언트 데이터베이스입니다.

다음 그림은 보호된 데이터베이스 6개와 복구 어플라이언스 2개를 포함하는 샘플 환경을 보여줍니다. 각 데이터베이스는 해당 백업에 Zero Data Loss Recovery Appliance 백업 모듈(Recovery Appliance Backup Module)을 사용합니다. 이 모듈은 RMAN이 네트워크를 통해 Recovery Appliance로 백업을 전송하는 데 사용하는 Oracle 제공 SBT 라이브러리입니다.

그림 4: Recovery Appliance 환경

그림 amagd_vm_025.png에 대한 설명

각 Recovery Appliance에 상주하는 Recovery Appliance 메타데이터 데이터베이스는 복구 카탈로그에 저장된 메타데이터를 관리합니다. Recovery Appliance에 백업을 전송하는 보호된 모든 데이터베이스는 이 복구 카탈로그를 사용해야 합니다. 백업은 Oracle ASM 디스크 그룹 세트인 Recovery Appliance 스토리지 위치에 있습니다. 주: 데이터베이스는 백업 저장소로 사용하지 않고도 Recovery Appliance를 복구 카탈로그로 사용할 수 있습니다.

관리자는 Cloud Control을 사용하여 환경을 관리하고 모니터합니다. Cloud Control은 백업이 디스크, 테이프 또는 다른 Recovery Appliance에 상주하는지 여부에 관계없이 각 데이터베이스의 전체 백업 수명 주기에 대한 "단일 창" 뷰를 제공합니다.

메모리 관리

메모리 관리에서는 데이터베이스에 대한 수요 변화에 따라 Oracle 인스턴스 메모리 구조의 최적 크기를 유지 관리합니다. 초기화 파라미터 설정에 따라 SGA 및 Instance PGA 메모리가 관리되는 방식이 결정됩니다. 그림 22-5에서는 메모리 관리 옵션에 대한 결정 트리를 보여줍니다. 다음 절에서는 옵션에 대해 자세히 설명합니다.

그림 5: 메모리 관리 방법

그림 cncpt242.gif에 대한 설명

자동 메모리 관리

자동 메모리 관리에서 Oracle AI Database는 SGA 및 인스턴스 PGA 메모리를 완전히 자동으로 관리합니다. 이 방식은 가장 간단하며 Oracle에서 강력히 권장합니다.

사용자가 지정한 컨트롤은 대상 메모리 크기 초기화 매개변수(MEMORY_TARGET)와 선택적 최대 메모리 크기 초기화 매개변수(MEMORY_MAX_TARGET)뿐입니다. Oracle AI Database는 SGA와 인스턴스 PGA 간에 필요에 따라 메모리를 재분배하여 목표 메모리 크기를 조정합니다.

SGA에는 In-Memory Column Store(IM 열 저장소) 또는 memoptimize pool(둘 다 선택 사항)이 포함될 수 있습니다. 어떤 메모리 관리 방식을 사용하든 INMEMORY_SIZE 초기화 매개변수를 사용하여 IM 열 저장소의 크기를 조정하고 MEMOPTIMIZE_POOL_SIZE 초기화 매개변수를 사용하여 memoptimize 풀의 크기를 조정합니다. IM 열 저장소 크기는 메모리 최적화 풀이 메모리 대상에 포함되지만 자동 크기 조정 알고리즘에 의해 관리되지 않습니다. 예를 들어, MEMORY_TARGET를 5GB, INMEMORY_SIZE를 1GB로 설정하면 전체 메모리 대상은 5GB(6GB 아님)이고 INMEMORY_SIZE는 항상 1GB입니다.

다음 그림은 때때로 온라인 사용자가 제출한 작업과 일괄 처리 작업을 처리하는 데이터베이스를 보여줍니다. 자동 메모리 관리를 사용하여 데이터베이스는 실행 중인 작업 유형에 따라 대형 풀 및 데이터베이스 버퍼 캐시의 크기를 자동으로 조정합니다. 그래픽은 IM 열 저장소 또는 memoptimize 영역을 나타내지 않습니다.

그림 6: 자동 메모리 관리

그림 cncpt256.gif에 대한 설명

DBCA로 데이터베이스를 생성하고 기본 설치 옵션을 선택하는 경우 Oracle AI Database는 기본적으로 자동 메모리 관리를 지원합니다.

참조:

SGA의 공유 메모리 관리

자동 공유 메모리 관리를 사용하여 SGA 크기를 설정하거나 SGA 구성 요소를 수동으로 튜닝하여 SGA의 크기를 수동으로 제어할 수 있습니다.

자동 메모리 관리가 활성화되지 않은 경우 시스템은 SGA의 공유 메모리 관리를 사용해야 합니다. 공유 메모리 관리는 다음 형식 중 하나로 수행할 수 있습니다.

참조:

Instance PGA의 메모리 관리

자동 메모리 관리가 활성화되지 않은 경우 Oracle AI Database는 자동 또는 수동 PGA 메모리 관리를 사용합니다.

다음 모드는 PGA 메모리 관리에 사용할 수 있습니다.

참조: PGA 메모리 관리에 대한 자세한 내용은 Oracle AI Database Performance Tuning Guide를 참조하십시오.

메모리 관리 방법 요약

메모리 관리는 자동 또는 수동입니다.

자동 메모리 관리를 활성화하지 않은 경우 SGA와 PGA에 대해 각각 하나의 메모리 관리 방식을 구성해야 합니다. 주: 데이터베이스 인스턴스에 대해 전체적으로 자동 메모리 관리가 사용 안함으로 설정된 경우 Oracle Database는 기본적으로 자동 PGA 메모리 관리를 사용으로 설정합니다.

다음 표에는 INMEMORY_SIZE 초기화 매개변수와 MEMOPTIMIZE_POOL_SIZE 초기화 매개변수가 포함되어 있습니다. 둘 다 선택 사항인 메모리 영역을 제어합니다.

표 3 메모리 관리 방법

인스턴스 SGA PGA 설명 초기화 매개변수
자동 n/a n/a 데이터베이스는 단일 인스턴스 대상 크기에 따라 인스턴스 크기를 조정합니다.

다음과 같이 설정합니다.

  • 데이터베이스 인스턴스에 대한 총 메모리 대상 크기(MEMORY_TARGET)

  • 데이터베이스 인스턴스에 대한 선택적 최대 메모리 크기(MEMORY_MAX_TARGET)

  • SGA의 IM 열 저장소(INMEMORY_SIZE)에 대한 선택적 크기

n/a 자동 자동

데이터베이스는 SGA 대상에 따라 SGA를 자동으로 튜닝합니다.

데이터베이스는 PGA 대상에 따라 PGA를 자동으로 튜닝합니다.

다음과 같이 설정합니다.

  • SGA 대상 크기(SGA_TARGET)

  • SGA 최대 크기(선택 사항)(SGA_MAX_SIZE)

  • SGA의 IM 열 저장소(INMEMORY_SIZE)에 대한 선택적 크기

  • SGA의 메모리 최적화 풀에 대한 선택적 크기(MEMOPTIMIZE_POOL_SIZE)

  • PGA 집계 대상 크기(PGA_AGGREGATE_TARGET)각주 1

데이터베이스는 PGA_AGGREGATE_LIMIT 초기화 매개변수를 자동으로 구성합니다. 이 매개변수를 수동으로 설정할 수 있습니다.

n/a 자동 수동

데이터베이스는 SGA 대상에 따라 SGA를 자동으로 튜닝합니다.

PGA를 수동으로 제어하여 각 SQL 연산자 유형에 대한 최대 작업 영역 크기를 설정합니다.

다음과 같이 설정합니다.

  • SGA 대상 크기(SGA_TARGET)

  • SGA 최대 크기(선택 사항)(SGA_MAX_SIZE)

  • SGA의 IM 열 저장소에 대한 선택적 크기(INMEMORY_SIZE)

  • SGA의 메모리 최적화 풀에 대한 선택적 크기(MEMOPTIMIZE_POOL_SIZE)

  • SORT_AREA_SIZE, HASH_AREA_SIZE 및 BITMAP_MERGE_AREA_SIZE와 같은 PGA 작업 영역 매개변수
n/a 수동 자동

개별 구성 요소 크기를 설정하여 수동으로 SGA를 제어합니다.

데이터베이스는 PGA 대상에 따라 PGA를 자동으로 튜닝합니다.

다음과 같이 설정합니다.

  • 공유 풀 크기(SHARED_POOL_SIZE)

  • 버퍼 캐시 크기는(DB_CACHE_SIZE)입니다.

  • 대형 풀 사이즈(LARGE_POOL_SIZE)

  • Java 풀 크기의 경우(JAVA_POOL_SIZE)

  • SGA의 IM 열 저장소(INMEMORY_SIZE)에 대한 선택적 크기

  • SGA의 메모리 최적화 풀에 대한 선택적 크기(MEMOPTIMIZE_POOL_SIZE)

  • PGA 집계 대상 크기(PGA_AGGREGATE_TARGET)각주 2

데이터베이스는 PGA_AGGREGATE_LIMIT 초기화 매개변수를 자동으로 구성합니다. 이 매개변수를 수동으로 설정할 수 있습니다.

n/a 수동 수동

SGA 구성 요소 크기를 수동으로 구성해야 합니다.

각 SQL 연산자 유형에 대한 최대 작업 영역 크기를 설정하여 수동으로 PGA를 제어합니다.

SGA 구성 요소 크기를 수동으로 구성해야 합니다. 다음과 같이 설정합니다.

  • 공유 풀 크기(SHARED_POOL_SIZE)

  • 버퍼 캐시 크기는(DB_CACHE_SIZE)입니다.

  • 대형 풀 사이즈(LARGE_POOL_SIZE)

  • Java 풀 크기를 나타냅니다(JAVA_POOL_SIZE).

  • SGA의 IM 열 저장소(INMEMORY_SIZE)에 대한 선택적 크기

  • SGA의 메모리 최적화 풀에 대한 선택적 크기(MEMOPTIMIZE_POOL_SIZE)

  • SORT_AREA_SIZE, HASH_AREA_SIZE 및 BITMAP_MERGE_AREA_SIZE와 같은 PGA 작업 영역 매개변수

각주 1

데이터베이스는 PGA_AGGREGATE_LIMIT 초기화 매개변수를 자동으로 구성합니다. 또한 이 매개변수를 수동으로 설정하도록 선택할 수도 있습니다.

각주 2

데이터베이스는 PGA_AGGREGATE_LIMIT 초기화 매개변수를 자동으로 구성합니다. 또한 이 매개변수를 수동으로 설정하도록 선택할 수도 있습니다.

참조: Oracle AI Database Administrator's Guide - 일부 플랫폼에서는 자동 메모리 관리를 사용할 수 없습니다.

Resource Management 및 작업 스케줄링

Oracle AI Database는 리소스 관리 및 일정 잡기 작업을 지원하여 사용자에게 미치는 영향을 줄이는 도구를 제공합니다.

활성 유저가 많은 데이터베이스에서는 리소스 관리가 데이터베이스 관리의 중요한 부분입니다. 과도한 리소스를 소비하는 세션은 다른 세션에서 해당 작업을 수행하지 못하도록 할 수 있습니다. 관련 문제는 최적의 시간에 실행되도록 작업을 스케줄링하는 방법입니다. Oracle AI Database는 이러한 문제를 해결하는 데 도움이 되는 도구를 제공합니다.

데이터베이스 리소스 관리자

Oracle AI Database Resource Manager(Resource Manager)는 유저 계정, 응용 프로그램 및 서비스에 할당되는 데이터베이스 리소스를 세밀하게 제어합니다. Resource Manager는 주로 게이트키퍼 역할을 하므로 일부 작업의 속도가 느려져 다른 작업이 빠르게 실행될 수 있습니다.

DBMS_RESOURCE_MANAGER PL/SQL 패키지는 다음을 포함하여 운영 체제에서 제대로 관리하지 못하는 많은 리소스 할당 문제를 해결합니다.

Resource Manager는 데이터베이스에 하드웨어 리소스 할당 및 데이터베이스 내 작업 우선 순위 지정에 대한 더 많은 제어 권한을 부여함으로써 이전의 문제를 해결할 수 있도록 합니다. 세션 속성을 기준으로 세션을 그룹으로 분류한 다음 이러한 그룹에 리소스를 할당하여 하드웨어 사용률을 최적화할 수 있습니다. Resource Manager를 사용하여 PDB 메모리 사용 제한을 설정할 수 있습니다.

리소스는 데이터베이스 관리자가 지정한 리소스 계획에 따라 사용자에게 할당됩니다. 이 계획은 자원이 자원 요구 사항별로 그룹화된 사용자 세션인 자원 소비자 그룹 간에 분배되는 방식을 지정합니다. 자원 계획 지시어는 자원 소비자 그룹을 계획과 연관시키고 자원이 그룹에 할당되는 방식을 지정합니다. 그림 22-7에서는 낮 동안 OLTP 응용 프로그램 및 보고 응용 프로그램을 동시에 실행하는 조직에 대한 간단한 리소스 계획을 보여줍니다. 현재 활성 계획인 DAYTIME는 세 개의 자원 소비자 그룹에 CPU 자원을 할당합니다. 특히 OLTP는 CPU 시간의 75%를 할당하고, REPORTS는 15%를 할당하며, OTHER_GROUPS는 나머지 10%를 수신합니다.

그림 7: 간단한 Resource Plan

그림 admin078.gif에 대한 설명

Resource Manager가 해결할 수 있는 문제 중 하나는 SQL Monitor를 사용하여 모니터할 수 있는 runaway query입니다. Resource Manager를 사용하면 이탈 SQL 문을 식별하고 응답하는 임계값을 지정할 수 있습니다. 예를 들어, Consumer Group의 각 포그라운드 프로세스에 의해 CPU 시간, 경과 시간, 물리적 또는 논리적 I/O 및 PGA 사용에 대한 임계값을 지정할 수 있습니다. 이에 대한 응답으로 Resource Manager는 우선 순위가 낮은 Consumer Group으로 전환하거나, SQL 문을 종료하거나, 임계값 위반을 기록할 수 있습니다.

참조:

CPU 관리

Oracle AI Database 26ai부터 Oracle은 서버의 모든 데이터베이스 인스턴스에 걸쳐 작동하는 CPU 리소스 관리를 위한 대체 방법을 제공합니다.

이전 릴리스에서는 Oracle이 데이터베이스 인스턴스 내에서 작동하는 한 가지 CPU 리소스 관리 방법을 제공했습니다. Oracle AI Database 26ai부터 RESOURCE_MANAGER_CPU_SCOPE를 설정하여 CPU 리소스 관리 범위를 제어할 수 있습니다. 이 매개변수를 사용하면 두 제어 방법 중 하나를 선택할 수 있습니다.

RESOURCE_MANAGER_CPU_SCOPE를 SERVER_WIDE로 설정하면 서버 레벨 인스턴스 간 CPU 리소스 관리가 가능합니다. Oracle AI Database 26ai에 도입된 이 방법은 여러 데이터베이스 인스턴스가 Linux 서버를 공유할 때 사용할 수 있습니다. 이를 통해 서버의 모든 데이터베이스 Instance에서 CPU 리소스를 관리할 수 있습니다. 이 방법을 사용하면 Oracle은 원하는 CPU 공유 및 CPU 사용량 제한으로 Linux 제어 그룹(cgroup)을 자동으로 구성한 다음 데이터베이스 세션을 적절한 cgroup에 배치합니다.

RESOURCE_MANAGER_CPU_SCOPE는 기본적으로 INSTANCE_ONLY로 설정됩니다.

참조:

Oracle Scheduler

Oracle Scheduler(스케줄러)를 사용하면 데이터베이스 관리자와 응용 프로그램 개발자가 데이터베이스 환경에서 여러 작업이 수행되는 시기와 위치를 제어할 수 있습니다.

스케줄러는 다음과 같은 작업에 사용할 수 있는 복잡한 엔터프라이즈 스케줄링 기능을 제공합니다.

프로그램 객체(프로그램)에는 인수에 대한 기본값을 포함하여 스케줄러가 실행할 명령에 대한 메타 데이터가 포함됩니다. 스케줄 객체(스케줄)에는 실행 일자 및 시간 및 반복 패턴에 대한 정보가 포함됩니다. 작업 객체(작업)는 프로그램을 스케줄과 연관시킵니다. 실행 대상과 시기를 정의하려면 프로그램, 스케줄 및 작업 간에 관계를 지정합니다.

스케줄러는 DBMS_SCHEDULER PL/SQL 패키지에서 함수 및 프로시저 집합으로 구현됩니다. 이 패키지 또는 Enterprise Manager를 사용하여 Scheduler 객체를 생성하고 조작합니다. 스케줄러 객체는 표준 데이터베이스 객체이므로 시스템 및 객체 권한을 사용하여 이에 대한 액세스를 제어할 수 있습니다. 그림 22-8은 스케줄러의 기본 구조를 보여줍니다. 작업 테이블은 모든 작업이 들어 있으며 데이터베이스마다 테이블이 하나씩입니다. 작업 조정자 백그라운드 프로세스는 필요에 따라 자동으로 시작 및 정지됩니다. 작업 하위 프로세스는 작업을 실행해야 할 때 조정자에 의해 깨어납니다. 하위 프로세스는 작업 테이블에서 메타데이터를 수집하고 작업을 실행합니다.

그림 8: 스케줄러 구성 요소

그림 admin062.gif에 대한 설명

참조:

성능 및 튜닝

DBA는 Oracle 데이터베이스 성능을 책임집니다. 일반적으로 성능 문제는 허용할 수 없는 응답 시간(지정된 작업 로드를 완료할 시간) 또는 지정된 시간에 완료할 수 있는 작업량인 처리량으로 인해 발생합니다.

일반적인 문제는 다음과 같습니다.

일반적으로 튜닝의 목표는 응답 시간을 향상시키거나 처리 능력을 증가시키는 것입니다. 구체적이고 측정 가능한 목표는 "지정된 SELECT 문의 응답 시간을 5초 미만으로 단축"할 수 있습니다. 이러한 목표를 달성할 수 있는지 여부는 DBA가 제어할 수 있는 요인에 따라 달라집니다. 일반적으로 튜닝은 가장 효율적인 방법으로 데이터베이스 리소스를 사용하여 구체적이고 측정 가능하며 달성 가능한 튜닝 목표를 달성하기 위한 노력입니다.

Oracle 성능 방식은 데이터베이스에서 병목 현상을 식별 및 제거하고 효율적인 SQL 문을 개발하는 방법을 기반으로 합니다. Oracle 성능 방식 적용 작업에서는 다음 작업이 포함되어 있습니다.

이 섹션에서는 Advisor 사용을 비롯하여 Oracle AI Database 성능 튜닝의 중요한 측면에 대해 설명합니다. Oracle AI Database Advisor는 공간, 성능, 실행 취소 관리 등의 광범위한 영역을 다루는 주요 데이터베이스 관리 문제를 해결하는 방법에 대한 특정 권고를 제공합니다.

데이터베이스 자체 모니터링

데이터베이스가 정기적인 작업을 수행함에 따라 자체 모니터가 수행되므로 데이터베이스가 문제가 발생할 때 이를 인식하게 됩니다. Oracle AI Database는 임박한 문제를 알리기 위해 서버 생성 경고를 보낼 수 있습니다.

문제가 발생하거나 데이터가 초당 물리적 읽기 또는 SQL 응답 시간과 같은 측정항목에 대한 예상 값과 일치하지 않는 경우 경보가 자동으로 생성됩니다. 측정 단위는 누적 통계에서의 변경 비율입니다. Server-generated alert는 사용자가 지정한 임계값 레벨을 기반으로 하거나 이벤트가 발생했기 때문에 발생할 수 있습니다.

서버 생성 alert는 문제를 식별할 뿐만 아니라 보고된 문제를 해결하는 방법을 권장하는 경우도 있습니다. 예를 들어, 불필요한 백업을 삭제하거나 디스크 공간을 더 추가하도록 권장하는 내용으로 Fast Recovery Area의 공간이 부족하다는 Alert가 있습니다.

참조: Oracle AI Database Administrator's Guide

AWR(자동 작업 로드 저장소)

AWR(자동 작업 로드 저장소)은 시스템, 세션, 개별 SQL 문, 세그먼트 및 서비스에 대한 누적 통계를 포함하는 과거 성능 데이터의 저장소입니다.

AWR 통계는 성능 튜닝의 기초입니다. AWR은 문제 감지 및 튜닝을 위해 데이터베이스 통계 수집을 자동화함으로써 데이터베이스 자체 관리의 토대가 됩니다.

다음 그림에 나오는 것처럼 데이터베이스는 최근 AWR 통계를 SGA에 저장합니다. 기본적으로 MMON 프로세스는 매시간마다 통계를 수집하고 AWR 스냅샷을 생성합니다. AWR 스냅샷은 특정 시간에 캡처된 성능 통계 집합입니다. 데이터베이스는 SYSAUX 테이블스페이스에 스냅샷을 기록합니다. AWR은 구성 가능한 스냅샷 retention 정책에 따라 이전 스냅샷을 지우면서 스냅샷 공간을 관리합니다.

그림 9: AWR(자동 작업 로드 저장소)

그림 cncpt279.gif에 대한 설명

AWR 기준 요소는 일반적으로 시스템이 최대 부하에서 제대로 작동하고 있는 기간에 걸리는 통계 비율 모음입니다. AWR 스냅샷의 쌍 또는 범위를 Baseline으로 지정할 수 있습니다. AWR 보고서를 사용하여 성능 저하 기간 동안 캡처된 통계를 Baseline과 비교하여 문제를 진단할 수 있습니다.

AutoTask이라는 자동화된 유지 관리 Infrastructure는 Oracle Database에서 자체 관리를 위해 AWR을 사용하는 방법을 보여줍니다. AutoTask는 AWR 데이터를 분석하여 유지 관리 작업의 필요성을 파악하고 Oracle Scheduler 유지 관리 윈도우(Maintenance windows)에서 실행되도록 일정을 잡을 수 있습니다. 작업의 예로는 옵티마이저에 대한 통계 수집 및 자동 세그먼트 권고자 실행이 있습니다.

참조:

ADDM(Automatic Database Monitor)

AWR(Automatic Workload Repository)에서 캡처된 통계를 사용하여 ADDM이 자동으로 사전에 데이터베이스 성능을 진단하고 식별된 문제를 해결할 수 있는 방법을 결정합니다. 수동으로 ADDM을 실행할 수도 있습니다. ADDM(자동 데이터베이스 진단 모니터)은 Oracle Database에 내장된 자체 진단 프로그램입니다.

ADDM은 시간을 구성 요소 간의 공통 통화로 사용하여 시스템 성능에 대한 전체적인 접근 방식을 취합니다. ADDM은 가장 많은 시간을 소비하는 Oracle Database 영역을 식별합니다. 예를 들어, 데이터베이스가 사용 가능한 데이터베이스 버퍼를 기다리는 데 지나치게 많은 시간을 소비할 수 있습니다. ADDM을 드릴 다운하여 증상이 아닌 문제의 근본 원인을 파악하고 문제가 Oracle Database 전반에 미치는 영향을 보고합니다. 프로세스 중에 최소 오버헤드가 발생합니다.

대부분의 경우 ADDM은 솔루션을 권장하고 예상되는 성능 이점을 수량화합니다. 예를 들어, ADDM은 하드웨어, 데이터베이스 구성, 데이터베이스 스키마 또는 응용 프로그램에 대한 변경 사항을 권장할 수 있습니다. 권장 사항이 생성되면 ADDM은 시간 이점을 보고합니다. 시간을 측정 단위로 사용하면 문제 또는 권장 사항을 비교할 수 있습니다.

ADDM은 잠재적인 성능 문제를 보고하는 것 외에도 문제가 없는 데이터베이스 영역을 문서화합니다. 데이터베이스 성능에 큰 영향을 주지 않는 I/O 및 메모리와 같은 하위 구성 요소는 초기 단계에서 분류 트리에서 제거됩니다. ADDM은 이러한 하위 구성 요소를 나열하므로 이러한 영역에서 작업을 수행하는 데 약간의 이점이 있음을 빠르게 확인할 수 있습니다.

참조: Oracle AI Database 성능 튜닝 시작하기 및 Oracle AI Database 성능 튜닝 가이드

ASH(활성 세션 내역)

ASH(활성 세션 내역)는 초당 활성 데이터베이스 세션을 샘플링하여 메모리와 영구 스토리지에 데이터를 기록합니다. ASH는 데이터베이스 자체 관리 프레임워크의 중요한 부분이며 성능 문제를 진단하는 데 유용합니다.

AWR(Automatic Workload Repository)에서 수집한 Instance 레벨 통계와 달리 데이터베이스는 세션 레벨에서 ASH 통계를 수집합니다. 활성 세션은 CPU를 사용 중이며 유휴 대기 클래스의 이벤트를 대기하지 않는 세션입니다.

Enterprise Manager 또는 SQL 스크립트를 사용하여 지정된 기간 동안 수집된 세션 통계를 수집하는 ASH 보고서를 생성할 수 있습니다. ASH 보고서는 다음 용도로 사용할 수 있습니다.

예를 들어, 유저는 데이터베이스가 오후 10시에서 오후 10시 사이에 느렸음을 알립니다. 그러나 2분 성능 저하는 오후 10시와 오후 11시 사이의 AWR 스냅샷 간격 중 일부를 나타내며 ADDM 결과에는 나타나지 않습니다. ASH 보고서는 일시적인 문제의 원인을 식별하는 데 도움이 될 수 있습니다.

참조: Oracle AI Database 성능 튜닝 시작하기 및 Oracle AI Database 성능 튜닝 가이드

응용 프로그램 및 SQL 튜닝

Oracle Database는 SQL 튜닝 프로세스를 완전히 자동화합니다.

ADDM은 비정상적으로 많은 시스템 리소스를 소모하는 SQL 문을 식별하므로 성능 문제가 발생합니다. 또한 AWR은 CPU 및 공유 메모리 소비 측면에서 Top SQL 문을 자동으로 캡처합니다. 로드가 많은 SQL 문 식별은 자동으로 수행되므로 개입이 필요하지 않습니다.

EXPLAIN PLAN 문

EXPLAIN PLAN 문과 같은 도구를 사용하면 옵티마이저가 선택한 실행 계획을 볼 수 있습니다.

EXPLAIN PLAN는 지정된 SQL 질의가 현재 세션에서 실행된 경우 해당 질의에 대한 질의 계획을 보여줍니다. 기타 툴은 Oracle Enterprise Manager 및 SQL*Plus AUTOTRACE 명령입니다.

참조: Oracle AI Database SQL Language Reference에서 EXPLAIN PLAN에 대해 알아보기

최적기 통계 권고자

옵티마이저 통계 Advisor는 현재 통계 수집 방법, 기존 통계 수집 작업의 효율성 및 수집된 통계의 품질을 분석하는 진단 소프트웨어입니다. 옵티마이저 통계 Advisor는 ADDM(Automatic Database Diagnostic Monitor), SQL Performance Analyzer 및 기타 Advisor와 동일한 Advisor 프레임워크를 사용합니다.

옵티마이저 통계 Advisor는 최적의 사용법(Best Practice)을 사용하는 기존 방식에 비해 다음과 같은 이점을 제공합니다.

옵티마이저 통계 권고자는 Advisor가 검사를 수행하는 데 사용되는 Oracle 제공 표준인 규칙을 유지 관리합니다. 이 규칙은 현재 기능 세트를 기반으로 하는 Oracle 모범 사례를 구현합니다. 최적의 사용법이 릴리스 간에 변경되면 옵티마이저 통계 Advisor 규칙도 변경됩니다. 이러한 방식으로 Advisor는 항상 최신 권장 사항을 제공합니다.

옵티마이저 통계 권고자는 통계 수집 프로세스를 검사한 다음 규칙 위반 조사 결과에 대한 보고서를 생성합니다. Advisor가 권장 사항을 생성하고 이러한 권장 사항을 기반으로 작업을 제안하는 경우 작업을 자동으로 구현하거나 편집 가능한 실행 가능한 PL/SQL 스크립트를 생성할 수 있습니다.

Advisor 작업은 유지 관리 윈도우(Maintenance windows)에서 자동으로 실행되지만 요청 시 실행할 수도 있습니다.

참조:

SQL 튜닝 권고자

자동 SQL 튜닝 인터페이스는 유지 관리 작업으로 시스템 유지 관리 윈도우(Maintenance windows) 동안 자동으로 실행되는 SQL Tuning Advisor입니다.

자동 실행 시마다 Advisor는 데이터베이스에서 로드량이 많은 SQL query를 선택하고 이러한 query 튜닝을 위한 권장 사항을 생성합니다.

SQL Tuning Advisor 권장 사항은 다음 범주에 속합니다.

SQL 프로파일에는 SQL 문과 관련된 추가 통계가 포함되어 있으며 옵티마이저가 더 나은 실행 계획을 생성할 수 있습니다. 기본적으로 SQL 프로파일은 query를 분석하는 방법입니다. 액세스 경로 및 SQL 구조 분석은 개발 중인 응용 프로그램 또는 자체 개발된 운용 응용 프로그램을 튜닝하는 데 유용합니다.

SQL Tuning Advisor의 주요 이점은 솔루션이 외부 도구가 아닌 옵티마이저에서 제공된다는 것입니다. 따라서 튜닝은 실행 계획 및 SQL 성능을 담당하는 데이터베이스 구성 요소에 의해 수행됩니다. 튜닝 프로세스는 SQL 문의 이전 실행 통계를 고려할 수 있으며 이 명령문에 대한 옵티마이저 설정을 커스터마이즈합니다.

참조:

SQL 액세스 권고자

SQL Access Advisor를 사용하면 SQL query 분석 및 스키마 객체 최적화 방법이나 query 튜닝 방법을 확인할 수 있습니다.

SQL Access Advisor는 데이터 액세스 경로를 최적화하는 방법에 대한 조언을 제공합니다. 특히 Partitioning, Materialized View, 인덱스 및 Materialized View 로그를 통해 데이터베이스 성능을 향상시킬 수 있는 방법을 권장합니다.

파티션 및 인덱스와 같은 스키마 객체는 데이터 집약적인 복잡한 쿼리를 최적화하는 데 필수적입니다. 그러나 이러한 객체의 작성 및 유지 관리는 많은 시간이 소요될 수 있으며 공간 요구 사항이 상당히 많을 수 있습니다. SQL Access Advisor는 지정된 작업 로드에 대한 데이터 구조를 권장하여 성능 목표를 달성하는 데 도움이 됩니다.

마법사 또는 DBMS_ADVISOR 패키지를 사용하여 Enterprise Manager에서 SQL Access Advisor를 실행할 수 있습니다. DBMS_ADVISOR는 모든 PL/SQL 프로그램에서 호출할 수 있는 분석 및 권고 함수와 프로시저 모음으로 구성됩니다.

참조: Oracle AI Database 성능 튜닝 시작하기 및 Oracle AI Database SQL 튜닝 가이드

SQL 계획 관리

SQL Plan Management를 사용하여 테스트 및 확인된 계획만 수행함으로써 SQL 실행 계획을 관리합니다.

기본적으로 SPM(SQL Plan Management) Evolve Advisor는 일정이 잡힌 유지 관리 윈도우(Maintenance windows)에서 매일 실행되며, 허용되지 않는 모든 계획의 순위를 지정하고, 가능한 많은 계획의 테스트 실행을 수행합니다. SPM Evolve Advisor는 SQL 계획 Baseline에서 허용되는 가장 낮은 비용의 계획을 선택하여 허용되지 않는 각 계획과 비교합니다. 허용되지 않는 계획이 기존의 허용된 계획보다 충분히 뛰어난 성능을 발휘할 경우 Advisor가 이를 수용합니다.

높은 빈도의 SPM이 사용으로 설정된 경우 유지 관리 기간 외부의 주기적 백그라운드 작업에서 SPM 전개 권고자를 실행하여 더 시기적절한 성능 향상을 허용합니다. 높은 빈도의 작업은 상당한 시스템 리소스를 사용하여 SQL 문을 식별하고 이전에 사용된 SQL 실행 계획의 성능이 향상되는지 여부를 확인합니다. 이 경우 이전 SQL 실행 계획을 적용하고 SQL 성능 회귀를 복구하기 위한 새 SQL 계획 Baseline이 생성됩니다.

Oracle Database 26ai부터 사용으로 설정된 경우 SQL 문이 새 SQL 실행 계획을 사용하는 경우 실시간 SPM이 즉시 성능 분석을 시작합니다. 이전에 표시된 SQL 실행 계획의 성능이 향상되면 백그라운드 작업에 의존하지 않고 새 SQL 계획 Baseline이 즉시 생성됩니다.

참조: