CHAPTER 25

Diagnosing Failures

Exam Objectives

• 63.1.9.1    Describe the Automatic Diagnostic Workflow

• 63.1.9.2    Handle Block Corruption

When you have to deal with database errors or even a database that is completely down, you don’t want to spend extra time documenting one or more database error conditions for Oracle Support. This chapter first gives you a brief overview of how Oracle reports problems with the database and then shows how it categorizes errors into problems and incidents.

In addition, the Health Monitor framework provides both proactive and reactive tools to deal with database errors. The database administrator (DBA) can run a proactive health check manually using Enterprise Manager Cloud Control 12c (Cloud Control) or PL/SQL packages. In contrast, the Health Monitor can run diagnostic checks in response to critical database errors.

Finally, the chapter will switch from reporting, managing, and submitting service requests for database problems and incidents to recovering individual blocks after you have identified the problem. Recovery Manager (RMAN) supports the detection and recovery of individual blocks using the DB_BLOCK_CHECKING initialization parameter and the RMAN RECOVER . . . BLOCK command. RMAN also makes it easy to identify failures and implement repairs using the Data Recovery Advisor.

Describe the Automatic Diagnostic Workflow

The key to the automatic diagnostic repository (ADR) is the first word: automatic. ADR is an always-on facility that captures errors in trace and dump files the first and any successive times they occur (which is the reason for the diagnostic part of the Oracle feature name). The third part, repository, is a location on disk that stores the diagnostic information on disk and comes with a tool that makes it easy to query the repository even when the database is unavailable.

The following sections provide more details about the structure of the repository, how to retrieve information from the repository, and how to find the diagnostic information you’re looking for in the repository using initialization parameters and data dictionary views. In addition, you’ll see how to easily and quickly package the diagnostic information from the ADR and send it to Oracle support for problem resolution.

Understanding the ADR

The ADR is a file-based repository of diagnostic and other noncritical information for all products in your environment. Each database instance and Automatic Storage Management (ASM) instance has its own directory structure called an ADR home within a top-level directory known as the ADR base. In a Real Application Clusters (RAC) environment, each instance has its own subdirectory, which not only makes it easy to view diagnostics for an individual instance, but also makes it easy for the diagnostic tools to analyze data across instances for cluster-wide problems.

The ADR base directory is also known as the ADR root directory. The location for the ADR base is set depending on the values of initialization parameters and environment variables. If the initialization parameter DIAGNOSTIC_DEST is set, the ADR base directory is set to this value, and all other file locations are set relative to this location. If DIAGNOSTIC_DEST is not set, then DIAGNOSTIC_DEST is set to the environment variable ORACLE_BASE. Figure 25-1 shows the ADR directory structure for the COMPLREF database.

Figure 25-1    ADR directory structure for the COMPLREF database

For the database in Figure 25-1, the initialization parameter DIAGNOSTIC_DEST is not set, so Oracle sets DIAGNOSTIC_DEST to the value of the environment variable ORACLE_BASE, which in this case is /u01/app/oracle.

You can retrieve the values for each diagnostic directory using the dynamic performance view V$DIAG_INFO, as in this example:

Note the column INST_ID. In a RAC environment, this value differentiates the value of each directory by node. For example, if COMPLREF were the database name and the database contained the three instances COMPLREF1, COMPLREF2, and COMPLREF3, the value for the second instance’s diagnostic trace directory would be as follows:

Compared to previous releases of Oracle, the diagnostic information is better partitioned. In other words, all nonincident trace files are stored in the trace subdirectory, all core dumps are in the cdump directory, and all incident dumps are stored as individual directories within the incident subdirectory. Table 25-1 shows the ADR location for each type of diagnostic data.

Table 25-1    ADR Diagnostic Information Directory Locations

