Oracle7 Archiving Tips and Hints

Published on November 2016 | Categories: Documents | Downloads: 73 | Comments: 0 | Views: 266
of 12
Download PDF   Embed   Report

DBA oracle

Comments

Content

Technical Reports Compendium II, 1996

Archiving Tips and Hints

®

Technical Paper

Archiving Tips and Hints

Lawrence To

Center of Expertise
Worldwide Customer Support
Oracle Corporation
August 1996

Oracle Release 7.0

5-1

Archiving Tips and Hints

Technical Reports Compendium II, 1996

TABLE OF CONTENTS
INTRODUCTION .......................................................................................................................................................3
AUDIENCE AND REQUIRED BACKGROUND ......................................................................................................................3
FURTHER READING.........................................................................................................................................................3
OVERVIEW AND CONCEPTS ............................................................................................................................................3
Threads ......................................................................................................................................................................5
OPS: Archiving Log Switches....................................................................................................................................6
Posting ARCH ...........................................................................................................................................................6
ARCH PROCESS FLOW...........................................................................................................................................7
REDO LOG AND ARCHIVE FILE CONFIGURATION.......................................................................................8
ARCHIVING TUNING...............................................................................................................................................8
ARCHIVING STRATEGY.........................................................................................................................................9
MONITORING FOR STALE LOGS ......................................................................................................................10
PROBLEM SOLVING..............................................................................................................................................10
DEBUGGING WITH ARCHIVE COMMANDS .....................................................................................................................10
CHECK THE V$ VIEWS..................................................................................................................................................11
CHECK ANY ARCHIVE TRACE FILES .............................................................................................................................11
DETERMINE WHAT ARCH IS CALLING .........................................................................................................................11
CHECK FOR PLATFORM SPECIFIC BUGS ........................................................................................................................11
PREVENTING THE PROBLEM RECURRING ......................................................................................................................11

ATTENTION READERS INCLUDING ORACLE EMPLOYEES. No part of this document may be reproduced
without the prior permission of the publishers, Center of Expertise, Oracle Worldwide Customer Support.
Copyright  Oracle Corporation 1995

All rights reserved. Printed in the U.S.A.

Author:

Lawrence To

Writer:

Brian Quigley

Reviewers:

Roderick Manalac, Reem Munakash, Sameer Patkar

Contributors:

Carol Colrain, Cary Millsap, Reem Munakash

Oracle is a registered trademark of Oracle Corporation. Oracle7 is a trademark of Oracle Corporation.
All other products or company names are used for identification purposes only, and may be trademarks of their
respective owners.

5-2

Oracle Release 7.0

Technical Reports Compendium II, 1996

Archiving Tips and Hints

INTRODUCTION
Audience and Required Background
You are interested in improving your knowledge of Oracle archiving. Before reading this paper, you should have a
working understanding of the Oracle archiving mechanism. Knowledge of Oracle internals is not essential, but will
help in reading this paper.

Further Reading
Oracle archiving uses physiological logging. This concept is thoroughly described in Transaction Processing:
Concepts and Technology by Jim Gray and Andreas Reuter, published by Morgan Kaufman.
RAID: High Performance Reliable Secondary Storage, by Peter Chen.
VLDB Best Practices by Cary Millsap, available in the corporate repository.
Oracle7 v7.2 Recovery Outline by Andrea Borr and Bill Bridges.
Oracle Parallel Server Internal Notes by Carol Colrain.
The text for bugs: 282224, 238308, 20126, 189963.

Overview and Concepts
In this section, a brief review is given of the most important archiving concepts. Most, but not all, information in this
review section is available in the Oracle7 Concepts Guide, the Oracle7 Administrator’s Guide, and the Oracle7
Parallel Server Administrator’s Guide. Sections after this review section provide information that is not generally
available in the Oracle7 documentation set. You should find this information useful in improving your understanding
or administrative skills regarding archiving.
The information in the rest of this paper is only meaningful if archiving is enabled for a database. That is, the
database was created with the CREATE DATABASE ARCHIVELOG command, or, the database was created with
the default NOARCHIVELOG clause and then the ALTER DATABASE ARCHIVELOG issued. (The second
method in the previous sentence is the quickest method.) From an Oracle viewpoint and as used in this paper, the
term archiving refers specifically to the copying of redo logs by the ARCH process.
Automatic archiving occurs when archiving is enabled and the database is started with initialization parameter
LOG_ARCHIVE_START=TRUE. In this case, an ARCH background process is started. ARCH looks for and
copies inactive redo log files. (Active redo log files are being written to by LGWR.)
Automatic archiving can be halted by issuing the ALTER SYSTEM ARCHIVE STOP command. In this case, it is
the responsibility of the database administrator to perform manual archiving to start ARCH processes to copy redo
log files. Automatic archiving can be restarted by issuing the ALTER SYSTEM ARCHIVE START command. In
some automatic archiving cases, it is necessary to issue manual archiving commands to start extra ARCH processes
to expedite archiving.
Manual archiving must be performed when archiving is enabled and the database is started with initialization
parameter LOG_ARCHIVE_START=FALSE (the default value). In this case, although manual archiving provides
control over when redo log files are copied, it is not recommended. Manual archiving tends to be an administrative
nightmare. For example, your database could hang during an unexpectedly busy period of processing because Oracle
will not continue until the appropriate redo log files are copied by an ARCH process. However, manual archiving in
conjunction with automatic archiving can be beneficial.

