건강 회복 기능

간략한 개요

Health Monitor가 어떻게 데이터베이스 컴포넌트의 건강 상태를 자동으로 모니터링해 Automatic Diagnostic Repository에 그 결과를 기록하는지, 어떻게 패키지를 생성해 문제가 있으면 Oracle Support로 보내는지, 또 alert 로그, 리스너 로그 및 기타 로그의 새로운 버전을 어떻게 파악하는지 자세한 정보를 알아 봅니다.

Automatic Health Monitor

귀사 데이터베이스가 원활하게 잘 돌아가고 있는지 어떻게 알 수 있을까요 “모든 것”을 점검하는 방법이 있기는 합니다만 시간이 많이 소모되고 과정 중에 실수가 발생하기 쉽습니다. 일부 기업의 경우 담당 DBA가 데이터베이스의 건강을 점검하고 보고하기 위해 동일한 작업을 계속 반복해서 실행합니다. 그렇지만 대부분은 이러한 작업을 위해 직원을 따로 고용할 여력이 없습니다. 그 대안으로 정규 DBA 직원이 건강 점검을 하는 경우가 있지만, 결과를 살펴 보면 그다지 권장할만하지 않습니다. 너무 많은 일들에 신경을 분산하다 보면 잠재적으로 큰 위험이 있는 일을 놓칠 수 있습니다.

Oracle Database 11g에서는 Automatic Health Monitor 기능을 도입해 이러한 노력이 한결 간단해졌습니다. Oracle Database 10g의 Advisors와 유사한 Automatic Health Monitor "체커 (checkers)"는 데이터 파일과 딕셔너리 같은 다양한 컴포넌트를 (장애 후 또는 온디맨드로 자동으로) 모니터링 하여, 물리적으로나 논리적으로 오류가 없도록 합니다. 체커가 이상한 점을 발견하면 정보로 보고되고, 다양한 복구 어드바이저에 피딩되기도 합니다. 최소한 새로운 Incident Packaging Service (뒷부분에서 설명)를 사용하여 모든 문제 및 지원 파일을 묶어 Oracle Support에 손쉽게 보고할 수 있습니다.

Oracle Database 11g의 다른 많은 기능들처럼, 이 프로세스 역시 코맨드 라인이나 Oracle Enterprise Manager GUI를 통해 관리 가능합니다. 이제, 후자의 경우 어떻게 처리되는지 살펴보겠습니다.

메인 Database 페이지에서 스크롤을 아래로 내려 아래와 같이 Related Links라고 표시된 부분으로 이동합니다.

하이퍼링크 리스트에서 Advisor Central을 클릭하면 Advisors and Checkers 화면이 나타납니다. Checkers라고 표시된 탭을 클릭합니다. 화면의 상단 부분이 다음과 같이 나타납니다.

이 화면은 실행된 자동 체커 실행뿐만 아니라 여러 가지 사용 가능한 체커를 표시하는 중요한 화면입니다.

먼저, 사용 가능한 여러 가지 체커를 살펴 보겠습니다.

DB Structure Integrity Check. 이 체커는 예를 들어 설명하겠습니다. 먼저 DB Structure Integrity Checks을 클릭하면 예에서처럼 실행 (run)을 "DB_Struct_Int1"라고 명명할 수 있는 작은 화면이 나타납니다. 다음은 실행 시간을 제한하는 것인데, 제한 없음으로 해서 그냥 넘어갑니다.

건강 점검을 성공적으로 실행한 후에는 화면의 상단 부분에서 다음과 같이 확인할 수 있습니다.

화면 아래 부분에서도 이제 막 시작된 실행이 나타납니다. 그 이름은 조금 전에 입력한 DB_Struct_Int1입니다. 여기서 중요한 차이점은 Run Type열로서, 다른 실행에 대해서는 ‘Reactive’라고 표시되는 것과 달리 이 실행에 대해서는 ‘Manual’이라고 나타납니다. 라디오 버튼의 왼쪽을 누른 다음에 Details이라고 표시된 버튼을 클릭하면 이 실행을 선택할 수 있습니다.

이 경우에서는 데이터 파일에 오류가 일어났으며, 이 체커가 오류 발생을 확인할 수 있습니다. 정보가 Data Recovery Advisor에 피딩되어 (RMAN 설치에서 설명) 적합한 조치를 취합니다. 언제든지 이 체커를 불러와 데이터 파일의 무결성을 점검할 수 있습니다.

아마 이 체커를 가장 즐겨 사용하시게 될 것 같습니다. 과거 실행을 표시하는 화면에서 해당 유형의 실행을 선택한 후, Details 버튼을 클릭하면 다음과 같은 화면이 나타납니다.

이 화면에 모든 문제의 내용이 표시됩니다. 7번 데이터 파일에 오류가 일어났습니다. 다음으로 어떻게 해야 하는지 도움말을 원하는 경우에는 Recovery Advisor를 시작합니다.
Data Block Integrity Checker. Data Block Integrity Checker는 DB Structure Integrity Check와 유사하지만, 전체 파일이 아니라 특 마찬가지로, 파일에 이름 및 기타 관련 정보를 줍니다. 다음과 같은 화면이 나타납니다.

