Home » Server Options » Data Guard » not able to apply the recovery in DR site (oracle 9.2.0.6.0 o/s sunsolaris 5.9)
not able to apply the recovery in DR site [message #307548] Wed, 19 March 2008 01:56 Go to next message
kesavansundaram
Messages: 183
Registered: October 2007
Location: MUMBAI
Senior Member
we are not able to perform the recovery at DR site,
we are getting following error:

SQL> recover standby database parallel 8 until cancel;
ORA-00279: change 23371874750 generated at 03/14/2008 12:35:36 needed for thread 1
ORA-00289: suggestion :
/BDPRD_dbarch/database/BDPRD/sbarch/ARC0001_0000070574.arc
ORA-00280: change 23371874750 for thread 1 is in sequence #70574


ORA-00283: recovery session canceled due to errors
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 161072 change 23371897785 time 03/14/2008 12:36:28
ORA-00334: archived log:
'/BDPRD_dbarch/database/BDPRD/sbarch/ARC0001_0000070574.arc'

ORA-01112: media recovery not started


we picked up this file from LIVE env and zipped and ftp to DR site,
but again they say, that subject arc file ( ARC0001_0000070574.arc ) is corrupted.

as a next step, we restored this archlog file from our backup tape.
but we did not send to DR site. we are holding to validate this arch log file.

pls guide me, how to validate this arch log file.
how to make sure that this file is not containing any corruption.


matter top most urgent.

tks
kesavan.



in alert log file , it shows:
Fri Mar 14 12:37:15 2008
Thread 1 advanced to log sequence 70575
Current log# 6 seq# 70575 mem# 0: /BDPRD_dblog/database/BDPRD/redo/redo_g6m1.log
Current log# 6 seq# 70575 mem# 1: /BDPRD_dbtemp/database/BDPRD/redo/redo_g6m2.log
Fri Mar 14 12:37:15 2008
ARC1: Evaluating archive log 5 thread 1 sequence 70574
ARC1: Beginning to archive log 5 thread 1 sequence 70574
Creating archive destination LOG_ARCHIVE_DEST_2: '/BDPRD_dbtemp/database/BDPRD/arch/ARC0001_0000070574.arc'
Creating archive destination LOG_ARCHIVE_DEST_1: '/BDPRD_dbarch/database/BDPRD/arch/ARC0001_0000070574.arc'
ARC1: I/O error 19502 archiving log 5 to '/BDPRD_dbarch/database/BDPRD/arch/ARC0001_0000070574.arc'
Fri Mar 14 12:37:17 2008
Errors in file /BDPRD_dbsys/database/BDPRD/trace/bdump/bdprd_arc1_20578.trc:
ORA-19502: write error on file "/BDPRD_dbarch/database/BDPRD/arch/ARC0001_0000070574.arc", blockno 165889 (blocksize=512)
ORA-27063: skgfospo: number of bytes read/written is incorrect
SVR4 Error: 28: No space left on device
Additional information: -1
Additional information: 1048576
ORA-19502: write error on file "/BDPRD_dbarch/database/BDPRD/arch/ARC0001_0000070574.arc", blockno 159745 (blocksize=512)
ARC1: Completed archiving log 5 thread 1 sequence 70574
Fri Mar 14 12:39:26 2008

tks

[Updated on: Wed, 19 March 2008 02:05]

Report message to a moderator

Re: not able to apply the recovery in DR site [message #307563 is a reply to message #307548] Wed, 19 March 2008 02:30 Go to previous messageGo to next message
Michel Cadot
Messages: 68633
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
As you can see in your alert.log you archived log file is corrupted at generation time (because there was no more space on your device).
As you have 2 destinations, use the second copy.

Regards
Michel
Re: not able to apply the recovery in DR site [message #307569 is a reply to message #307563] Wed, 19 March 2008 02:42 Go to previous messageGo to next message
kesavansundaram
Messages: 183
Registered: October 2007
Location: MUMBAI
Senior Member
YES AS YOu said, 2nd copy i can try.....but is there any source to validate this archivelog file like dbverify.....
i think dbverify we can use for datafiles...not for archivelog files....


now as you told, iam sending this file to DR site, let them try to apply the recovery, if again we get same error, then what to do ?

pls adv me at the earliest...thank you .
Re: not able to apply the recovery in DR site [message #307570 is a reply to message #307569] Wed, 19 March 2008 02:45 Go to previous messageGo to next message
Michel Cadot
Messages: 68633
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
o there is no tool
But if you had a look at your alert log before sending the file you'd know the file was corrupted.
So this is a first step for validation.
The only way to know if an archived log is valid is to recover with it.
As the only way to know if a backup on tape is valid is to restore it and try to recover with it.

Regards
Michel
Re: not able to apply the recovery in DR site [message #307571 is a reply to message #307570] Wed, 19 March 2008 02:49 Go to previous messageGo to next message
kesavansundaram
Messages: 183
Registered: October 2007
Location: MUMBAI
Senior Member
i checked in 2nd destination:


oracle/oracle/product/9.2.0 >cd /BDPRD_backup/stored_arch
oracle/oracle/product/9.2.0 >ls -ltr ARC0001_0000070574*
-rw-r----- 1 oracle dba 28308267 Mar 14 12:37 ARC0001_0000070574.arc.gz

the file size is: 28308267 bytes


but yesterday we sent the file from primary location :

oracle/oracle/product/9.2.0 >cd /BDPRD_dbarch/database/BDPRD/arch
oracle/oracle/product/9.2.0 >ls -ltr ARC0001_0000070574*
-rw-r----- 1 oracle dba 22211198 Mar 14 12:37 ARC0001_0000070574.arc.gz

here the file size 22211198,

i hope now if we sent the 2nd copy, it will be ok ,
i will send to uk and then i will update you.

tks
Re: not able to apply the recovery in DR site [message #307574 is a reply to message #307571] Wed, 19 March 2008 03:18 Go to previous messageGo to next message
Michel Cadot
Messages: 68633
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
Of course the primary one is smaller because it had not space enough to be completly generated.

Regards
Michel
Re: not able to apply the recovery in DR site [message #308061 is a reply to message #307574] Thu, 20 March 2008 23:46 Go to previous messageGo to next message
kesavansundaram
Messages: 183
Registered: October 2007
Location: MUMBAI
Senior Member
dear sir,
successfully this archive log file applied..in DR day before yesterday....thankyou

now today we have same problem...one archivelog file is corrupted in DR site.

we checked in live..
actually we are writing in 2 places..this time, i checked 2nd copy also, but size is same ( as below )

oracle/oracle/product/9.2.0 >cd /BDPRD_dbarch/database/BDPRD/arch
oracle/oracle/product/9.2.0 >ls -ltr ARC0001_0000071285*
-rw-r----- 1 oracle dba 26053657 Mar 19 04:38 ARC0001_0000071285.arc.gz

oracle/oracle/product/9.2.0 >cd /BDPRD_dbtemp/database/BDPRD/arch
oracle/oracle/product/9.2.0 >ls -ltr ARC0001_0000071285*
-rw-r----- 1 oracle dba 26053657 Mar 19 04:38 ARC0001_0000071285.arc.gz


in alert log file also,i checked for any ORA ERROR...
BUT THERE IS NO ERROR IN LOG FILE GENERATION...

alert_log check:
----------------
Wed Mar 19 04:38:44 2008
Thread 1 advanced to log sequence 71286
Current log# 5 seq# 71286 mem# 0: /BDPRD_dblog/database/BDPRD/redo/redo_g5m1.log
Current log# 5 seq# 71286 mem# 1: /BDPRD_dbtemp/database/BDPRD/redo/redo_g5m2.log
Wed Mar 19 04:38:44 2008
ARC1: Evaluating archive log 4 thread 1 sequence 71285
ARC1: Beginning to archive log 4 thread 1 sequence 71285
Creating archive destination LOG_ARCHIVE_DEST_2: '/BDPRD_dbtemp/database/BDPRD/arch/ARC0001_0000071285.arc'
Creating archive destination LOG_ARCHIVE_DEST_1: '/BDPRD_dbarch/database/BDPRD/arch/ARC0001_0000071285.arc'
ARC1: Completed archiving log 4 thread 1 sequence 71285
Wed Mar 19 08:39:10 2008
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
SCN scheme 3
Using log_archive_dest parameter default value
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up ORACLE RDBMS Version: 9.2.0.6.0.
System parameters with non-default values:
processes = 300
timed_statistics = TRUE
shared_pool_size = 838860800
large_pool_size = 117440512
java_pool_size = 117440512
nls_date_format = DD-MON-RR
control_files = /BDPRD_dbsys/database/BDPRD/ctrl/control01.ctl, /BDPRD_dblog/database/BDPRD/ctrl/control02.ctl, /BDPRD_dbtemp/database/BDPRD/ctrl/control03.ctl
db_block_size = 8192
db_writer_processes = 10
db_16k_cache_size = 838860800
db_cache_size = 3221225472
db_cache_advice = ON
compatible = 9.2.0.0.0
log_archive_start = TRUE
log_archive_dest_1 = LOCATION=/BDPRD_dbarch/database/BDPRD/arch
log_archive_dest_2 = LOCATION=/BDPRD_dbtemp/database/BDPRD/arch
log_archive_format = ARC%T_%S.arc
db_files = 2000
db_file_multiblock_read_count= 16
fast_start_mttr_target = 300
undo_management = AUTO
undo_tablespace = UNDO_TS1
undo_retention = 64800
remote_login_passwordfile= EXCLUSIVE
db_domain =
instance_name = BDPRD
utl_file_dir = *
job_queue_processes = 1
hash_join_enabled = TRUE
hash_area_size = 838860800
background_dump_dest = /BDPRD_dbsys/database/BDPRD/trace/bdump
user_dump_dest = /BDPRD_dbsys/database/BDPRD/trace/udump
core_dump_dest = /BDPRD_dbsys/database/BDPRD/trace/cdump
audit_trail = TRUE
sort_area_size = 55524288
db_name = BDPRD
open_cursors = 1000
optimizer_mode = CHOOSE
star_transformation_enabled= FALSE
optimizer_index_cost_adj = 20
optimizer_index_caching = 50
query_rewrite_enabled = FALSE
pga_aggregate_target = 1073741824
PMON started with pid=2
DBW0 started with pid=3
DBW1 started with pid=4
DBW2 started with pid=5
DBW3 started with pid=6
DBW4 started with pid=7
DBW5 started with pid=8
DBW6 started with pid=9
DBW7 started with pid=10
DBW8 started with pid=11
DBW9 started with pid=12
LGWR started with pid=13
CKPT started with pid=14
SMON started with pid=15
RECO started with pid=16
CJQ0 started with pid=17
Wed Mar 19 08:39:18 2008
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=18
ARC0: Archival started
ARC1 started with pid=19
ARC1: Archival started
Wed Mar 19 08:39:18 2008
ARCH: STARTING ARCH PROCESSES COMPLETE
Wed Mar 19 08:39:18 2008
ARC0: Thread not mounted
Wed Mar 19 08:39:18 2008
ARC1: Thread not mounted
Wed Mar 19 08:39:19 2008
ALTER DATABASE MOUNT
Wed Mar 19 08:39:23 2008
Successful mount of redo thread 1, with mount id 2471819191
Wed Mar 19 08:39:23 2008
Database mounted in Exclusive Mode.
Completed: ALTER DATABASE MOUNT
Wed Mar 19 08:39:24 2008
ALTER DATABASE OPEN
Wed Mar 19 08:39:25 2008
Beginning crash recovery of 1 threads
Wed Mar 19 08:39:25 2008
Started redo scan
Wed Mar 19 08:39:25 2008
Completed redo scan
52257 redo blocks read, 5073 data blocks need recovery
Wed Mar 19 08:39:26 2008
Started recovery at
Thread 1: logseq 71285, block 176508, scn 0.0
Wed Mar 19 08:39:26 2008
Recovery of Online Redo Log: Thread 1 Group 4 Seq 71285 Reading mem 0
Mem# 0 errs 0: /BDPRD_dblog/database/BDPRD/redo/redo_g4m1.log
Mem# 1 errs 0: /BDPRD_dbtemp/database/BDPRD/redo/redo_g4m2.log
Wed Mar 19 08:39:28 2008
Recovery of Online Redo Log: Thread 1 Group 5 Seq 71286 Reading mem 0
Mem# 0 errs 0: /BDPRD_dblog/database/BDPRD/redo/redo_g5m1.log
Mem# 1 errs 0: /BDPRD_dbtemp/database/BDPRD/redo/redo_g5m2.log
Wed Mar 19 08:39:28 2008
Completed redo application
Wed Mar 19 08:40:02 2008
Ended recovery at
Thread 1: logseq 71286, block 23968, scn 5.2039718964
5073 data blocks read, 5073 data blocks written, 52257 redo blocks read
Crash recovery completed successfully
Wed Mar 19 08:40:04 2008
LGWR: Primary database is in CLUSTER CONSISTENT mode
Thread 1 advanced to log sequence 71287
Thread 1 opened at log sequence 71287
Current log# 6 seq# 71287 mem# 0: /BDPRD_dblog/database/BDPRD/redo/redo_g6m1.log
Current log# 6 seq# 71287 mem# 1: /BDPRD_dbtemp/database/BDPRD/redo/redo_g6m2.log
Successful open of redo thread 1
Wed Mar 19 08:40:05 2008
ARC0: Evaluating archive log 5 thread 1 sequence 71286
ARC0: Beginning to archive log 5 thread 1 sequence 71286
Wed Mar 19 08:40:05 2008
SMON: enabling cache recovery
Wed Mar 19 08:40:05 2008
Creating archive destination LOG_ARCHIVE_DEST_2: '/BDPRD_dbtemp/database/BDPRD/arch/ARC0001_0000071286.arc'
Creating archive destination LOG_ARCHIVE_DEST_1: '/BDPRD_dbarch/database/BDPRD/arch/ARC0001_0000071286.arc'
ARC0: Completed archiving log 5 thread 1 sequence 71286
Wed Mar 19 08:40:13 2008
Successfully onlined Undo Tablespace 101.
Wed Mar 19 08:40:13 2008
SMON: enabling tx recovery
Wed Mar 19 08:40:14 2008
Database Characterset is WE8ISO8859P1
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: ALTER DATABASE OPEN
Wed Mar 19 10:06:47 2008
Thread 1 advanced to log sequence 71288
Current log# 7 seq# 71288 mem# 0: /BDPRD_dblog/database/BDPRD/redo/redo_g7m1.log
Current log# 7 seq# 71288 mem# 1: /BDPRD_dbtemp/database/BDPRD/redo/redo_g7m2.log
Wed Mar 19 10:06:47 2008
ARC0: Evaluating archive log 6 thread 1 sequence 71287
ARC0: Beginning to archive log 6 thread 1 sequence 71287
Creating archive destination LOG_ARCHIVE_DEST_2: '/BDPRD_dbtemp/database/BDPRD/arch/ARC0001_0000071287.arc'
Creating archive destination LOG_ARCHIVE_DEST_1: '/BDPRD_dbarch/database/BDPRD/arch/ARC0001_0000071287.arc'
ARC0: Completed archiving log 6 thread 1 sequence 71287


the file which is presented as of now in DR ( as follows )

in bmi-uk
---------
-rw-r--r-- 1 kaleftp other 26053657 Mar 21 02:32 ARC0001_0000071285.arc.gz

file size is same only...

how to proceed,
since we take backup on daily basis, i will restore this file from tape and check the size...and ftp the same to DR-site...
meantime, pls adv is there any other alternate for this

pls reply on urgent basis. thank you.


Re: not able to apply the recovery in DR site [message #308064 is a reply to message #308061] Fri, 21 March 2008 00:01 Go to previous messageGo to next message
Michel Cadot
Messages: 68633
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
What make you think it is corrupted?

Regards
Michel
Re: not able to apply the recovery in DR site [message #308065 is a reply to message #308064] Fri, 21 March 2008 00:24 Go to previous messageGo to next message
kesavansundaram
Messages: 183
Registered: October 2007
Location: MUMBAI
Senior Member
Iam iam wrong,pls correct me.

if the file is not properly generated,then we can't apply the same in DR site.

kesavan.
Re: not able to apply the recovery in DR site [message #308085 is a reply to message #308065] Fri, 21 March 2008 01:41 Go to previous message
Michel Cadot
Messages: 68633
Registered: March 2007
Location: Nanterre, France, http://...
Senior Member
Account Moderator
Yes.

Regards
Michel
Previous Topic: DATAGUARD - HOW TO CONFIGURE STANDBY ON THE SAME SYSTEM AS PRIMARY
Next Topic: How many standy database should I build?
Goto Forum:
  


Current Time: Tue Apr 16 00:32:56 CDT 2024