Skip to Main Content
  • Questions
  • ARC1: Beginning to archive log# 1 seq# 56947

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, rong.

Asked: November 11, 2001 - 4:33 pm UTC

Last updated: March 10, 2008 - 11:27 am UTC

Version: 8.1.6.1.3

Viewed 1000+ times

You Asked

We have the environment called data storage, from tuesday to saturday, large amount of data inserted into database from 4:00am to 9:00am. we have got errors from alert log off and on:"
Fri Nov 09 08:13:42 2001
ARC2: Beginning to archive log# 2 seq# 56943
ARC2: Failed to archive log# 2 seq# 56943
ARC2: Beginning to archive log# 5 seq# 56944
ARC2: Failed to archive log# 5 seq# 56944
ARC2: Beginning to archive log# 4 seq# 56945
Fri Nov 09 08:13:50 2001
ARC0: Completed archiving log# 2 seq# 56943
Fri Nov 09 08:13:50 2001
ARC3: Beginning to archive log# 5 seq# 56944
ARC3: Failed to archive log# 5 seq# 56944
ARC3: Beginning to archive log# 4 seq# 56945
ARC3: Failed to archive log# 4 seq# 56945
Fri Nov 09 08:13:57 2001
Thread 1 advanced to log sequence 56947
Current log# 1 seq# 56947 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP01A.DBF
Current log# 1 seq# 56947 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP01B.DBF
Fri Nov 09 08:13:57 2001
ARC4: Beginning to archive log# 5 seq# 56944
ARC4: Failed to archive log# 5 seq# 56944
ARC4: Beginning to archive log# 4 seq# 56945
ARC4: Failed to archive log# 4 seq# 56945
ARC4: Beginning to archive log# 3 seq# 56946
Fri Nov 09 08:14:10 2001
Thread 1 advanced to log sequence 56948
Current log# 2 seq# 56948 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP02A.DBF
Current log# 2 seq# 56948 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP02B.DBF
Fri Nov 09 08:14:10 2001
ARC0: Beginning to archive log# 5 seq# 56944
ARC0: Failed to archive log# 5 seq# 56944
ARC0: Beginning to archive log# 4 seq# 56945
ARC0: Failed to archive log# 4 seq# 56945
ARC0: Beginning to archive log# 3 seq# 56946
ARC0: Failed to archive log# 3 seq# 56946
ARC0: Beginning to archive log# 1 seq# 56947
Fri Nov 09 08:14:11 2001
ARC1: Completed archiving log# 5 seq# 56944
ARC1: Beginning to archive log# 4 seq# 56945
ARC1: Failed to archive log# 4 seq# 56945
ARC1: Beginning to archive log# 3 seq# 56946
ARC1: Failed to archive log# 3 seq# 56946
ARC1: Beginning to archive log# 1 seq# 56947
ARC1: Failed to archive log# 1 seq# 56947
Fri Nov 09 08:14:25 2001
Thread 1 advanced to log sequence 56949
Current log# 5 seq# 56949 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP05A.DBF
Current log# 5 seq# 56949 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP05B.DBF
Fri Nov 09 08:14:25 2001
ARC3: Beginning to archive log# 4 seq# 56945
ARC3: Failed to archive log# 4 seq# 56945
ARC3: Beginning to archive log# 3 seq# 56946
ARC3: Failed to archive log# 3 seq# 56946
ARC3: Beginning to archive log# 1 seq# 56947
ARC3: Failed to archive log# 1 seq# 56947
ARC3: Beginning to archive log# 2 seq# 56948
Fri Nov 09 08:14:26 2001
ARC2: Completed archiving log# 4 seq# 56945
Fri Nov 09 08:14:27 2001
ARC1: Beginning to archive log# 3 seq# 56946
ARC1: Failed to archive log# 3 seq# 56946
ARC1: Beginning to archive log# 1 seq# 56947
ARC1: Failed to archive log# 1 seq# 56947
ARC1: Beginning to archive log# 2 seq# 56948
ARC1: Failed to archive log# 2 seq# 56948
Fri Nov 09 08:14:41 2001
Thread 1 advanced to log sequence 56950
Current log# 4 seq# 56950 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP04A.DBF
Current log# 4 seq# 56950 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP04B.DBF
Fri Nov 09 08:14:42 2001
ARC2: Beginning to archive log# 3 seq# 56946
ARC2: Failed to archive log# 3 seq# 56946
ARC2: Beginning to archive log# 1 seq# 56947
ARC2: Failed to archive log# 1 seq# 56947
ARC2: Beginning to archive log# 2 seq# 56948
ARC2: Failed to archive log# 2 seq# 56948
ARC2: Beginning to archive log# 5 seq# 56949
Fri Nov 09 08:14:46 2001
ARC4: Completed archiving log# 3 seq# 56946
ARC4: Beginning to archive log# 1 seq# 56947
ARC4: Failed to archive log# 1 seq# 56947
ARC4: Beginning to archive log# 2 seq# 56948
ARC4: Failed to archive log# 2 seq# 56948
ARC4: Beginning to archive log# 5 seq# 56949
ARC4: Failed to archive log# 5 seq# 56949
Fri Nov 09 08:14:56 2001
Thread 1 advanced to log sequence 56951
Current log# 3 seq# 56951 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP03A.DBF
Current log# 3 seq# 56951 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP03B.DBF
Fri Nov 09 08:14:56 2001
ARC1: Beginning to archive log# 1 seq# 56947
ARC1: Failed to archive log# 1 seq# 56947
ARC1: Beginning to archive log# 2 seq# 56948
ARC1: Failed to archive log# 2 seq# 56948
ARC1: Beginning to archive log# 5 seq# 56949
ARC1: Failed to archive log# 5 seq# 56949
ARC1: Beginning to archive log# 4 seq# 56950
Fri Nov 09 08:15:05 2001
ARC0: Completed archiving log# 1 seq# 56947
Fri Nov 09 08:15:05 2001
ARC4: Beginning to archive log# 2 seq# 56948
ARC4: Failed to archive log# 2 seq# 56948
ARC4: Beginning to archive log# 5 seq# 56949
ARC4: Failed to archive log# 5 seq# 56949
ARC4: Beginning to archive log# 4 seq# 56950
ARC4: Failed to archive log# 4 seq# 56950
Fri Nov 09 08:15:11 2001
Thread 1 advanced to log sequence 56952
Current log# 1 seq# 56952 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP01A.DBF
Current log# 1 seq# 56952 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP01B.DBF
Fri Nov 09 08:15:11 2001
ARC0: Beginning to archive log# 2 seq# 56948
ARC0: Failed to archive log# 2 seq# 56948
ARC0: Beginning to archive log# 5 seq# 56949
ARC0: Failed to archive log# 5 seq# 56949
ARC0: Beginning to archive log# 4 seq# 56950
ARC0: Failed to archive log# 4 seq# 56950
ARC0: Beginning to archive log# 3 seq# 56951
Fri Nov 09 08:15:21 2001
ARC3: Completed archiving log# 2 seq# 56948
ARC3: Beginning to archive log# 5 seq# 56949
ARC3: Failed to archive log# 5 seq# 56949
ARC3: Beginning to archive log# 4 seq# 56950
ARC3: Failed to archive log# 4 seq# 56950
ARC3: Beginning to archive log# 3 seq# 56951
ARC3: Failed to archive log# 3 seq# 56951
Fri Nov 09 08:15:27 2001
Thread 1 advanced to log sequence 56953
Current log# 2 seq# 56953 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP02A.DBF
Current log# 2 seq# 56953 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP02B.DBF
Fri Nov 09 08:15:27 2001
ARC4: Beginning to archive log# 5 seq# 56949
ARC4: Failed to archive log# 5 seq# 56949
ARC4: Beginning to archive log# 4 seq# 56950
ARC4: Failed to archive log# 4 seq# 56950
ARC4: Beginning to archive log# 3 seq# 56951
ARC4: Failed to archive log# 3 seq# 56951
ARC4: Beginning to archive log# 1 seq# 56952
Fri Nov 09 08:15:37 2001
ARC2: Completed archiving log# 5 seq# 56949
ARC2: Beginning to archive log# 4 seq# 56950
ARC2: Failed to archive log# 4 seq# 56950
ARC2: Beginning to archive log# 3 seq# 56951
ARC2: Failed to archive log# 3 seq# 56951
ARC2: Beginning to archive log# 1 seq# 56952
ARC2: Failed to archive log# 1 seq# 56952
Fri Nov 09 08:15:43 2001
Thread 1 advanced to log sequence 56954
Current log# 5 seq# 56954 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP05A.DBF
Current log# 5 seq# 56954 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP05B.DBF
Fri Nov 09 08:15:43 2001
ARC3: Beginning to archive log# 4 seq# 56950
ARC3: Failed to archive log# 4 seq# 56950
ARC3: Beginning to archive log# 3 seq# 56951
ARC3: Failed to archive log# 3 seq# 56951
ARC3: Beginning to archive log# 1 seq# 56952
ARC3: Failed to archive log# 1 seq# 56952
ARC3: Beginning to archive log# 2 seq# 56953
Fri Nov 09 08:15:49 2001
ARC1: Completed archiving log# 4 seq# 56950
ARC1: Beginning to archive log# 3 seq# 56951
ARC1: Failed to archive log# 3 seq# 56951
ARC1: Beginning to archive log# 1 seq# 56952
ARC1: Failed to archive log# 1 seq# 56952
ARC1: Beginning to archive log# 2 seq# 56953
ARC1: Failed to archive log# 2 seq# 56953
Fri Nov 09 08:15:59 2001
Thread 1 advanced to log sequence 56955
Current log# 4 seq# 56955 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP04A.DBF
Current log# 4 seq# 56955 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP04B.DBF
Fri Nov 09 08:15:59 2001
ARC2: Beginning to archive log# 3 seq# 56951
ARC2: Failed to archive log# 3 seq# 56951
ARC2: Beginning to archive log# 1 seq# 56952
ARC2: Failed to archive log# 1 seq# 56952
ARC2: Beginning to archive log# 2 seq# 56953
ARC2: Failed to archive log# 2 seq# 56953
ARC2: Beginning to archive log# 5 seq# 56954
Fri Nov 09 08:16:14 2001
ARC1: Beginning to archive log# 3 seq# 56951
ARC1: Failed to archive log# 3 seq# 56951
ARC1: Beginning to archive log# 1 seq# 56952
ARC1: Failed to archive log# 1 seq# 56952
Fri Nov 09 08:16:14 2001
Thread 1 cannot allocate new log, sequence 56956
All online logs needed archiving
Current log# 4 seq# 56955 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP04A.DBF
Current log# 4 seq# 56955 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP04B.DBF
Fri Nov 09 08:16:14 2001
ARC1: Beginning to archive log# 2 seq# 56953
ARC1: Failed to archive log# 2 seq# 56953
ARC1: Beginning to archive log# 5 seq# 56954
ARC1: Failed to archive log# 5 seq# 56954
ARC1: Beginning to archive log# 3 seq# 56951
ARC1: Failed to archive log# 3 seq# 56951
ARC1: Beginning to archive log# 1 seq# 56952
ARC1: Failed to archive log# 1 seq# 56952
ARC1: Beginning to archive log# 2 seq# 56953
ARC1: Failed to archive log# 2 seq# 56953
ARC1: Beginning to archive log# 5 seq# 56954
ARC1: Failed to archive log# 5 seq# 56954
Fri Nov 09 08:16:15 2001
ARC0: Completed archiving log# 3 seq# 56951
ARC0: Beginning to archive log# 1 seq# 56952
ARC0: Failed to archive log# 1 seq# 56952
ARC0: Beginning to archive log# 2 seq# 56953
ARC0: Failed to archive log# 2 seq# 56953
ARC0: Beginning to archive log# 5 seq# 56954
ARC0: Failed to archive log# 5 seq# 56954
Fri Nov 09 08:16:16 2001
Thread 1 advanced to log sequence 56956
Current log# 3 seq# 56956 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP03A.DBF
Current log# 3 seq# 56956 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP03B.DBF
Fri Nov 09 08:16:16 2001
ARC1: Beginning to archive log# 1 seq# 56952
ARC1: Failed to archive log# 1 seq# 56952
ARC1: Beginning to archive log# 2 seq# 56953
ARC1: Failed to archive log# 2 seq# 56953
ARC1: Beginning to archive log# 5 seq# 56954
ARC1: Failed to archive log# 5 seq# 56954
ARC1: Beginning to archive log# 4 seq# 56955
Fri Nov 09 08:16:31 2001
Thread 1 cannot allocate new log, sequence 56957
All online logs needed archiving
Current log# 3 seq# 56956 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP03A.DBF
Current log# 3 seq# 56956 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP03B.DBF
Fri Nov 09 08:16:31 2001
ARC0: Beginning to archive log# 1 seq# 56952
ARC0: Failed to archive log# 1 seq# 56952
ARC0: Beginning to archive log# 2 seq# 56953
ARC0: Failed to archive log# 2 seq# 56953
ARC0: Beginning to archive log# 5 seq# 56954
ARC0: Failed to archive log# 5 seq# 56954
ARC0: Beginning to archive log# 4 seq# 56955
ARC0: Failed to archive log# 4 seq# 56955
ARC0: Beginning to archive log# 1 seq# 56952
ARC0: Failed to archive log# 1 seq# 56952
ARC0: Beginning to archive log# 2 seq# 56953
ARC0: Failed to archive log# 2 seq# 56953
ARC0: Beginning to archive log# 5 seq# 56954
ARC0: Failed to archive log# 5 seq# 56954
ARC0: Beginning to archive log# 4 seq# 56955
ARC0: Failed to archive log# 4 seq# 56955
Fri Nov 09 08:16:34 2001
ARC4: Completed archiving log# 1 seq# 56952
Fri Nov 09 08:16:34 2001
Thread 1 advanced to log sequence 56957
Current log# 1 seq# 56957 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP01A.DBF
Current log# 1 seq# 56957 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP01B.DBF
Fri Nov 09 08:16:34 2001
ARC0: Beginning to archive log# 2 seq# 56953
ARC0: Failed to archive log# 2 seq# 56953
Fri Nov 09 08:16:34 2001
ARC4: Beginning to archive log# 2 seq# 56953
ARC4: Failed to archive log# 2 seq# 56953
ARC4: Beginning to archive log# 5 seq# 56954
Fri Nov 09 08:16:34 2001
ARC0: Beginning to archive log# 5 seq# 56954
Fri Nov 09 08:16:34 2001
ARC0: Failed to archive log# 5 seq# 56954
ARC0: Beginning to archive log# 4 seq# 56955
ARC0: Failed to archive log# 4 seq# 56955
ARC0: Beginning to archive log# 3 seq# 56956
Fri Nov 09 08:16:35 2001
ARC4: Failed to archive log# 5 seq# 56954
Fri Nov 09 08:16:35 2001
ARC4: Beginning to archive log# 4 seq# 56955
ARC4: Failed to archive log# 4 seq# 56955
ARC4: Beginning to archive log# 3 seq# 56956
ARC4: Failed to archive log# 3 seq# 56956
Fri Nov 09 08:16:49 2001
Thread 1 cannot allocate new log, sequence 56958
All online logs needed archiving
Current log# 1 seq# 56957 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP01A.DBF
Current log# 1 seq# 56957 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP01B.DBF
Fri Nov 09 08:16:49 2001
ARC4: Beginning to archive log# 2 seq# 56953
ARC4: Failed to archive log# 2 seq# 56953
ARC4: Beginning to archive log# 5 seq# 56954
ARC4: Failed to archive log# 5 seq# 56954
ARC4: Beginning to archive log# 4 seq# 56955
ARC4: Failed to archive log# 4 seq# 56955
ARC4: Beginning to archive log# 3 seq# 56956
ARC4: Failed to archive log# 3 seq# 56956
Fri Nov 09 08:16:50 2001
ARC3: Completed archiving log# 2 seq# 56953
ARC3: Beginning to archive log# 5 seq# 56954
ARC3: Failed to archive log# 5 seq# 56954
ARC3: Beginning to archive log# 4 seq# 56955
ARC3: Failed to archive log# 4 seq# 56955
ARC3: Beginning to archive log# 3 seq# 56956
ARC3: Failed to archive log# 3 seq# 56956
Fri Nov 09 08:16:50 2001
Thread 1 advanced to log sequence 56958
Current log# 2 seq# 56958 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP02A.DBF
Current log# 2 seq# 56958 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP02B.DBF
Fri Nov 09 08:16:50 2001
ARC4: Beginning to archive log# 5 seq# 56954
ARC4: Failed to archive log# 5 seq# 56954
ARC4: Beginning to archive log# 4 seq# 56955
ARC4: Failed to archive log# 4 seq# 56955
ARC4: Beginning to archive log# 3 seq# 56956
ARC4: Failed to archive log# 3 seq# 56956
ARC4: Beginning to archive log# 1 seq# 56957
Fri Nov 09 08:17:04 2001
ARC2: Completed archiving log# 5 seq# 56954
ARC2: Beginning to archive log# 4 seq# 56955
ARC2: Failed to archive log# 4 seq# 56955
ARC2: Beginning to archive log# 3 seq# 56956
ARC2: Failed to archive log# 3 seq# 56956
ARC2: Beginning to archive log# 1 seq# 56957
ARC2: Failed to archive log# 1 seq# 56957
Fri Nov 09 08:17:09 2001
Thread 1 advanced to log sequence 56959
Current log# 5 seq# 56959 mem# 0: I:\DATA\ORADATA\DFWP\LOGDFWP05A.DBF
Current log# 5 seq# 56959 mem# 1: K:\DATA\ORADATA\DFWP\LOGDFWP05B.DBF
Fri Nov 09 08:17:09 2001
ARC3: Beginning to archive log# 4 seq# 56955
ARC3: Failed to archive log# 4 seq# 56955
ARC3: Beginning to archive log# 3 seq# 56956
ARC3: Failed to archive log# 3 seq# 56956
ARC3: Beginning to archive log# 1 seq# 56957
ARC3: Failed to archive log# 1 seq# 56957
ARC3: Beginning to archive log# 2 seq# 56958
Fri Nov 09 08:17:11 2001
ARC1: Completed archiving log# 4 seq# 56955
ARC1: Beginning to archive log# 3 seq# 56956
ARC1: Failed to archive log# 3 seq# 56956
ARC1: Beginning to archive log# 1 seq# 56957
ARC1: Failed to archive log# 1 seq# 56957
ARC1: Beginning to archive log# 2 seq# 56958
ARC1: Failed to archive log# 2 seq# 56958
Fri Nov 09 08:17:24 2001
ARC0: Completed archiving log# 3 seq# 56956
Fri Nov 09 08:17:24 2001
ARC2: Beginning to archive log# 1 seq# 56957
ARC2: Failed to archive log# 1 seq# 56957
ARC2: Beginning to archive log# 2 seq# 56958
ARC2: Failed to archive log# 2 seq# 56958
Fri Nov 09 08:17:31 2001
ARC4: Completed archiving log# 1 seq# 56957
ARC4: Beginning to archive log# 2 seq# 56958
ARC4: Failed to archive log# 2 seq# 56958"
====================================================================
THERE ARE FOLLLOWING PARAMETERS SET IN INIT.ORA FILE:
log_archive_dest = J:\DATA\ORADATA\DFWP\ARCHLOGS
log_archive_max_processes = 5
log_buffer = 9437184
log_archive_format = log_dfwp_%S.arc