Note the differentiation between trace and dump files. Trace files contain continuous output to diagnose a problem with a running process. A dump file is a one-time diagnostic output file resulting from an incident. Similarly, a core dump is a one-time platform-specific binary memory dump. Note also that there is no initialization parameter or environment variable named ADR_HOME. You can determine the value of ADR_HOME from the row in V$DIAG_INFO containing the name ADR Home.

Using the ADRCI Tool

The ADR Command Interpreter (ADRCI) tool makes it easy to query the contents of the ADR. You can use the tool in command mode or create scripts to run in batch mode. You can use ADRCI even when the database is down—remember that the ADR is completely file system based. In addition to querying the contents of the ADR with ADRCI, you can package incident and problem information into a compressed ZIP file that you can send to Oracle Support.

Note that ADRCI does not require a login or any other authorization. The contents of the ADR are protected only by operating system permissions on the directory containing the ADR file structures. For a default installation of Oracle Database 12c, this means that the ADR has the same permissions as the ORACLE_BASE directory and its subdirectories. You can alter the permissions further if you want, but you must make sure the user owning the Oracle processes (usually the oracle user) has full read-write access to the ADR.

When you start ADRCI, you see the current ADR base directory. Type help for a list of commands.

Even when there are no incidents or problems to view, you can perform more mundane tasks such as viewing the alert log from ADRCI.

Notice that the ADRCI tool tracks all ADR home directories within the ADR root directory. Therefore, you must select which database, ASM, or listener directory you want to view with ADRCI.

Of course, you can perform the same task from Cloud Control 12c. At the bottom of the Cloud Control home page, click the Alert Log Contents link. Then select the number of lines at the end of the alert log you want to see and click Go. You’ll see the page shown in Figure 25-2.

Figure 25-2    Viewing alert log contents from Cloud Control

Understanding Alerts, Problems, and Incidents

Although the alert log (either text format or XML format) contains all alerts for the instance, you see the alerts at the warning and critical levels on the Enterprise Manager (EM) home page. You can view specific incidents in the Incident Manager in Cloud Control 12c. In Figure 25-3, you see several recent incidents. In the oldest incident (at the bottom), Cloud Control reported that a user was trying to access an object without the proper privileges. In the most recent incident, the database reports that a user connected to the SYS user or another user with SYSDBA privileges.

Figure 25-3    Viewing error alerts in EM

A problem, defined by the Support Workbench framework, is a critical error in the database, such as the internal error ORA-00600 or some other serious event such as running out of memory in the shared pool or an operating system exception. An incident is a single occurrence of a problem. Each problem has a problem key, which is a text string that contains the error code and optionally other problem characteristics. A problem may have one or many incidents. Each incident is identified by a numeric incident ID and is stored in its own subdirectory of the ADR (ADR_HOME/incident/incdir_n). When an incident occurs, the database performs the following steps:

1.  Adds an entry to the alert log (both text and XML based)

2.  Sends an incident alert to EM

3.  Sends an alert via e-mail to administrators (if configured)

4.  Gathers trace files and other incident information

5.  Tags all incident information with the incident ID

6.  Creates an incident directory under ADR_HOME for the incident and stores incident information and trace files in the directory

Using the Health Monitor

You can use the Oracle Health Monitor framework to proactively or reactively assess the health of your database. Health Monitor checks the status of various database components, including the following:

•  Datafiles

•  Memory

•  Transaction integrity

•  Metadata

•  Process usage

You can run health checks using Cloud Control via the Support Workbench, or you can manually run a health check using the DBMS_HM PL/SQL package. Some checks can be run only when the database is open. Other checks are available when the instance is running but the database is in NOMOUNT mode. You can list the checks available and whether they are available in offline or online mode by querying the dynamic performance view V$HM_CHECK.

Note that all but eight of the checks are INTERNAL_CHECK='Y'. The DBA cannot invoke the internal checks. You can view the results of health checks from the ADRCI tool with the show hm_run command. In the following examples, you retrieve the results of a Health Monitor run first in text format, and then you generate a Health Monitor report in XML format.