Oracle Release 7.0

5-3

Archiving Tips and Hints

Technical Reports Compendium II, 1996

System Global Area

Buffer Cache

Redo
Cache
Control
Files

Server
Process

DBWR

CKPT

LGWR

Redo Log
Group
Database Database
Files
Files

ARCH

Archived
Redo
Logs

O/S
file copy

tape

Redo Log
Group

The three manual archiving commands that are most used are:


ALTER SYSTEM ARCHIVE LOG ALL -- archive all inactive redo logs



ALTER SYSTEM ARCHIVE LOG NEXT -- archive only the next inactive redo log



ALTER SYSTEM ARCHIVE LOG CURRENT -- archive all inactive redo logs and the current active log

By issuing any of the above commands when an ARCH process is already running, it is possible to start extra ARCH
processes. Thus, it is possible to concurrently archive several inactive or active (current) online redo log groups.
This is particularly useful for stopping database hangs during automatic archiving when the redo log rate is much
higher than the archive log rate.
When archiving is enabled, online redo log groups cannot be re-used until the redo log files are successfully copied
by the ARCH process; that is, the database will hang until filled redo logs are copied. Thus, the Oracle physiological
logging mechanism guarantees that all changes to the database are written to archived log files, which are then
available if media recovery is required. The archiving mechanism tracks the status of each online redo log by
updating status information in the control files. In particular, an archive link list is maintained in the control file; that
is, a list of inactive redo log files that need to be archived.
(Note: When archiving is not enabled, Oracle only maintains which redo log is current, does not check whether a
redo log group was archived, and does not maintain the archive link list. Furthermore, if an inactive log is manually
archived, the status of the log will not be updated.)
ARCHIVE LOG ALL is the most advantageous of the manual archiving commands because it archives all redo logs
except the current redo log and redo logs already being archived. ARCHIVE LOG NEXT fails if the next online redo
log is already being archived. ARCHIVE LOG CURRENT archives all logs including the current log. This may not
be advantageous if the current redo log only contains a small amount of relevant redo.
Note: Oracle can archive a redo log that was not checkpointed. However, it is not possible to overwrite a log that was
not checkpointed. In other words, ARCH can be ahead of DBWR.

5-4

Oracle Release 7.0

Technical Reports Compendium II, 1996

Archiving Tips and Hints