online log files are located @ i:\data\oradata\dfwp\, and k:\data\oradata\dfwp\
====================================================================
HERE IS THE INITDFWP.ORA FILE:
#####################################################
# Initdfwp.ora Revised 12/01/98 S.M. Lawrence
# Revised 07/14/99 P. Cappabianca Data Warehouse changes
# 05/21/01 P. Cappabianca RBS changes
# 06/22/01
# increased log buffer from 65536 to 9437184
# 06/22/01 P. Cappabianca Timed_statistics to true
# 06/29/01 P. Cappabianca added log_archive_max_processes
#####################################################

# audit_trail = true # if you want auditing
background_dump_dest=D:\DATA\ORADBA\ADMIN\DFWP\BDUMP
control_files = D:\APPS\ORA8i\DATABASE\ctl1DFWP.ORA
control_files = J:\DATA\ORADATA\DFWP\ctl2DFWP.ORA
control_files = K:\DATA\ORADATA\DFWP\ctl3DFWP.ORA
cursor_space_for_time = TRUE
db_block_buffers = 231000
# do NOT change the below value
db_block_size = 8192
# do NOT change the above value
db_file_multiblock_read_count = 8 # pjc 7/20/00 parallel tuning, was 32
#DB_FILE_SIMULTANEOUS_WRITES = 16
db_files = 1024 # pjc 3/6/00 set to maxdatafiles
db_name = dfwp
dml_locks = 500 # INITIAL
# sml added 12 01 98 to override the default value 73XX
enqueue_resources = 9000
# event="471 trace name errorstack level 10"
# event="10235 trace name context forever, level 1"
hash_area_size = 16384000 # pjc 7/20/00 increased from 4096000
hash_join_enabled = TRUE # pjc 7/20/00 parallel tuning, was FALSE
hash_multiblock_io_count = 4 # pjc 7/20/00 parallel tuning, was 2
log_archive_start = true # if you want automatic archiving
log_archive_dest = J:\DATA\ORADATA\DFWP\ARCHLOGS
log_archive_max_processes = 5
log_archive_format = log_dfwp_%S.arc
log_buffer = 9437184
# write 400 blocks then do a checkpoint
# 4096 block size x 400 div 2 plus 1 equals 819201
log_checkpoint_interval = 819201
#LOG_SIMULTANEOUS_COPIES = 8
max_dump_file_size = 10240 # limit trace file size to 5 Meg each
max_rollback_segments = 100
# nls_data_format added 11/21/99
nls_date_format = "DD-MON-RR"
open_cursors = 1000
#partition_view_enabled = TRUE
pre_page_sga = TRUE
# processes = 3500 # see parallel_automatic_tuning 40+6+5(4*4)=816
# Pat O changed remote_login_passwordfile = EXCLUSIVE 11/21/00
remote_login_passwordfile = EXCLUSIVE
#rollback_segments = (rseg01_01,rseg01_02,rseg01_03,rseg01_04,rseg01_05,rseg01_06,rseg01_07,rseg01_08,rseg01_09,rseg01_10)
shared_pool_reserved_size = 22500000
shared_pool_size = 45000000
sort_area_size=8192000
sort_area_retained_size=8192000
timed_statistics = true # if you want timed statistics
user_dump_dest=D:\DATA\ORADBA\ADMIN\DFWP\UDUMP
#JOB_QUEUE_PROCESSES = 3
#Parameter added by Data Migration Assistant
compatible = 8.1.6 # updated 6/13/2000 PJC enable transportable TS
db_domain = world
# Parallel Tuning pjc 7/20/00
parallel_automatic_tuning = TRUE
optimizer_percent_parallel = 10 # 100/# concurrent_users
transactions = 942 # default 1.1 * PROCESSES + 5 = 902
transactions_per_rollback_segment=98 #5/22/01 # rbs started=trans/trans_per_rbs (98 is max value)

