Managing Contorl Archive Redolog Files Skillbuilders

SkillBuilders Advertisement
Instructor's Notes
(If applicable)
Lesson 18: Managing Control Files
This hands-on lesson will teach you how to protect, add, backup and recreate
control files.
Other Text:
(Examples or comments displayed on slide, if any).
Instructor's Notes
(If applicable)
In this course, the control file was introduced in the lessons on database
architecture. Let's spend a minute to review the major concepts
The control file is a relatively small file typically a few megabytes which
contains control information for the database. This information includes the
name of the database, the name and location of the database files, the names of
the online and archived redo log files and information required for database
recovery.
The control file is read at startup time (specifically, when the database is
mounted). Reading the control file gives the instance the names and locations of
the datafiles and redo log files. If the control file is not available then the
instance will not mount (i.e start). The control file is also updated during normal
database operations:
o
All structural changes such as adding or removing datafiles are recorded

in the control file.
Notes continue on the next page
Other Text:
SQL> select name
2 from v$controlfile;
NAME
-----------------------------------C:\ORACLE\ORADATA\DAVE\CONTROL01.CTL
C:\ORACLE\ORADATA\DAVE\CONTROL02.CTL
Instructor's Notes
(If applicable)
The checkpoint process updates the control file when a checkpoint is

performed. Remember that a checkpoint operation writes all changed
(dirty) blocks to disk. By recording this fact in the control file, Oracle
knows what redo records need to be applied in the event of instance
failure. i.e. In the event of instance failure, Oracle needs to apply all redo
generated after the last checkpoint recorded in the control file. Refer to
the lessons on Backup and Recovery for more information.
o The archive process (ARCH) will record the name and location of
archived redo logs in the control file.
RMAN processes update the control file to record backup and recovery
operations. Refer to the Introduction to RMAN lesson for more
information.
As we will learn in this lesson, it is easy for the database administrator to keep
more than one copy of the control file. These copies should obviously be on
separate disk drives to guard against loss of the entire disk. Query the
V$CONTROLFILE view to determine the name and location of current in-use
control files.
Other Text:
Instructor's Notes
(If applicable)
The database administrator has the following responsibilities related to the

control file:
o To protect the control file. Since we cannot start or run the database
without the it, the control file is of utmost importance. There are three
levels of protection:
The first level of protection comes from maintaining multiple

mirror-image copies on separate disk devices. As we will learn in
this lesson, this is easily accomplished with the
CONTROL_FILES initialization parameter.
The second level of protection is to backup the control file. Since
the control is updated to record any structural change made to the
database (such as adding a datafile with CREATE
TABLESPACE), it should be backed up whenever a structural
change occurs. Oracle9i Release 2 RMAN will do this
automatically. Also, since the control file is regularly updated

during normal database operations, include control file backups
in all regularly scheduled backups.
The third level of protection comes at the operating system level.

Prohibit all access to this file from all OS users except for the
owner of the database, typically a user named "oracle".
Refer to the lesson on Backup and Recovery for detailed instructions on backing
up the control file with RMAN.
Other Text:
Instructor's Notes
(If applicable)
The administrator will be responsible for restoring the control file if all copies
are lost. This should not happen! Remember, you will have a minimum of two,
preferably three or four copies of the control file on separate disk devices.
However, if you do lose all copies, you can restore from backups or recreate
with the CREATE CONTROLFILE command. (We will study the CREATE
CONTROLFILE command in this lesson.)
Another reason to use the CREATE CONTROLFILE command is to recreate
the control file to change the "fixed" parameter values specified on the CREATE
DATABASE command. A little background information on CREATE
DATABASE command (which is covered in detail in the Creating a New
Database lesson): The control file is created by the CREATE DATABASE
command. The parameters specified on CREATE DATABASE cause Oracle to
reserve records (also known as "slots") in the control file. For example,
"MAXLOGFILES 5" will reserve 5 slots for recording the names of redo logs.
If, over time, you determine that the database will perform better with 10 log
files, you will need to recreate the control file which a larger
MAXLOGFILES value to add more slots.
Yet another reason to situation that would require control file to be recreated
would be when moving a database to a new server where the directory structure
does not match the original server.
Other Text:
Instructor's Notes
(If applicable)
We have established that it is critical to maintain more than one at least two
copies of the control file, on separate disk devices. Follow the steps summarized
here and demonstrated in the next few pages if your database does not have
enough control files or you would like to move a control file to a new disk
device.
Other Text:
See the following page for an example
Instructor's Notes
(If applicable)
Start by determining the current in-use control files. This can be accomplished
with a query on the V$PARAMETER2 view as shown above.
V$PARAMETER2 is a new view available with Oracle9i. It is similar to the
V$PARAMETER view in that it shows the current, in-use initialization
parameter values. The difference is that for parameters such as
CONTROL_FILES that contain multiple values it contains one row per value.
The ORDINAL column allows you to extract the parameter values in the order
specified in the parameter file.
As I demonstrated in the review earlier in this lesson, another method of

locating current control files is to query the V$CONTROLFILE view:
SQL> select name
2 from v$controlfile;
NAME
--------------------------------------
Other Text:
SQL> select value
2 from v$parameter2
3 where name = 'control_files'
4 order by ordinal;
VALUE
------------------------------------C:\oracle\oradata\dave\CONTROL01.CTL
C:\oracle\oradata\dave\CONTROL02.CTL
Instructor's Notes
(If applicable)
The next step is to cleanly shutdown the database. Use SHUTDOWN,
SHUTDOWN IMMEDIATE or SHUTDOWN TRANSACTIONAL. This is
required to get a consistent copy of the control file. Do not use SHUTDOWN
ABORT because that would cause the control files to be out of sync with the
datafiles .
Next, use the operating system to copy an existing control file to the new
location.
Other Text:
SQL> shutdown transactional
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> $copy C:\ORACLE\ORADATA\DAVE\CONTROL01.CTL
D:\ORACLE\ORADATA\DAVE\CONTROL03.CTL
1 file(s) copied.
Create a new copy of the control file.
Instructor's Notes
(If applicable)
Next, we need to update the CONTROL_FILES parameter in the initialization