데이터 파일 번호와 블록 번호를 입력해야 한다는 점에 주의하십시오. (이 경우에는 7과 20을 각각 입력했습니다.). 상세정보를 입력한 후에 OK를 누릅니다. 점검 프로세스가 시작되고, 아래 부분에 다음과 같이 실행 상태가 나타납니다.

블록에 문제가 있었다면 체커가 역시 발견했을 것입니다. 하이퍼링크를 사용하여 상세정보 페이지로 가서 문제에 대해 알아볼 수 있습니다.
Redo Integrity Check. 이 체커는 redo 내용을 스캔하고 접근 및 오류 로그를 저장합니다.

Undo Segment Integrity Check. 이 체커는 rollback 운영 중에 가끔씩 확인되는 물리적 undo 오류를 발견합니다. undo 오류의 위치를 확인한 후에 PMON과 SMON을 사용하여 오류가 발생한 트랜잭션을 복구합니다. 복구에 실패하면, Automatic Health Monitor가 V$CORRUPT_XID_LIST에 오류 정보를 저장합니다. 대부분의 undo 오류는 강제 실행으로 해결됩니다.

Transaction Integrity Check. Transaction Integrity Check의 경우, 입력 파라미터로 체크에 전달되는 한 개의 특정 트랜잭션을 점검한다는 점을 제외하면 Undo Segment Check와 거의 동일합니다. undo 오류의 위치를 확인한 후에 PMON과 SMON을 사용하여 오류가 발생한 트랜잭션을 복구합니다. 복구에 실패하면, Automatic Health Monitor가 V$CORRUPT_XID_LIST에 오류 정보를 저장합니다. 대부분의 undo 오류는 강제 실행으로 해결됩니다.

Dictionary Integrity Check. 이 점검은 tab$과 col$ 같은 핵심 딕셔너리 오브젝트의 무결성을 조사합니다. 딕셔너리의 행에 논리적 제약이 실행되었는지, 딕셔너리 오브젝트 사이의 부모 관계가 실행되었는지, 각 딕셔너리 오브젝트의 딕셔너리 입력 내용을 검증합니다.

Automatic Diagnostic Repository

메인 화면의 체커는 모두 기억하시겠습니까 페이지 하단의 Checker Runs 목록은 발생한 다양한 체커 실행과 이들의 Run Type을 보여 줍니다. 본 항의 앞 부분에서 그랬듯이 수동으로 체커를 실행하는 경우에는 Run Type이 ‘Manual’이라고 표시합니다. ‘Reactive’라고 표시되는 체커 실행은 어딘가에서 오류가 감지될 때 자동으로 실행된다는 의미입니다. 실행에서 이상한 점을 발견하면 이를 기록하고, 이들 하이퍼링크를 클릭하면 발견 내용을 확인할 수 있습니다. 예를 들어, 첫 번째 실행을 클릭하면, HM_RUN_140013이 해당 체커 실행의 상세정보를 보여 줍니다.

화면에 장애의 원인이 확실하게 나타납니다. 실제로, 최소한 두 가지의 장애 유형이 있는데, 데이터 파일뿐만 아니라 온라인 redo 로그 파일에 오류가 있습니다. 먼저 Launch Recovery Advisor 버튼을 눌러 도움말을 구합니다. 위저드 기반 인터페이스를 계속 진행하면 어드바이저가 구체적인 조치를 취하도록 안내하는 화면으로 이어집니다.

directory /home/oracle/diag/rdbms/odel11/ODEL11/hm의 SQL file reco_767216331.hm을 실행하라는 조치일 수도 있습니다. 파일을 열면 내용을 확인할 수 있습니다.begin
/*Clear the Log Group*/
execute immediate 'ALTER DATABASE CLEAR LOGFILE GROUP 3';
end;오류 로그 파일은 활성화되지 않은 그룹에 속하기 때문에, 없애도 괜찮습니다. Recovery Advisor의 도움말도 없애라고 나타날 것입니다. 도움말을 따르는 경우에, Continue 버튼을 누르면 복구가 계속 진행됩니다. 진행이 완료된 후에 Support Workbench로 돌아가면, redo 오류는 사라지고 아카이브에 새로운 오류가 감지된 사실을 확인할 수 있습니다.

평상시처럼, 이 오류를 해결하기 위해서는 어드바이저를 시작합니다.

Automatic Diagnostic Repository

체커가 이상한 점을 발견하면, 추후 분석과 프로세싱을 위해 내용을 어딘가에 기록해야 합니다. 이러한 메타데이터는 Automatic Diagnostic Repository라는 새로운 장소에 기록되는데, 이 곳에는 체커가 감지한 이벤트만이 아니라 모든 주요 이벤트가 기록됩니다. 데이터베이스 내의 주요 이벤트 SYSTEM tablespace와 같습니다. Enterprise Manager를 사용해서 어떻게 레포지터리를 사용할 수 있는지 알아 보겠습니다.