To run a check manually, use the DBMS_HM package. For example, this is a run of the Data Dictionary Integrity check, ID 24 in the previous listing:

Handle Block Corruption

Many of the errors you will encounter will be related to bad blocks in your database datafiles because of either media failures, server memory errors, or logical corruption caused by Oracle bugs (not that Oracle has bugs—merely anomalous and undocumented behavior). Once you’ve identified these problems using the diagnostic methods provided earlier in this chapter, you can use the tools in the following sections to fix the problems.

As with nearly every Oracle feature, you can adjust the level of control and monitoring that Oracle performs; data block checking is no exception. Regardless of the settings you’ll learn about shortly, Oracle always performs the following checks on a data block when it is read from or written to a datafile:

•  Checks that the block version matches the version of the database

•  Checks that data block address (DBA) in the cache is the same as the DBA value in the block buffer

•  Checks that, by default, the block checksum is correct

You can repair a corrupt block either by recovering the block or by dropping the object containing the bad block. The following sections tell you more about block corruption, how to control the amount of overhead Oracle will use to ensure the integrity of blocks, and how to fix a corrupted block.

Block Corruption

When Oracle detects a corrupted block, it registers an ORA-01578 error in the alert log and on the EM home page. Included in the error message are the absolute file number and block number of the bad block. In addition, the session reading or writing the bad block sees the same error message. Here is an example of a block corruption error message:

Most often, corruption is caused by operating system or disk hardware failures such as faulty input/output (I/O) hardware or firmware, operating system caching problems, memory or paging problems, or errors caused by disk repair utilities.

Two instance parameters control the checks for block corruption: DB_BLOCK_CHECKSUM and DB_BLOCK_CHECKING.

DB_BLOCK_CHECKSUM has three possible values:

•  OFF or FALSE    No checksums are computed.

•  TYPICAL    This is the default value. Checksums are computed when writing a block to disk and validated on reading it from disk.

•  FULL    Checksums are computed and checked every time a block is changed. Checksums are also added to redo blocks on writing.

Note that even if this parameter is OFF, checksums are still computed for all blocks in the SYSTEM tablespace.

The initialization parameter DB_BLOCK_CHECKING controls how thoroughly Oracle checks the logical structure of every data block. The level of checking you enable depends on the level of failure tolerable in your environment balanced against the overhead required to perform the continuous block checks. The possible values for DB_BLOCK_CHECKING are as follows:

•  OFF or FALSE    This is the default value; no block checking is performed.

•  LOW    Basic block checks are performed after blocks are changed in memory or read from disk, including interinstance block transfers in RAC environments.

•  MEDIUM    This includes all LOW checks plus block checking for all non-index-organized table blocks.

•  FULL or TRUE    This includes all LOW and MEDIUM checks plus checks for index blocks.

DB_BLOCK_CHECKING is known to have a performance overhead, and by default it is therefore not enabled. However, FULL block checking for the SYSTEM tablespace is always enabled and cannot be stopped.

The default value for DB_BLOCK_CHECKSUM means that Oracle will be able to detect damage to a block that occurred while it was on disk. Good idea! Enabling DB_BLOCK_CHECKING lets Oracle detect problems that occur while the block is in memory. Usually this is not necessary and would be enabled only on instruction from Oracle Support when trying to resolve a problem.

Using Block Media Recovery

If you discover only a small handful of blocks to recover in a database from the aforementioned health checks or results discovered in the alert log, RMAN can perform block media recovery rather than a full datafile recovery. Block media recovery minimizes the time required to apply the redo logs (since only a small part of each redo log is needed or possibly no redo logs are required!) and drastically reduces the amount of I/O required to recover only the block or blocks in question. While block media recovery is in progress, the affected datafiles can remain online and available to users.

In addition to the block verification performed by Oracle as defined by the DB_BLOCK_CHECKING initialization parameter, an RMAN BACKUP or BACKUP VALIDATE command can add information about corrupted blocks to the dynamic performance view V$DATABASE_BLOCK_CORRUPTION.