=====================================================================
MY QUESTION IS WHAT WE CAN DO TO ELIMINATE ABOVE "ARC2: Failed to archive log# 2 seq# XXXX" to happen?

I have set LOG_ARCHIVE_TRACE =95, if you want, I can email you the trace file it generated for the last 2 days.


and Tom said...

It is just a side effect of having more then one archiver.

If automatic archiving is turned on then all of the archiver process will try
to archive this logfile, however they will not be able to aquire the lock 'kcrrlt',
the lock to protect multiple arch processes from archiving the same logfile.

The failing process process will write to the trace/alert message that it was
unable to archive the logfile.

The file is successfully archived by some other process.

In 9i, this message is a little more informative:

ARC1: Beginning to archive log# 2 thrd# 1 seq# 24
ARC1: Unable to archive log# 2 thrd# 1 seq# 24
Log actively being archived by another process



Rating

  (30 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Bhadresh Patel, January 04, 2002 - 1:48 am UTC

It's totally a different case you have answered. This is tmporarily solution. I'm also facing a same problem. Give me suggession for permanent solution.

1) I have added one more redo log file with mirror image but still problem is coming. So If I'll increase the size of all redo log files by creating a new redo log files and dropping the existing files. will it solve my problem? If not, please suggest other permanent solution.

