Control (.ctl) Files
define the physical data structure and attributes of each database, starting from
the timestamp when the database was created, its DB_BLOCK_SIZE,
and the locations of associated Checkpoint, datafiles, and
redo log files.
Fields in the control file are listed by the V$CONTROLFILE view or command SHOW PARAMETER CONTROL.
When Oracle starts, it refers to a single control file,
but several control files exists for a database because
multiple control files are created and updated for redundancy.
Oracle recommends specifying at least 3 (up to 8) duplicates on separate disk drives.
These files are read based on CONTROL_FILES= parameter specified in init.ora
or initORACLASS.ora.
Starting the SQL Loader utility requires specification of a control file:
SQLLDR \'SYS/password AS SYSDBA\' control=foo.ctl
As the database runs, the control file holds the log sequence number
linking redo log files with datafiles.
That's why the instance needs to be bounced when
redo logs or datafiles are added or moved.
Restart DB (mounted mode) with PFILE parameter.
When creating the control file for a production database,
MAXINSTANCES, MAXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS, and MAXLOGHISTORY
should be set and watched to avoid an emergency to extend them.
Setting these requires the creation of a new control file.
Since this file is stored in binary format, create a text formatted user trace file:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
Redo Log (.rdo & .arc) files
Redo Logs hold recordings of every change made to datafiles.
They are useful for fine-grained recovery of specific changes.
To restore an entire database, a backup is restored, then
rolled forward using archived and online redo log files
to make changes to a point-in-time before the error occurred.
A "redo log" refers to a set of redo log files.
Oracle switches to another log group when one is full.
Oracle redo files are "circular" because when
it's done writing to the last file in the series,
it begins overwriting to the first online redo log file.
Several Redo Logs may reside inside an .arc file recognized by the operating system.
Oracle can multiplex (mirror) Redo logs on several different disks that are updated simultaneously.
Each member of a log group is an exact mirror of the others, and redo log entries are written to each member in parallel.
This is instead of using RAID-1 or RAID-5.
NOTE: By contrast, Flashback files (new to 10g) capture changes to
specific blocks on physical disk drives
to return to the state of the database at specified points in time.
Flashbacks operate in addition to redo logs.
NOTE: Within ORACLE_HOME\sqlplus\admin, movelogs.sql moves online logs to a new flash recovery area,
which is specified in INIT.ORA parameter db_recovery_file_dest.
The "redo entries" statistic viewed with V$SYSSTAT
increments each time redo entries are copied into the redo log buffer.
LoadRunner Oracle metrics provide a "Redo entries linearized" statistic that
reports on the total number of entries
that are below the REDO_ENTRY_PREBUILD_THRESHOLD because
building redo entries costs CPU time as it improves concurrency on a multi-processor system.
[_] To reduce use of computer power and disk space,
datafiles can be set to be updated without redo logs
by setting the NOACHIVELOG run parameter.
The V$LOG view returns from the control file the member count for each group#.
The V$LOGFILE view returns information about member .rdo file path for each GROUP#.
If there isn't enough space in the redo buffer, a redo space wait occurs.
An indicator of this is when the rate of requests ("req") is higher than the ("wrt") rate required of the log writer:
select round((req.value/wrt.value)*100,2)
from v$sysstat req, v$sysstat wrt
where req.name='redo log space requests' and wrt.name='redo writes'
The "redo log space requests" statistic in V$SYSSTAT and LoadRunner
tracks the number of times a log file switch has occured --
when the active log file is full and Oracle must wait for disk space to be allocated to hold more redo log entries.
Log Switch!
When a log group fills up with records, Oracle switches to another log group.
This is called a log switch.
The "Log File Switch" wait event counter is incremented when commit requests wait for
"logfile switch (archiving needed)"
or "logfile switch (chkpt. Incomplete)".
This web page recommendes:
"Ensure that the archive disk is not full or slow.
DBWR may be too slow because of I/O.
You may need to add more or larger redo logs, and you may potentially need to add database writers if the DBWR is the problem.
"
"Small Log files in relation to the size of the SGA or the commit rate of the workload can cause problems.
When the log switch occurs, Oracle must ensure that all committed dirty buffers are written to disk before switching to a new log file.
If you have a large SGA full of dirty buffers and small redo log files,
a log switch must wait for DBWR to write dirty buffers to disk before continuing.
"
The "log file space/switch" wait event in V$SESSION_WAIT...
Before performing maintenance on the active log group, manually trigger a log switch
from the Enterprise Manager console (OEM), SQL*Plus Worksheet,
connect as the SYS user and execute:
ALTER SYSTEM SWITCH LOGFILE;
The system should respond with "System altered"
Password files
Password Files are optional disk components used for securely storing privileged user connection information so that the database can be administered remotely using Oracle Enterprise Manager rather than directly connecting to the machine hosting the Oracle database and using SQL*Plus.
ALRT.log file in User Dump (udump) folder
Oracle logs critical failures to the sidALRT.log
(where sid is the system identifier for the database).
Its location is specified by the BACKGROUND_DUMP_DEST and USER_DUMP_DEST parameters before 11g and
DIAGNOSTIC_DEST in 11g.
By default, that's the $ORACLE_HOME/admin/$ORACLE_SID/bdump directory before 11g and
$ORACLE_BASE/diag/$ORACLE_SID in 11g.
The format of alert log is in plain text.
Oracle 11g writes an additional alert log named log.xml in XML format.
Standard SQL (and thus server access) was needed to access the log, but 11g provides a view:
select name, value from v$diag_info.
Trace (.trc) files
`
User session trace files are given an ora prefix (such as "xe_ora_"
followed by a unique sequence number, plus the .trc file extension.
When parameter sql_trace is set to TRUE.
To create a text formatted user trace file in the location specified in parameter USER_DUMP_DEST:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
The instance needs to be bounced after this change.
Trace (.trc) files can be used to track down problems not causing critical failures.
Trace (.trc) files are in binary format, so special tools are needed, such as
TKPROF
|