You’ll need to know the advantages and disadvantages of block media recovery; as you might expect, there are many more advantages than disadvantages. In addition to touting the benefits of RMAN block media recovery, the following sections cover the prerequisites for block media recovery and provide some real-world use cases.

Advantages of Block Media Recovery

Recovering one or a small number of blocks using RMAN has some obvious and some not-so-obvious advantages. First, recovering one block using a recent backup, together with archived and online redo log files, will almost certainly take much less time than restoring and recovering one or more datafiles. In addition, during block media recovery, the entire datafile remains online and available during the recovery process; only the blocks being recovered are unavailable. Therefore, only a small part of one table, index, or other database object remains unavailable during block media recovery.

When you use the RMAN RECOVER . . . BLOCK command, RMAN first searches the flashback logs for a good copy of the corrupted block (if Flashback Database is enabled). Otherwise, RMAN uses the latest level 0 or full backup, restores the bad blocks, and performs media recovery on the bad blocks using the redo stream. Note that RMAN cannot use incremental level 1 backups for block media recovery.

You can use the dynamic performance view V$DATABASE_BLOCK_CORRUPTION to view the bad blocks in the database. This view contains blocks that are both physically and logically corrupted. Here are the tools or commands that can populate this view when they find bad blocks:

•  RMAN backup commands

•  ANALYZE

•  dbv operating system utility

•  SQL queries that try to access a corrupted block

Prerequisites for Using Block Recovery

Before you can use block media recovery, your database must fulfill a few prerequisites. First, the target database must be in ARCHIVELOG mode. Unless your database is for testing or is a read-only database, your database should be in ARCHIVELOG mode for maximum recoverability anyway!

Second, the backups of datafiles with bad blocks must be full backups or level 0 incremental backups. RMAN cannot use level 1 incremental backups for block recovery. Thus, you must have all archived redo log files since the last full backup or level 0 incremental backup.

Alternatively, you can use flashback logs in the flash recovery area for retrieving uncorrupt versions of bad blocks if you have Flashback Database enabled. Unless the number of bad blocks is large, recovering a block from the flashback logs will certainly be faster than starting with a level 0 incremental or full backup.

Using the RMAN RECOVER . . . BLOCK Command

You can use the RMAN RECOVER . . . BLOCK command in response to an alert or other notification of a bad block. Typically, block corruption is reported in the following locations:

•  Output from the RMAN LIST FAILURE, VALIDATE, or BACKUP . . . VALIDATE commands

•  The V$DATABASE_BLOCK_CORRUPTION dynamic performance view

•  Error messages during a SQL*Plus or other client session

•  The alert log or user trace files

•  Results from the SQL commands ANALYZE TABLE or ANALYZE INDEX

•  Results from the DBVERIFY command-line utility (dbv)

To recover one or more data blocks, RMAN must know the datafile number and block number within the datafile. As mentioned previously, this information is available in a user trace file, as in the following example:

In addition, the block information will appear in the view V$DATABASE_BLOCK_CORRUPTION; the columns FILE# and BLOCK# provide the information needed to execute the RECOVER command. The column CORRUPTION_TYPE identifies the type of corruption in the block, such as FRACTURED, CHECKSUM, or CORRUPT. Fixing the block is easily accomplished in RMAN.

A corrupted block must be recovered completely. In other words, all redo operations up to the latest SCN against the data block must be applied before the block can be considered usable again.

If all bad blocks are recorded in V$DATABASE_BLOCK_CORRUPTION, you can easily recover all of them at once. Using the following command, RMAN will recover all physically corrupted blocks in V$DATABASE_BLOCK_CORRUPTION:

After RMAN recovers the blocks, they are removed from V$DATABASE_BLOCK_CORRUPTION.

Using the Data Recovery Advisor