parameter file to reflect the new, additional control file. As of Oracle9i, the
default initialization parameter file is called "server parameter file" (SPFILE).
Its is a binary file and is updated with the ALTER SYSTEM command as
demonstrated above.
Backup the SPFILE
I recommend that you backup the server parameter file (SPFILE) before
you update it. Why? Because I discovered (the hard way) that the
ALTER SYSTEM command will let you put invalid file names in the
CONTROL_FILES parameter and thus cause a failure when you attempt
to restart the database. It is easy to backup the SPFILE; use the CREATE
PFILE FROM SPFILE command as shown above (yes, this command
works with the database shut down). The text parameter file is created in
the default directory, $ORACLE_HOME\database on a Windows server.
Notes continues on the next page
Other Text:
Backup SPFILE before changing
SQL> create pfile from spfile;
File created.
Start DB to change SPFILE. Use NOMOUNT so control file is not opened
Update SPFILE SQL> startup nomount
SQL> alter system
2 set control_files = 'C:\oracle\oradata\dave\CONTROL01.CTL' ,
3 'C:\oracle\oradata\dave\CONTROL02.CTL' ,
4 'D:\oracle\oradata\dave\CONTROL03.CTL'
5 scope = spfile
6/
Shutdown the database and restart
System altered.
SQL> shutdown
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup
Instructor's Notes
(If applicable)
Update the SPFILE
The database must be in NOMOUNT mode for this next step. We do not want to
MOUNT the database at this time because the control file would then be opened
and updated and we have not yet told Oracle about our additional new control
file. The ALTER SYSTEM command, as shown above, will update the
CONTROL_FILES parameter in the SPFILE.
CAUTION: Next, shutdown and restart the database. This is a critical step
because when we restart the database the updated parameter file is read and the
instance recognizes the existence of the new control file. Do not do an ALTER
DATABASE MOUNT and ALTER DATABASE OPEN because the new
control file is not recognized. If you do this, the database will open without the
new control file in effect. Therefore the new control file will not be kept in sync
with the existing control files. The next time you shutdown and startup, the new
control file will be opened, but Oracle will give a ORA-00214: control file xxx
version vvv inconsistent with file yyy version www. You can recover from this
error my doing a shutdown and recopying one of the original control files to the
new control file .
Recovering from an Error
If you experience errors when you try to restart the database, shutdown
the database (you will probably be in nomount stage), restore the
original copy of the server parameter file, then restart the database. Use
the CREATE SPFILE command to restore the server parameter file:
o
SQL> create spfile from pfile;
Other Text:
Instructor's Notes
(If applicable)
Add Control File Workshop
1. Determine the control files currently in use.

2. Add another control file to your database.
3. Check that the new control file is in use.
Other Text:
Instructor's Notes
(If applicable)
In addition to protecting the control file, backing up the control file is also a
primary responsibility of the DBA. This can be accomplished:
o With user-managed backups.
o
With server-managed (RMAN) backups. Refer to the lesson

Introduction to RMAN for more information.
With the ALTER DATABASE BACKUP CONTROLFILE command.
The example shown above uses the "TO TRACE" option to create a script to
recreate the control file. The script is written to the USER_DUMP_DEST
directory. Unfortunately, the name of the script is not intuitive or obvious. It will
typically follow the format "SID_ora_SPID.trc", where SID is the database
system id and SPID is the session process id of the session that executed the
ALTER DATABASE command. The easiest method of determining which file
in the USER_DUMP_DEST directory is the script file is by the date/time stamp.
However, we can get more precise. The SID can be found with this query:
SQL> select instance_name from v$instance;
INSTANCE_NAME
---------------
dave
Other Text:
SQL> alter database backup controlfile to trace;
Database altered.
SQL> show parameter user_dump_dest
NAME VALUE
---------------------------------- -------------------------user_dump_dest C:\oracle\admin\class\udump
Instructor's Notes
(If applicable)
The SPID can be found unless you are connected as SYSDBA - by executing
this query:
SQL> select a.spid
2 from v$process a, v$session b
3 where a.addr = b.paddr
4 and b.audsid = userenv('sessionid');
SPID
------------
1752
If the session that ran the ALTER DATABASE command was connected as
SYSDBA, the SPID's of all sessions are returned. In this case, you are back to
searching using the file date/time stamp.
The following pages in this lesson will describe the process of using this script
to recreate a control file.
Other Text:
Instructor's Notes
(If applicable)
A new control file can be created with the CREATE CONTROLFILE
command. This can be useful when you have lost all copies of the current
control file, you are moving the database to a server with different mount points
or directories or you want to change some of the "fixed" parameters on the