Threads
A thread of redo or thread is a concept specific to the parallel server option. However, this concept is useful even for
non-parallel server discussions on Oracle backup and recovery. A thread consists of the online portion of redo log
and the archived portions of redo logs. For a non-parallel server, there is only one thread and one set of redo log
groups. For a parallel server, there may be many threads and as many
Note: The annotation OPS is used hereon to indicate that information is only relevant to the parallel server option.
OPS: For a parallel server, each thread is unique and switches logs independently of all other threads. Depending on
the mode and status of a thread, archiving of the online redo logs may or may not be enforced.
An open thread is a thread held by an instance once the database is opened by an instance. This thread is chosen at
mount time.
OPS: A thread is chosen by examining the initialization parameter THREAD. If THREAD=0, an instance will obtain
any available public thread, which is then held by the instance until the instance is closed. A thread mount lock
prevents other instances from accessing a thread. Once the thread is opened, thread open locks (RT enqueues) are
held by background processes (LGWR, DBWR, LCKnn). When an instance opens a thread, the thread open flag is
set in the thread’s control file record.
A closed thread is a thread that is no longer active because of instance shutdown or after instance recovery. Redo is
not generated to a closed thread.
OPS: When a thread is closed, the thread open flag is cleared in the control file for closing instance and a final
thread checkpoint is updated in that control file.
An enabled thread is a thread that is available for opening by an instance. At database creation, a thread is
automatically made available.
OPS: Threads are enabled using the ALTER DATABASE ENABLE THREAD command. This command can only
be issued through an instance that already has a thread enabled. Oracle keeps track of enabled threads both in the
control file as well as in redo logs. When a thread is enabled, the control file for the instance is updated to reflect this
event and a redo record is written into the current online redo logs. If this redo record is encountered during
recovery, then the control file may be updated.
OPS: If there exist at least two redo log groups for a thread, then the thread can be either public or private. A public
thread is available to the first instance starting with initialization parameter THREAD=0. A private thread is named
with a particular numeric value and can only be mounted or opened by an instance with THREAD equal to the same
numeric value.
A disabled thread is a thread that is made unavailable to instances.
OPS: A thread must be closed before the thread can be disabled. It is beneficial to disable a thread if the thread will
not be used for a long time. Disabling a thread also disables media recovery for the instance.
The ARCH process ensures that a thread of redo is archived and attempts to keep pace with LGWR.
OPS: The ARCH process ensures that all online redo logs in an instance’s thread, other than the current redo log, are
archived out. When an ARCH process is active, it may be archiving:


any inactive redo log group within the instance’s thread



any inactive redo log group of a closed and enabled thread for another instance



posting (also known as kicking) other instances of enabled and open threads to archive the posting instance’s
thread

Oracle Release 7.0

5-5

Archiving Tips and Hints

Technical Reports Compendium II, 1996

OPS: Archiving Log Switches
OPS: Each instance archive its thread and redo logs independently. However, all threads are maintained such that
each thread is relatively current with respect to SCNs. (If an un-archived log for an enabled thread contained a very
old SCN, as in the case of a commonly idle instance, it would not be possible to use archive logs from a primary site
to do recovery to a higher SCN at a standby database site.) Threads are kept relatively current by forcing log
switches or kicking idle instances to archive. For an open and enabled thread, a lock is used to kick an idle instance.
For a closed and enabled thread, the ARCH process for an active instance will log switch and archive the closed
thread. A force archive SCN is maintained in the control file to implement this feature.
OPS: The ARCH process scans the archive link list found in the control file and archives all inactive redo logs
whose SCN is less than the force archive SCN. Oracle strives to archive any log that contain less than or equal to the
force archive SCN. Generally, the log with the lowest SCN is archived first.
OPS: The force archive SCN is also used to kick idle instances to archive their logs. Oracle only kicks open and
enabled threads that need to switch the current log because the SCN is too old. It also be necessary to archive closed
and enabled threads. However, to archive the log, a log switch occurs on the closed thread.
OPS: When there are idle instances, it is not uncommon to see small archive files containing just header information.
This occurs because Oracle forces idle instances to perform log switches, which advances the SCN in the log, so that
the log is kept relatively current with other threads. Thus, the redo log for an idle instance may only contain head
information and possibly not contain any relevant redo.
OPS: If a thread was closed but not disabled, then Oracle also attempts to keep that thread relatively current with
respect to SCNs. To do so, another instance performs a log switch and the archiving for the closed instance.

Posting ARCH
Posting refers to signaling ARCH to do some work. ARCH is posted only when archiving is enabled. Posting ARCH
occurs in the following events:


300 second time-out



each log switch



when archiving is started automatically or manually



during instance recovery



ARCH may post itself, if it is archiving a log and another log must be archived

When a database is opened and archiving is enabled, ARCH is posted if the current control file is used.
OPS: During the open, ARCH may also be posted to archive a log so that a closed thread may perform a log switch.
ARCH is posted not to archive when instance or media recovery is occurring.
When ARCH is archiving, LGWR may post ARCH to archive another log. ARCH must complete before LGWR can
overwrite the next log. In this case, escalation occurs because user processes might be waiting. Thus, ARCH may
stop work to archive the log requested by LGWR before continuing with the original log.

5-6

Oracle Release 7.0

Technical Reports Compendium II, 1996

Archiving Tips and Hints

ARCH PROCESS FLOW
Note: Most, but not all, platforms support asynchronous I/O. For these platforms, you can simply ignore the word
asynchronous in the following discussion.
Archiving a log encompasses the following three main phases: asynchronous read of online redo log and perform
checks, allocate and fill archive redo log buffers, and asynchronous write to new or existing archive file. A more
detailed description of the these phases is as follows:


read control file to find any un-archived logs