Please give me the answer as soon as possibe.
Thanks & regards
bhadresh




Tom Kyte
January 04, 2002 - 8:09 am UTC

I don't believe you read the answer so I'll repeat it:

It is just a side effect of having more then one archiver.

If automatic archiving is turned on then all of the archiver process will try
to archive this logfile, however they will not be able to aquire the lock
'kcrrlt',
the lock to protect multiple arch processes from archiving the same logfile.

The failing process process will write to the trace/alert message that it was
unable to archive the logfile.

The file is successfully archived by some other process.

In 9i, this message is a little more informative:

ARC1: Beginning to archive log# 2 thrd# 1 seq# 24
ARC1: Unable to archive log# 2 thrd# 1 seq# 24
Log actively being archived by another process


-------------------------------------------------------

You see, this is a benign, harmless warning. I offered no "temporary" (or permanent or in fact ANY) solution here -- its just a harmless warning.


adding more redo's, having them mirrored -- that won't make it "go away". You want it to go away -- use one archiver process only.

Similar problem

Mikel Jurisich, January 04, 2002 - 8:42 am UTC

Hi Tom,

I too have noticed this problem. I'd determined that it wasn't a problem as you say, but thought I'd try to prevent it being generated by limiting each db to one archiver process via the log_archive_max_processes init.ora parameter - as my understanding of this was that it controls the max no. allowed. But setting this is one was - during heavy periods - still triggering the automatic startup of another archiver process leaving me with two running despite the parameter saying only one should be allowed.