Enterprise Manager 메인 데이터베이스 페이지에서 Software and Support라고 표시된 탭을 클릭한 후에 Support Workbench를 클릭하면 아래와 유사한 화면이 나타납니다.

체커가 보고한 내용을 요약해 보여 주는 것인데, ORA-603 오류가 발생했습니다. 오류 왼쪽의 + 표시를 클릭하면 이들 오류의 상세정보가 나타납니다.

Incidents 헤딩 아래 각각의 인시던트 ID에 해당되는 링크를 클릭하면 인시던트를 확인할 수 있습니다. 예를 들어, 14435 인시던트를 예로 들어 보겠습니다. 링크를 클릭하면 아래와 같이 화면에 인시던트의 상세정보가 표시됩니다.

화면 상단에 자기 설명적 상세정보가 나타날 수 있습니다. 화면 하단에는 trace 파일과 같은 인시던트의 지원 상세정보가 나타납니다. 분석을 위해 이들 파일을 Oracle Support에 보냅니다 (단, 파일들을 묶는 Incident Packaging Service를 사용하고 Oracle Configuration Manager로 적합한 크리덴셜을 구성하는 경우에 가능). 첫 번째 trace 파일 옆의 안경 아이콘을 클릭하면 아래와 같이 trace 파일이 나타납니다.

파일의 라인이 사용하기 매우 편리한 방식으로 구문 분석되어 제시됩니다. Enterprise Manager가 각 라인을 읽고, 의존 라인을 확인하여, 라인의 첫머리를 조정해서 적당하게 제시합니다. 파일의 하이퍼링크를 클릭하면, trace 파일의 원천 섹션을 확인하실 수 있습니다.
인시던트를 한 개의 ‘envelope’에 묶어서 Oracle Support에 보낼 수 있으며, 다음에 할 일이 바로 그것입니다. 이를 위해서는 Select 밑의 체크 박스 안을 클릭하고, Package라고 표시된 버튼을 클릭합니다. 아래와 유사한 화면이 나타납니다.

우선은 Custom Packaging은 무시하고, Quick Packaging을 클릭한 후에 Continue 버튼을 누릅니다. 아래와 같은 화면이 나타납니다.

모든 상세정보를 입력한 후 Next를 클릭합니다. 다음에 이어지는 화면에서 패키징된 부분, 패키지 매니페스트 등을 확인합니다. 여기에서 오류와 관련된 모든 관련 trace 파일을 확인하고 패키지에 추가할 수 있습니다. 이 프로세스를 사용하면, 실수가 일어나기 쉬운 특정 오류에 대해 정확한 trace 파일을 확인하는 작업을 하지 않아도 되며, 툴 역시 동일한 패키지 내의 관련 오류 trace 파일을 모으는 정보를 갖고 있습니다. 오라클이 문제의 근본 원인을 확인하기 위해서는 모든 관련 오류의 trace 파일이 필요하므로, 이러한 기능이 중요합니다. 패키징하기로 한 오류가 증상이기는 하지만 근본 원인은 아닐 수 있습니다. 마지막으로, Submit을 눌러 오라클에 패키지를 보냅니다. 전송이 완료되면 아래와 같이 화면이 조금 달라집니다.

Packaged 칼럼 밑에 내용이 입력되었습니다 ("Yes"). 이를 통해 인시던트가 패키지 되었음을 확인할 수 있습니다. 한 가지 부분을 더 살펴 봅니다.

생성 시간, 패키지 내의 주요 이슈 등과 같은 상세정보와 함께 업로드 파일이 생성되었음을 보여 줍니다. 그러나 아직 Configuration Manager가 설치되어 있지 않거나 구성되어 있지 않아 파일이 Oracle Support에 업로드 되지 않았습니다. 후에 이 기능에 대해서는 알아보도록 하겠습니다. 자 이제, 이름을 클릭하면 패키지에 대한 더욱 자세한 정보를 확인할 수 있습니다.

상세정보는 모두 자기 설명적입니다. 인시던트는 모두 하이퍼링크로 나타나고, 클릭하면 이전에 확인한 인시던트 페이지로 이동합니다. Files 라고 표시된 탭을 클릭하면 패키지 내에 포함된 모든 파일을 보여 주는 페이지가 나타납니다. 오른쪽의 작은 안경 아이콘은 클릭하면 파일을 볼 수 있다는 의미입니다.

이제 Activity Log 탭을 클릭하면, 언제 패키지가 생성되었는지, 언제 오라클에 보내졌는지와 같은 패키지 히스토리가 나타납니다.

Customizing the Package

이 툴의 가장 유용한 기능 중 하나가 바로 오라클에 보낼 패키지 컨텐츠를 맞춤화 하는 기능입니다. 실행을 위해 Customize라고 표시된 버튼을 클릭합니다. 버튼을 클릭하면 아래와 같은 화면이 나타납니다.