The Data Recovery Advisor is part of the Oracle advisor framework and automatically gathers information about a failure when an error is encountered. If you run the Data Recovery Advisor proactively, you are often able to detect and repair a failure before a user query or backup operation detects it. The Data Recovery Advisor can detect relatively small errors such as corrupted blocks. At the other end of the spectrum, it will detect errors that would otherwise prevent successful startup of the database, such as missing online redo log files. Your database may continue running for a short amount of time without online redo log files, but it will not start the next time you shut down and restart. Data Recovery Advisor will catch this error proactively.

Identifying Failures

As with most advisors and Oracle features, you can use either Cloud Control or command-line tools to run the Data Recovery Advisor, show the errors, and repair the failures.

Once the Data Recovery Advisor has identified a failure, you can review the details of the failure using the EM or RMAN interface. From RMAN, you can use the LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, and CHANGE FAILURE commands. Table 25-2 summarizes the purpose of these commands.

Table 25-2    RMAN Failure Advisory and Repair Commands

The LIST FAILURE command has a number of options, depending on what types of errors you want to see:

•  Failure#    Lists an individual failure’s details (by failure number).

•  ALL    Lists all failures.

•  CRITICAL    Lists failures that make the database unavailable.

•  HIGH    Lists serious failures that make parts of the database unavailable, such as a missing datafile.

•  LOW    Lists intermittent or lower-priority failures that can wait until more serious problems are fixed. For example, this can include corrupted blocks in infrequently used tablespaces.

•  CLOSED    Lists only closed failures.

For example, LIST FAILURE 2097 lists the details for a failure with an identifier of 2097. Also, LIST FAILURE ALL lists all open failures of any priority.

Implementing Repairs

Once the Data Recovery Advisor has identified a failure, you can use the RMAN ADVISE FAILURE command to recommend a repair option for the specified failure. RMAN will suggest a repair and create a script with the recommended repair. If the repair is acceptable (in terms of downtime or other factors), you can then run REPAIR FAILURE (within the same RMAN session) to perform the recommended action. After the repair action completes successfully, the failure is automatically closed. The commands must always be run in the correct order: LIST, then ADVISE, then REPAIR.

You can also change the priority of a failure using CHANGE FAILURE. For example, a corrupted block will be recorded as a HIGH failure, but if it is in an infrequently used tablespace, then you can change its priority to LOW so that you see only other more serious failures in the LIST FAILURE command. However, you cannot change the priority of a CRITICAL failure. You can change the priority of a failure only from HIGH to LOW, or vice versa. Here is how you can change the priority of failure number 307 from HIGH to LOW:

Data Recovery Advisor Views

You can use several dynamic performance views to retrieve information about failures detected by the Data Recovery Advisor:

•  V$IR_FAILURE    Lists all failures, including closed failures

•  V$IR_MANUAL_CHECKLIST    Lists of manual advice

•  V$IR_REPAIR    Lists of repairs

•  V$IR_REPAIR_SET    Cross-references failure and advises on identifier numbers

For example, to retrieve the information for the failure with an ID of 37305, query V$IR_FAILURE as follows:

Exercise 25-1: Use the DRA to Diagnose and Resolve Problems    In this exercise, you will cause a problem with the database and use the DRA to report on and fix it.

1.  From an operating system prompt, launch the RMAN executable.

2.  Confirm that there is a whole full backup of the SYSAUX tablespace.

If this does not return at least one backup set of type FULL, create one.

3.  Shut down the instance and exit from RMAN.

4.  Using an operating system utility, delete the datafile (or datafiles) for the SYSAUX tablespace that were listed in step 2. If using Windows, you may have to stop the Windows service under which the instance is running to release the Windows file lock before the deletion is possible.

5.  Connect to the database with SQL*Plus and attempt a startup.

This will stop in mount mode, with an error regarding the missing file. If using Windows, make sure the service has been started.

6.  Launch the RMAN executable and connect, as in step 1.

7.  Diagnose the problem.