Any thoughts on how to ensure only one archiver process is running - and why this parameter doesn't do what I thought it should be doing?

Cheers,

Mikel

Tom Kyte
January 04, 2002 - 9:37 am UTC

This is fixed in 9.0.1, it appears to have been back ported to 817.x as well. Contact support, reference bug1921532

Jeff Hunter, January 04, 2002 - 2:47 pm UTC

I love it! You should re-title this to "How to impact the performance of your database so your alert.logs look cleaner."

Why only sometimes?

Venky Dev, December 18, 2002 - 7:01 pm UTC

I have 5 arc processes running. I see the "failed to archive" only sometimes and not all the time a redo log is archived. I would expect based on your answer to happen every time. Why does it happen only sometimes?

Tom Kyte
December 19, 2002 - 7:22 am UTC

because only sometimes do they go for the same file at the same time.

Automatic archiving not restarting

kumar, April 21, 2003 - 1:55 am UTC

Tom,

We have an oracle 8.1.7 database on Win NT. When there is no diskspace available for automatic archiving, the archiver process records an error in the alert log file and the db stops responding. Even after I make the space available by clearing the files, the archiver continues to give the same error message. Accoring the Oracle Server Admin Guide, it has to restart archiving automatically once the space is made available. Why is this not happening ?
Also REOPEN_SECS from v$archive_dest shows 0. But the still the archiver tries every 5 mins - which according to the manual is default. Why is this not displayed in the V$archive_dest ? Is there some other view to see this info?

Tom Kyte
April 21, 2003 - 7:19 am UTC

I'll let you contact support for this one. It gets "unstuck" for me, always has.

I can only guess that not enough space was cleared perhaps.

did you try kickstarting it with alter database archivelog all after clearing space.

Manual Archiving also gives the error

kumar, April 21, 2003 - 10:57 pm UTC

Tom,

I failed to mention one thing in my last posting. That, when I shutdown the instance and re-started it the archiver started archiving without further errors. When I got the problem and after clearing the space, I tried manual archiving also. It did not help - gave the same error. The STATUS column of v$archive_dest showed the status as 'ERROR' once the problem occured and remained so until I re-started the instance.

Thanks for the response.

Tom Kyte
April 22, 2003 - 7:36 am UTC

they i would suspect your "clearing" process -- how did you do it, did it really work -- did you verify the OS thought "there is free space" (and you HAVE filed a TAR right)

Got the solution

kumar, April 23, 2003 - 6:50 am UTC

Tom,

Thanks for the response. It took some time for me to get the access details for the metalink. I could find some threads over there on the same problem. They have suggested various solutions. I recreated the problem and tried them. One of the solution worked for me. I am giving that one here in case some one else needs it. After making enough space available, I gave the following commands
ALTER SYSTEM ARCHIVE LOG STOP;
ALTER SYSTEM ARCHIVE LOG START;
Now it started the archiving process.

Now i have one small doubt - will the above steps affect the recovery process in case i need to do media recovery in future ?

Tom Kyte
April 23, 2003 - 7:36 am UTC

No they will not.

i thought there was something wrong with the archiving process!

Alvin, May 05, 2003 - 11:54 pm UTC

Tnx for the clarification !

Btw, how would i know how many archiving proccess running and how do i increase /decrease them ?


ARC4: Failed to archive....

does this mean that i have around 4 ??

Tom Kyte
May 06, 2003 - 7:44 am UTC

select program from v$process where program like '%(ARC_)%'


it'll start them as it needs them. you can set log_archive_max_processes to some degree as well.

Free 'kcrrlt' lock

JHT, March 30, 2004 - 2:49 pm UTC

Thanks Tom for all the good information. I have a similar problem is that an archiver died abornormally and must have left this "kcrrlt" lock on one of my redo logs #3 (I'm getting the "log actively being archived by another process"). Now, I cannot get a new archiver to archive this log #3. The db is smoothly running and switching log files, but it always skips this log #3 because this log is not yet archived. How would I get rid of this lock and start using #3 again. I'm guessing bouncing the DB will probably clear the lock, but it's a production system. Thanks.

Tom Kyte
March 30, 2004 - 6:23 pm UTC

it would not skip it, it would get *stuck*. lgwr would try to advance into this log file and just halt the database until it was archived.

Something else is going on there.

Free 'kcrrlt' lock

JHT, March 30, 2004 - 11:26 pm UTC