open online red log members to be read



allocate LOG_ARCHIVE_BUFFERS redo buffers



asynchronous read of the online redo log (read size is LOG_ARCHIVE_BUFFER_SIZE)



use alternative redo log members per buffer stream



fill redo log buffers (check if buffers full or at end of log)



if new file needed, create UFS archive file



asynchronous write to the archive files (write size is LOG_ARCHIVE_BUFFER_SIZE)



update control file (modify archive link list and change the status of redo logs)



repeat above steps until finished archiving

Async Read

Archive Log Buffer

Redo
Log
File

Async Write

y
As

Async Read

nc

Wr

ite

Archive
Log
File

Archive Log Buffer

ALTERNATE REDO LOG MEMBERS PER BUFFER STREAM
When an error is encountered in one log, a mask is maintained of all logs and what redo log blocks were attempted to
be retrieved. For an erroneous block, all other logs are read until a good copy of the block is found. If no good copy
of the erroneous block is found, then an error is signaled indicating that archiving failed.
In Release 7.0 and higher, only valid redo blocks are archived. A valid redo log block is a block that must be
archived. (OPS: For parallel server, valid redo log blocks are thread specific and thus must have the appropriate
thread number.) An invalid redo log block does not need to be archived. A corrupted redo log block is a block that
has some error that makes the block not usable in recovery.
ARCH checks the validity of redo headers and redo blocks before copying them to the log archive buffer. If ARCH
encounters a redo log block with the wrong SCN, the future redo is not relevant and archiving is stopped for the
current log. Thus, the archive log file sizes can be less than or equal to the corresponding redo log file sizes.

Oracle Release 7.0

5-7

Archiving Tips and Hints

Technical Reports Compendium II, 1996

REDO LOG AND ARCHIVE FILE CONFIGURATION
Redo log files are heavily written to by LGWR, and read by ARCH (or any process performing recovery). That is,
the disks for redo log files are write intensive and at times read intensive. Generally, there is low contention between
reading and writing. It is recommended that redo log files be Oracle multiplexed or hardware mirrored.
Redo log files should never be placed on the same disks as the archive log files. Ideally, redo log files should be
located on a set of disks separated from all other files. Redo log members, or mirrored files, should be on different
disks and controllers to prevent any single point of failure and to increase throughput. It is recommended that redo
log files be placed on raw disks using a RAID 0+1 configuration (mirroring and fine grain striping). Striping
introduces parallelism to the disk writes. That is, disk writes occur in parallel, which should improve disk write
performance.
Archiving log files must be placed on a User File System (UFS in UNIX) and ideally using a RAID 0+1
configuration. Again, fine grain striping is recommended to improve performance. Archive log files should be on
separate disks than the redo log files.

ARCHIVING TUNING
It is a common and best practice to regularly check for system or I/O contention incurred by archiving. For example,
on some UNIX ports you can use either sari -d or iostat to identify disk bottlenecks. It is recommended that you
check for the following potential bottlenecks: disk queue lengths, CPU waits, CPU usage, and contention at the level
of disks, channels, and controllers.
It is also a common and best practice to regularly check the alert file for the occurrence of unusual events. In the case
of archiving, you should check for archiver busy waits or checkpoint busy waits. If these events occur frequently,
then you consider the tuning methods described in the rest of this section.
Evaluate the number and size of the online redo log: Often, increasing the size and number of online redo log
groups provides more time to archive (and more time to catch up with LGWR). Generally, only adding online redo
logs does not help in a situation where ARCH cannot keep up with LGWR. However, adding online redo logs may
help if there are bursts of redo generation because ARCH has more time to average its processing rate over time.
Evaluate checkpoint interval and frequency: Checkpoint mechanisms are performed independently of the archiving
mechanism. (For example, an online redo log can be archived prior to the log being checkpointed.) However, LGWR
might have to wait on the checkpointing mechanism performed by DBWR or CKPT before re-using an online redo
log. You can alleviate this bottleneck by one or more of the following methods: use multiple DBWRs, increasing
DB_BLOCK_CHECKPOINT_BATCH, reducing DB_BLOCK_BUFFERS, or, by enabling Oracle to use
asynchronous I/O (if supported by the operating system).
Multiple archiver processes: You can initiate extra ARCH processes at fixed intervals to ensure that the automatic
archiving ARCH process does not fall behind LGWR. Typically, you could have scripts running at a regular interval
that issue the ALTER SYSTEM ARCHIVE LOG ALL command. This method is extremely useful in that it allows
several inactive red log to be archived concurrently. When the LOG ALL command is successful, the temporary
ARCH process terminates. (There is an enhancement to allow for multiple automatic ARCH processes. See bug
260126.)
Tune ARCH process: Some sites have seen a 20 to 30 percent performance improvement by changing
LOG_ARCHIVE_BUFFER_SIZE and LOG_ARCHIVE_BUFFERS. Respectively, the maximum value for these
parameters on some ports is 128 and 8. On some platforms, a patch needs to be applied to increase the maximum
value for these parameters. On some ports, release 7.3.2 fixes this limitation.
Check operating system support for asynchronous I/O: Asynchronous reads and writes improve ARCH
performance and should be used if possible. If your platform does not currently support asynchronous I/O, check
with your vendor to see if an upgrade does support the feature.

