Oracle enables you to save filled groups of online redo log files to one or more offline
destinations, known collectively as the archived redo log, or more simply archive log. The
process of turning online redo log files into archived redo log files is called archiving. This
process is only possible if the database is running in ARCHIVELOG mode. You can choose
automatic or manual archiving.
An archived redo log file is a copy of one of the identical filled members of an online redo
log group. It includes the redo entries present in the identical member of a redo log group
and also preserves the group's unique log sequence number. For example, if you are
multiplexing your online redo log, and if Group 1 contains member files (depending upon
the number of members you have attached for each group) redo_log_01_01.log and
redo_log_01_02.log, then the archiver process (ARCn) will archive one of these identical
members. Should a_log1 become corrupted, then ARCn can still archive the identical
b_log1. The archived redo log contains a copy of every group created since you enabled
archiving.
When running in ARCHIVELOG mode, the log writer process (LGWR) is not allowed to reuse
and hence overwrite an online redo log group until it has been archived. The background
process ARCn automates archiving operations when automatic archiving is enabled. Oracle
starts multiple archiver processes as needed to ensure that the archiving of filled online
redo logs does not fall behind.
How they are useful to me???
ARCHIVELOG mode enabled databases are also called media recovery enabled databases.
This means that you shall be able to restore and recover the database.
RESTORE-ing the database means restoring from the backup. The backup may be online,
offline or a logical export of a database, schema or table.
RECOVERY means recovering the database to point of time of failure, log sequence or
change sequence number. To perform these kind of operations we need the archived redo
log files generated by Oracle from the time of the start of the last backup, which has been
used to restore the database. The required number of the archived log files is dependent on
kind of recovery you are going for.
So you can use archived redo logs to:
(1) Recover a database
(2) Update a standby database
(3) Gain information about the history of a database using the LogMiner utility.
(We shall discuss standby database and LogMiner at a later point of time, as that discussion
is irrelevant here).
What if I run my database in NOARCHIVELOG MODE???
When you run your database in NOARCHIVELOG mode, you disable the archiving of the
online redo log. The database's control file indicates that filled groups are not required to be
archived. Therefore, when a filled group becomes inactive after a log switch, the group is
available for reuse by LGWR.
The choice of whether to enable the archiving of filled groups of online redo log files
depends on the availability and reliability requirements of the application running on the
database. If you cannot afford to lose any data in your database in the event of a disk
failure, use ARCHIVELOG mode. The archiving of filled online redo log files can require you
to perform extra administrative operations.
NOARCHIVELOG mode protects a database only from instance failure, but not from media
failure. Only the most recent changes made to the database, which are stored in the groups
of the online redo log, are available for instance recovery. In other words, if a media failure
occurs while in NOARCHIVELOG mode, you can only restore (not recover) the database to
the point of the most recent full database backup. You cannot recover subsequent
transactions.
Also, in NOARCHIVELOG mode you cannot perform online tablespace backups. Furthermore,
you cannot use online tablespace backups previously taken while the database operated in
ARCHIVELOG mode.
You can only use whole database backups taken while the database is closed to restore a
database operating in NOARCHIVELOG mode. Therefore, if you decide to operate a database
in NOARCHIVELOG mode, take whole database backups at regular, frequent intervals.
Can I use RMAN to backup my database, which is in NOARCHIVELOG mode?
Yes, you can use RMAN for offline or cold backups by keeping the database in mount mode.
It is because the data files are not open at that stage.
What if I run the database in ARCHIVELOG mode???
When you run a database in ARCHIVELOG mode, you specify the archiving of the online
redo log. The database control file indicates that a group of filled online redo log files cannot
be used by LGWR until the group is archived. A filled group is immediately available for
archiving after a redo log switch occurs.
The archiving of filled groups has these advantages:
A database backup, together with online and archived redo log files, guarantees that you
can recover all committed transactions in the event of an operating system or disk failure.
You can use a backup taken while the database is open and in normal system use if you
keep an archived log.
You can keep a standby database current with its original database by continually applying
the original's archived redo logs to the standby.
Can I anytime delete these archived log files from the computer at all???
If you do not delete these files at all it is a showstopper. The disks get filled with these files
and database gets stuck. It is always advised to backup these archived log files on to a tape
or any other destination of your choice, which does not effect the functioning of the
database, and then delete them. You can determine required archived log files basing on the
latest full backup of the database. There are so many factors to be considered and we shall
discuss them in detail while discussing the backup strategies.
How can I set my database to ARCHIVELOG mode from NOARCHIVELOG mode???
(1) Shutdown the database with normal or immediate option but not abort option.
Shutdown immediate;
(2) Back up the database
(3) Edit the initialization parameter file to set archive log mode PARAMETERS
LOG_ARCHIVE_START=TRUE
LOG_ARCHIVE_DEST= 'c:\oracle\admin\whs\archive\'
(4) Start a new instance and mount, but do not open, the database.
STARTUP MOUNT
To enable or disable archiving, the database must be mounted but not open.
(5) Switch the database's archiving mode. Then open the database for normal operations.
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
(6) Shut down the database.
SHUTDOWN IMMEDIATE
(7) Back up the database:
Changing the database archiving mode updates the control file. After changing the database
archiving mode, you must back up all of your database files and control file. Any previous
backup is no longer usable because it was taken in NOARCHIVELOG mode.
When you set LOG_ARCHIVE_START=TRUE you are setting up automatic archiving of the
database. If you do not set this it is manual and you are to manually archive the archive log
files as and when they are filled. If not Oracle overwrites those online redo log files and they
are no more available for performing any recovery.
How can I start the archiving after the instance is started???
To start the archiving after the instance is started issue the following statement
ALTER SYSTEM ARCHIVE LOG START;
You can optionally include the archiving destination.
If an instance is shut down and restarted after automatic archiving is enabled using the
ALTER SYSTEM statement, the instance is reinitialized using the settings of the initialization
parameter file.
Those settings may or may not enable automatic archiving. If your intent is to always
archive redo log files automatically, then you should include LOG_ARCHIVE_START = TRUE
in your initialization parameters.
How can I control the number of archive processes???
This is controlled by Oracle, if it is left to Oracle, provided you are ready to take the runtime
over heads. If you do not want them and you need to take control of these kind of situations
set this parameter LOG_ARCHIVE_MAX_PROCESSES. The maximum number of processes
you can start using this parameter is 10.
Initialization Parameter
LOG_ARCHIVE_DEST_n
where: n is an integer
from 1 to 10
Host
Example
Local LOG_ARCHIVE_DEST_1 =
or
'LOCATION=/disk1/arc'
remot LOG_ARCHIVE_DEST_2 =
e
'SERVICE=standby1'
LOG_ARCHIVE_DEST =
LOG_ARCHIVE_DEST and
Local
'/disk1/arc'
LOG_ARCHIVE_DUPLEX_D
only LOG_ARCHIVE_DUPLEX_D
EST
EST = '/disk2/arc'
01 Method
Perform the following steps to set the destination for archived redo logs using the
LOG_ARCHIVE_DEST_n initialization parameter:
(1) Use SQL*Plus to shut down the database with normal or immediate option but not
abort.
SHUTDOWN
(2) Edit the LOG_ARCHIVE_DEST_n parameter to specify from one to ten archiving
locations. The LOCATION keyword specifies an operating system specific path name.
For example, enter:
LOG_ARCHIVE_DEST_1 = 'LOCATION = /disk1/archive'
LOG_ARCHIVE_DEST_2 = 'LOCATION = /disk2/archive'
LOG_ARCHIVE_DEST_3 = 'LOCATION = /disk3/archive'
If you are archiving to a standby database, use the SERVICE keyword to specify a valid net
service name from the tnsnames.ora file. For example, enter:
LOG_ARCHIVE_DEST_4 = 'SERVICE = standby1'
(3) Edit the LOG_ARCHIVE_FORMAT initialization parameter, using %s to include the log
sequence number as part of the file name and %t to include the thread number. Use capital
letters (%S and %T) to pad the file name to the left with zeroes. For example, enter:
LOG_ARCHIVE_FORMAT = arch%s.arc
These settings will generate archived logs as follows for log sequence
numbers 100, 101, and 102:
/disk1/archive/arch100.arc,
/disk1/archive/arch101.arc,
/disk1/archive/arch102.arc
/disk2/archive/arch100.arc,
/disk2/archive/arch101.arc,
/disk2/archive/arch102.arc
/disk3/archive/arch100.arc,
/disk3/archive/arch101.arc,
/disk3/archive/arch102.arc
02 Method
The second method, which allows you to specify a maximum of two locations, is to use the
LOG_ARCHIVE_DEST parameter to specify a primary archive destination and the
LOG_ARCHIVE_DUPLEX_DEST to specify an optional secondary archive destination.
Whenever Oracle archives a redo log, it archives it to every destination specified by either
set of parameters.
Perform the following steps to use method 2:
(1) Use SQL*Plus to shut down the database.
SHUTDOWN
(2) Specify destinations for the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST
parameter (you can also specify LOG_ARCHIVE_DUPLEX_DEST dynamically using the ALTER
SYSTEM statement).
Description
V$ARCHIVE_DEST
V$ARCHIVE_DEST_STATUS
V$ARCHIVE_GAP
V$ARCHIVE_PROCESSES
V$PROXY_ARCHIVEDLOG
V$ARCHIVED_LOG
V$ARCHIVE
V$DATABASE
V$ARCHIVE_DEST
V$BACKUP_REDOLOG
V$LOG
V$LOG_HISTORY