오른쪽의 Packaging Tasks 패널에 주목합니다. 이 패널에서 패키지와 관련된 다양한 과제를 수행하는 하이퍼링크를 볼 수 있습니다. 주요 과제는 다음과 같습니다. :
* 컨텐츠 편집
1. 문제 추가: 동일한 패키지에 문제를 추가할 수 있습니다. 추가 문제가 관련 있다고 생각되는 경우에 유용합니다.
2. 문제 배제: 문제를 제거할 수 있습니다. 문제가 패키지 안의 다른 문제들과 관련이 없다고 생각되는
경우에 유용합니다.
3. Package Manifest 보기: 매니페스트는 패키지 컨텐츠를 설명하는 문서로 (무엇에 대한 것인지, 어떤 문제를
발견했는지, 어떤 다양한 trace 파일이 포함되어 있는지 등) 텍스트 파일입니다. 이 링크를 클릭하면 매니페스트가 나타납니다.
* 사용자 데이터 스크럽
1. 파일 복사로 컨텐츠 편집: 원하는 경우에 패키지 내의 trace 파일과 다른 파일을 로컬 OS 폴더로 복사하고 편집할 수 있습니다. 파일에 민감한 사안이 포함되어 있는 경우에 사용할 수 있습니다.
2. 파일 복사로 컨텐츠 대체: 파일을 편집한 후에 패키지 내의 사본을 편집한 파일로 대체할 수 있습니다.
* 추가 진단 데이터
1. 추가 덤프 (Dump) 수집: 기존에 포함되어 있지 않는 경우에 (sql_trace = true 설정으로 인해 생성된 trace 파일 같은 경우) 다른 덤프를 추가하고 테스트할 수 있습니다.
2. 외부 파일 추가: Support에서 필요로 하는 경우에 외부 파일 (init.ora 혹은 listener.ora 등)을 패키지에 추가할 수 있습니다.
* Oracle Support에 전송
1. 컨텐츠 준비 완료: 이름에서 알 수 있듯이, 컨텐츠가 정확한지 Oracle Support에 전송될 준비가 되었는지 확인할 수 있습니다.
2. 업로드 파일 생성: 파일 목록 상의 모든 추가와 삭제와 더불어 다시 한번 업로드 파일을 생성할 수 있습니다.
3. 업로드 파일 보기/전송: Configuration Manager를 구성한 경우에 파일을 Support에 업로드 할 수 있습니다.

Configuration Manager

패키지가 개발되어 Oracle Support로 보내지고, CSI 및 MetaLink userid 등 세부 정보를 가진 드래프트 Service Request (TAR)가 개발된다면 멋지지 않을까요 Oracle Configuration Manager라는 툴을 사용하면 가능합니다.
Oracle Database 11g를 설치할 때, 이 툴을 설치, 구성할 것인지에 대한 물음에 "Yes"를 선택했다면, 이미 해당 작업이 완료되었으며, "No"를 선택했다면, 지금 구성할 수 있습니다.

Oracle Home의 cd to ccr/bin로 이동합니다. 그런 다음 최초로 Configuration Manager를 설정하기 위하여 setupCCR 파일을 실행합니다. 라이선스 메시지가 나타나고, 끝 부분에 승인할 것인지 거절할 것인지에 대한 질문이 보일 것입니다. 그런 다음 CSI#, MetaLink userid 등의 질문을 받게 될 것입니다. 다음의 텍스트는 대화형 섹션을 나타냅니다. 사용자가 입력할 내용은 굵은 글자체로 되어 있습니다.

*** Do you accept this license agreement (Y/N) [Y]: Y
구성은 다음과 같은 정보를 필요로 합니다.
Customer Support Identifier (CSI): XXXXXXX
Oracle MetaLink User Name: arup@proligence.com
The two character country code: US
** Installing base package **
Deploying core - Version 10.2.6.0.0
** Registering installation with Oracle Configuration Manager server(s) **
Deploying engines - Version 10.2.2.0.3
Deploying metricdata - Version 10.2.4.0.2
Deploying scripts - Version 10.2.6.0.0** Getting package updates from ContentServer **
** Starting the Oracle Configuration Manager Scheduler **
Oracle Configuration Manager - Release: 10.2.6.0.0 - Production
Copyright (c) 2005, 2007, Oracle. All rights reserved.
------------------------------------------------------------------
Starting Oracle Configuration Manager...
Waiting for status from Oracle Configuration Manager....
Start Date 16-Oct-2007 09:28:46
Last Collection Time -
Next Collection Time 17-Oct-2007 09:28:00
Collection Frequency Daily at 09:28
Collection Status scheduled collection running
Log Directory /home/oracle/app/oracle/product/11.1/db_1/ccr/log
Registered At 16-Oct-2007 09:28:17
Automatic Update On
Collector Mode ConnectedOracle Configuration Manager가 성공적으로 실행되었습니다.
Configuration Manager가 설정되면, 같은 디렉토리에 있는 configCCR 스크립트를 사용하여 파라미터를 변경할 수 있습니다.

ADR Home