Thanks Tom, but what else could be going on here? Maybe some additional information will be helpful. The 9.2.0.3 primary database is also archiving redo logs to a standby database. The standby database server was down for an extended period of time. I see from the alert logs that the primary archiver is getting the ORA-3113 (end-of-communication) to the standby db...that is expected. But because the standby archive destination is optional, the db continues to run fine.

As expected, the alert logs shows a lot of "Log actively being archived by another process", as I have 2 archivers. Of course, after one mention of this error for a redo log, alert.log shows a "Completed archiving".

Finally, the 4 redo log groups are being switch in a round robin format as expected, even as the archiver is failing with ORA-3113 when archiving to the standby database.

Then all of a sudden, alert.log complains about redo log #3 with "Log actively being archived by another process" continuously. As before, the other 3 redo log groups get this error once and then "completed archiving". When I executed "alter system switch logfile", the alert.log file shows that oracle switches logs fine but it leaves log #3 out of the rotation. In the meantime, alert.log still complains about log #3 with the "Log actively being archived by another process".

When I execute a "alter system archive log current" or "alter system archive log all", the command hangs, as oracle cannot archive log #3. I have tried to restart the archivers with "alter system archive log stop" and "alter system archive log start", but it doesn't resolve the problem. I have also tried to change the number of archivers down to 1 with the "max_archive_processes" (forgot the exact parameter name), but to no avail.


Tom Kyte
March 31, 2004 - 8:32 am UTC

Please contact support for this. They'll extract the relevant information they need to diagnose if there is a problem or not.

Archived File Size

DBA, May 21, 2004 - 1:56 am UTC

Hi,


                  Using 8.1.7 on Sun Sparc 64bit
             ----------------------------------------

Our redo log size is 750 mb. V$archived log is showing
archived log for sequence 224 and 225 should be of 750 mb.
But at os level it shows 0 bytes.
   

SQL> r
  1  select sequence#, name,blocks,block_size from
  2* v$archived_log where recid between  223 and 225

 SEQUENCE# NAME                               BLOCKS BLOCK_SIZE
---------- ------------------------------ ---------- ----------
       223 /data9/arch/log223.arc            1536000        512
       224 /data9/arch/log224.arc            1536000        512
       225 /data9/arch/log225.arc            1536000        512

-------------------- A L E R T  F I L E -------------------------


This is our alert file. I noticed that after compeleting archive deadlock occured. Is this happening due to deadlock or there is another reason.



ARC0: Completed archiving log# 13 seq# 223
Thu May 20 19:35:49 2004
Thread 1 advanced to log sequence 225
Thu May 20 19:35:49 2004
ARC2: Beginning to archive log# 14 seq# 224
Thu May 20 19:35:49 2004
  Current log# 12 seq# 225 mem# 0: /data12/oradata/lgeil/redolog12a.rdo
Thu May 20 19:36:45 2004
ARC2: Completed archiving log# 14 seq# 224
Thu May 20 20:01:55 2004
ORA-000060: Deadlock detected. More info in file /oracle/home/admin/lgeil/udump/lgeil_ora_21946.trc.
Thu May 20 20:02:22 2004
Thread 1 advanced to log sequence 226
  Current log# 11 seq# 226 mem# 0: /data5/oradata/lgeil/redolog11a.rdo
Thu May 20 20:02:22 2004
ARC1: Beginning to archive log# 12 seq# 225
Thu May 20 20:02:39 2004
ORA-000060: Deadlock detected. More info in file /oracle/home/admin/lgeil/udump/lgeil_ora_21946.trc.
Thu May 20 20:03:19 2004
ARC1: Completed archiving log# 12 seq# 225
Thu May 20 20:34:26 2004
Thread 1 advanced to log sequence 227
Thu May 20 20:34:26 2004
ARC0: Beginning to archive log# 11 seq# 226


and how can we find the involved objects and statements 
cause the deadlock. 

Tom Kyte
May 21, 2004 - 9:56 am UTC

see the trace file for deadlock details (lots of notes on this site as well as metalink on them)


the deadlock is nothing to do with arch, the deadlock is your application.


if you are getting 0 length archives, that would be "a problem" and you'd need to get in touch with support ASAP to determine the root cause.

Manual archiving

Anil Pant, August 25, 2004 - 4:56 am UTC

Tom, In which anyone would go for manual archiving ?

Tom Kyte
August 25, 2004 - 7:43 am UTC

not sure that they would. I guess you'd know you wanted to if you wanted to.

How t o get rid of extra archive process

Sean, August 27, 2004 - 3:04 pm UTC

We used to get this kind of error in alert file (920, Solaris 9) while we had only one member in each log group but with multiple log_archive_dest:

-------------------------------------------------------------
-- Part of text in Alert file
Thu Aug 26 16:43:36 2004
ARC0: Evaluating archive   log 1 thread 1 sequence 13535
ARC0: Unable to archive log 1 thread 1 sequence 13535
      Log actively being archived by another process
Thu Aug 26 16:43:36 2004
ARCH: Beginning to archive log 1 thread 1 sequence 13535
--------------------------------------------------------------


But now we only use one log_archive_dest.  But we still got this error sometimes.  I guess that we still have two archive process running according to the answer in this thread.  How do I deal with it without shutting down the db?  Juse use OS to kill one process?


----------------------------------------------------------------
-- Part of text in pfile
*.log_archive_dest_1='LOCATION=/u01/oradata/cbprod/archive mandatory'
*.log_archive_dest_2=''
*.log_archive_dest_3=''
-----------------------------------------------------------------



-----------------------------------------------------------------------
SQL> select program from v$process where program like '%(ARC_)%'
  2  ;
PROGRAM
------------------------------------------------
oracle@orcl (ARC0)
oracle@orcl (ARC1)

SQL>show parameter archive

log_archive_max_processes
integer
2

---------------------------------------------------------------------------


Thanks so much for your help.






 

Tom Kyte
August 27, 2004 - 3:07 pm UTC

what is to deal with?

it is perfectly OK.

extra archive process

Sean, August 27, 2004 - 3:29 pm UTC

Thanks so much

