Overview of Diagnostic Files Flashcards
Fault Diagnosability Infrastructure Overview
+ Is there for preventing, detecting, diagnosing, and resolving db problems
+ Problems include critical errors such as code bugs, metadata corruption and customer data corruption
Goals of the Advanced Fault Diagnosability Infrastructure (5 Points)
+ Detecting problems proactively
+ Limiting damage and interruptions after a problem is detected
+ Reducing problem diagnostic and resolution time
+ Improving manageability by enabling trace files to be partitioned, allowing users to define the size per piece and maximum number of pieces to retain, and disabling tracing after a user-specified disk space limit it reached
+ Simplifying customer interactions with Oracle Support
Automatic Diagnostic Repository (ADR)
+ file based repository that stores db diag data such as trace files, the alert log, DDL log, and Health Monitoring reports.
Key characteristics of ADR (7 Points)
+ Unified directory structure
+ Consistent diag data formats
+ Unified tool set
+ Is located ouside the db
+ Proactively tracks problems, which are critical errors in the database.
+ Time-stamped incident for each occurence with an incident ID which sends an incident alert to Enterprise Manager.
+ Applies flood control after a threshold is reached, which generates an alert log entry without overloading the system with diag data.
ADR Structure
+ ADR base is the ADR root directory
+ Can contain multiple ADR homes, where each home is the root directory for all diag data for an instance of an Oracle product or component.
\+ ADR Base contains: \++ diag \++ rdbms \++database name \++SID
\+ ADR Home = ADR Base\SID \++alert \++cdump \++incident \++trace \++hm \++others
Alert Log (2 Points)
+ Every db has an alert log
+ Is an XML file containing a chronological log of db messages and errors
Alert Log contents
+ All internal errors (ORA-600)
+ Block corruption errors (ORA-1578)
+ Deadlock errors (ORA-60)
+ Administrative Opertations i.e STARTUP, SHUTDOWN, ARCHIVE LOG, and RECOVER
+ Several messages and errors relating to the functions of shared server and dispatcher processes.
+ Errors during the automatic refresh of a materialized view
+ Successful operation get written with a completed msg with timestamp
DDL Log (5 Points)
+ Has the same basic behavior as the alert log but contains only DDL statements and details.
+ The db writes DDL info into its own file to reduce the clutter in the alert log
+ Log records are text
+ One log record exists for each DDL statement
+ DDL log is stored in the log/ddl subdirectory of the ADR home.
Trace Files (9 Points)
+ A tracefile is a file that contains diag data used to investigate problems.
+ Trace files can provide guidance for tuning applications or an instance
+ Trace files contain info on the process environment, status, activities, and errors.
+ A trace tends to be continuous output of diagnostic data
+ The SQL trace facility also created trace files which provide performace information on individual SQL statements.
+ Tracing can be enabled for a client identifier, service, module, action, session, instance, or db in various ways.
+ Trace files are located in the ADR subdirectory trace
+ Naming conventions typically contains the SID and process ID
+ The file extension is .trc except for metadata files which end in .trm
Segmentation of Trace Files (4 Points)
+ When the trace file size is limited, the db may automatically split it into a maximum of 5 segments.
+ Segments are seperate files that have the same name as the active trace with a segment number appended.
+ Each segment is typically 20% of the limit set by MAX_DUMP_FILE_SIZE.
+ When the combined size of all segments exceeds the limit, the db deletes the oldest segment (although never the first segment, which may contain relevant inf about the initial state of the process)
Diagnostic Dumps (2 Points)
+ Is a special type of trace file that contains detailed point-in-time info about the state or structure.
+ a dump is typically a one-time output of diagnostic data in response to an event.
Trace Dumps and Incidents (4 Points)
+ Most dumps occur because of incidents.
+ When an incident occurs, the database writes one or more dumps to the incident directory created for the incident.
+ Incident dumps also contain the incident number in the file name.
+ During incident creation, an application may take a heap or system state dump as part of an action.