5-8

Oracle Release 7.0

Technical Reports Compendium II, 1996

Archiving Tips and Hints

ARCHIVING STRATEGY
A successful archiving strategy ensures that all online redo logs are archived and backed up, prevents archiver busy
waits, and reduces recovery time by keeping all archive log files on disk since the last database backup.
Ensure All Online Redo Logs Archived and Backed UP: It is essential to monitor the following: database, archiving
progress, archive destination, and the tape management procedure. Monitoring archiving progress requires
examination of archive trace files and the V$LOG view.
You should never archive a log until the V$LOG column ARCHIVED is set to YES.
Scripts should be written that log onto the database and query V$LOG to build a list of archived log files that must
be backed up to tape. Concurrently, a monitor process should be checking for: space availability in the archive
destination (LOG_ARCHIVE_DEST), disk errors, and tape management errors indicating that an archive file was
not backed up. The tape management procedure should have checksums to ensure that an archive file was
successfully backed up. Error checking and a good reporting too are essential in detecting and resolving archivingtape-backup-restore errors.
ARCH checks the validity of redo headers and block headers data structures. In release 7.3, Oracle provides optional
additional validity checking in the form of a checksum mechanism when redo is copied from the online redo log to
the archive log files. For this feature to work, the initialization parameter LOG_BLOCK_CHECKSUM is set.
OPS Note: All archives from all enabled threads need to be backed up. If you have idle instances, they still create
archive files containing header information that is essential for media recovery.
It is recommended that an ALTER SYSTEM ARCHIVE LOG CURRENT command is used after the successful
completion of an online backup. This command forces all inactive logs including the current logs to be archived. A
successful backup of all database files and these last archive log files, ensure that the backup set can be used
independently if an emergency occurs. For example, the backup set has minimal information required to bring up a
consistent point in time database if recovery attempts fail using newer archived files.
Prevent Archiver Busy Waits: To prevent ARCH busy waits, ARCH should be tuned by adjusting
LOG_ARCHIVE_BUFFERS and LOG_ARCHIVE_BUFFER_SIZE as described in the previous section.
Reduce Recovery Time: Mean time to recovery (MTTR) may be dramatically reduced if archive log files do not
need to be restored from tape. Thus, you should try to keep all archive log files on disk from the last database
backup. Two methods are commonly used, as described in the two following examples.
Multiple Archive Destinations Example -- ARCH writes to DEST1. When DEST1 fills to a certain threshold, say 80
percent to allow for two more archive files, you can switch the archive destination by issuing the ALTER SYSTEM
ARCHIVE LOG TO ’DEST2’. ARCH will then archive the next log or current log (if ARCH is stuck) to the new
destination. Tape backups can be performed while ARCH is writing to DEST2. On a successful backup, the DEST1
archive log files can be purged so that archiving can be switch to DEST1 when DEST2 is 80 percent full. Depending
on available space, you can keep a large number of archive log files on disk. Assuming that DEST1 and DEST2 are
on separate sets of disks, I/O contention will not occur between backup reads and archiving writes.
Single Large Archive Destination Example -- Some sites use one very large archive destination. Scripts are used to
monitor and to log on to the database to determine which archive log files need to be backed up to tape. These
archive log files are backed up as soon as possible. A purging algorithm is used to purge only those archive log files
that were successfully backed up and have a file timestamp that is older than the begin time of the last successful
online database backup. The disadvantage of a single archive destination is that I/O contention will occur between
the backup reads and the archiving writes.

Oracle Release 7.0

5-9

Archiving Tips and Hints

Technical Reports Compendium II, 1996