데이터베이스의 진단 기능에 중점이 두어지기 때문에, Oracle Database는 체계적으로 정리된 trace 파일, 로그 파일 등을 저장해야 하게 됩니다. Automatic Diagnostic Repository (ADR) 파일들은 Diagnostic Destination (혹은 ADR Base)으로 특정된 공통 디렉토리 하부의 디렉토리들에 위치합니다. 이 디렉토리는 초기화 파라미터 (diagnostic_dest)에 의해 설정됩니다. 이것은 $ORACLE_BASE로 디폴트로 설정되지만, 별도의 디렉토리로 설정하는 것도 가능합니다. (하지만, 이 방법은 권장되지는 않습니다.) 이 디렉토리에는 diag라는 하부 디렉토리가 있는데, 여기에는 진단 파일이 저장된 하부 디렉토리들이 있습니다.

ADR은 데이터베이스 자체는 물론 ASM, CRS, listener 등 모든 컴포넌트의 로그 및 trace를 갖고 있습니다. 따라서, 한 곳에서 특정 로그를 찾아보는 것이 편리합니다.

ADR Base 내부에는, 각각의 컴포넌트 및 인스턴스를 위한 몇 개의 ADR Home이 있을 수 있습니다. 예를 들면, 서버가 2개의 오라클 인스턴스를 갖고 있다면, 2개의 ADR Homes가 존재합니다. 다음은 데이터베이스 인스턴스를 위한 ADR Homes의 디렉토리 구조입니다.

디렉토리 이름	개요
→diag
→rdbms
→<데이터베이스 이름>
→<인스턴스 이름>
→alert	XML 포맷의 alert 로그가 이 곳에 저장됩니다..
→cdump	이전 버전의 core_dump_dest에 해당하는 Core dumps가 이 곳에 저장됩니다.
→hm	Health Monitor가 여러 컴포넌트를 검사한 후, 일부 파일을 이 곳에 저장합니다.
→incident	모든 인시던트 덤프가 이 곳에 저장됩니다.
→<디렉토리들이 이 곳에 위치합니다>	각각의 인시던트는 서로 다른 디렉토리에 저장되며, 이들 디렉토리는 모두 여기에 저장됩니다.
→incpkg	인시던트를 패키징할 때 (패키징에 대해선 이 문서에서 자세히 알 수 있습니다), 특정 지원 파일들이 이 곳에 저장됩니다.
→metadata	문제, 인시던트, 패키지 등에 대한 메타데이터는 이 곳에 저장됩니다.
→trace	사용자 trace 및 백그라운드 trace가 alert 로그의 텍스트 버전과 함께 이 곳에 저장됩니다.

예를 들어, 데이터베이스 이름이 ODEL11이고 인스턴스 이름도 ODEL11 (대문자로)이라면, ADR Home의 경로는 /home/oracle/diag/rdbms/odel11/ODEL11입니다. 이 ADR Home에는 서로 다른 하부 디렉토리들이 있습니다:
$ ls
alert cdump hm incident incpkg ir lck metadata stage sweep trace

이 새로운 구조를 지원하려면, 이전 제품의 *_dest 파라미터 (background_dump_dest 및 user_dump_dest)는 무시되어야 합니다. (core_dump_dest는 무시되지 않습니다; 사실 오라클은 그것을 core dumps can be very large로 설정할 것을 권장합니다.) 사용자는 이들을 설정할 필요가 전혀 없으며, 10g에서11g로 업그레이드 할 때는, 나중에 혼동이 생기는 것을 없애기 위하여, 초기화 파라미터에서 이들을 제거해야 합니다.

다른 컴포넌트용 ADR 디렉토리도 유사합니다. 예를 들어 ASM 인스턴스의 경니다. 나머지 디렉토리 구조는 동일합니다. asm의 경우 타깃의 이름은 +asm입니다. 예를 들면, ADR Home for ASM의 하나의 예를 봅시다:

$ pwd
/home/oracle/diag/asm/+asm/+ASM
$ ls
alert cdump hm incident incpkg ir lck metadata stage sweep trace

리스너의 경우, diag 아래의 디렉토리는 tnslsnr로 불리며, 그 아래 호스트 이름을 가진 또다른 디렉토리가 있고, 그 아래 리스너 이름을 가진 또다른 디리들이 있습니다.
diag
tnslsnr
<서버의 호스트 이름>
<리스너의 이름>
alert
trace ...

예를 들면, oradba3라는 이름의 호스트와 "listener" (디폴트 이름)라는 이름의 리스너의 경우, 디렉토리는 유사하게 보일 것입니다 /home/oracle/diag/tnslsnr/oradba3/listener. 이 디렉토리 아래에 다른 모든 것 (alert, trace, metadata 등)이 생성됩니다. alert 로그처럼, 리스너 로그 파일 또한 하부 디렉토리인 alert에 XML 형식으로 저장됩니다. 일상적인 텍스트 리스너 로그 파일은 trace 디렉토리에서 생성됩니다 .

새로운 뷰인 V$DIAG_INFO는 ADR Homes에 대한 자세한 정보를 보여줍니다. 예를 들면, RDBMS home에서, 다음과 같이 보일 수 있습니다:

SQL> select * from v$diag_info;