But it will be easier for me to glance over alert file if there is no such 'unable things'. Now every time I read unable things, I have to look at it more carefully to make sure this unable thing is the one which is 'OK'.

Tom Kyte
August 27, 2004 - 3:44 pm UTC

you would set the log_archive_max_processes down  


alter system set log_archive_max_processes =1;


ops$tkyte@ORA9IR2> !ps -auxww | grep -i arc
ora9ir2  10842  0.0  0.3 229660 6856 ?       S    15:31   0:00 ora_arc0_ora9ir2
ora9ir2  10844  0.0  0.3 229812 7016 ?       S    15:31   0:00 ora_arc1_ora9ir2
ora9ir2  10846  0.1  0.3 229652 6844 ?       S    15:31   0:00 ora_arc2_ora9ir2
ora9ir2  10848  0.0  0.3 229652 6852 ?       S    15:31   0:00 ora_arc3_ora9ir2
ora9ir2  10850  0.0  0.3 229648 6848 ?       S    15:31   0:00 ora_arc4_ora9ir2
tkyte    10857  0.0  0.0  4200  992 pts/0    S    15:31   0:00 /bin/bash -c ps -auxww | grep -i arc
tkyte    10859  0.0  0.0  3680  664 pts/0    S    15:31   0:00 grep -i arc
 
ops$tkyte@ORA9IR2> alter system set log_archive_max_processes=1;
 
System altered.
 
ops$tkyte@ORA9IR2> !ps -auxww | grep -i arc
ora9ir2  10850  0.0  0.3 229648 6848 ?       S    15:31   0:00 ora_arc4_ora9ir2
tkyte    10860  0.0  0.0  4212  988 pts/0    S    15:31   0:00 /bin/bash -c ps -auxww | grep -i arc
tkyte    10862  0.0  0.0  3680  664 pts/0    S    15:31   0:00 grep -i arc
 
 

Online redo log multiplexing

Logan Palanisamy, August 27, 2004 - 4:46 pm UTC

Sean,

You said "We used to get this kind of error in alert file (920, Solaris 9) while we had only one member in each log group ..."

So, you have a bigger risk in running with only one member per redo log group. If it is production system, you should have a mininum of 2 members per group, each on a separate disk.


Multiplexing online redo logs is as important as running in Archive log mode for production systems.



Our disks are in RAID 5

Sean, August 27, 2004 - 8:40 pm UTC

Hi Logan,

Very good point. I am not sure whether we still need multiple members of log group if the system is in RAID. Tom, what do you think?

Thanks so much.

Tom Kyte
August 28, 2004 - 9:36 am UTC

it is best to allow Oracle to mirror the redo information - to perform the two writes by itself.

raid 01/10 will instantly mirror corruptions
raid 5 isn't excessively "highly available and fast for writes"



multiple arch processes

Sean, August 28, 2004 - 2:37 pm UTC

Hi Tom,

After I issued "alter system set log_archive_max_processes=1", arch0 process shutdown and only arch1 exists.  But somehow now there is a mystirious arch process (without number attached to it) which sometimes doing arching and sometimes is unable to access to logfile.

Thanks so much for your help

------------------------------------------------------------
fluke:/export/home/oracle/9.2.0/admin/cbprod2/bdump: ps -ef | grep oracle | gre
p arc
  oracle  1135     1  0   Aug 24 ?       17:11 ora_arc1_cbprod2
  oracle 10939 10901  0 14:12:00 pts/9    0:00 grep arc
fluke:/export/home/oracle/9.2.0/admin/cbprod2/bdump:



SQL> select program from v$process where program like '%(ARC_)%';

PROGRAM
------------------------------------------------
oracle@fluke (ARC1)

SQL>
------------------------------------------------------------


------------------------------------------------------------
-- From part of alert file
Sat Aug 28 04:35:58 2004
ARC1: Evaluating archive   log 4 thread 1 sequence 13600
ARC1: Beginning to archive log 4 thread 1 sequence 13600
Creating archive destination LOG_ARCHIVE_DEST_1: '/u01/oradata/cbprod/archive/1_
13600.dbf'
Sat Aug 28 04:35:58 2004
Thread 1 advanced to log sequence 13601
  Current log# 2 seq# 13601 mem# 0: /u04/oradata/cbprod/redo/logCBPROD22.ora
Sat Aug 28 04:36:15 2004
ARCH: Evaluating archive   log 4 thread 1 sequence 13600
ARCH: Unable to archive log 4 thread 1 sequence 13600
      Log actively being archived by another process
Sat Aug 28 04:36:16 2004
Beginning log switch checkpoint up to RBA [0x3522.2.10], SCN: 0x0004.8696ad1e
Thread 1 advanced to log sequence 13602
  Current log# 3 seq# 13602 mem# 0: /u04/oradata/cbprod/redo/logCBPROD23.ora
Sat Aug 28 04:36:46 2004
ARC1: Completed archiving  log 4 thread 1 sequence 13600
Sat Aug 28 04:36:46 2004
ARCH: Evaluating archive   log 2 thread 1 sequence 13601
ARCH: Beginning to archive log 2 thread 1 sequence 13601
Creating archive destination LOG_ARCHIVE_DEST_1: '/u01/oradata/cbprod/archive/1_
13601.dbf'
------------------------------------------------------------



 

A reader, May 28, 2005 - 10:30 am UTC

Tom,

According to ILT the new log archive format is for UNIX, which other platform doesnt require the %r?

Thanks.

Tom Kyte
May 28, 2005 - 12:51 pm UTC

none of them "require" anything? not sure what you mean...

A reader, May 28, 2005 - 1:14 pm UTC

The new log archive format is %t_%s_%r... %r do we need it on all the OS, as it mentioned on UNIX...

Thanks..

Tom Kyte
May 28, 2005 - 1:36 pm UTC

that is a default format, you may set it to whatever you like.

The defaults are set by the software, you are free to change them if you have reason to.



A reader, May 28, 2005 - 1:46 pm UTC

Tom,

Here is an example..

SQL> show parameter log_archive_format

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_format                   string      ARC%S_%R.%T

SQL> alter system set log_archive_format='TEST%s%t.arc' scope=spfile;

SQL> startup force
ORA-19905: log_archive_format must contain %s, %t and %r