MONITORING FOR STALE LOGS
Monitoring V$LOG should always check for STALE or INVALID logs. If the logs remain stale, then you should
investigate any possible media problems and relocate or recreate new members to main the level of resiliency for the
logs. Stale logs imply that there are missing writes in the logs. Incomplete logs are deemed as stale logs by Oracle.
You can get stale logs after a shutdown abort, or if LGWR cannot write to a redo log member.
ARCH can easily detect whether there are missing changes in the redo log member when verifying the correctness of
redo log blocks. When detecting a problem, ARCH will search other members for good redo log blocks. ARCH
never complains if an archive log file can be successfully created from the composite information in all online redo
log members, even if ARCH encountered a corrupt redo log block.

PROBLEM SOLVING
For some mission critical systems, especially 7x24 sites, an archiving problem may be extremely alarming. Keep
calm. Deal with the problem in a logical manner to prevent mistakes. Assessing the problem may also require talking
with the user community. It is important to take adequate time to gather all pertinent information, which should
hopefully provide you with a non-damaging resolution. For example, redirecting archiving to another file destination.
The two most common problems encountered are: lack of space in the archive file destination, and archiving being
enabled without an ARCH process running.
When you encounter an archiving problem, you should use the following methodology:


obtain a thorough description of the problem



debugging with archive commands



check the V$ views



check any archive trace files



determine what ARCH is calling



check for platform specific bugs



find a solution to prevent the problem recurring

Debugging with Archive Commands
Using the ALTER SYSTEM ARCHIVE LOG LIST command reveals whether archiving is enabled and whether an
ARCH process is running. You can also determine if there is a database hanging problems by comparing NEXT
LOG TO BE ARCHIVE with the OLDEST REDO LOG SEQUENCE number.
After the LOG LIST command, you can issue an ALTER SYSTEM ARCHIVE LOG [NEXT|ALL|CURRENT]
command, which will usually generate a more understandable error message.

5-10

Oracle Release 7.0

Technical Reports Compendium II, 1996

Archiving Tips and Hints

Check the V$ Views
There are several views that are useful in debugging archiving problems, as follows:


V$LOG



V$DATABASE



V$LOGFILE



V$ARCHIVE

Each of the above views provides a wealth of data useful in solving problems. These views are described in detail in
the Oracle7 Server Reference Manual.
V$LOG -- This view give a lot of information. In particular, you should check the ARCHIVED column to determine
if ARCH is falling behind LGWR.
V$DATABASE -- This view is useful in that column ARCHIVE_CHECKPOINT shows the last SCN archived.
V$LOGFILE -- This view is useful in that you can correlate a problem log with a file name. You should always
check the STATUS column for frequent STALE or INVALID statuses.
V$ARCHIVE -- This view describes all logs from all threads that need archiving. If the number of rows increase
dramatically, then this is an archiving hanging situation, or an archiver perform issue. In this case, issue an ALTER
SYSTEM ARCHIVE LOG ALL command to allow multiple ARCH processes to archive concurrently.

Check Any Archive Trace Files
The alert.log or background trace files may indicate that the current archive destination cannot be written to, possibly
due to lack of disk space. Evaluation of disk hardware must be prompt and preferably automated. Immediate
resolution usually requires freeing up disk space, or re-directing archiving to a different destination. However,
proceed with caution; ensure that archive log files were successfully backed up to tape before purging those archive
log files. Once such a problem is resolved, you must take measures to ensure that the problem can not happen again.

Determine What ARCH is Calling
If there is no I/O contention and ARCH seems too slow, or is hanging, but there is no evidence of error or hardware
problems, it may be necessary to dump the call stack for ARCH. This usually requires the use of an operating system
debugger or oradbx (if available).
Caution: oradbx is not support by Oracle. The utility may have bugs; on some occasions oradbx has killed the
ARCH process. You should always test oradbx prior to using the utility in a production environment. oradbx can
usually be found in $ORACLE_HOME/rdbms/lib. It will be necessary to link and compile the utility using the make
-f oracle.mk oradbx command.

Check for Platform Specific Bugs
It is possible that there are port specific bugs that may be causing archiving bottlenecks. Limitations on
ARCHIVE_LOG_BUFFERS and ARCHIVE_LOG_SIZE are the most common port specific bugs.

Preventing the Problem Recurring
If an archiving problem occurs, it is time to review your archiving procedures. Archive log files should be backed up
to media that can be taken off site. When done properly, archiving should not incur degradation to the performance
of a database.

Oracle Release 7.0

5-11

Archiving Tips and Hints

5-12

Technical Reports Compendium II, 1996

Oracle Release 7.0

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close