Oracle 11g feature van de maand: Automatic Diagnostic Repository

September 2008 - Op 6 november 2007 vond de eerste officiële release plaats van de nieuwste versie van de Oracle database: 11g. In eerdere Whitebooks behandelden de specialisten van Whitehorses al diverse belangrijke nieuwe features. Deze maand: de Automatic Diagnostic Repository.

Oracle software wordt met de grootste zorg ontwikkeld en getest voordat deze vrijgegeven wordt voor gebruik. Dat geldt ook voor de hardware waarop de Oracle software gecertificeerd wordt. Helaas komt Murphy op de meest onverwachte en ongelegen momenten om de hoek kijken. De software vertoont bugs waardoor fuctionaliteit niet werkt of, nog erger, de database crasht. Ook de hardware kan mankementen vertonen die leiden tot verlies van service.

Ernstige software of hardware problemen worden, indien ze niet zelf opgelost kunnen worden, gemeld bij Oracle Support. Via Oracle Metalink wordt een Service Request (SR) aangemaakt en de dialoog met de support engineers kan beginnen. In de praktijk blijkt dit vaak een tijdrovende en soms voor beide partijen een frustrerende exercitie te zijn. Om een goede diagnose van het probleem te stellen wordt de klant keer op keer verzocht additionele informatie te verstrekken, wat de tijd om het probleem op te lossen niet ten goede komt.

Oracle heeft dit ook onderkend en introduceert als onderdeel van de 11g-database de Automatic Diagnostic Repository, kortweg de ADR genoemd. Het doel van de ADR is om de tijd benodigd voor het stellen van een diagnose en het oplossen van een probleem drastisch te bekorten.

Met de ADR biedt Oracle een centrale beheeromgeving voor alle relevante informatie die betrekking heeft op het diagnosticeren van ernstige fouten in de database. De ADR is overigens zodanig ingericht dat ook andere software producten van Oracle in de toekomst gebruik kunnen maken van deze nieuwe feature.

In dit Whitebook gaan we in op hoe de ADR is ingericht en wat de ADR aan functionaliteit te bieden heeft.

Wat is de Automatic Diagnostic Repository?

De ADR is op de eerste plaats een directory structuur die, onafhankelijk van de database, op het filesystem van de server wordt ingericht bij installatie van de 11g Server software. De wijze waarop de ADR is ingericht betekent een behoorlijke aanpassing op de bekende OFA (Optimal Flexible Architecture) manier van inrichten van de server.

Een nieuwe init.ora parameter geeft aan waar de ADR BASE te vinden is:

SQL> show parameter diag 

NAME                                 TYPE        VALUE 
------------------------------------ ----------- ------------------------------ 
diagnostic_dest                      string      /app/oracle 

Hieronder vinden we, per database, onder andere de volgende directories:

diag/rdbms/<database-naam>/<database-SID>/alert 
                                         /cdump 
                                         /trace 
                                         /incident 

De alert log van de database vinden we nu in de 'alert' directory in XML formaat! Vanwege de backward compatibility is de tekstversie van het alert log gelukkig nog te vinden in de 'trace' directory.

Opvallend is dat de oude bekenden 'bdump' en 'udump' directories verdwenen zijn. Van nu af aan worden alle trace files naar de 'trace' directory geschreven. De directory 'incident' is de locatie waar de ADR incidents gelogd worden. Per incident zal hier een nieuwe subdirectory verschijnen.

Een nieuwe view, V$DIAG_INFO biedt gedetailleerde informatie over de ADR repository:

SQL> select name from v$diag_info order by name; 

NAME 
------------------------------ 
ADR Base 
ADR Home 
Active Incident Count 
Active Problem Count 
Default Trace File 
Diag Alert 
Diag Cdump 
Diag Enabled 
Diag Incident 
Diag Trace 
Health Monitor 

11 rows selected. 

Is de database eenmaal operationeel en doet zich een ernstig probleem voor met het functioneren van de software, dan verzorgt ADR het automatisch vastleggen en groeperen van alle aan het probleem gerelateerde informatie. Denk hierbij aan trace files, dumps, logging informatie enzovoort. Het automatisch vastleggen wordt verzorgd door twee nieuwe database processen, DIAG en DIAO die bij het opstarten van de database verschijnen.

Is een probleem eenmaal geregistreerd dan worden alle verdere aan het probleem gerelateerde incidenten automatisch vastgelegd. Hierbij wordt het aantal 'incidents' gemaximeerd ('flood control') om het eventueel vollopen van het filesystem te voorkomen.

Om een 'problem' met alle bijbehorende 'incidents' te bekijken kan gebruik worden gemaakt van de nieuwe utility ADRCI (Automatic Diagnostic Repository Command Interface). Oracle Enterprise Manager biedt ook de mogelijkheid de ADR informatie te beheren.

