You are on page 1of 4

Place your database into archivelog mode:

SQL> archive log list;


Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 19
Current log sequence 21

SQL> select log_mode from v$database;

LOG_MODE
------------
NOARCHIVELOG

SQL> shutdown immediate


Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount


ORACLE instance started.

Total System Global Area 444596224 bytes


Fixed Size 1219904 bytes
Variable Size 138412736 bytes
Database Buffers 301989888 bytes
Redo Buffers 2973696 bytes
Database mounted.

SQL> alter database archivelog;

Database altered.

SQL> alter database open;

Database altered.

SQL> archive log list;


Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 19
Next log sequence to archive 21
Current log sequence 21
SQL> select log_mode from v$database;

LOG_MODE
------------
ARCHIVELOG

Page | 1
LOG FILES:

Every Oracle database must have at least 2 redo logfile groups. Oracle writes all statements
except, SELECT statement, to the logfiles. This is done because Oracle performs deferred batch
writes i.e. it does write changes to disk per statement instead it performs write in batches. So in
this case if a user updates a row, Oracle will change the row in db_buffer_cache and records the
statement in the logfile and give the message to the user that row is updated. Actually the row is
not yet written back to the datafile but still it give the message to the user that row is updated.
After 3 seconds the row is actually written to the datafile. This is known as deferred batch
writes.

Since Oracle defers writing to the datafile there is chance of power failure or system crash before
the row is written to the disk. That’s why Oracle writes the statement in redo logfile so that in
case of power failure or system crash oracle can re-execute the statements next time when you
open the database.

Adding a New Redo Logfile Group


SQL>alter database add logfile group 3
‘/u01/oracle/ica/log3.ora’ size 10M;

Note: You can add groups to a database up to the MAXLOGFILES setting you have specified at
the time of creating the database. If you want to change MAXLOGFILE setting you have to
create a new controlfile.

Adding Members to an existing group


SQL>alter database add logfile member
‘/u01/oracle/ica/log11.ora’ to group 1;

Note: You can add members to a group up to the MAXLOGMEMBERS setting you have
specified at the time of creating the database. If you want to change MAXLOGMEMBERS
setting you have create a new controlfile

Dropping Members from a group


You can drop member from a log group only if the group is having more than one member and if
it is not the current group. If you want to drop members from the current group, force a log
switch or wait so that log switch occurs and another group becomes current. To force a log
switch give the following command

SQL>alter system switch logfile;

The following command can be used to drop a logfile member

Page | 2
SQL>alter database drop logfile member
‘/u01/oracle/ica/log11.ora’;

Note: When you drop logfiles the files are not deleted from the disk. You have to use O/S
command to delete the files from disk.

Dropping Logfile Group


Similarly, you can also drop logfile group only if the database is having more than two groups
and if it is not the current group.

SQL>alter database drop logfile group 3;

Automatic Undo Management:


Traditionally transaction undo information was stored in Rollback Segments until a commit
or rollback statement was issued, at which point it was purged. In Oracle 9i this method of
manual undo management is still available in addition to a new automatic method which
frees DBAs from routine undo management tasks and tuning. In addition it allows the DBA
to specify how long undo information should be retained after commit, preventing "snapshot
too old" errors on long running queries in addition to supporting Oracle flashback query.

It is not possible to use both methods in a single instance simultaneous, but the method can
be switched, a procedure which requires the instance to be bounced.
• Undo Tablespace Creation
• Enabling Automatic Undo Management
• Maintenance
• Monitoring

Undo Tablespace Creation

Automatic undo management requires a locally managed undo tablespace to store undo
segments in. Undo tablespaces can be created during database creation or using the
CREATE UNDO TABLESPACE statement:
-- As part of database creation
CREATE DATABASE rbdb1
CONTROLFILE REUSE
...
UNDO TABLESPACE undotbs_01
DATAFILE 'C:\Oracle\Ordata\TSH1\undo0101.dbf'
SIZE 100M REUSE AUTOEXTEND ON;

-- Using the create undo tablespace statement


CREATE UNDO TABLESPACE undotbs_02
DATAFILE 'C:\Oracle\Ordata\TSH1\undo0201.dbf'
SIZE 100M REUSE AUTOEXTEND ON;

If undo_management is set to auto and no undo_tablespace is defined Oracle will create


one during the database creation.

Page | 3
Enabling Automatic Undo Management

Since the default undo management mode is MANUAL, the instance must be told to use
AUTO mode at instance startup. To do this the following initialization parameters can be set:
UNDO_MANAGEMENT = AUTO # Default is MANUAL
UNDO_TABLESPACE = undotbs_01 # The name of the undo tablespace.
UNDO_RETENTION = 900 # The time undo is retained.
# Default is 900 seconds.
UNDO_SUPPRESS_ERRORS = TRUE # Suppress errors when MANUAL undo admin
# SQL statements are issued.
Several of these parameters can be altered while the instance is up, but the
UNDO_MANAGEMENT parameter is static:
-- Dynamic Parameters.
ALTER SYSTEM SET UNDO_TABLESPACE=UNDOTBS_02;
ALTER SYSTEM SET UNDO_RETENTION=5;
ALTER SYSTEM SET UNDO_SUPPRESS_ERRORS=FALSE;

-- Static Parameters.
ALTER SYSTEM SET UNDO_MANAGEMENT=AUTO SCOPE=SPFILE;

Maintenance

Maintenance of undo tablespaces is similar to that of regular tablespaces, although some


options are not neccessary as Oracle takes over the burden of most management tasks:

-- Add a datafile.
ALTER TABLESPACE undotbs_01
ADD DATAFILE 'C:\Oracle\Ordata\TSH1\undo0102.dbf'
AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED;

-- Resize an undo datafile.


ALTER DATABASE DATAFILE 'C:\Oracle\Ordata\TSH1\undo0102.dbf'
RESIZE 10M;

-- Perform backup operations


ALTER TABLESPACE undotbs_01 BEGIN BACKUP;
ALTER TABLESPACE undotbs_01 END BACKUP;

-- Drop an undo tablespace.


DROP TABLESPACE undotbs_01;
In the last example the tablespace will only be dropped if it is not currently being used or
contains undo information for a current transaction. It will however drop tablespaces where
the undo information has not yet expired, thus affecting long running queries and flashback
query.

Monitoring
Undo information can be queried using the following views:
V$UNDOSTAT
V$ROLLSTAT
V$TRANSACTION
DBA_UNDO_EXTENTS

Page | 4