CREATE DATABASE command.
Create a new control file carefully: remember that you cannot start your
database without a valid control file. It is recommended to perform a full cold
backup before attempting this procedure. This is because bad things can happen;
e.g. omitting a datafile name in the CREATE CONTROLFILE command can
cause loss of data.
Note that the Oracle9i Administration Guide and Metalink
(http://metalink.oracle.com) also have detailed descriptions of this procedure.
See document Note:1012929.6
Other Text:
Instructor's Notes
(If applicable)
The script created by the ALTER DATABASE BACKUP CONTROLFILE TO

TRACE command will not run without some editing. (The next two pages
contain an excerpt of this script.)
o First, copy the script from the USER_DUMP_DEST directory to a
directory easily accessible from SQL*Plus. Rename the script to
something like "CREATE_CONTROLFILE.SQL".
Next, delete all the header and comment records up to, but not including,
the STARTUP NOMOUNT command.
There are two versions of the CREATE CONTROLFILE command in

the file. The first should be used if you have all online redo logs
available. It is noted with this comment "Set#1. NORESETLOGS case".
The second version, noted "Set #2. RESETLOGS case" will not attempt
to apply any changes found in the redo logs. Use this version if you have
lost the redo log files. Note that detailed discussions of RESETLOGS
and NORESETLOGS can be found in Oracles documentation. It is not
necessary at this time to have a complete understanding of this.
Next, if the database is running, shutdown the database. It is
recommended to perform a full cold backup before continuing. This will
provide a fallback point should things go awry.
o
Note that the Oracle9i Administration Guide and Metalink

(http://metalink.oracle.com) also have detailed descriptions of this procedure.
See Metalink document 1012929.6
Other Text:
Procedure continues
Instructor's Notes
(If applicable)
Excerpt from the BACKUP CONTROLFILE TO TRACE trace file:

Dump file c:\oracle\admin\dave\udump\dave_ora_1752.trc
Fri Oct 03 13:05:25 2003
ORACLE V9.2.0.1.0 - Production vsnsta=0
vsnsql=12 vsnxtr=3
Windows 2000 Version 5.0 Service Pack 4, CPU type 586
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production

With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Windows 2000 Version 5.0 Service Pack 4, CPU type 586
Redo thread mounted by this instance: 1
Oracle process number: 15
Windows thread id: 1752, image: ORACLE.EXE
Instance name: dave
*** SESSION ID:(12.430) 2003-10-03 13:05:25.000

*** 2003-10-03 13:05:25.000
# The following are current System-scope REDO Log Archival related
# parameters and can be included in the database initialization file.
# LOG_ARCHIVE_DEST=''
# LOG_ARCHIVE_DUPLEX_DEST=''
# LOG_ARCHIVE_FORMAT=ARC%S.%T
# REMOTE_ARCHIVE_ENABLE=TRUE
# LOG_ARCHIVE_START=TRUE
# LOG_ARCHIVE_MAX_PROCESSES=2
# STANDBY_FILE_MANAGEMENT=MANUAL
# STANDBY_ARCHIVE_DEST=%ORACLE_HOME%\RDBMS
# FAL_CLIENT=''
# FAL_SERVER=''
# LOG_ARCHIVE_DEST_1='LOCATION=c:\oracle\oradata\dave\archive\'
# LOG_ARCHIVE_DEST_1='MANDATORY NOREOPEN NODELAY'
# LOG_ARCHIVE_DEST_1='ARCH NOAFFIRM SYNC'
# LOG_ARCHIVE_DEST_1='NOREGISTER NOALTERNATE
NODEPENDENCY'
# LOG_ARCHIVE_DEST_1='NOMAX_FAILURE NOQUOTA_SIZE
NOQUOTA_USED'
# LOG_ARCHIVE_DEST_STATE_1=ENABLE
Other Text:
Instructor's Notes
(If applicable)
# Below are two sets of SQL statements, each of which creates a new
# control file and uses it to open the database. The first set opens
# the database with the NORESETLOGS option and should be used only if
# the current versions of all online logs are available. The second
# set opens the database with the RESETLOGS option and should be used
# if online logs are unavailable.
# The appropriate set of statements can be copied from the trace into
# a script file, edited as necessary, and executed when there is a
# need to re-create the control file.
# Set #1. NORESETLOGS case
# The following commands will create a new control file and use it
# to open the database.
# Data used by the recovery manager will be lost. Additional logs may
# be required for media recovery of offline data files. Use this
# only if the current version of all online logs are available.
STARTUP NOMOUNT <--[Delete all records before this]
CREATE CONTROLFILE REUSE DATABASE "DAVE" NORESETLOGS

ARCHIVELOG
-- SET STANDBY TO MAXIMIZE PERFORMANCE
MAXLOGFILES 50
MAXLOGMEMBERS 5
MAXDATAFILES 1000
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 'C:\ORACLE\ORADATA\DAVE\REDO01.LOG' SIZE 100M,
GROUP 2 'C:\ORACLE\ORADATA\DAVE\REDO02.LOG' SIZE 100M,
GROUP 3 'C:\ORACLE\ORADATA\DAVE\REDO03.LOG' SIZE 100M
-- STANDBY LOGFILE
'C:\ORACLE\ORADATA\DAVE\SYSTEM01.DBF',
'C:\ORACLE\ORADATA\DAVE\UNDOTBS01.DBF',
'C:\ORACLE\ORADATA\DAVE\CWMLITE01.DBF',
'C:\ORACLE\ORADATA\DAVE\DRSYS01.DBF',
'C:\ORACLE\ORADATA\DAVE\EXAMPLE01.DBF',
'C:\ORACLE\ORADATA\DAVE\INDX01.DBF',
'C:\ORACLE\ORADATA\DAVE\ODM01.DBF',
'C:\ORACLE\ORADATA\DAVE\TOOLS01.DBF',
DATAFILE
'C:\ORACLE\ORADATA\DAVE\XDB01.DBF',
'C:\ORACLE\ORADATA\DAVE\O1_MF_USERS_ZMNKR400_.DBF'
CHARACTER SET WE8MSWIN1252
Other Text:
Instructor's Notes
(If applicable)
Description of steps to recreate the control file, continued:

If any control files exist, rename or move them so they do not interfere
with the CREATE CONTROLFILE command.
Next, use SQL*Plus to login with SYSDBA privileges and execute the
script. Check for errors. If everything is OK, shutdown the database and
perform a full cold backup.
Note that since the database parameter file contains the location of the control
files, the script above will create all control file copies.
Other Text:
SQL> connect system/dave as sysdba
Connected.
SQL> shutdown
SQL> @create_controlfile
ORACLE instance started.
Total System Global Area 126950220 bytes
Fixed Size 453452 bytes
Variable Size 96468992 bytes
Database Buffers 29360128 bytes
Redo Buffers 667648 bytes
Control file created.
Instructor's Notes
(If applicable)
This is an optional workshop. The instructor will assign only if time

permits.
1. Execute the ALTER DATABASE command that creates the CREATE

CONTROLFILE command script.
2. Shutdown your database.
3. Rename or move all control files to an alternate location. Do not delete,
lose or edit the control files (in case we need them for recovery).
4. Try to start your database. The startup will fail because the control files
cannot be found.
5. Locate the error message in the alert file.
6. Recreate all your control files and startup your database by executing the
script created in step 1.
7. Shutdown and restart your database. The startup should succeed. If it
does not, shutdown the database, restore the original control files and
bounce the database.
Other Text:
Instructor's Notes
(If applicable)
Lesson 17: Managing Redo Logs
In this lesson we will cover redo log concepts and a DBAs responsibilities to
redo logs, including archiving online logs, multiplexing online and archive logs
and avoiding log switch waits.
Other Text:
Instructor's Notes
(If applicable)
We learned about REDO, online logs and archived logs in the lessons on
database architecture. Let's take a moment to review the basics
The online redo log files are used to record changes made to the database files.
As an update is applied to the database, Oracle automatically creates a "redo"
record. The redo contains the after-image of the change and is used in the event
the change needs to be reapplied, e.g. a recovery operation.
This redo record is written to the redo buffer. When a commit is issued, the redo
is flushed to the redo log file by the log writer background process (LGWR).
The logs are used in cyclical rotation. When one redo log file fills a log switch
occurs and Oracle begins writing redo to the next log file. At least two log files
must exist. Specifically, when a log fills:
o
A checkpoint is initiated for that log (i.e. the blocks changed by the
operations recorded in the log are flushed to disk by the DBWR
background process).
A log switch occurs - Oracle starts writing to the next log in the
rotation.
Other Text:
Online Logs
Redo Buffer
Redo Buffer
LGWR
SGA
Instructor's Notes
(If applicable)
The dynamic performance view V$LOGFILE contains a row for each online log
defined to the database.
The V$LOG view contains, for each log group, the size of the logs in the group.
A group can contain more than one log file. Log files in a single group are
mirror images of each other. This multiplexing concept protects against the loss
of a disk device containing an online log. See the section on Multiplexing in this
lesson for more information.
Supplemental Notes
There is no advantage to having different size log files. In fact, there is a
disadvantage - tuning is near impossible. The decision of how many and
how big your log files are is a tuning issue.
Other Text:
SQL> select member
2 from v$logfile;
MEMBER
----------------------------------C:\ORACLE\ORADATA\DAVE\REDO01.LOG
C:\ORACLE\ORADATA\DAVE\REDO02.LOG
C:\ORACLE\ORADATA\DAVE\REDO03.LOG
Active online logs
SQL> select group#, bytes
2 from v$log;
GROUP# BYTES
---------- ---------1 104857600
2 104857600
3 104857600
Group number and size
Instructor's Notes
(If applicable)
If the archive background process is running and the database is in
ARCHIVELOG mode, the ARCH background process will write a filled log file
to an archive location so that the changes will not be lost when the log file is
needed again (and its contents are overwritten). Oracle9i supports multiplexing
the archive logs, i.e. writing the archive logs to multiple locations (up to 10).
If the archive process is not active you cannot recover your database after a
MEDIA (disk) failure!
Other Text:
LGWR
SGA
Redo Buffer
Online Logs
Archive Logs
When active log fills:

Checkpoint occurs
Log switch occurs
ARCH process writes inactive file to archive location
Mirror Archive
Logs
Instructor's Notes
(If applicable)
Some of the primary responsibilities of the DBA regarding redo logs are to
insure the recoverability of the database by:
o Insuring that the redo logs are archived (thus preserving the contents)
o
Multiplexing the online logs (thus protecting against the loss of redo
though loss of a disk device)
Multiplexing the archive logs (essentially creating backup copies of the

archive redo logs)
Additionally, having enough online logs will prevent the database from waiting
for a log as it cycles through the available logs. Adding more log files can fix
this problem.
In this lesson we will focus our study on learning the techniques necessary to
fulfill the responsibilities stated here. Let's get started
Other Text:
Instructor's Notes
(If applicable)
To determine the status of archiving on a database:
Check the LOG_ARCHIVE_START parameter value. TRUE causes

Oracle to start one or more archive background processes when the
instance is started.
Check the LOG_MODE value in V$DATABASE. ARCHIVELOG
indicates that the database will not overwrite an online log file until it
has been archived.
Other Text:
SQL> show parameter log_archive_start
NAME TYPE VALUE
--------------------- ------------ ----log_archive_start boolean TRUE
SQL> select log_mode from v$database;
LOG_MODE
-----------ARCHIVELOG
Instructor's Notes
(If applicable)
Yet another way to check on the archive status of your database is to use the
SQL*Plus command ARCHIVE LOG LIST. This command displays the log
mode, whether the automatic archive (ARCH) process is active, the archive log
file destination and the current log sequence number.
The two main points we can determine from the output of the ARCHIVE LOG
LIST command are:
o
Database Log Mode When in "Archive Mode", the database will not
overwrite an online redo log until it has been archived. This is the
desired mode.
Automatic Archival When "enabled", the archive background process

is started, typically with the LOG_ARCHIVE_START=TRUE
parameter. This is the desired mode.
Other Text:
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination C:\Oracle\oradata\dave\archive
Oldest online log sequence 111
Next log sequence to archive 113
Current log sequence 113
Instructor's Notes
(If applicable)
You will want to insure that you are archiving to protect the redo generated by
database operations. There are two steps:
Putting the database in "archive log" mode. When in "Archive Mode",

the database will not overwrite an online redo log until it has been
archived.
Starting the archive (ARCH) background process when the instance
starts. If you do the first step but not this step, the database will hang
when it cycles to a log that has not been archived (because the database
is in archive log mode).
Other Text:
Instructor's Notes
(If applicable)
Archive-related activity in the database is controlled with initialization

parameters. Some of the archive-related initialization parameters are:
o LOG_ARCHIVE_START: When set to TRUE initiates the ARCH
Oracle background process will be started at startup time.
LOG_ARCHIVE_DEST_n: Controls where the redo log files are
archived. This will usually be a disk drive different from the one where
the database files are stored. "n" is digit 1,2,310. Can specify up to 10
locations, including standby databases (via the SERVICE clause of the
LOG_ARCHIVE_DEST_n parameter) .
LOG_ARCHIVE_FORMAT: Controls the format of the archive file

name. As specified in the Oracle Administration manual, these variables
can be used:
%T Thread number, left zero padded. For example, 001.ARC
%t Thread number, not padded. For example, 1.ARC

%S Log sequence number, left zero padded. For example,
00116.ARC
%s Log sequence number, not padded. For example, 116.ARC
Other Text:
###########################################
# Archive
###########################################
log_archive_dest_1='LOCATION=C:\Oracle\oradata\dave\archive'
log_archive_format=%S.arc
log_archive_start=true
Database parameter file contains
Instructor's Notes
(If applicable)
First, insure that the archive background process starts when the database is
started. This is done by setting initialization parameter
LOG_ARCHIVE_START = TRUE.
If using a text INIT.ORA file (the only option in pre-9i databases), simply edit
the text file and restart the database as shown on the previous page.
If you are using a Server Parameter file (SPFILE), execute the ALTER
SYSTEM command as shown in the example above. Since
LOG_ARCHIVE_START is not a dynamic parameter (it is a static parameter),
we need to alter the SPFILE then restart the database (as the example
demonstrates).
Next, we will put the database in ARCHIVELOG mode. Turn to the next page
for an example.
Other Text:
SQL> alter system
2 set log_archive_start = true
3 comment = 'dga, 6/6/03'
4 scope = spfile;
System altered.
SQL> shutdown immediate
...
SQL> startup
...
Instructor's Notes
(If applicable)
To put your database in ARCHIVELOG mode, shutdown the database in

consistent mode (i.e. do not shutdown abort), then use the ALTER DATABASE
ARCHIVELOG statement. The example above demonstrates the procedure.
Remember, the ARCHIVE LOG LIST command or dynamic performance view
V$DATABASE will show you the current mode of the database.
Other Text:
Shutdown the database cleanly, then mount
SQL> shutdown
SQL> startup mount
...
SQL> alter database archivelog;
Statement processed.
SQL> alter database open;
Statement processed.
Instructor's Notes
(If applicable)
Archiving Workshop
1. Check the ARCHIVELOG mode of your database.
2. Check the value of the LOG_ARCHIVE_START parameter.

3. If the database is not in archive log mode, enable it. If the automatic
archival process is not started, start it.
Other Text:
Instructor's Notes
(If applicable)
We have learned that protecting archived redo is one of our main responsibilities
because without archived redo we cannot recover the database from a disk
failure. To meet this responsibility we should "multiplex" the archived redo
logs. When we multiplex the archive logs, the archive background process
simultaneously writes the logs to all locations up to 10 that we specify in the
initialization parameters LOG_ARCHIVE_DEST_n. These logs are mirror
images of each other.
By default many databases use the old LOG_ARCHIVE_DEST and
LOG_ARCHIVE_DUPLEX_DEST parameters. These parameters have been
deprecated with Oracle9i and replaced by LOG_ARCHIVE_DEST_n, where
"n" is 1 to 10. (Note that Standard Edition does not support 10 locations, just
two; therefore, LOG_ARCHIVE_DEST and
LOG_ARCHIVE_DUPLEX_DEST have not been deprecated with Standard
Edition.)
The example above demonstrates how to multiplex the archive logs on a system
that currently used the LOG_ARCHIVE_DEST parameter to specify just one
archive destination. Here's a description of the steps:
First, I alter the database to remove the current setting of
LOG_ARCHIVE_DEST parameter. This is required because the
LOG_ARCHIVE_DEST parameter is mutually exclusive with the
LOG_ARCHIVE_DEST_n parameters.
o
Other Text:
SQL> alter system
2 set log_archive_dest = ''
3 scope = both;
System altered.
SQL> alter system
2 set log_archive_dest_1 = "location=c:\archive\ mandatory"
3 scope = both;
System altered.
SQL> alter system
2 set log_archive_dest_2 = "location=d:\archive2\ mandatory"
3 scope = both;
System altered.
Instructor's Notes
(If applicable)
Notes continued from the previous page:
o Next, I set LOG_ARCHIVE_DEST_1 and LOG_ARCHIVE_DEST_2
parameters to the desired locations. This causes Oracle to create two
mirror-image archive logs for each online redo log file. Note that I have
specified "mandatory" for both locations. This means that Oracle will
not overwrite the online redo log until it have been copied to both
locations. You can also specify "optional". At least one location must be
specified as mandatory.
CAUTION
Be sure to place your LOG_ARCHIVE_DEST_n on different

physical drives. If they are all on one physical drive, a media
failure on that drive can cause you to lose all copies of the
archived logs, making complete recovery of the database

impossible.
Other Text:
Instructor's Notes
(If applicable)
The V$ARCHIVE_STATUS view contains the current status of the archive log
destinations.
In this example we see that - as a result of the commands executed in the
previous example - destinations 1 and 2 are active and mandatory. We can also
see the destination directories.
Other Text:
SQL> select dest_name, status, binding, destination

2 from v$archive_dest;
DEST_NAME STATUS BINDING
------------------------- --------- --------- LOG_ARCHIVE_DEST_1 VALID MANDATORY
LOG_ARCHIVE_DEST_2 VALID MANDATORY LOG_ARCHIVE_DEST_3 INACTIVE
OPTIONAL
LOG_ARCHIVE_DEST_4 INACTIVE OPTIONAL
DESTINATION
--------------c:\archive\
d:\archive2\
Instructor's Notes
(If applicable)
Multiplex Archive Logs Workshop
1. Determine the current status of your databases archive logs, with respect
to location and multiplexing.
2. If your database is not multiplexing the archive redo log, multiplex the
log. Specify two mandatory locations for the log. If the computer you
are using for these workshops has two disks available, place the archive
logs on separate disks. (If your database is already multiplexing the
online logs, try adding another multiplexed location.)
3. Query the V$ARCHIVE_DEST view to insure the configuration
multiplexes the archive log.
Other Text:
Instructor's Notes
(If applicable)
If the DBWR background process has not finished checkpoint operation for a
log (remember that a log switch causes a checkpoint), and that log is needed by
LGWR (i.e. it is the next log in the cycle), the database will suspend all
operations until the checkpoint is complete.
You can detect this problem by searching your alert log for the "checkpoint not
complete, cannot allocate new log" messages.
Possible solutions to this problem include adding more log files, speeding up
checkpoints and decreasing the log file size to increase the number of
checkpoints taken.
Note that this is a Tuning issue and covered in more detail in SkillBuilders'
Database Performance and Tuning course.
Other Text:
Tuning course covers in more detail
Instructor's Notes
(If applicable)
If you determine that additional logs are necessary, they can easily be added
with the ALTER DATABASE ADD LOGFILE command, as shown in the
example above. Refer to the next page for an example of adding OMF-managed
logs.
Because we are modifying the structure of the database, the instance must be
started in a MOUNT mode. Remember that having the instance in a mounted
state means that the control file is open - the names of the new redo log file can
be recorded in the control file(s).
Other Text:
ALTER DATABASE ADD LOGFILE
'C:\Oracle\oradata\dave\redo03.log' SIZE 100m;
See next page for more info!
Instructor's Notes
(If applicable)
Oracle Managed Files (OMF) gives the database the ability to manage database
files, including datafiles, online redo log files, and control files. Oracle will
create, name, and locate physical files for you and will delete them from the
operating system automatically when you drop objects the file is associated
with.
OMF is an optional feature and, even when configured, is not mandatory.
OMF is configured with initialization parameters. To configure OMF-managed

online redo logs, set the DB_CREATE_ONLINE_LOG_DEST_n parameters.
See the next page for an example.
Other Text:
Instructor's Notes
(If applicable)
This example demonstrates the use of the Oracle9i feature Oracle Managed
Files (OMF) to add OMF-managed redo logs.
First, insure the DB_CREATE_ONLINE_DEST_n parameters are set correctly.
DB_CREATE_ONLINE_DEST_n specifies the location of the online logs. Up
to 5 can be specified so that, like the archive logs, you can multiplex the online
logs.
In this example, when the ALTER SYSTEM ADD LOGFILE command is

issued, Oracle creates two logs mirror images of each other of 100Mb in
size.
Be sure that all the online logs are the same size. Tuning is made more difficult
(impossible?) is the logs are different sizes. Add the SIZE parameter to the
ALTER SYSTEM command if the database does not use 100Mb log files:
ALTER SYSTEM ADD LOGFILE SIZE 50M;
Turn to the next page for more information on multiplexing the online logs.
Other Text:
SQL> alter system set

2 db_create_online_log_dest_1='C:\ORACLE\ORADATA\DAVE\'
3 scope=both;
System altered.
SQL> alter system set
2 db_create_online_log_dest_2='D:\ORACLE\ORADATA\DAVE\'
3* scope=both;
System altered.
Different location for a multiplexed online log
SQL> alter database add logfile;
Database altered.
Adds and multiplexes 100Mb online redo log
Instructor's Notes
(If applicable)
As illustrated above, the online redo log files can be easily multiplexed (also
known as "mirrored logs"). Thus, each group can have any number of members,
where each member in the group is a mirror-image of another member. Ideally
the members would be placed on separate disk devices. This technique greatly
reduces the chance of losing a log file and being unable to recover the database.
Supplemental Notes
Note that multiplexing generally results in faster commits, not slower!
This is because Oracle signals the completion of a commit as soon as
any one of the mirrored log files has been written.
Other Text:
Instructor's Notes
(If applicable)
Multiplexing the online logs when using OMF is easy. Just set the
DB_CREATE_ONLINE_LOG_DEST_n parameters (where "n" is 1, 2, 3, 4 or
5). This was demonstrated in the previous example. Then simply execute the
ALTER DATABASE ADD LOGFILE command. Oracle takes care of the rest.
To manually add new members to existing groups, we will need to know what
groups and members currently exist. Querying V$LOGFILE will reveal what
log files currently exist and what group they belong to.
Use the ALTER DATABASE ADD LOGFILE MEMBER statement to add

members. Note that SIZE is not specified; the log file size is obtained from
other members in the group.
Supplemental Notes
To drop an entire group, we can issue the following command:

o
ALTER DATABASE DROP LOGFILE GROUP 3;
To drop an individual online redo logfile member:

ALTER DATABASE DROP LOGFILE
C:\Oracle\oradata\multi\redo03b.log;
Note that you cannot drop a logfile group or a member of a group if the
group is the active group. You must first force a log file switch:
o
ALTER SYSTEM SWITCH LOGFILE;
You may have to force a checkpoint too so the the redo in the log is not
needed for crash recovery:
o
ALTER SYSTEM CHECKPOINT;
Other Text:
SQL> alter database add logfile;
Database altered.
OMF does automatically
Find existing groups & members
1 SELECT group#, member
2* FROM v$logfile
SQL> /
GROUP# MEMBER
---------- --------------------------------1 C:\ORACLE\ORADATA\DAVE\REDO01.LOG
2 C:\ORACLE\ORADATA\DAVE\REDO02.LOG
3 C:\ORACLE\ORADATA\DAVE\REDO03.LOG
Manually add new members; OMF not used
ALTER DATABASE ADD LOGFILE MEMBER 'C:\Oracle\oradata\multi\redo01b.log' TO
GROUP 1;
GROUP 2;
GROUP 3;
Instructor's Notes
(If applicable)
Redo Log Workshop
1. Use V$LOG and V$LOGFILE to determine the number and size of the
existing log files.
2. Add another multiplexed OMF log file to the database.

Other Text:
Instructor's Notes
(If applicable)
Lesson 16: Managing Undo
We will start by defining the term undo and introducing the two methods of
managing: manual and automatic. We will then learn the new method,
Automatic Undo Management (AUM) in detail. Automatic Undo Management
(AUM) is a new Oracle9i feature that deprecates the configuration and use of
Rollback Segments.
Provide a brief review of rollback segments (and remind ourselves what

a pain in the neck they are!).
o
Specifically, in this lesson we will:
Learn about the concepts and architecture of AUM. This will also
uncover the benefits of AUM.
Provide a brief review of locally managed tablespaces. Locally managed

tablespaces were introduced in Oracle8i and are required by AUM.
o
o
Provide procedures for implementing AUM.
Look at the new data dictionary views available for monitoring and
sizing the AUM tablespace.
Lets get started!
Other Text:
Instructor's Notes
(If applicable)
Undo is before-images of changed data. Undo records are automatically

created by the database whenever a change is made. As the Oracle Concepts
manual states "When an update occurs, the original data values changed by the
update are recorded in the database's undo records."
Undo exists to:
Support the ROLLBACK SQL statement.
Support statement-level read consistency. A good definition of

statement-level read consistency can be found in this quote from Kevin
Loney: Queries by other users against the data that is being changed
will return the data as it existed before the change began.* Another way
to explain it is to say that if a query starts at 12 Noon and executes for 15
minutes, all data retrieved by that query will be exactly as it was at 12
noon; updates made between 12 and 12:15 will not be included in the
result set.
o
Support database recovery operations. Recovery involves applying all

changes in the redo logs (optionally up to a point-in-time or system
change number), then undoing changes that have not been committed
(i.e. a commit record is not found in the redo).
* Quote from Oracle8 DBA Handbook, Kevin Loney, Oracle Press ISBN 0-07882406
Other Text:
Instructor's Notes
(If applicable)
Undo records need disk space. With Oracle9i, there are two methods of
acquiring and managing the disk space, automatic and manual.
In Automatic Undo Management mode, we will create an undo tablespace and
let the database create undo segments within the tablespace. In manual mode,
we are responsible for creating and managing the rollback segments within the
rollback tablespace.
According to Oracle9i Database Concepts Release 2, Appendix B Information

on Deprecated Features, Oracle strongly recommends the use of AUM as
well as locally managed tablespaces.The implication is that, at some point, in
the future manually managed undo will not be supported. When that will happen
is anyones guess. (It took many releases for Oracle to remove support for
connect internal. As Mark Twain once remarked, News of my death has been
greatly exaggerated.) However, you can still use rollback segments if you want
to. Simply set UNDO_MANAGEMENT=MANUAL.
Other Text:
Instructor's Notes
(If applicable)
Rollback segments have always been a thorn in the side of Oracle DBAs.
Planning for, creation, monitoring, and maintenance of rollback segments can
sometimes be an onerous task even for experienced DBAs. Until precise
statistics are available, configuring rollback segments is, at best, educated
guesses based on anticipated number and size of transactions your database will
support. The considerations involve:
o how big to make the tablespace(s) that will contain the rollback
segments
how many rollback segments to create inside that tablespace(s)

o
what the segments size should be
max number of extents the rollback segments should be allowed
o
o
what size to make the rollback segment parameter OPTIMAL
Monitoring rollback segments involves tracking waits for segments (a bad

thing!), too many extends (rollback segments are too small), and excessive
shrinks (OPTIMAL parameter needs to be increased).
Other Text:
Instructor's Notes
(If applicable)
And lets not forget about the dreaded snapshot too old errors. These typically
occur when a long running query is accessing data that is being changed by
another transaction; the before image of the data is overwritten in the rollback
segment before the query gets to it.
In summary, tuning rollback segments is an ongoing task and a hassle. So, lets
move on to AUM!
Other Text:
Instructor's Notes
(If applicable)
In automatic undo management mode, an undo segments are used instead of

rollback segments. The benefit is that Oracle automatically allocates and
maintains the undo segments within the undo tablespace.
Automatic undo management mode greatly simplifies undo management. Our
greatest concern in this mode is the size of the undo tablespace. We no longer
need to be concerned with number of rollback segments, size of the segments,
transaction per segment, and so forth.
Automatic undo management mode also provides a simple way to specify, in
seconds, a retention time. i.e. The period of time that undo records should be
kept. This can reduce possibly eliminate snapshot too old errors.
Other Text:
Instructor's Notes
(If applicable)
OK, now that we know what AUM is, why we want to use it, let's get started
with implementation. If creating a new database with the Oracle9i Database
Configuration Assistant, it is easy; the DBCA automatically creates the database
in AUM mode. Implementing AUM on an existing database involves the
following steps:
1. Planning Check for applications that depend on rollback segments.
Code that includes the SET TRANSACTION USE ROLLBACK
SEGMENT statement will fail unless errors are suppressed. See
initialization parameters later in this lesson to see how to suppress
errors.
2. Create the undo tablespace. We will need to guesstimate the initial size
of our undo tablespace. A starting point can be calculated by multiplying
UNDO per second (transaction rate - see V$UNDOSTAT) * blocksize *
your desired retention period. See chapter 13 of the Oracle9i
Administrators Guide for a complete description of this calculation and
Managing UNDO in general.
3. Adjust the initialization parameters.
4. Bounce the database.
Lets look at steps 2 through 4 in turn
Other Text:
Instructor's Notes
(If applicable)
The DBA_TABLESPACES view contains a row for every tablespace. To

determine what UNDO tablespaces are available, execute the query shown
above.
Note that while more than one may be online, only one can be used at any given
time. The exception to this is while switching to a new undo tablespace. See the
section Switching Tablespaces later in this lesson for an example.
Other Text:
1 select tablespace_name, status
2 from dba_tablespaces
3* where contents = 'UNDO'
SQL> /
TABLESPACE_NAME STATUS
------------------------------ --------UNDOTBS1 ONLINE
UNDO_DATA_TS ONLINE
Only one will be in use
Instructor's Notes
(If applicable)
The DBA_DATA_FILES view shows the current size of the datafile(s)

associated with the UNDO tablespace.
Other Text:
SQL> l
1 select tablespace_name, file_name, bytes
2 from dba_data_files
3* where tablespace_name like 'UNDO%'
SQL> /
TABLESPACE_NAM FILE_NAME BYTES

-------------- ------------------------------ ---------UNDOTBS1 C:\ORACLE\ORADATA\DAVE\UNDOTBS 429916160
UNDO_DATA_TS C:\ORACLE\ORADATA\DAVE\O1_MF_U 1048576
Instructor's Notes
(If applicable)
The example above creates a tablespace named SKILLBUILDERS_UNDO

utilizing the new 9i keyword UNDO. Other notables:
o UNDO tablespaces must be locally managed tablespaces. The
DEFAULT STORAGE clause is not allowed.
o
The undo tablespaces cannot be used for anything but undo segments,
else an ORA-30022 error is returned.
Our example omits the EXTENT MANAGEMENT clause; therefore the
default ALLOCATION TYPE of AUTOALLOCATE is used.
Other Text:
CREATE UNDO TABLESPACE skillbuilders_undo

DATAFILE
'c:\oracle9i\oradata\test\skillbuilders_undo01.dbf'
SIZE 100M AUTOEXTEND ON;
Instructor's Notes
(If applicable)
This excerpt above shows an undo tablespace being created as part of a

CREATE DATABASE command. The CREATE DATABASE command is
discussed in detail in the lesson Creating a New Database. A complete
statement might look like this:
CREATE DATABASE prod
DATAFILE 'c:\oradata\tbs\system01.dbf' SIZE 60m
AUTOEXTEND ON NEXT 10m MAXSIZE unlimited
LOGFILE
(c:\oradata\redo\log01a.log',
d:\oradata\redo\log01b.log') SIZE 500k,
d:\oradata\redo\log02b.log') SIZE 500k,
GROUP 3
d:\oradata\redo\log03b.log') SIZE 500k
MAXINSTANCES 1 MAXDATAFILES 300
GROUP 2
GROUP 1
UNDO TABLESPACE skillbuilders_undo
DATAFILE d:\oradata\tbs\ skillbuilders_undo.dbf SIZE 40m AUTOEXTEND

OFF
Other Text:
CREATE DATABASE prod
DATAFILE 'c:\oradata\tbs\system01.dbf' SIZE 60m
AUTOEXTEND ON NEXT 10m MAXSIZE unlimited
LOGFILE
...
UNDO TABLESPACE skillbuilders_undo
DATAFILE
'd:\oradata\tbs\ skillbuilders_undo.dbf'
SIZE 40m AUTOEXTEND OFF
Instructor's Notes
(If applicable)
To enable AUM, parameter UNDO_MANAGEMENT=AUTO must be set. The

parameter UNDO_TABLESPACE should also be set to a valid undo tablespace
name; otherwise, Oracle will use a system-default undo tablespace, which, as a
general rule, is not desirable.
Turn to the next page for details on these parameters.
Other Text:
SQL> show parameter undo_
NAME TYPE VALUE
-------------------------------- ----------- ---------undo_management string AUTO
undo_retention integer 10800
undo_suppress_errors boolean FALSE

undo_tablespace string UNDOTBS1
Instructor's Notes
(If applicable)
The four AUM-related parameters are described here:
UNDO_MANAGEMENT - Set equal to MANUAL or AUTO. This
parameter is not dynamic. If AUTO is specified, Oracle will use an
UNDO tablespace if available (details on the following slides).
However, if an UNDO tablespace is not available, Oracle will use the
SYSTEM rollback segment which is really NOT a good idea. In fact,
Oracle gets so upset about having to use the SYSTEM rollback segment
that it complains loudly by writing warnings to the alert log.
UNDO_TABLESPACE - Set to name of UNDO tablespace. This is a

dynamic parameter. Note that if you change the UNDO tablespace with
alter system set UNDO_TABLESPACE = TSNAME; while there are
active transactions, Oracle will continue to use the original tablespace

until all active transactions have committed. Undo for new transactions
is placed in the tablespace named in the ALTER SYSTEM command.
Other Text:
Instructor's Notes
(If applicable)
o
UNDO_RETENTION Number of seconds Oracle should try to keep

UNDO before being overwritten. Undo that is younger that the retention
value is said to be unexpired. The default is 900 seconds. Set to a
minimum of the longest running query in your database. Range is 0 to 2
Gb (approx 25,000 days!). Increasing provides a larger window for
Flashback Query, but will cause Oracle to keep more undo, requiring a
larger undo tablespace. If an out-of-space condition occurs in the
tablespace, Oracle will start using unexpired undo, which can cause
snapshot too old errors to occur. This is a dynamic parameter.
UNDO_SUPPRESS_ERRORS - (TRUE|FALSE) Provides support for
applications written using manual UNDO commands such as SET
TRANSACTION USE ROLLBACK SEGMENT. Suppresses errors
such as ORA-30019. This parameter can be set at the system level (in
the database parameter file or ALTER SYSTEM) or at the session level
with ALTER SESSION.
After adding these parameters to your database parameter file, shutdown and restart your database to implement AUM.
Other Text:
Instructor's Notes
(If applicable)
Assume that UNDO_TABLESPACE = SKILLBUILDERS_OTHER_UNDO
has been specified and we would like to change the UNDO tablespace. To do so,
we would issue the commands shown in this example.
Oracle places the old undo tablespace in PENDING OFFLINE mode which
means that existing transactions continue but the tablespace will not accept new
transaction undo. When all active transactions have committed, the tablespace is
placed in OFFLINE mode.
Other Text:
ALTER TABLESPACE skillbuilders_undo ONLINE;
ALTER SYSTEM
SET UNDO_TABLESPACE = skillbuilders_undo
COMMENT = 'changed on 5-1-2003'
SCOPE = BOTH;
Instructor's Notes
(If applicable)
An UNDO tablespace may also be dropped provided that it is not in use by any
instance and does not contain information about incomplete transactions.
Additionally, the UNDO_RETENTION parameter is ignored during DROP.
Oracle does not care that you may have specified a six month retention period.
When the DROP is processed, the tablespace is history! It will, however, wait
for active transactions to complete.
Other Text:
DROP TABLESPACE skillbuilders_undo ;
Instructor's Notes
(If applicable)
Data dictionary view DBA_UNDO_EXTENTS provides commit information

about each extent in UNDO tablespaces. See the example in the Tuning AUM
section of this lesson.
Dynamic performance view V$UNDOSTAT provides Oracle-generated
statistics for monitoring and maintenance of undo tablespace sizing problems. It
works for both AUM and manual (rollback segment) undo.
Other Text:
Instructor's Notes
(If applicable)
The whole point of AUM is the little maintenance required, especially compared
to rollback segments. However, certain columns in the V$UNDOSTAT dynamic
view will help the DBA keep abreast, or better yet ahead, of any potential
problems due to lack of space in the undo tablespace.
A general rule-of-thumb provided by the Oracle Concepts manual is to make

the size of the undo tablespace 20% larger than what is needed for your
specified retention value (see parameter UNDO_RETENTION). Use the
V$UNDOSTAT.UNDOBLKS to determine the number of undo blocks used,
and translate that into the undo tablespace size.
Oracle Enterprise Manager will recommend a size for the UNDO tablespace
too.
Other Text:
Instructor's Notes
(If applicable)
A description of helpful columns in V$UNDOSTAT:
UNDOBLKS this column contains the total number of undo blocks
generated during period of statistical collection. If this number is far
larger then the UNDO tablespaces size, then the size of the undo
tablespace needs to be increased.
Additional information is found on the next page
Other Text:
Instructor's Notes
(If applicable)
o
UNXPSTEALCNT Number of unexpired blocks (as set in parameter

UNDO_RETENTION) that are being expired prematurely; that is, other
transactions have taken over those blocks because not enough UNDO
space was available for those transactions. This columns value is
particularly useful when a new application and database is brought
online: the famous and frustrating snapshot too old error can appear as
more and more users start to use the system, generating increasing
numbers of undo blocks. The Oracle DBA can increase the value of
parameter UNDO_RETENTION_TIME to get rid of such errors.
Sometimes raising this value is not enough to get rid of all snapshot too
old errors, and the DBA has to additionally add more space to the undo
tablespace.
o MAXQUERYLEN this column contains the value, in seconds, of the
longest-running transaction in the past 24 hours. The undo management
parameter UNDO_RETENTION should be set to a value larger than the
value in MAXQUERYLEN.
NOSPACERRCNT This column keep track of the number of any
space unavailable errors generated when Oracle writes undo transaction
blocks to an undo tablespace. If this value is not zero, increase the size
of the undo tablespace.
Other Text:
Instructor's Notes
(If applicable)
There is also some useful transaction-related information in
V$TRANSACTION and V$ROLLSTAT. V$TRANSACTION contains
information on active transactions. V$ROLLSTAT contains information about
undo segments if operating in AUM mode; rollback segment information if
running in manual mode.
Other Text:
Instructor's Notes
(If applicable)
If you determine that the undo tablespace is not large enough, adding space can
be accomplished by adding a datafile to the tablespace as shown in this
example.
Other Text:
ALTER TABLESPACE skillbuilders_undo
ADD DATAFILE
'c:\oracle9i\oradata\test\sb_undo02.dbf'
SIZE 10M AUTOEXTEND ON;
Instructor's Notes
(If applicable)
Other Text:
Instructor's Notes
(If applicable)
Other Text:
Instructor's Notes
(If applicable)
AUM Workshop
1. What are the current values of the four AUM parameters for your
database?
2. Create a new undo tablespace called UNDO_DATA_TS. Use OMF for

the location and filename if OMF is active. Create a 1M datafile with
AUTOEXTEND OFF.
3. Make the tablespace UNDO_DATA_TS the undo tablespace for your
database. Verify that the change worked.
4. Execute the supplied script AUM1.SQL. Ignore any ORA-00942: table
or view does not exist error messages. Note that you should get an
error: ORA-30036: unable to extend segment by 16 in undo tablespace
UNDO_DATA_TS.
5. Query V$UNDOSTAT to determine the number of undo blocks

consumed in the last 60 minutes. Was there any attempted stealing of
unexpired blocks? If you experienced any attempted stealing of
unexpired blocks, what would you do to correct this?
6. Revert to the original undo tablespace. Rerun supplied script
AUM1.SQL. Insure there are no errors.
Other Text:

Managing Contorl Archive Redolog Files Skillbuilders

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Managing Contorl Archive Redolog Files Skillbuilders

Uploaded by

Copyright:

Available Formats

SkillBuilders Advertisement

All structural changes such as adding or removing datafiles are recorded

Notes continue on the next page

The checkpoint process updates the control file when a checkpoint is

The database administrator has the following responsibilities related to the

The first level of protection comes from maintaining multiple

automatically. Also, since the control file is regularly updated

The third level of protection comes at the operating system level.

As I demonstrated in the review earlier in this lesson, another method of

Next, we need to update the CONTROL_FILES parameter in the initialization

Notes continues on the next page

Recovering from an Error

SQL> create spfile from pfile;

Add Control File Workshop

1. Determine the control files currently in use.

With server-managed (RMAN) backups. Refer to the lesson

With the ALTER DATABASE BACKUP CONTROLFILE command.

SQL> select instance_name from v$instance;

Notes continue on the next page

2 from v$process a, v$session b

3 where a.addr = b.paddr

4 and b.audsid = userenv('sessionid');

or directories or you want to change some of the "fixed" parameters on the

The script created by the ALTER DATABASE BACKUP CONTROLFILE TO

There are two versions of the CREATE CONTROLFILE command in

Note that the Oracle9i Administration Guide and Metalink

Excerpt from the BACKUP CONTROLFILE TO TRACE trace file:

ORACLE V9.2.0.1.0 - Production vsnsta=0

Windows 2000 Version 5.0 Service Pack 4, CPU type 586

Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production

JServer Release 9.2.0.1.0 - Production

Windows 2000 Version 5.0 Service Pack 4, CPU type 586

Redo thread mounted by this instance: 1

Oracle process number: 15

Windows thread id: 1752, image: ORACLE.EXE

Instance name: dave

*** SESSION ID:(12.430) 2003-10-03 13:05:25.000

# The following are current System-scope REDO Log Archival related

# parameters and can be included in the database initialization file.

# LOG_ARCHIVE_DEST_1='MANDATORY NOREOPEN NODELAY'

# LOG_ARCHIVE_DEST_1='ARCH NOAFFIRM SYNC'

# if online logs are unavailable.

# a script file, edited as necessary, and executed when there is a

# need to re-create the control file.

# Set #1. NORESETLOGS case

# to open the database.

# only if the current version of all online logs are available.

STARTUP NOMOUNT <--[Delete all records before this]

CREATE CONTROLFILE REUSE DATABASE "DAVE" NORESETLOGS

-- SET STANDBY TO MAXIMIZE PERFORMANCE

GROUP 1 'C:\ORACLE\ORADATA\DAVE\REDO01.LOG' SIZE 100M,

GROUP 2 'C:\ORACLE\ORADATA\DAVE\REDO02.LOG' SIZE 100M,

GROUP 3 'C:\ORACLE\ORADATA\DAVE\REDO03.LOG' SIZE 100M

CHARACTER SET WE8MSWIN1252

Description of steps to recreate the control file, continued:

This is an optional workshop. The instructor will assign only if time

1. Execute the ALTER DATABASE command that creates the CREATE

When active log fills:

Multiplexing the archive logs (essentially creating backup copies of the

To determine the status of archiving on a database:

Check the LOG_ARCHIVE_START parameter value. TRUE causes

Automatic Archival When "enabled", the archive background process

Putting the database in "archive log" mode. When in "Archive Mode",

Archive-related activity in the database is controlled with initialization