INST_ID NAME VALUE
-------- ------------------------------ ----------------------------------------------
1 Diag Enabled TRUE
1 ADR Base /home/oracle
1 ADR Home /home/oracle/diag/rdbms/odel11/ODEL11
1 Diag Trace /home/oracle/diag/rdbms/odel11/ODEL11/trace
1 Diag Alert /home/oracle/diag/rdbms/odel11/ODEL11/alert
1 Diag Incident /home/oracle/diag/rdbms/odel11/ODEL11/incident
1 Diag Cdump /home/oracle/diag/rdbms/odel11/ODEL11/cdump
1 Health Monitor /home/oracle/diag/rdbms/odel11/ODEL11/hm
1 Default Trace File /home/oracle/diag/rdbms/odel11/ODEL11/trace/ODEL11_ora_3908.trc
1 Active Problem Count 3
1 Active Incident Count 3711 rows selected.

이 것은 이 인스턴스만의 ADR 정보를 나타냅니다. 다른 인스턴스의 정보를 보려면, 해당 인스턴스에 접속해 v$diag_info에서 선택하면 됩니다. 칼럼은 자기 설명적인 특성을 가집니다. 디폴트 trace 파일은 현재 세션의 trace 파일을 나타냅니다. Active Problem 및 Incident 카운트는 앞서 언급된 문제 및 인시던트에 대한 것입니다. 이들 파일에 접근하여 ADR에서 2가지 방법으로 다른 일을 수행할 수 있습니다. 가장 쉬운 방법은 앞서 본 Enterprise Manager를 사용하는 것입니다. 다른 방법은 asrci로 불리는 코맨드 라인 툴을 사용하는 것입니다. 이 툴을 사용하는 방법을 알아봅시다. UNIX (혹은 Windows) 코맨드 프롬프트에, "adrci"라고 입력합니다:

$ adrciADRCI: Release 11.1.0.6.0 - Beta on Sun Sep 23 23:22:24 2007Copyright (c) 1982, 2007, Oracle. All rights reserved.ADR base = /home/oracle

앞서 알아본 것처럼, 오라클 컴포넌트의 각각의 인스턴스를 위한 몇 개의 ADR Home이 있습니다. 따라서, 처음 할 일은 몇 개의 home이 존재하는지 알아보는 것입니다. 명령어는 show homes 입니다.
adrci> show homes
ADR Homes:
diag/rdbms/odel11/ODEL11
diag/rdbms/dbeng1/DBENG1
diag/clients/user_unknown/host_411310321_11
diag/tnslsnr/oradba3/listener

여기서 알 수 있듯이, 몇 개의 home이 보입니다. 특정 home에서 작업을 하려면, set homepath 코맨드를 사용해야 합니다:
adrci> set homepath diag/rdbms/odel11/ODEL11

설정이 끝나면, 프롬프트에 많은 코맨드를 사용할 수 있습니다. 처음 시도할 수 있는 코맨드는 help로, 이것은 모든 사용 가능한 코맨드를 보여줍니다. 출력 결과는 다음과 같습니다:
adrci> help

HELP [topic]
Available Topics:
CREATE REPORT
ECHO
EXIT
HELP
HOST
IPS
...

특정 코맨드에 대해 자세히 알고 싶다면, help 를 입력하십시오. 예를 들어, 코맨드의 사용법을 알고 싶다면, 다음과 같이 명령어를 입력하면 됩니다:
adrci> help show incident

Usage: SHOW INCIDENT [-p ]
[-mode BASIC|BRIEF|DETAIL]
[-last | -all]
[-orderby (field1, field2, ...) [ASC|DSC]]
Purpose: Show the incident information. By default, this command will
only show the last 50 incidents which are not flood controlled.Options:
[-p ]: The predicate string must be double-quoted.[-mode BASIC|BRIEF|DETAIL]: The different modes of showing incidents.
[... and so on ...]

통계 자료의 수집과 출판을 분리시키는 이 방법은 파티션 테이블에도 사용될 수 있습니다. 테이블을 파티션별로 로딩하고 있다고 가정합시다. 일부 정보를 옵티마이저에 피딩하지 않고, 모든 파티션의 통계를 동시에 보이게 하고 싶습니다. 하지만, 파티션이 로딩된 직후 시간을 활용하고 싶습니다. 이 경우 파티션이 로딩은 되었지만 출판되기 전에 파티션 정보를 수집하는 것이 가능합니다. 모든 파티션은 분석이 끝난 후, 한꺼번에 출판할 수 있습니다. 출력 결과를 통해 우리는 사용량을 알 수 있습니다. 이제 몇 개의 인시던트가 기록되었는지 알기 위하여 다음과 같은 명령어를 입력합니다:

adrci> show incident -mode basicADR Home = /home/oracle/diag/rdbms/odel11/ODEL11:
******************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
-------------------- ------------------------------ --------------------
14556 ORA 600 [KSSRMP1] 2007-10-17 04:01:57.725620 -04:00
14555 ORA 600 [KSSRMP1] 2007-10-16 18:45:03.970884 -04:00
14435 ORA 603 2007-10-16 06:06:46.705430 -04:00
14427 ORA 603 2007-10-16 06:06:42.007937 -04:00
14419 ORA 603 2007-10-16 06:06:30.069050 -04:00
6001 ORA 4031 2007-08-28 14:50:01.355783 -04:00
5169 ORA 4031 2007-09-04 19:09:36.310123 -04:00
5121 ORA 4031 2007-09-03 14:40:14.575457 -04:00
5017 ORA 4031 2007-09-04 19:09:30.969226 -04:00
4993 ORA 4031 2007-09-04 19:09:33.179857 -04:00
4945 ORA 4031 2007-09-04 19:09:30.955524 -04:00
4913 ORA 4031 2007-09-04 19:09:31.641990 -04:00이 것은 모든 인시던트의 리스트를 보여줍니다. 이제 아래와 같이 특정 인시던트에 대한 자세한 정보를 알 수 있습니다:
adrci> show incident -mode detail -p "incident_id=14556"
ADR Home = /home/oracle/diag/rdbms/odel11/ODEL11:
***********************************************************************************************************************************
INCIDENT INFO RECORD 1
**********************************************************
INCIDENT_ID 14556
STATUS ready
CREATE_TIME 2007-10-17 04:01:57.725620 -04:00[... and so on ...]INCIDENT_FILE /home/oracle/diag/rdbms/odel11/ODEL11/trace/ODEL11_mmon_14831.trc
OWNER_ID 1
INCIDENT_FILE /home/oracle/diag/rdbms/odel11/ODEL11/incident/incdir_14556/ODEL11_mmon_14831_i14556.trc
1 rows fetched

adcri 코맨드 라인에 나타난 정보는 Enterprise Manager 스크린에서 볼 수 있는 것과 유사합니다. 하지만, 후자의 경우가 보다 단순하고 사용자 친화적입니다. adcri는 어떤 이유로 EM Support Workbench에 접근하지 못할 때 매우 유용합니다. adcri는 alert 로그 파일을 첨부하거나 특정 패턴을 위해 어떤 로그 (listener, css, crs, alert 등)를 찾을 때도 사용할 수 있습니다. adcri는 ADR에서 프로그램 작업을 할 때도 유용합니다.

새로운 Alert 로그

Oracle Database 11g에서, alert 로그는 XML 포맷으로 작성됩니다. 다른 툴과의 호환성을 위하여, 전통적인 alert 로그는 trace 디렉토리 하부의 ADR Home에서도 사용할 수 있습니다. 예를 들면, 위 예에서, 디렉토리는 /home/oracle/diag/rdbms/odel11/ODEL11/trace로, 여기서 alert_ODEL11.log를 볼 수 있습니다. 하지만, 다른 alert 로그들은 XML 포맷으로 되어, ADR Home 하부의 alert 디렉토리에 위치해 있습니다. 파일들을 살펴 봅시다:

$ pwd
/home/oracle/diag/rdbms/odel11/ODEL11/alert
$ ls -ltr
total 60136
-rw-r----- 1 oracle oinstall 10485977 Sep 13 17:44 log_1.xml
-rw-r----- 1 oracle oinstall 10486008 Oct 16 06:35 log_2.xml
-rw-r----- 1 oracle oinstall 10485901 Oct 16 07:27 log_3.xml
-rw-r----- 1 oracle oinstall 10485866 Oct 16 08:12 log_4.xml
-rw-r----- 1 oracle oinstall 10486010 Oct 17 23:56 log_5.xml
-rw-r----- 1 oracle oinstall 9028631 Oct 21 20:07 log.xml

몇 개의 파일이 있다는 사실을 염두에 두십시오: log_1.xml, log_2.xml 등. log.xml이 일정 크기에 달하면, 해당 파일은 log_.xml로 다시 명명되고 새로운 파일이 시작됩니다. 이것은 alert 로그가 너무 크거나 관리할 수 없게 되는 것을 방지합니다.
새로운 alert 로그는 앞 섹션에서 밝힌 ADR 코맨드 라인 툴인 adrci 유틸리티를 통해 접근할 수 있습니다. adrci 툴에서 명령을 입력합니다:

adrci> show alert 다음의 중에서 보고자 하는 alert 로그를 선택합니다: 1: diag/rdbms/odel11/ODEL11 2: diag/clients/user_oracle/host_1967384410_11 3: diag/clients/user_unknown/host_411310321_11 4: diag/tnslsnr/oradba3/listener Q: to quit Please select option:

메뉴에서 하나를 선택하거나 특정 home을 입력할 수 있습니다:

adrci> set homepath diag/rdbms/odel11/ODEL11
adrci> show alertADR Home = /home/oracle/diag/rdbms/odel11/ODEL11:

[... 전체 alert 로그가 여기에 나타납니다 ...]

전체 alert 로그를 선택하지 않고, 마지막 몇 라인, 예를 들어 10개의 라인을 선택할 수 있습니다. (UNIX에서의 tail -10 command와 유사):

adrci> show alert -tail 10
2007-09-23 19:57:44.502000 -04:00
Errors in file /home/oracle/diag/rdbms/odel11/ODEL11/trace/ODEL11_arc1_20810.trc:
[... the rest of the 10 lines ...]