Een voorbeeld uit de praktijk: ORA-01578: Block corruption

In het wat versleten schema 'SCOTT' is een tabel aangemaakt met de naam 'MOOI'. De gevolgen laten zich raden: binnen deze tabel blijkt een database block corrupt te zijn:

SQL> select * from scott.mooi; 
select * from scott.mooi 
                    * 
ERROR at line 1: 
ORA-01578: ORACLE data block corrupted (file # 4, block # 404) 
ORA-01110: data file 4: '/APP/ORADATA/ORCL/USERS01.DBF' 

ADR komt meteen in actie naar aanleiding van het falende select statement en logt een 'problem' met het bijbehorende 'incident'. Ieder volgend incident wordt automatisch gekoppeld aan het eerder vastgelegde probleem.

Met behulp van ADRCI kan het 'problem' en de bijbehorende 'incidents' als volgt bekeken worden. Eerst zetten we de juiste ADR 'home' omgeving:

adrci> set homepath rdbms/orcl 

Daarna kan de informatie opgevraagd worden:

adrci> show problem 

ADR Home = /app/oracle/diag/rdbms/orcl/orcl: 
******************************************************************************** 
PROBLEM_ID           PROBLEM_KEY LAST_INCIDENT LASTINC_TIME 
-------------------- ----------- ------------- --------------------------------- 
1                    ORA 1578    14555         2008-09-01 14:52:13.660000 +02:00 

1 rows fetched 

adrci> show incident 

ADR Home = /app/oracle/diag/rdbms/orcl/orcl: 
******************************************************************************** 
INCIDENT_ID          PROBLEM_KEY CREATE_TIME 
-------------------- ----------- ----------------------------------------------- 
14555                ORA 1578    2008-09-01 14:52:13.660000 +02:00 
14554                ORA 1578    2008-09-01 14:50:02.637000 +02:00 
14553                ORA 1578    2008-09-01 14:49:58.919000 +02:00 

3 rows fetched 

Vervolgens kan, indien men niet beschikt over voldoende kennis om dit probleem op te lossen, de informatie in de vorm van een package naar Oracle Support gezonden worden. Nadat een Service Request is aangemaakt op Oracle Metalink wordt als volgt een 'package' samengesteld:

adrci> ips create package incident 14555 
Created package 1 based on incident id 14555, correlation level typical 
adrci> ips generate package 1 in /home/dba/ 
Generated package 1 in file /home/dba/ORA1578_20080901151043_COM_1.zip,  
  mode complete 

Het aangemaakte bestand bevat alle relevante informatie, trace- en logfiles en kan vervolgens, gekoppeld aan het Service Request, naar Oracle Support verzonden worden. Een eenmaal aangemaakte package vormt geen statisch geheel. Aan een package kan m.b.v. ADRCI later nog informatie toegevoegd worden.

Support komt, mede dankzij de ADR package, al snel met de oplossing. Met behulp van RMAN (we beschikken gelukkig over een goede backup!) is het leed snel verholpen:

1. Waar bevindt zich het corrupte database block?

sqlplus / as sysdba 

SQL> select * from v$database_block_corruption; 

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO 
---------- ---------- ---------- ------------------ --------- 
         4        404          1                  0 CORRUPT 

2. Met de RMAN blockrecover functie (een 10g feature) wordt het block online gerepareerd:

rman 

Recovery Manager: Release 11.1.0.6.0 - Production on Mon Sep 1 15:28:55 2008 

Copyright (c) 1982, 2007, Oracle.  All rights reserved. 

RMAN> connect target 

connected to target database: ORCL (DBID=1191826843) 

RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 404; 

Starting recover at 01-SEP-08 
using target database control file instead of recovery catalog 
. 
. 
. 
media recovery complete, elapsed time: 00:00:03 

Finished recover at 01-SEP-08 

RMAN> 

Het probleem is verholpen!

Conclusie

De Automatic Diagnostic Repository betekent een significante verbetering daar waar het gaat om het snel diagnosticeren en oplossen van problemen. Tot en met versie 10g van de database was er geen instrument voorhanden dat voorzag in het automatisch rapporteren en bundelen van relevante informatie met betrekking tot problemen die zich voordeden in de software. De DBA moest vaak, op aanwijzing van Support, een forse hoeveelheid informatie in 'bits & pieces' opsturen. ADR biedt een goede ondersteuning daar waar het gaat om het snel kunnen analyseren en oplossen van problemen.

Referentie

• Oracle Database Administrator's Guide 11g Release 1

Over de auteur
Jan Vader is sinds 1986 werkzaam in de ICT en vanaf 1996 werkzaam als DBA.