This will return a message to the effect that one or more nonsystem datafiles are missing.

8.  Generate advice on the failure.

This will suggest that you should restore and recover the datafile and generate a repair script. Open the script with any operating system editor and study its contents.

9.  Run the commands in the generated script to restore the missing file, recover it, and bring it online.

Two-Minute Drill

Describe the Automatic Diagnostic Workflow

•  ADR is an always-on facility that captures errors in trace and dump files the first and any subsequent times they occur.

•  ADR uses a location on disk to store the diagnostic information and comes with a tool that makes it easy to query the repository even when the database is unavailable.

•  Each database instance or Automatic Storage Management instance has its own directory structure called an ADR home within a top-level directory known as the ADR base.

•  The ADR base directory is also known as the ADR root directory.

•  If the initialization parameter DIAGNOSTIC_DEST is set, the ADR base directory is set to this value, and all other file locations are set relative to this location.

•  If DIAGNOSTIC_DEST is not set, then DIAGNOSTIC_DEST is set to the environment variable ORACLE_BASE.

•  If ORACLE_BASE is not set, DIAGNOSTIC_DEST is set to the value $ORACLE_HOME/log.

•  The ADR diagnostic information is partitioned. All nonincident traces are stored in the trace subdirectory, all core dumps are stored in the cdump directory, and all incident dumps are stored as individual directories within the incident subdirectory.

•  The ADR Command Interpreter tool makes it easy to query the contents of the ADR. You can use ADRCI even when the database is down.

•  ADRCI does not require a login or any other authorization. The contents of the ADR are protected only by operating system permissions on the directory containing the ADR file structures.

•  A problem, as defined by the Support Workbench framework, is a critical error in the database. An example is the internal error ORA-00600 or some other serious event such as running out of memory in the shared pool or perhaps an operating system exception.

•  An incident is a single occurrence of a problem.

•  Each problem has a problem key, which is a text string that contains the error code and optionally other problem characteristics.

•  Health Monitor checks the status of various database components, including datafiles, memory, transaction integrity, metadata, and process usage.

•  You can run health checks using EM via the Support Workbench, or you can manually run a health check using the DBMS_HM PL/SQL package.

Handle Block Corruption

•  When Oracle detects a corrupted block, it registers an ORA-01578 error in the alert log and on the EM home page.

•  The initialization parameter DB_BLOCK_CHECKING controls how thoroughly Oracle checks the integrity of every data block that is read or written.

•  If you discover only a small handful of blocks to recover in a database from the aforementioned health checks or results discovered in the alert log, then RMAN can perform block media recovery rather than a full datafile recovery.

•  When you use the RMAN RECOVER . . . BLOCK command, RMAN first searches the flashback logs for a good copy of the corrupted block (if Flashback Database is enabled).

•  You can use the dynamic performance view V$DATABASE_BLOCK_CORRUPTION to view the bad blocks in the database.

•  The target database must be in ARCHIVELOG mode to use RMAN block recovery.

•  Alternatively, you can use flashback logs in the flash recovery area for uncorrupt versions of bad blocks.

•  The Data Recovery Advisor is part of the Oracle advisor framework and automatically gathers information about a failure when an error is encountered.

•  Once the Data Recovery Advisor has identified a failure, you can review the details of the failure using the EM or RMAN interface.

•  Once the Data Recovery Advisor has identified a failure, you can use the RMAN ADVISE FAILURE command to recommend a repair option for the specified failure.

Self Test

1.  The value of the initialization parameter DIAGNOSTIC_DEST is NULL, the environment variable ORACLE_HOME is set to /u01/app/oracle/product/12.1.0/db_1, and the value of the environment variable ORACLE_BASE is set to /u01/app/oracle. At startup, what value is assigned by Oracle to DIAGNOSTIC_DEST? (Choose the best answer.)

A.  /u01/app/oracle/diag

B.  /u01/app/oracle/log