Thanks.

 

Tom Kyte
May 28, 2005 - 2:53 pm UTC

[tkyte@dellpe tkyte]$ oerr ora 19905
19905, 00000, "log_archive_format must contain %%s, %%t and %%r"
// *Cause: log_archive_format is missing a mandatory format element.
// Starting with Oracle 10i, archived log file names must contain each
// of the elements %s(sequence), %t(thread), and %r(resetlogs id) to
// ensure that all archived log file names are unique.
// *Action: Add the missing format elements to log_archive_format.




A reader, May 28, 2005 - 7:05 pm UTC

Tom,

Exactly thats what my question was, is it required on all the OS as the ILT mentioned UNIX..

Thanks.

Tom Kyte
May 28, 2005 - 7:36 pm UTC

it would appear, given the message, that the answer is in the message?

A reader, May 28, 2005 - 7:11 pm UTC

ora error messages needs to be modified

<<Starting with Oracle 10i,>> should be 10g :-)

reader

A reader, August 02, 2005 - 2:57 pm UTC

in 10g v$managed_standby.resetlog_id
what it is made up of

very useful

Balu, December 29, 2006 - 12:44 am UTC

Dear Tom,

This is very helpful you are always great Thanks very much
for every information you have provided in this site.

Dear Tom i have a small question in this website if i want to ask question so how do i go about can you pls help me out in this.

Regards

Balu.
Tom Kyte
December 29, 2006 - 9:41 am UTC

when I have time, there is a button on the home page that says "press me to submit a question"

when I don't have time, the message you see on the home page is there.

Frequent Archives

Muhammad Waseem Haroon, February 05, 2007 - 12:07 pm UTC

Hi Tom,

I have a Problem of Archiving...

My Database(9i) is Generating Frequent Archives as the same size of RedoLog File (100MB) after every minute or after every 5 minute.

I want to Know the reason behind it?

Some time I find the problem in between 10:00 AM - 11:00 AM & some time in 04:00 PM - 06:00 PM Timings.

In other Timings, its Normal, No Problem...

I have Checked out many things but can't find the reason.

I have discussed this metter with my friends but they are suggesting about LOG MINER.

is there any other way to find out the reason?

I want to define one more thing that we have a practice of creating No-Logging Tables for Reporting Purpose.

It might be possible that No-Logging clause was missed by a Developer when he was creating the Table.

but how can I find out that table also?

Thanks in Advance,

Muhammad Waseem Haroon

waseemharoon@gmail.com
mwaseem_haroon@yahoo.com
ocp_waseem@hotmail.com

Tom Kyte
February 05, 2007 - 12:25 pm UTC

You could just look at what your system does during that time, I'd bet you that you do some "extra processing" right about then


You can use log miner, but it is going to be tedious to read through hundreds of megabytes of redo - I'd rather just look at the database and monitor what it does during those times (eg; a statspack set of reports might be very illuminating)

backing archive log files to tape

naz, February 20, 2007 - 9:16 am UTC

I am
I have a disk on which Oracle is archiving the redo log.
This disk is not much in capacity and therefore I have
to backup the archived files from the disk to tape
frequently. What I do is "copy * to tape" but I doubt
that during this copy (or move) if the archive process
is in middle of copying the online redolog to archive log.
that file will not be properly copied to tape.

And after copying I will delete all files in that
directory, but again there is a doubt that, that half
copied file will get deleted.
Tom Kyte
February 20, 2007 - 9:52 am UTC

so, don't copy a file that is being written do. you can query the V$ tables to discover what archives exist that are fully archived and ready to be backed up.

Archived Log names

DJB, February 27, 2007 - 9:19 am UTC

Tom,
Our 'new' 10g database produces archived log files in the following format:-
cobra_ARCH_1_02777_600011315.ORA.
I know why the 600011315 part is there, but I don't know why it's that particular set of didgits. No 'resetlogs' operation has been done. Where does it generate that number from ?

Thanks in advance.
Tom Kyte
February 27, 2007 - 11:01 am UTC

show parameter log_archive_format


it controls the formatting of the archive log file names.


http://docs.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams103.htm#sthref432

ops$tkyte%ORA10GR2> show parameter log_archive_format

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_format                   string      %t_%s_%r.dbf


%t thread number
%s log sequence number
%r resetlogs ID


the resetlogs id is just a unique number that would change if you resetlogs.

I can

DJB, February 27, 2007 - 9:21 am UTC

spell 'digits' really !

Alert log error

Bob, March 09, 2008 - 11:41 am UTC

Hi Tom,

We have a database on Oracle 9.2 on Sun Solaris UNIX and this is dataguarded. I got the following error in our alert logs last night on the DR (Standby server). We have a job that backs up our DR server (using a RMAN script) that runs at 10:30pm and this was received from the alert logs:

LOGISDR Alert Log Error 22:40:00 08/03/08

ORA-00367: checksum error in log file header
ORA-00311: cannot read header from archived log
ORA-00334: archived log: '/u03/oraarch/LOGIS/LOGIS_0001_0000022013.arc'
ORA-27091: skgfqio: unable to queue I/O
ORA-27072: skgfdisp: I/O error

However from the v$archived_log view it would appear that it got applied last night.

  1  SELECT SEQUENCE#, 
     to_char(FIRST_TIME,'hh24:mi:ss') first,
  2  to_char(NEXT_TIME,'hh24:mi:ss') last, applied
  3  FROM V$ARCHIVED_LOG
  4* where sequence# = 22013
SQL> /

 SEQUENCE#   FIRST    LAST     APP
----------   --------      -------- ---
     22013   22:30:03  22:39:25 YES

Please can you explain the reason for error and how it may be avoided? Thanks

Tom Kyte
March 10, 2008 - 11:27 am UTC

please utilize support.

rman retries failed operations more than once before finally giving up, a subsequent reread or a read of another file could have succeeded.

Alert log error

Bob, March 09, 2008 - 11:44 am UTC

Hi Tom,

I forgot to mention - the archived redo log (physical file) was not shipped across to the /u03/oraarch on the DR server.

More to Explore

Performance

Get all the information about database performance in the Database Performance guide.