Which two statements are true regarding the Health Chec…

Examine the section of the Health Check report given below:
DBMS_HM.GET_RUN_REPORT(‘HM_RUN_1061’)
Run Name : HM_RUN_1061
Run Id : 1061
Check Name : Data Block Integrity
Check Mode : REACTIVE
Status : COMPLETED
Start Time : 2007-05-12 22:11:02.032292 -07:00
End Time : 2007-05-12 22:11:20.835135 -07:00
Error Encountered : 0
Source Incident Id : 7418
Number of Incidents Created :0
Which two statements are true regarding the Health Check report? (Choose two.)

Examine the section of the Health Check report given below:
DBMS_HM.GET_RUN_REPORT(‘HM_RUN_1061’)
Run Name : HM_RUN_1061
Run Id : 1061
Check Name : Data Block Integrity
Check Mode : REACTIVE
Status : COMPLETED
Start Time : 2007-05-12 22:11:02.032292 -07:00
End Time : 2007-05-12 22:11:20.835135 -07:00
Error Encountered : 0
Source Incident Id : 7418
Number of Incidents Created :0
Which two statements are true regarding the Health Check report? (Choose two.)

A.
Health Check was performed manually.

B.
Health Check was performed to check the disk image block corruptions.

C.
Health Check was performed to check interblock and intersegment corruption.

D.
Health Check was performed to verify the integrity of database files and report failures.

E.
Health Check was performed by the Health Monitor automatically in response to a critical error.

Explanation:
About Health Monitor Checks
Health Monitor checks (also known as checkers, health checks, or checks) examine various layers and
components of the database. Health checks detect file corruptions, physical and logical block corruptions, undo
and redo corruptions, data dictionary corruptions, and more. The health checks generate reports of their
findings and, in many cases, recommendations for resolving problems. Health checks can be run in two ways:
Reactive–The fault diagnosability infrastructure can run health checks automatically in response to a critical
error.
Manual–As a DBA, you can manually run health checks using either the DBMS_HM PL/SQL package or the
Enterprise Manager interface. You can run checkers on a regular basis if desired, or Oracle Support may ask
you to run a checker while working with you on a service request.
Health Monitor checks store findings, recommendations, and other information in the Automatic Diagnostic
Repository (ADR).
Health checks can run in two modes:
DB-online mode means the check can be run while the database is open (that is, in OPEN mode or MOUNT
mode).
DB-offline mode means the check can be run when the instance is available but the database itself is closed
(that is, in NOMOUNT mode).
All the health checks can be run in DB-online mode. Only the Redo Integrity Check and the DB Structure
Integrity Check can be used in DB-offline mode.
Types of Health Checks:
Health monitor runs the following checks:
DB Structure Integrity Check–This check verifies the integrity of database files and reports failures if these files
are inaccessible, corrupt or inconsistent. If the database is in mount or open mode, this check examines the log
files and data files listed in the control file. If the database is in NOMOUNT mode, only the control file is
checked.
Data Block Integrity Check–This check detects disk image block corruptions such as checksum failures, head/
tail mismatch, and logical inconsistencies within the block. Most corruptions can be repaired using Block Media
Recovery.
Corrupted block information is also captured in the V$DATABASE_BLOCK_CORRUPTION view. This check
does not detect inter- block or inter-segment corruption.
Redo Integrity Check–This check scans the contents of the redo log for accessibility and corruption, as well as
the archive logs, if available. The Redo Integrity Check reports failures such as archive log or redo corruption.
Undo Segment Integrity Check–This check finds logical undo corruptions. After locating an undo corruption,
this check uses PMON and SMON to try to recover the corrupted transaction. If this recovery fails, then Health
Monitor stores information about the corruption in V$CORRUPT_XID_LIST. Most undo corruptions can be
resolved by forcing a commit.
Transaction Integrity Check–This check is identical to the Undo Segment Integrity Check except that it checks
only one specific transaction. Dictionary Integrity
Check–This check examines the integrity of core dictionary objects, such as tab$ and col$. It performs the
following operations:
Verifies the contents of dictionary entries for each dictionary object. Performs a cross-row level check, which
verifies that logical constraints on rows in the dictionary are enforced.
Performs an object relationship check, which verifies that parent-child relationships between dictionary objects
are enforced.
The Dictionary Integrity Check operates on the following dictionary objects:tab$, clu$, fet$, uet$, seg$, undo$, ts$, file$, obj$, ind$, icol$, col$, user$, con$, cdef$, ccol$, bootstrap$,
objauth$, ugroup$, tsq$, syn$, view$, typed_view$, superobj$, seq$, lob$, coltype$, subcoltype$, ntab$,
refcon$, opqtype$, dependency$, access$, viewcon$, icoldep$, dual$, sysauth$, objpriv$, defrole$, and ecol$.



Leave a Reply 0

Your email address will not be published. Required fields are marked *