C.  /u01/app/oracle/product/12.1.0/db_1/log

D.  /u01/app/oracle

2.  Which of the following tasks can you accomplish using the ADRCI tool? (Choose all that apply.)

A.  Package incident information into a ZIP file to send to Oracle Support

B.  View diagnostic data within ADR

C.  Perform a health check on the database while it is running

D.  Run recommended fixes from the most recent health check on the database

3.  The V$DIAG_INFO view shows the location of various files. Which of the following file types are not identified in V$DIAG_INFO? (Choose the best answer.)

A.  Diagnostic trace files

B.  Diagnostic incident files

C.  Diagnostic problem files

D.  The database XML alert log

4.  Which of the following basic consistency checks are performed by default when a block is written or read? (Choose all that apply.)

A.  Block checksum.

B.  Data block address in cache matches the address on disk.

C.  Block version.

D.  The data block is below the high water mark when reading or updating a block.

5.  What is a prerequisite for using block media recovery? (Choose the best answer.)

A.  Flashback Database must be enabled.

B.  The database must be in ARCHIVELOG mode.

C.  A full (or level 0) backup from before the damage must be available.

D.  DB_BLOCK_CHECKING must be set to LOW, MEDIUM, or FULL.

6.  You can use the RMAN CHANGE FAILURE command to change the priority of which types of failures? (Choose all that apply.)

A.  OPEN

B.  HIGH

C.  CRITICAL

D.  LOW

E.  CLOSED

7.  When using the Data Recovery Advisor, you run the LIST FAILURE command, and it reports an issue with a datafile. Then after a second datafile is damaged, you run ADVISE FAILURE. For which issues will the advisor generate advice? (Choose the best answer.)

A.  Only the first file

B.  Only the second file

C.  Both files

D.  Neither file, because ADVISE must be immediately preceded by LIST

Self Test Answers

1.      D. The ADR root directory (also known as the ADR base) is set by the parameter DIAGNOSTIC_DEST. If it is not set, Oracle sets DIAGNOSTIC_DEST to the environment variable ORACLE_BASE.
    A, B, and C are incorrect. All three locations are not assigned, given the values of DIAGNOSTIC_DEST, ORACLE_BASE, and ORACLE_HOME.

2.      A and B. The ADRCI tool allows you to view diagnostic information in the ADR root directory in addition to packaging both problem and incident information for Oracle Support.
    C and D are incorrect. The ADRCI tool cannot initiate health checks or run fixes recommended by other Oracle diagnostic tools.

3.      C. The view V$DIAG_INFO does not specify a directory for problems, only incidents. Each incident is labeled with a text string representing the problem identifier.
    A, B, and D are incorrect. They are listed in V$DIAG_INFO with the operating system–specific path name. Note that the text version of the database alert log is not specifically mentioned; it exists with the trace files. The XML version of the database alert log is specifically given.

4.      A, B, and C. Oracle performs all of these checks with the default value of DB_BLOCK_CHECKSUM=TYPICAL.
    D is incorrect because Oracle does not check whether a block is below the high water mark when updating or reading a block.

5.      B. A complete chain of redo is required to recover the restored block to the present point.
    A, C, and D are incorrect. A and C are incorrect because the block can be extracted from either a full (level 0) backup or from the flashback log; either is sufficient, but only one is necessary. D is incorrect because DB_BLOCK_CHECKING does not have to be enabled at all to use block recovery, though it may help with detecting damage.

6.      B and D. You can change the priority of a HIGH failure to LOW, and vice versa.
    A, C, and E are incorrect. A is incorrect because OPEN is not a failure status. C is incorrect because you cannot change the priority of a CRITICAL failure. E is incorrect because once closed, it cannot be further adjusted.

7.      A. Advice is generated only for problems previously detected with LIST.
    B, C, and D are incorrect. B and C are incorrect because advice cannot be generated for a problem that has not been listed. D is incorrect because there is no time limit between LIST and ADVISE.