아마 이것을 가장 자주 이용하는 것은 alert 로그의 마지막 몇 라인을 지속적으로 보여주는 것으로, 이는 UNIX의 tail -f command와 유사합니다.
adrci> show alert -tail -f

adrci 코맨드 라인 프롬프트에서 스크립트를 실행할 수 있습니다. 다음은 home을 설정하고 alert 로그의 마지막 10 라인을 보여주는 Windows 스크립트의 예입니다:

C:\>type show_alert_10lines.cmd
set homepath diag\rdbms\lapdb11\lapdb11
show alert -tail 10아래에서 보듯이 이 스크립트를 호출할 수 있습니다:adrci script=show_alert_10lines.cmd이와 유사한 기능이 exec 파라미터로서, 코맨드 라인에서 직접 명령어를 실행할 수 있도록 합니다:adrci exec=”show homes; show catalog”adrci 프롬프트에서, "run" 명령어나 "@" 사인을 사용하여 명령을 실행할 수 있습니다:adrci>> @show_alert_10lines.cmd

XML 파일인 alert 로그의 가장 좋은 점은 정보가 체계적으로 작성된다는 것입니다. alert 로그가 비정형 데이터의 레포지토리였던 시대는 갔습니다. XML 포맷을 사용함으로써 파일은 adrci의 테이블로 볼 수 있게 되었습니다. 이 "table"의 필드를 보려면, describe 명령어를 사용하면 됩니다:

adrci>>describe alert_ext
Name Type NULL
----------------------------- --------------- -----------
ORIGINATING_TIMESTAMP timestamp
NORMALIZED_TIMESTAMP timestamp
ORGANIZATION_ID text(65)
COMPONENT_ID text(65)
HOST_ID text(65)
HOST_ADDRESS text(17)
MESSAGE_TYPE number
MESSAGE_LEVEL number
MESSAGE_ID text(65)
MESSAGE_GROUP text(65)
CLIENT_ID text(65)
MODULE_ID text(65)
PROCESS_ID text(33)
THREAD_ID text(65)
USER_ID text(65)
INSTANCE_ID text(65)
DETAILED_LOCATION text(161)
UPSTREAM_COMP_ID text(101)
DOWNSTREAM_COMP_ID text(101)
EXECUTION_CONTEXT_ID text(101)
EXECUTION_CONTEXT_SEQUENCE number
ERROR_INSTANCE_ID number
ERROR_INSTANCE_SEQUENCE number
MESSAGE_TEXT text(2049)
MESSAGE_ARGUMENTS text(129)
SUPPLEMENTAL_ATTRIBUTES text(129)
SUPPLEMENTAL_DETAILS text(129)
PARTITION number
RECORD_ID number
FILENAME text(513)
PROBLEM_KEY text(65)

이제 정보가 체계화되었으므로, 정확한 검색이 가능합니다. 필드의 특정 값과 매칭되는 alert 로그의 라인을 찾는 예를 보도록 하겠습니다:

adrci>> show alert -p "module_id='DBMS_SCHEDULER'"

이것은 module id dbms_scheduler 프로세스에 의해 작성된 모든 라인을 보여줍니다. 또한, inequality
operator를 사용할 수도 있습니다. (DBMS_SCHEDULER 불포함):
adrci>>show alert -p "module_id != 'DBMS_SCHEDULER'"

마찬가지로 pattern-matching operators를 사용할 수도 있습니다:

adrci>>show alert -p "module_id like '%SCHEDULER'"

스풀 코맨드는 명령어는 SQL*Plus에서 스풀 명령을 수행하여, 결과를 파일로 스풀링합니다:

adrci>> spool a
adrci>> show alert -tail 50
adrci>> spool off

이것은 alert 로그의 마지막 50 라인을 포함하는 파일 (a.ado)을 생성합니다. 이 옵션을 많이 사용하는 것은 alert 로그에서 특정 유형의 메시지를 추출하는 경우입니다. alert 로그에서 Streams 관련 구문을 추출하고자 한다면 다음과 같이 할 수 있습니다:

adrci> show alert -p "message_text like '%STREAM%'"

adrci 코맨드 프롬프트에서 ADR 베이스 디렉토리로 수집된 모든 trace 파일도 볼 수 있습니다

adrci>> show tracefile

위의 명령어는 ADR 디렉토리에 수집된 모든 trace 파일을 나타냅니다. 특정 유형의 trace 파일들( "reco" 등)을 과거의 것부터 나타내려면 다음과 같이 합니다:

adrci>>show tracefile %reco% -rt
18-JUL-07 22:59:50 diag\rdbms\lapdb11\lapdb11\trace\lapdb11_reco_4604.trc
12-JUL-07 09:48:23 diag\rdbms\lapdb11\lapdb11\trace\lapdb11_reco_4236.trc
11-JUL-07 10:30:22 diag\rdbms\lapdb11\lapdb11\trace\lapdb11_reco_3256.trc

adrci는 가장 효율적인 방법으로 alert 로그 및 관련 파일을 볼 수 있는 다양한 옵션을 제공합니다. adrci 코맨드에 대한 자세한 설명은 이 문서 를 참조하십시오