Cancelling recovery on Physical standby.
Hi ALL,
recovery is cancel and i am looking following error in alert log file
how can solve this problem
database version 11gr2
aix 6.1 64 bit
physical standby datbase
ORA-03170: deadlocked on readable physical standby (undo segment 65535)
Tue Jun 05 12:25:27 2012
Errors in file /u01/oracle/diag/rdbms/sfxdb/sfxdb1/trace/sfxdb1_pmon_14614728.t
c:
ORA-03170: deadlocked on readable physical standby (undo segment 65535)
Tue Jun 05 12:25:47 2012
Errors in file /u01/oracle/diag/rdbms/sfxdb/sfxdb1/trace/sfxdb1_pmon_14614728.t
c:
ORA-03170: deadlocked on readable physical standby (undo segment 65535)
ORA-03170: deadlocked on readable physical standby (undo segment 65535)
Tue Jun 05 12:25:27 2012
Errors in file /u01/oracle/diag/rdbms/sfxdb/sfxdb1/trace/sfxdb1_pmon_14614728.t
c:
ORA-03170: deadlocked on readable physical standby (undo segment 65535)
Tue Jun 05 12:25:47 2012
Errors in file /u01/oracle/diag/rdbms/sfxdb/sfxdb1/trace/sfxdb1_pmon_14614728.t
c:
ORA-03170: deadlocked on readable physical standby (undo segment 65535)You cancelled recovery or it is terminated?
Try to start once again, I have seen some listed bugs with the same error but those are applicable for 11gR1, but you are in 11gR2.
Refer ORA-03170: Deadlocked on Readable Physical Standby [ID 846324.1], better you submit an SR to Support.
Thanks.
Similar Messages
-
Corrupting the block to continue recovery in physical standby
Hi,
Just like to inquire how I will be able to corrupt the block to be able to continue the recovery in the physical standby.
DB Version: 11.1.0.7
Database Type: Data Warehouse
The setup we have is primary database and standby database, we are not using dataguard, and our standby setup is another physical copy of production which act as standby and being sync using script that being run from time to time to apply the archive log came from production (its not configured to sync using ARCH or LGWR and its corresponding configurations).
Then, the standby database is not sync due to errors encountered while trying to apply the archive log, error is below:
Fri Feb 11 05:50:59 2011
ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /u01/archive/<sid>/1_50741_651679913.arch
Fri Feb 11 05:52:06 2011
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x7FFFD2F18FF8] [PC:0x60197E0, kdr9ir2rst0()+326]
Errors in file /u01/app/oracle/diag/rdbms/<sid>/<sid>/trace/<sid>pr0028085.trc (incident=631460):
ORA-07445: exception encountered: core dump [kdr9ir2rst0()+326] [SIGSEGV] [ADDR:0x7FFFD2F18FF8] [PC:0x60197E0] [Address not mapped to object] []
Incident details in: /u01/app/oracle/diag/rdbms/<sid>/<sid>/incident/incdir_631460/<sid>pr0028085_i631460.trc
Fri Feb 11 05:52:10 2011
Trace dumping is performing id=[cdmp_20110211055210]
Fri Feb 11 05:52:14 2011
Sweep Incident[631460]: completed
Fri Feb 11 05:52:17 2011
Slave exiting with ORA-10562 exception
Errors in file /u01/app/oracle/diag/rdbms/<sid>/<sid>/trace/<sid>pr0028085.trc:
ORA-10562: Error occurred while applying redo to data block (file# 36, block# 1576118)
ORA-10564: tablespace <tablespace name>
ORA-01110: data file 36: '/u02/oradata/<sid>/<datafile>.dbf'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 14877145
ORA-00607: Internal error occurred while making a change to a data block
ORA-00602: internal programming exception
ORA-07445: exception encountered: core dump [kdr9ir2rst0()+326] [SIGSEGV] [ADDR:0x7FFFD2F18FF8] [PC:0x60197E0] [Address not mapped to object] []
Based on the error log it seems we are hitting some bug from metalink (document id 460169.1 and 882851.1)
my question is, the datafile # is given, block# is known too and the data object is also identified. I just verified that object is not that important, is there a way to set the block# to corrupted to be able the recovery to continue? Then I will just drop the table from production so that will also happen in standby, and the block corrupted will be gone too. Is this feasible?
If its not, can you suggest what's next I can do so the the physical standby will be able to sync again to prod aside from rebuilding the standby?
Please take note that I also tried to dbv the file to confirm if there is marked as corrupted and the result for that datafile is also good:
dbv file=/u02/oradata/<sid>/<datafile>_19.dbf logfile=dbv_file_36.log blocksize=16384
oracle@<server>:[~] $ cat dbv_file_36.log
DBVERIFY: Release 11.1.0.7.0 - Production on Sun Feb 13 04:35:28 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
DBVERIFY - Verification starting : FILE = /u02/oradata/<sid>/<datafile>_19.dbf
DBVERIFY - Verification complete
Total Pages Examined : 3840000
Total Pages Processed (Data) : 700644
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 417545
Total Pages Failing (Index): 0
Total Pages Processed (Other): 88910
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 2632901
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 3811184883 (1.3811184883)
Any help is really appreciated. I hope to hear feedback from you.
Thanksdamorgan, i understand the opinion.
just new with the organization and just inherit a data warehouse database without rman backup. I am still setting up the rman backup thats why i can't use rman to resolve the issue, the only i have is physical standby and its not a standby that automatically sync using dataguard or standard standby setup, i am just checking solution that is applicable in the current situation -
Related to recovery in Physical standby database in RAC
In Physical Standby database all instance involved in recovery processes or any one instance will be their in in recovery mode
If is like this another instance will be for high availabily can any one in forum explain me it will be help fullWith your Primary database being RAC, the Physical Standby does not have to be RAC, although, obviously it would be preferred to have scalability as required at a DR site.
Whether your Standby is RAC or non-RAC, the automatic Recovery that is done at the Standby is done by one instance only. It would be applying the ArchiveLogs from all the threads (i.e. instances) of the Primary.
Database Recovery is always done by a single instance.
Hemant K Chitale
http://hemantoracledba.blogspot.com -
Rman backup on physical standby database without cancelling MRP
Hi all,
Could anyone share, is this possible to take RMAN backup on physical standby database without cancelling MRP process.
regarrds,Hi,
On Standby Side:
SQL> alter database mount;
Database altered.
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
SQL> select max(Sequence#) from v$archived_log;
MAX(SEQUENCE#)
405
SQL> select max(Sequence#) from v$archived_log where applied='YES';
MAX(SEQUENCE#)
404
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@oel62-x64 Desktop]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue May 21 15:31:43 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ADMDB (DBID=4063877183, not open)
RMAN> backup database plus archivelog delete all input;
Starting backup at 21-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=32 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=390 RECID=391 STAMP=815416638
input archived log thread=1 sequence=391 RECID=392 STAMP=815421952
input archived log thread=1 sequence=392 RECID=393 STAMP=815422343
input archived log thread=1 sequence=393 RECID=394 STAMP=815422434
input archived log thread=1 sequence=394 RECID=395 STAMP=815422570
input archived log thread=1 sequence=395 RECID=396 STAMP=815476598
input archived log thread=1 sequence=396 RECID=397 STAMP=815476615
input archived log thread=1 sequence=397 RECID=398 STAMP=815476645
input archived log thread=1 sequence=398 RECID=399 STAMP=815477471
input archived log thread=1 sequence=399 RECID=400 STAMP=815477475
input archived log thread=1 sequence=400 RECID=401 STAMP=815477628
input archived log thread=1 sequence=401 RECID=403 STAMP=815584146
input archived log thread=1 sequence=402 RECID=402 STAMP=815584137
input archived log thread=1 sequence=403 RECID=405 STAMP=816017446
*input archived log thread=1 sequence=404 RECID=404 STAMP=816017444*
*input archived log thread=1 sequence=405 RECID=406 STAMP=816017455*
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_annnn_TAG20130521T153202_8spm937d_.bkp tag=TAG20130521T153202 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
channel ORA_DISK_1: deleting archived log(s)
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_14/o1_mf_1_390_8s48hfrp_.arc RECID=391 STAMP=815416638
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_14/o1_mf_1_391_8s4fohwb_.arc RECID=392 STAMP=815421952
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_14/o1_mf_1_392_8s4g1q0v_.arc RECID=393 STAMP=815422343
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_14/o1_mf_1_393_8s4g4l8z_.arc RECID=394 STAMP=815422434
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_14/o1_mf_1_394_8s4g8t9h_.arc RECID=395 STAMP=815422570
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_395_8s631622_.arc RECID=396 STAMP=815476598
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_396_8s631qjj_.arc RECID=397 STAMP=815476615
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_397_8s632od8_.arc RECID=398 STAMP=815476645
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_398_8s63whqc_.arc RECID=399 STAMP=815477471
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_399_8s63wly4_.arc RECID=400 STAMP=815477475
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_15/o1_mf_1_400_8s641d8j_.arc RECID=401 STAMP=815477628
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_16/o1_mf_1_401_8s9d21jk_.arc RECID=403 STAMP=815584146
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_16/o1_mf_1_402_8s9d1skv_.arc RECID=402 STAMP=815584137
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_403_8spm6p4h_.arc RECID=405 STAMP=816017446
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_404_8spm6mqj_.arc RECID=404 STAMP=816017444
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_405_8spm6yg0_.arc thread=1 sequence=405
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/stldb/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/stldb/sysaux01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/stldb/example01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/stldb/undotbs01.dbf
input datafile file number=00006 name=/u01/app/oracle/oradata/stldb/appdata01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/stldb/users01.dbf
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_nnndf_TAG20130521T153213_8spm9fnc_.bkp tag=TAG20130521T153213 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:15
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_ncsnf_TAG20130521T153213_8spmfqxf_.bkp tag=TAG20130521T153213 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
specification does not match any archived log in the repository
backup cancelled because there are no files to backup
Finished backup at 21-MAY-13
RMAN> exit
Recovery Manager complete.
[oracle@oel62-x64 Desktop]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Tue May 21 15:34:42 2013
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select max(Sequence#) from v$archived_log;
MAX(SEQUENCE#)
405
SQL> select max(Sequence#) from v$archived_log where applied='YES';
MAX(SEQUENCE#)
404
SQL> There have no problem, backup database when MRP is running. But if you want delete, then you are getting RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process.
And will not delete this archived log, because it is needed for standby or upstream capture process.
Updated
When MRP stoped
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@oel62-x64 Desktop]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue May 21 15:46:07 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ADMDB (DBID=4063877183, not open)
RMAN> backup database plus archivelog delete all input;
Starting backup at 21-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=24 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=405 RECID=406 STAMP=816017455
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_annnn_TAG20130521T154617_8spn3s9w_.bkp tag=TAG20130521T154617 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archived log(s)
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_405_8spm6yg0_.arc RECID=406 STAMP=816017455
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/stldb/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/stldb/sysaux01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/stldb/example01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/stldb/undotbs01.dbf
input datafile file number=00006 name=/u01/app/oracle/oradata/stldb/appdata01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/stldb/users01.dbf
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_nnndf_TAG20130521T154618_8spn3v4f_.bkp tag=TAG20130521T154618 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:16
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_ncsnf_TAG20130521T154618_8spn6779_.bkp tag=TAG20130521T154618 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
specification does not match any archived log in the repository
backup cancelled because there are no files to backup
Finished backup at 21-MAY-13
RMAN> Apply process is stopped and new redo received from primary.
SQL> select max(Sequence#) from v$archived_log;
MAX(SEQUENCE#)
407
SQL> select max(Sequence#) from v$archived_log where applied='YES';
MAX(SEQUENCE#)
405
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@oel62-x64 Desktop]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Tue May 21 15:49:28 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ADMDB (DBID=4063877183, not open)
RMAN> backup database plus archivelog delete all input;
Starting backup at 21-MAY-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=32 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=406 RECID=407 STAMP=816018527
input archived log thread=1 sequence=407 RECID=408 STAMP=816018530
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_annnn_TAG20130521T154937_8spnb1y3_.bkp tag=TAG20130521T154937 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archived log(s)
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_406_8spn8hkn_.arc thread=1 sequence=406
RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process
archived log file name=/u01/app/oracle/fast_recovery_area/stldb/STLDB/archivelog/2013_05_21/o1_mf_1_407_8spn8l69_.arc thread=1 sequence=407
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/stldb/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/stldb/sysaux01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/stldb/example01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/stldb/undotbs01.dbf
input datafile file number=00006 name=/u01/app/oracle/oradata/stldb/appdata01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/stldb/users01.dbf
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_nnndf_TAG20130521T154939_8spnb3f5_.bkp tag=TAG20130521T154939 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:15
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 21-MAY-13
channel ORA_DISK_1: finished piece 1 at 21-MAY-13
piece handle=/u01/app/oracle/fast_recovery_area/stldb/STLDB/backupset/2013_05_21/o1_mf_ncsnf_TAG20130521T154939_8spndhly_.bkp tag=TAG20130521T154939 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 21-MAY-13
Starting backup at 21-MAY-13
using channel ORA_DISK_1
specification does not match any archived log in the repository
backup cancelled because there are no files to backup
Finished backup at 21-MAY-13
RMAN> I think, codes is understandable.
Regard
Mahir M. Quluzade
Edited by: Mahir M. Quluzade on May 21, 2013 3:36 PM -
Physica standby recovery problem
Hi,
I am trying to recover physical standby database manually
I am getting below error:
alter database recover standby database parallel (degree 32);
alter database recover standby database parallel (degree 32)
ERROR at line 1:
ORA-01153: an incompatible media recovery is active
I have tried to cancel managed recovery, but no managed recovery is active.
alter database recover managed standby database cancel;
alter database recover managed standby database cancel
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
select distinct recovery_mode from v$archive_dest_status;
RECOVER
IDLE
Please help me to resolve this. Thanks in advance.
regards,
NarendraApparently this is bug 5084496, related to parallel recovery on 10.1 and below (ML note 361883.1). You may avoid this bug if you don't use parallel recovery. It looks like there are no one-off patches available, so you are stuck with either serial recovery or upgrade to 10.2 or higher :-(
Regards,
Jeremiah Wilton
ORA-600 Consulting
http://www.ora-600.net -
Recovery very very slow on the physical standby recently
The standby was running fine for over a year. But recently the recovery became very slow. It took over an hour to apply one archivelog causing the standby falling behind. What could be the cause and solution?
Thanks!Before I go further with my comment, I would recommend to open a SR with Oracle and have them help you to resolve the problem.
You said that the archive logs are being applied, however the apply rate is slow? Is this true?
Since you are applying the archive logs, it looks like your protection mode is set to ASYNC Maximum Performance.
Can you check if all the logs are being shipped to the standby without any problem?
There are couple of DG healthcheck scripts available on Metalink.
Metalink Note 241438.1 Script to Collect Data Guard Physical Standby Diagnostic Information
Metalink Note 241374.1 Script to Collect Data Guard Primary Site Diagnostic Information
Can you run those scripts? If you feel comfortable, publish the output of the scripts on this tread, otherwise review them. They may give you some clue on what might be going on.
Also check v$dataguard_status view.
select *
from v$dataguard_status
where severity in ('Error','Fatal')
order by timestamp; If you are not able to run the scripts due to database hanging state, as you described in your last post, try to determine why the database is hanging.
In this kind of situations I usually use HANGANALYZE that will generate trace files for all the running processes. It may take a while until you review these files. Especially pay attention to the RFS process.
SQL>oradebug setmypid
SQL>oradebug unlimit;
SQL>oradebug hanganalyze 266For more information on how to use HANGANALYZE refer to Metalink Notes: 175006.1, 452358.1 and 61552.1
However, if you haven't used oradebug before or don't feel comfortable using it, you better don't do that and wait on instructions from Oracle.
Also, as always, check the alert log file and the data guard log file (drc<sid>.log).
Cheers,
Edited by: tekicora on Dec 31, 2008 10:22 AM -
How to stop and cancel physical standby database (ORACLE 10g)
Dear All,
I have physical standby setup and I want stopped for the time being that to use the database as an normal DB (standalone inestance).
Kindly advise and show me how do I do that.
Regards,executing below query on primary db stops log shipping to standby.......i think this is sufficient for disabling your physical standby setup temporary
alter system set log_archive_dest_state_2=defer scope=both;
In future if you want your dataguard setup back..............you can rebuild the standby and enable the log_archive_dest_state_2 parameter.
Edited by: Veeresh.S on Nov 14, 2012 5:45 PM -
Urgent- block corruption on standby and recovery thru physical copy file
Hi all,
We have a ORacle 9.2.0.6 DB and we have manula physical standby DB.
We got a block corruption on standby and I got to know thru metalink that we have to copy the data file from primary to standby but
my question is when we copy the datafile from primary to standby, will i be able to do the same because I think the SCN may varies ,as when i down the standby to copy the datafile ,oracle server wrtie a SCN to the control file of standby and when i will open it it will throw an error....
Please suggest me....we are having n numbers od block corruption so what should be the exact value in
alter database recover automatic standby database allow *1* corruptionpls suggeest me
select * from v$backup_corruption;
RECID STAMP SET_STAMP SET_COUNT PIECE# FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# MARKED_CORRUPT CORRUPTION_TYPE
1 679059926 679058677 54 1 3 299997 12 1790569359 NO LOGICAL
2 679059926 679058677 54 1 3 300010 15 1790569374 NO LOGICAL
3 679059926 679058677 54 1 3 300026 15 1790569389 NO LOGICAL
4 679059926 679058677 54 1 3 300042 7 1790569404 NO LOGICAL
5 679059926 679058677 54 1 3 300433 8 1790569404 NO LOGICAL
6 679059926 679058677 54 1 3 300442 15 1790569419 NO LOGICAL
7 679059926 679058677 54 1 3 300458 15 1790569434 NO LOGICAL
8 679059926 679058677 54 1 3 300690 15 1790569450 NO LOGICAL
9 679059926 679058677 54 1 3 300930 7 1790569465 NO LOGICAL
10 679059926 679058677 54 1 3 2427217 64 1545959567 NO LOGICAL
11 679059926 679058677 54 1 3 3078291 126 1790569473 NO LOGICAL
12 679059926 679058677 54 1 3 3236929 8 1790569465 NO LOGICAL
13 679059926 679058677 54 1 3 3236941 12 1790464761 NO LOGICAL
14 679059926 679058677 54 1 3 3236954 15 1790464776 NO LOGICAL
15 679059926 679058677 54 1 3 3236970 15 1790464792 NO LOGICAL
16 679059926 679058677 54 1 3 3236986 15 1790464807 NO LOGICAL
17 679059926 679058677 54 1 3 3237002 7 1790464822 NO LOGICAL
18 679059926 679058677 54 1 3 3242641 8 1790464822 NO LOGICAL
19 679059926 679058677 54 1 3 3242650 15 1790464837 NO LOGICAL
20 679059926 679058677 54 1 3 3242666 15 1790464852 NO LOGICAL
21 679059926 679058677 54 1 3 3242682 15 1790464867 NO LOGICAL
22 679059926 679058677 54 1 3 3242771 40 1790464875 NO LOGICAL
23 679059926 679058677 54 1 3 3242899 126 1790569482 NO LOGICAL
24 679059926 679058677 54 1 3 3243027 126 1790569491 NO LOGICAL
25 679059926 679058677 54 1 3 3243155 126 1790569500 NO LOGICAL
26 679059926 679058677 54 1 3 3243283 126 1790569509 NO LOGICAL
27 679059926 679058677 54 1 3 3243411 126 1790569518 NO LOGICAL
28 679059926 679058677 54 1 3 3243539 126 1790569527 NO LOGICAL
29 679059926 679058677 54 1 3 3243667 126 1790569536 NO LOGICAL
30 679059926 679058677 54 1 3 3243795 126 1790569545 NO LOGICAL
31 679059926 679058677 54 1 3 3243923 126 1790569554 NO LOGICAL
32 679059926 679058677 54 1 3 3244051 126 1790569564 NO LOGICAL
33 679059926 679058677 54 1 3 3244179 126 1790569573 NO LOGICAL
34 679059926 679058677 54 1 3 3244307 126 1790569582 NO LOGICAL
35 679059926 679058677 54 1 3 3244435 126 1790569591 NO LOGICAL
36 679059926 679058677 54 1 3 3244563 126 1790569600 NO LOGICAL
37 679059926 679058677 54 1 3 3244691 126 1790569609 NO LOGICAL
38 679059926 679058677 54 1 3 3244819 126 1790569618 NO LOGICAL
39 679059926 679058677 54 1 3 3244947 126 1790569627 NO LOGICAL
40 679059926 679058677 54 1 3 3245075 126 1790569637 NO LOGICAL
41 679059926 679058677 54 1 3 3245203 126 1790569646 NO LOGICAL
42 679059926 679058677 54 1 3 3245331 126 1790569655 NO LOGICAL
43 679059926 679058677 54 1 3 3245459 126 1790569664 NO LOGICAL
44 679059926 679058677 54 1 3 3245587 126 1790569673 NO LOGICAL
45 679059926 679058677 54 1 3 3245715 126 1790569683 NO LOGICAL
46 679059926 679058677 54 1 3 3245843 126 1790569692 NO LOGICAL
47 679059926 679058677 54 1 3 3245971 126 1790569701 NO LOGICAL
48 679059926 679058677 54 1 3 3246099 126 1790569710 NO LOGICAL
49 679059926 679058677 54 1 3 3246227 126 1790569719 NO LOGICAL
50 679059926 679058677 54 1 3 3246355 126 1790569728 NO LOGICAL
51 679059926 679058677 54 1 3 3246483 126 1790569737 NO LOGICAL
52 679059926 679058677 54 1 3 3246611 126 1790569746 NO LOGICAL
53 679059926 679058677 54 1 3 3246739 126 1790569755 NO LOGICAL
54 679059926 679058677 54 1 3 3246867 126 1790569764 NO LOGICAL
55 679059926 679058677 54 1 3 3246995 126 1790569773 NO LOGICAL
56 679059926 679058677 54 1 3 3247123 126 1790569782 NO LOGICAL
57 679059926 679058677 54 1 3 3247251 126 1790569791 NO LOGICAL
58 679059926 679058677 54 1 3 3247379 126 1790569801 NO LOGICAL
59 679059926 679058677 54 1 3 3247507 126 1790569811 NO LOGICAL
60 679059926 679058677 54 1 3 3247635 126 1790569820 NO LOGICAL
61 679059926 679058677 54 1 3 3247763 126 1790569829 NO LOGICAL
62 679059926 679058677 54 1 3 3247891 126 1790569838 NO LOGICAL
63 679059926 679058677 54 1 3 3248019 126 1790569847 NO LOGICAL
64 679059926 679058677 54 1 3 3248147 126 1790569856 NO LOGICAL
65 679059926 679058677 54 1 3 3248275 126 1790569865 NO LOGICAL
66 679059926 679058677 54 1 3 3248403 126 1790569874 NO LOGICAL
67 679059926 679058677 54 1 3 3248531 126 1790569883 NO LOGICAL
68 679059926 679058677 54 1 3 3248659 126 1790569892 NO LOGICAL
69 679059926 679058677 54 1 3 3248787 126 1790569901 NO LOGICAL
70 679059926 679058677 54 1 3 3248915 126 1790569910 NO LOGICAL
71 679059926 679058677 54 1 3 3249043 126 1790569920 NO LOGICAL
72 679059926 679058677 54 1 3 3249171 126 1790569929 NO LOGICAL
73 679059926 679058677 54 1 3 3249299 126 1790569938 NO LOGICAL
74 679059926 679058677 54 1 3 3249427 126 1790569947 NO LOGICAL
75 679059926 679058677 54 1 3 3249555 126 1790569956 NO LOGICAL
76 679059926 679058677 54 1 3 3249683 126 1790569965 NO LOGICAL
77 679059926 679058677 54 1 3 3249811 126 1790569974 NO LOGICAL
78 679059926 679058677 54 1 3 3249939 126 1790569984 NO LOGICAL
79 679059926 679058677 54 1 3 3250067 126 1790569993 NO LOGICAL
80 679059926 679058677 54 1 3 3250195 126 1790570002 NO LOGICAL
81 679059926 679058677 54 1 3 3250323 126 1790570011 NO LOGICAL
82 679059926 679058677 54 1 3 3250451 126 1790570020 NO LOGICAL
83 679059926 679058677 54 1 3 3250579 126 1790570029 NO LOGICAL
84 679059926 679058677 54 1 3 3250706 127 1790570039 NO LOGICAL
85 679059926 679058677 54 1 3 3250837 1020 1790570048 NO LOGICAL
86 679059926 679058677 54 1 3 3251861 1020 1790570057 NO LOGICAL
87 679059926 679058677 54 1 3 3252885 1020 1790570067 NO LOGICAL
88 679059926 679058677 54 1 3 3253909 1020 1790570076 NO LOGICAL
89 679059926 679058677 54 1 3 3254933 1020 1790570086 NO LOGICAL
90 679059926 679058677 54 1 3 3255957 1020 1790570095 NO LOGICAL
91 679059926 679058677 54 1 3 3256981 1020 1790570104 NO LOGICAL
92 679059926 679058677 54 1 3 3258005 1020 1790570114 NO LOGICAL
93 679059926 679058677 54 1 3 3259029 1020 1790570123 NO LOGICAL
94 679059926 679058677 54 1 3 3260053 1020 1790570133 NO LOGICAL
95 679059926 679058677 54 1 3 3261077 486 1790570142 NO LOGICAL NO LOGICAL
SQL> select * from v$database_block_corruption;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 299997 12 1790569359 LOGICAL
3 300010 15 1790569374 LOGICAL
3 300026 15 1790569389 LOGICAL
3 300042 7 1790569404 LOGICAL
3 300433 8 1790569404 LOGICAL
3 300442 15 1790569419 LOGICAL
3 300458 15 1790569434 LOGICAL
3 300690 15 1790569450 LOGICAL
3 300930 7 1790569465 LOGICAL
3 2427217 64 1545959567 LOGICAL
3 3078291 126 1790569473 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3236929 8 1790569465 LOGICAL
3 3236941 12 1790464761 LOGICAL
3 3236954 15 1790464776 LOGICAL
3 3236970 15 1790464792 LOGICAL
3 3236986 15 1790464807 LOGICAL
3 3237002 7 1790464822 LOGICAL
3 3242641 8 1790464822 LOGICAL
3 3242650 15 1790464837 LOGICAL
3 3242666 15 1790464852 LOGICAL
3 3242682 15 1790464867 LOGICAL
3 3242771 40 1790464875 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3242899 126 1790569482 LOGICAL
3 3243027 126 1790569491 LOGICAL
3 3243155 126 1790569500 LOGICAL
3 3243283 126 1790569509 LOGICAL
3 3243411 126 1790569518 LOGICAL
3 3243539 126 1790569527 LOGICAL
3 3243667 126 1790569536 LOGICAL
3 3243795 126 1790569545 LOGICAL
3 3243923 126 1790569554 LOGICAL
3 3244051 126 1790569564 LOGICAL
3 3244179 126 1790569573 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3244307 126 1790569582 LOGICAL
3 3244435 126 1790569591 LOGICAL
3 3244563 126 1790569600 LOGICAL
3 3244691 126 1790569609 LOGICAL
3 3244819 126 1790569618 LOGICAL
3 3244947 126 1790569627 LOGICAL
3 3245075 126 1790569637 LOGICAL
3 3245203 126 1790569646 LOGICAL
3 3245331 126 1790569655 LOGICAL
3 3245459 126 1790569664 LOGICAL
3 3245587 126 1790569673 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3245715 126 1790569683 LOGICAL
3 3245843 126 1790569692 LOGICAL
3 3245971 126 1790569701 LOGICAL
3 3246099 126 1790569710 LOGICAL
3 3246227 126 1790569719 LOGICAL
3 3246355 126 1790569728 LOGICAL
3 3246483 126 1790569737 LOGICAL
3 3246611 126 1790569746 LOGICAL
3 3246739 126 1790569755 LOGICAL
3 3246867 126 1790569764 LOGICAL
3 3246995 126 1790569773 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3247123 126 1790569782 LOGICAL
3 3247251 126 1790569791 LOGICAL
3 3247379 126 1790569801 LOGICAL
3 3247507 126 1790569811 LOGICAL
3 3247635 126 1790569820 LOGICAL
3 3247763 126 1790569829 LOGICAL
3 3247891 126 1790569838 LOGICAL
3 3248019 126 1790569847 LOGICAL
3 3248147 126 1790569856 LOGICAL
3 3248275 126 1790569865 LOGICAL
3 3248403 126 1790569874 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3248531 126 1790569883 LOGICAL
3 3248659 126 1790569892 LOGICAL
3 3248787 126 1790569901 LOGICAL
3 3248915 126 1790569910 LOGICAL
3 3249043 126 1790569920 LOGICAL
3 3249171 126 1790569929 LOGICAL
3 3249299 126 1790569938 LOGICAL
3 3249427 126 1790569947 LOGICAL
3 3249555 126 1790569956 LOGICAL
3 3249683 126 1790569965 LOGICAL
3 3249811 126 1790569974 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3249939 126 1790569984 LOGICAL
3 3250067 126 1790569993 LOGICAL
3 3250195 126 1790570002 LOGICAL
3 3250323 126 1790570011 LOGICAL
3 3250451 126 1790570020 LOGICAL
3 3250579 126 1790570029 LOGICAL
3 3250706 127 1790570039 LOGICAL
3 3250837 1020 1790570048 LOGICAL
3 3251861 1020 1790570057 LOGICAL
3 3252885 1020 1790570067 LOGICAL
3 3253909 1020 1790570076 LOGICAL
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO
3 3254933 1020 1790570086 LOGICAL
3 3255957 1020 1790570095 LOGICAL
3 3256981 1020 1790570104 LOGICAL
3 3258005 1020 1790570114 LOGICAL
3 3259029 1020 1790570123 LOGICAL
3 3260053 1020 1790570133 LOGICAL
3 3261077 486 1790570142 LOGICAL
95 rows selected.
SQL> -
Recovery is slow on physical standby
When delete stmts are issued on primary, resync/recovery process on standby side is very slow. Logs are shipped fine and fast , but recovery process is slow. Is there some configuration needs to be updated?
Normall all other dmls are fast in the resync process.
OS: RHEL5
Primary : RAC
Standby: Phy. standby on standalonedeclare
vthread# NUMBER;
vsequence# NUMBER;
vfirst_time DATE;
vname VARCHAR2(513);
vapplied VARCHAR2(3);
vdest_id NUMBER;
vsysdate date := sysdate ;
cursor lgsarcchk is
select thread#,sequence#,first_time,name,applied from V$ARCHIVED_LOG
where trunc(first_time) >= trunc(sysdate-3)
and applied='YES'
order BY first_time ;
begin
for lgsarc in lgsarcchk
loop
if lgsarc.applied = 'YES' then
dbms_output.put_line('Thread#'||lgsarc.thread#||' sequence# '|| rpad(lgsarc.sequence#,45)||' Status => '||lgsarc.applied||' applied at '||lgsarc.first_time);
end if;
end loop;
end;
im using above cmd to check and also alert log of standby prints when it applies.
Alert log msg:
Media Recovery Log /MOUNTPOINT/DBNAME/ARCHIVELOGNUMBER.arc -
Error while trying to open physical standby database - (DATA GUARD)
Hi Everyone,
I have problems in opening the database of the physical standby in read- write mode/ read only mode. I have a primary server which is running on 2 node RAC and the standby on a seperate single server being used as DR. I recently got this server and my aim was to isolate the standby server from primary server and perform few test. As it has never been tested even once.
Primary Database spec: (2 Node Rac on ASM)
Oracle Version : 10.2.0.3.0
O/s : HP-UX B.11.23
Standby Database spec: (Single Node)
Oracle Version : 10.2.0.3.0
O/s: HP-UX db01 B.11.23
Error:
alter database recover managed standby database cancel;
Database altered.
SQL> alter database open
2 ;
alter database open
ERROR at line 1:
ORA-16004: backup database requires recovery
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '+DATA/dprod/datafile/system01.dbf'
Parameters :
log_archive_dest_2 string SERVICE=PROD1 LGWR ASYNC VALID
FOR=(ONLINELOGFILES,PRIMARY_
ROLE) DB_UNIQUE_NAME=PROD
remote_archive_enable string true
fal_client string DPROD
fal_server string PROD1, PROD2
Steps tried so far:
Changed log_archive_dest_2 = DEFER on both the primary nodes
Standby :
startup nomount
alter database mount standby database;
alter database recover managed standby database disconnect;
alter database recover managed standby database cancel;
alter database open/readonly (tried both)
Same error.
On Primary:
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
55702
on Standby:
MAX(SEQUENCE#)
33289
Primary Database:
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIME NEXT_TIME
55700 13-JUN-11 13-JUN-11
55700 13-JUN-11 13-JUN-11
55701 13-JUN-11 13-JUN-11
55701 13-JUN-11 13-JUN-11
55702 13-JUN-11 13-JUN-11
60824 rows selected.
Standby Database:
SEQUENCE# FIRST_TIME NEXT_TIME
55698 13-JUN-11 13-JUN-11
55699 13-JUN-11 13-JUN-11
55700 13-JUN-11 13-JUN-11
55701 13-JUN-11 13-JUN-11
15206 rows selected.
Additional Information :
There is a delay of 20 minutes before the logs get applied. which has been intentional set by team.
Any help will be highly appreciated. Thanks in advance
SadiqHi,
Primary Database:
select status,checkpoint_count from v$datafile_header;
STATUS CHECKPOINT_COUNT
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
STATUS CHECKPOINT_COUNT
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 672472065
ONLINE 59736
ONLINE 59736
ONLINE 59736
ONLINE 59736
ONLINE 59736
STATUS CHECKPOINT_COUNT
ONLINE 57717
ONLINE 57717
57 rows selected.
Standby Database;
select status,checkpoint_count from v$datafile_header;
STATUS CHECKPOINT_COUNT
ONLINE 672445072
ONLINE 672445072
ONLINE 672445072
ONLINE 672445072
ONLINE 672445072
ONLINE 672445072
ONLINE 672445072
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
STATUS CHECKPOINT_COUNT
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
ONLINE 672445071
ONLINE 32742
ONLINE 32742
ONLINE 32742
ONLINE 32742
ONLINE 32742
STATUS CHECKPOINT_COUNT
ONLINE 30723
ONLINE 30723
57 rows selected.
Archieve log list :
Primary database:
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 49110
Next log sequence to archive 49111
Current log sequence 49111
Standby Database:
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 49110
Next log sequence to archive 0
Current log sequence 49111
I tried log switch multiple times in primary database i saw that its getting highlighted in standby database. -
Drop a datafile from physical standby's control file
Hi,
I am trying to create a physical standby database for my production...
1) I have taken cold backup of my primary database on 18-Nov-2013...
2) I added a datafile on 19-nov-2013 ( 'O:\ORADATA\SFMS\SFMS_DATA4.DBF' )
3) Standby control file was generated on 20-ov-2013 (today) after shutting down and then mounting the primary database...
When i try to recover the newly setup standby using archive files, i am getting the following error (datafile added on 19th Nov is missing)
SQL> recover standby database;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 39: 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
How to overcome this situation...
Can i delete the entry for the newly added datafile from the backup control file ?
When i tried to delete datafile using "alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF';", it is showing that database should be open..
SQL> alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ERROR at line 1:
ORA-01109: database not open
SQL> show parameter STANDBY_FILE_MANAGEMENT
NAME TYPE VALUE
standby_file_management string AUTO
SQL> alter system set STANDBY_FILE_MANAGEMENT=manual;
System altered.
SQL> show parameter STANDBY_FILE_MANAGEMENT
NAME TYPE VALUE
standby_file_management string MANUAL
SQL> alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ERROR at line 1:
ORA-01109: database not open
Regards,
JibuJibu wrote:
Hi,
I am trying to create a physical standby database for my production...
1) I have taken cold backup of my primary database on 18-Nov-2013...
2) I added a datafile on 19-nov-2013 ( 'O:\ORADATA\SFMS\SFMS_DATA4.DBF' )
3) Standby control file was generated on 20-ov-2013 (today) after shutting down and then mounting the primary database..
Hi,
What is your version?
If you added new datafile or created new tablespace, take backup again for restore new created standby database.
If your standby database running well, DG configuration success, then this datafile will create on standby side, too.
Set STANDBY_FILE_MANAGEMENT=AUTO best practice.
When i try to recover the newly setup standby using archive files, i am getting the following error (datafile added on 19th Nov is missing)
SQL> recover standby database;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 39: 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ORA-01157: cannot identify/lock data file 39 - see DBWR trace file
ORA-01110: data file 39: 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
How to overcome this situation...
Can i delete the entry for the newly added datafile from the backup control file ?
Not need any delete datafile from standby side, you must recreate standby database, or you can take RMAN backup and restore to standby side again.
When i tried to delete datafile using "alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF';", it is showing that database should be open..
SQL> alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ERROR at line 1:
ORA-01109: database not open
SQL> show parameter STANDBY_FILE_MANAGEMENT
NAME TYPE VALUE
standby_file_management string AUTO
SQL> alter system set STANDBY_FILE_MANAGEMENT=manual;
System altered.
SQL> show parameter STANDBY_FILE_MANAGEMENT
NAME TYPE VALUE
standby_file_management string MANUAL
SQL> alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
alter tablespace SFMS_BR_DATA drop datafile 'O:\ORADATA\SFMS\SFMS_DATA4.DBF'
ERROR at line 1:
ORA-01109: database not open
It is not logical, Physical standby must be bit-for-bit same with Primary database.
Regards
Mahir M. Quluzade -
Unable to open the physical standby in read only (10g)
Hi,
I m trying to create physical standby using RMAN to another server . But at the last step when trying to test Real Time Apply i m unable to open the standby in read only mode.Can Anyone please let me know whats the issue and how to resolve it
SQL> select status from v$instance;
STATUS
MOUNTED
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database open read only;
alter database open read only
ERROR at line 1:
ORA-16004: backup database requires recovery
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1:
'/u01/app/oracle/product/10.2.0/oradata/test1/system.dbf'Hi,
This is a newly created standby. I created just now. Below the o/p requested
In Primary
SQL> set line 200
SQL> set pagesize 200
SQL> col message format a90
SQL> select severity, error_code, to_char(timestamp,'DD-MON-YYYY HH24:MI:SS'), message from v$dataguard_status where dest_id=2;
SEVERITY ERROR_CODE TO_CHAR(TIMESTAMP,'D MESSAGE
Error 12541 04-MAR-2012 11:55:05 PING[ARC1]: Heartbeat failed to connect to standby 'test1'. Error is 12541.
Error 12541 04-MAR-2012 12:00:12 PING[ARC1]: Heartbeat failed to connect to standby 'test1'. Error is 12541.
Error 1034 04-MAR-2012 12:06:25 PING[ARC1]: Heartbeat failed to connect to standby 'test1'. Error is 1034.
Warning 3113 04-MAR-2012 13:21:24 ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
Warning 3113 04-MAR-2012 13:21:24 ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Error 3113 04-MAR-2012 13:21:24 PING[ARC1]: Error 3113 when pinging standby test1.
Warning 3113 04-MAR-2012 13:33:29 ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
Warning 3113 04-MAR-2012 13:33:29 ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Error 3113 04-MAR-2012 13:33:29 PING[ARC1]: Error 3113 when pinging standby test1.
Error 1034 04-MAR-2012 13:39:50 PING[ARC1]: Heartbeat failed to connect to standby 'test1'. Error is 1034.
Error 1034 04-MAR-2012 13:45:29 PING[ARC1]: Heartbeat failed to connect to standby 'test1'. Error is 1034.
Warning 3113 04-MAR-2012 13:57:56 ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
Warning 3113 04-MAR-2012 13:57:56 ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Error 3113 04-MAR-2012 13:57:56 PING[ARC1]: Error 3113 when pinging standby test1.
14 rows selected.
SQL> select ds.dest_id id
, ad.status
, ds.database_mode db_mode
, ad.archiver type
, ds.recovery_mode
, ds.protection_mode
, ds.standby_logfile_count "SRLs"
, ds.standby_logfile_active active
, ds.archived_seq#
from v$archive_dest_status ds
, v$archive_dest ad
where ds.dest_id = ad.dest_id
and ad.status != 'INACTIVE'
order by
ds.dest_id
/ 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
ID STATUS DB_MODE TYPE RECOVERY_MODE PROTECTION_MODE SRLs ACTIVE ARCHIVED_SEQ#
1 VALID OPEN ARCH IDLE MAXIMUM PERFORMANCE 0 0 64
2 VALID UNKNOWN ARCH UNKNOWN MAXIMUM PERFORMANCE 3 0 64In standby
SQL> select thread#,max(sequence#) from v$archived_log where applied='YES' group by thread#;
THREAD# MAX(SEQUENCE#)
1 64
SQL> select thread#,max(sequence#) from v$archived_log group by thread#;
THREAD# MAX(SEQUENCE#)
1 64
SQL> select message from v$dataguard_status;
MESSAGE
ARC0: Archival started
ARC1: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC0: Becoming the heartbeat ARCH
Attempt to start background Managed Standby Recovery process
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery starting Real Time Apply
Media Recovery Waiting for thread 1 sequence 63
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
MESSAGE
RFS[1]: Assigned to RFS process 9880
RFS[1]: Identified database type as 'physical standby'
Media Recovery Log /u01/app/oracle/product/10.2.0/archive/test1/1_63_776981781.arc
Media Recovery Log /u01/app/oracle/product/10.2.0/archive/test1/1_64_776981781.arc
Media Recovery Waiting for thread 1 sequence 65
16 rows selected. -
Problems while creating a physical Standby
Hi,
I am trying to setup a physical standby database with oracle 10g.
I configured a specific log archive destination:
LOG_ARCHIVE_DEST_3 = 'SERVICE=ORAMPSEC REOPEN=60 MAX_FAILURE=3 LGWR SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORAMPSEC'
The service is reachable via network.
To establish the standby database I copied all datafiles from the primary database using scp. I also created a standby controlfile and a modified pfile. In addition I added a standby redo logfile which has the same size as the online redo log files on the primary database.
After starting the standby database in open read only mode I receive the following error message:
Database mounted.
ORA-16004: backup database requires recovery
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oradata/ORAMPPRD/data/system01.dbf'
I tried to recover using "recover standby database" I receive the following message:
ORA-00279: change 884348 generated at 07/18/2006 17:08:07 needed for thread 1
ORA-00289: suggestion : /oradata/ORAMPPRD/archive/1_30_595767954.dbf
ORA-00280: change 884348 for thread 1 is in sequence #30
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Although I transmitted all archived log files from the primary database the archived log file mentioned above is not available. After hitting RETURN I get this message:
ORA-00308: cannot open archived log
'/oradata/ORAMPPRD/archive/1_30_595767954.dbf'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oradata/ORAMPPRD/data/system01.dbf'
Here is a listing of all archived logfiles from the primary database:
bash-3.00$ ls -latr
total 494144
drwxr-xr-x 6 oracle oinstall 512 Jul 14 11:03 ..
-rw-r----- 1 oracle oinstall 20732928 Jul 17 11:47 1_6_595767954.dbf
-rw-r----- 1 oracle oinstall 86013440 Jul 17 13:56 1_7_595767954.dbf
-rw-r----- 1 oracle oinstall 214016 Jul 17 13:57 1_8_595767954.dbf
-rw-r----- 1 oracle oinstall 1986560 Jul 17 14:10 1_9_595767954.dbf
-rw-r----- 1 oracle oinstall 150016 Jul 17 14:10 1_10_595767954.dbf
-rw-r----- 1 oracle oinstall 504320 Jul 17 14:17 1_11_595767954.dbf
-rw-r----- 1 oracle oinstall 1807872 Jul 17 14:22 1_12_595767954.dbf
-rw-r----- 1 oracle oinstall 589824 Jul 17 14:25 1_13_595767954.dbf
-rw-r----- 1 oracle oinstall 1190912 Jul 17 14:37 1_14_595767954.dbf
-rw-r----- 1 oracle oinstall 584704 Jul 17 14:42 1_15_595767954.dbf
-rw-r----- 1 oracle oinstall 80896 Jul 17 14:45 1_16_595767954.dbf
-rw-r----- 1 oracle oinstall 6050816 Jul 17 15:08 1_17_595767954.dbf
-rw-r----- 1 oracle oinstall 4238848 Jul 17 16:04 1_18_595767954.dbf
-rw-r----- 1 oracle oinstall 4920832 Jul 17 17:21 1_19_595767954.dbf
-rw-r----- 1 oracle oinstall 1520128 Jul 17 17:30 1_20_595767954.dbf
-rw-r----- 1 oracle oinstall 360960 Jul 17 17:35 1_21_595767954.dbf
-rw-r----- 1 oracle oinstall 89186304 Jul 18 10:52
1_22_595767954.dbf
-rw-r----- 1 oracle oinstall 16216576 Jul 18 14:18
1_23_595767954.dbf
-rw-r----- 1 oracle oinstall 12288 Jul 18 14:18 1_24_595767954.dbf
-rw-r--r-- 1 oracle oinstall 2073 Jul 18 14:26 sqlnet.log
-rw-r----- 1 oracle oinstall 14387200 Jul 18 16:56
1_25_595767954.dbf
-rw-r----- 1 oracle oinstall 116736 Jul 18 16:58 1_26_595767954.dbf
-rw-r----- 1 oracle oinstall 1536000 Jul 18 17:04 1_27_595767954.dbf
-rw-r----- 1 oracle oinstall 156672 Jul 18 17:05 1_28_595767954.dbf
drwxr-xr-x 2 oracle oinstall 1024 Jul 18 17:08 .
-rw-r----- 1 oracle oinstall 65536 Jul 18 17:08 1_29_595767954.dbf
Nothing known about the *30*dbf file.
Although there still seems to be something wrong, the archived log file transmission seems to work since there is no error reported on the log archive destination:
SQL> select status, error from v$archive_dest where dest_id = 3;
STATUS ERROR
VALID
And after I manually force a log switch I see that archived redo logs were applied on the standby database:
select sequence#, applied from v$archived_log order by sequence#;
SEQUENCE# APPLIED
27 YES
28 NO
28 YES
29 NO
29 YES
Unfortunately because of the recovering problem I cannot open the database to see if the changes were applied. So my first question is, how can I get the standby database completely recovered ??
In addition to this I was expecting that the changes to the standby database were made immediately since I choosed LGWR sync but I have to manually force the logfile switch. As I already mentioned a standby redo log file is available as well.
Thanks for your help,
Philipp.Hi,
since it does not seem to work with just copying the datafiles I switched to RMAN. I created a full database backup from Enterprise Manager. Similiar to http://dizwell.com/main/content/view/81/122/1/1/ I tried to duplicate the database to the standby instance (running on a different server). But unfortunately I receive error messages that the files, previously created, cannot be found:
channel d1: starting datafile backupset restore channel d1: specifying datafile(s) to restore from backup set restoring datafile 00001 to /oradata/ORAMPPRD/data/1.dbf restoring datafile 00002 to /oradata/ORAMPPRD/data/2.dbf restoring datafile 00003 to /oradata/ORAMPPRD/data/3.dbf restoring datafile 00004 to /oradata/ORAMPPRD/data/4.dbf channel d1: reading from backup piece /opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1
ORA-19870: error reading backup
piece /opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1
ORA-19505: failed to identify file
"/opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1"
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory Additional information: 3 failover to previous backup
But when I crosscheck my backup inside RMAN it clearly shows the backup files:
RMAN> crosscheck backup;
backup piece
handle=/opt/oracle/ora10/product/10.2.0.1.0/dbs/0bhoiq60_1_1 recid=7
stamp=596207811
crosschecked backup piece: found to be 'AVAILABLE'
I already checked the file permissions, everybody on the system is able to access this file.
Do you know what is going wrong here ??
Cheers,
Philipp. -
Issue on physical standby database
Hi
I've a problem on standby database.
I recently added a datafile on primary database, then I scp'ed the data file to physical standby database.On physical standby database I tried performing recovery.
I get following message in my alert log
WARNING! Recovering data file 88 from a fuzzy file. If not the current file
it might be an online backup taken without entering the begin backup command.
ORA-279 signalled during: ALTER DATABASE RECOVER standby database ...
how can I fix this now.
We keep physical standby database 2 day behind, and apply logs manually.
Physical standby database is maintained manually.
Could someone help me in getting out of this problem.
Oracle 9.2.0.7
solarisVersus keeping it in manual mode, you can specify a time "delay" for the application of the logs:
From http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/log_apply.htm#i1022811
6.2.2 Specifying a Time Delay for the Application of Archived Redo Log Files
In some cases, you may want to create a time lag between the time when redo data is received from the primary site and when it is applied to the standby database. You can specify a time interval (in minutes) to protect against the application of corrupted or erroneous data to the standby database. When you set a DELAY interval, it does not delay the transport of the redo data to the standby database. Instead, the time lag you specify begins when the redo data is completely archived at the standby destination.
Note:
If you define a delay for a destination that has real-time apply enabled, the delay is ignored.
Specifying a Time Delay
You can set a time delay on primary and standby databases using the DELAY=minutes attribute of the LOG_ARCHIVE_DEST_n initialization parameter to delay applying archived redo log files to the standby database. By default, there is no time delay. If you specify the DELAY attribute without specifying a value, then the default delay interval is 30 minutes.
Canceling a Time Delay
You can cancel a specified delay interval as follows:
For physical standby databases, use the NODELAY keyword of the RECOVER MANAGED STANDBY DATABASE clause:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
For logical standby databases, specify the following SQL statement:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
These commands result in log apply services immediately beginning to apply archived redo log files to the standby database, before the time interval expires. Also, see:
Section 12.8, "Using a Physical Standby Database with a Time Lag"
Oracle Database SQL Reference for the DELAY attribute of the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement -
Online redo logs on a physical standby?
A question on REDO logs on physical standby databases. (10.2.0.4 db on Windows 32bit)
My PRIMARY has 3 ONLINE REDO groups, 2 members each, in ..ORADATA\LOCP10G
My PHYSICAL STANDBY has 4 STANDBY REDO groups, 2 members each, in ..ORADATA\SBY10G
I have shipping occurring from the primary in LGWR, ASYNC mode - max availablility
However I notice the STANDBY also has ONLINE REDO logs, same as the PRIMARY, in the ..ORADATA\SBY10G folder
According to the 10g Dataguard docs, section 2.5.1:
"Physical standby databases do not use an online redo log, because physical standby databases are not opened for read/write I/O."
I have tried to drop these on the STANDBY when not in apply mode, but I get the following:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Database altered.
SQL> ALTER DATABASE DROP LOGFILE GROUP 3;
ALTER DATABASE DROP LOGFILE GROUP 3
ERROR at line 1:
ORA-01275: Operation DROP LOGFILE is not allowed if standby file management is
automatic.
I also deleted them while the STANDBY instance was idle, but it recreated them when moved to MOUNT mode.
So my question is why is my PHYSICAL recreating and using these, if the docs say the shouldn't?
I saw the same error mentioned here: prob. with DataGuard
Is this a case of the STANDBY needing at least a notion of where the REDO logs will need to be should a failover occur, and if the files are already there, the standby database CONTROLFILE will hold onto them, as they are not doing any harm anyway?
Or, is this a prooduct of having management=AUTOMATIC - i.e. the database will create these 'automatically'
Ta
btAccording to the 10g Dataguard docs, section 2.5.1:
"Physical standby databases do not use an online redo log, because physical standby databases are not opened for read/write I/O."yes, those are used when database is open.
You should not perform any changes in Standby. Even if those exist online redo log files, whats the difficulty you have seen?
These will be used whenever you performed switchover/failover. So nothing to worry on this.
Is this a case of the STANDBY needing at least a notion of where the REDO logs will need to be should a failover occur, and if the files are already there, the standby database CONTROLFILE will hold onto them, as they are not doing any harm anyway?Then oracle functionality itself harm if you think in that way. When they not used in open then what the harm with that?
Standby_File_management --> for example if you add any datafile, those information will be in archives/redos once they applied on standby those will be added automatically when it is set to AUTO if its manual, then it creates a unnamed file in $ORACLE_HOME/dbs location later you have to rename that file and recovery need to perform .
check this http://docs.oracle.com/cd/B14117_01/server.101/b10755/initparams206.htm
HTH.
Maybe you are looking for
-
Problem in variable substitution
Hi experts, I need help for a strange problem: I have a proxy to file scenario in which I create an xml file; I need to use a field of the mapping to create filename. In Receiver CChannel I have used variable substitution, but in message monitoring I
-
Problem setting up 5Ghz security on WRT610Nv2 2.00.00.B05
Was able to set up my WRT610v2 to use WEP on the 2.4 Ghz side with the same key as my old router and my network is running fine. When I go to set up the 5Ghz side however I'm seeing a really odd problem even the Cisco tech rep I chatted with could n
-
I just upgraded to CF Builder 2 yesterday. I did a clean install along with grabbing version 3.6.2 64 bit version of eclipse. Everything was fine at first but now any time I launch eclipse and the Builder Plugin starts up I keep seeing a message in t
-
Hi I want to know, 1. System requirement for VM based Sharepoint 2013 development environment for minimum 3 user's 2. SharePoint Topologies based on system architecture,system requirements 3. General SharePoint Development env
-
Hi, I have tried to load up software for an Epson 1270 A3 printer and perfection 1200 scanner on my Mac mini OSX 4.7. OSX won't read the installation programs on the CD's. Does anyone know if there are OSX compatible drivers avaialable for download a