Recovery in standby

Hello DBAs
I have been thinking about the below scenerio for the last two weeks, but still have doubts.
I have a primary database and a standby database ( not a real standby,it is in mount state, and
I apply archivelogs manually).
I will rebuild some tablespaces from DMT to LMT.
After I move the data inside the test1 I will issue:
drop tablespace test1;
create tablespace test1
datafile 'C:\oraclexe\oradata\XE\test1.dbf' reuse;
Move the data back to the test1;
Again, I move the data inside the test2 and issue:
drop tablespace test2;
create tablespace test2
datafile 'C:\oraclexe\oradata\XE\test2.dbf' reuse;
Move the data back to the test2;
So on...
What I want to ask is, during recovery I hit an error message in standby database.
What should I do in standby database in this issue?
If I copy the controlfile from primary database and issue:
alter database create datafile 'C:\oraclexe\oradata\XE\test1.dbf' as 'C:\oraclexe\oradata\XE\test1.dbf';
alter database create datafile 'C:\oraclexe\oradata\XE\test2.dbf' as 'C:\oraclexe\oradata\XE\test2.dbf';
and then start recovery, will it solve the problem?
I am not sure if I need to copy controlfile or something else?

Can you provide the error message that you are receiving from the standby database?
Alfredo

Similar Messages

ORA-279 signalled during recovery of standby database

Hi All,
I am preparing standby database after taking hot backup and copying those datafiles to standby,
taken controlfile standby controlfile backup from primary
mounted the standby database using standby controlfile using
startup nomount pfile='/u01/stand.ora'
alter database mount standby database;
Now I have started applying archives on standby database after copying all archives from primary to standby box the archives generated during backup using..
recover standby database;
But I am getting the below warning on the recovery screen...
ORA-00279: change 51667629050 generated at 07/02/2009 00:59:43 needed for
thread 1
ORA-00289: suggestion : /nodal-archive/archive/1_55118_652209172.arc
ORA-00280: change 51667629050 for thread 1 is in sequence #55118
ORA-00278: log file '/nodal-archive/archive/1_55117_652209172.arc' no longer
needed for this recovery
ORA-00279: change 51667703096 generated at 07/02/2009 01:06:04 needed for
thread 1
ORA-00289: suggestion : /nodal-archive/archive/1_55119_652209172.arc
ORA-00280: change 51667703096 for thread 1 is in sequence #55119
ORA-00278: log file '/nodal-archive/archive/1_55118_652209172.arc' no longer
needed for this recovery
ORA-00279: change 51667767649 generated at 07/02/2009 01:12:28 needed for
thread 1
ORA-00289: suggestion : /nodal-archive/archive/1_55120_652209172.arc
ORA-00280: change 51667767649 for thread 1 is in sequence #55120
ORA-00278: log file '/nodal-archive/archive/1_55119_652209172.arc' no longer
needed for this recovery
ORA-00279: change 51667831821 generated at 07/02/2009 01:19:40 needed for
thread 1
ORA-00289: suggestion : /nodal-archive/archive/1_55121_652209172.arc
ORA-00280: change 51667831821 for thread 1 is in sequence #55121
ORA-00278: log file '/nodal-archive/archive/1_55120_652209172.arc' no longer
needed for this recovery
and I am getting the below warning on the alert log..........
Sun Jul 5 18:37:36 2009
ALTER DATABASE RECOVER CONTINUE DEFAULT
Sun Jul 5 18:37:36 2009
Media Recovery Log /nodal-archive/archive/1_55256_652209172.arc
Sun Jul 5 18:40:31 2009
ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Sun Jul 5 18:40:31 2009
ALTER DATABASE RECOVER CONTINUE DEFAULT
Sun Jul 5 18:40:31 2009
Media Recovery Log /nodal-archive/archive/1_55257_652209172.arc
Please suggest what to do now.............
Thanks in Advance,
Sukanta Paul.

Hi Sukanta,
I didn't really understand what the problem is...
Let me explain, hope it will be clear.
You created a standby control file, and backed up the database (it doesn't matter in which order). Now, you have a standby database that is ready to apply logs. It will be able to apply log forever, until we will stop it.
The messages you see say the following:
ORA-00279: change 51667831821 generated at 07/02/2009 01:19:40 needed for thread 1 {color:blue} - this says that the recovery process is now at scn 51667831821 {color}
ORA-00289: suggestion : /nodal-archive/archive/1_55121_652209172.arc {color:blue} - the information needed for the recover is in this file (this is only the default name, you can choose other name if the file is called differently) {color}
ORA-00280: change 51667831821 for thread 1 is in sequence #55121 {color:blue} - same here, the needed archive is sequence 55121 {color}
ORA-00278: log file '/nodal-archive/archive/1_55120_652209172.arc' no longer needed for this recovery {color:blue} - this message is after Oracle has applied the log, and it means that this log is no longer needed {color}
Now it will wait for the next log. Again, this process is endless, this is how it is made to allow the standby database to be always synched with the primary.
Liron Amitzi
Senior DBA consultant
[www.dbsnaps.com]
[www.orbiumsoftware.com]

MANAGED RECOVERY AT STANDBY DATABASE REQURING OLD ARCHIVELOGS ORA-00308

Oracle 9.2.0.4
HP-UX 11.11i
The database in Archivelog mode, single standby database in managed recovery
mode.
keeping standby in sync with manual applying the ARCHIVELOG from primary to
standby database.
primary database was 3 REDO log members of 100 MB with 1 member each.
what i did, 1 drop and re-create the INACTIVE REDO group for all three, and
make them
5 REDO logs of 200 MB with 1 member each,
then in order to keep fresh copy of primary database onto standby database, i
send the cold backup after 15 days (last week) with standby controlfile.
now, with that standby controlfile and the database, i can mount the database
but while to open the database, receives messages as , it requiring the
ARCHIVELOGS generated log time ago.
changes the REDO groups from 3 to 5 and size 100 to 200 MB at INACTIVE state
### Workarounds Used ###
SQL> alter database mount standby database;
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: '/user01/oracle9i/oradata/iobasprd/system01.dbf'
SQL> alter database recover automatic standby database;
alter database recover automatic standby database
ERROR at line 1:
ORA-00279: change 1655989696 generated at 08/12/2005 12:46:25 needed for thread
1
ORA-00289: suggestion :
/user02/oracle9i/oradata/iobasprd/archive/archive_16849.dbf
ORA-00280: change 1655989696 for thread 1 is in sequence #16849
ORA-00278: log file
'/user02/oracle9i/oradata/iobasprd/archive/archive_16849.dbf' no longer needed
for this recovery
ORA-00308: cannot open archived log
'/user02/oracle9i/oradata/iobasprd/archive/archive_16849.dbf'
ORA-27037: unable to obtain file status
HP-UX Error: 2: No such file or directory
Additional information: 3
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /user02/oracle9i/oradata/iobasprd/archive
Oldest online log sequence 53052
Next log sequence to archive 53056
Current log sequence
53056
-----------------------AlertIOBASPRD.log----------------------------
alter database mount standby database
Mon Oct 24 12:05:05 2005
Successful mount of redo thread 1, with mount id 3283884781.
Mon Oct 24 12:05:05 2005
Standby Database mounted.
Completed: alter database mount standby database
Mon Oct 24 12:05:12 2005
alter database open read only
ORA-16004 signalled during: alter database open read only...
Mon Oct 24 12:05:23 2005
alter database recover automatic standby database
Mon Oct 24 12:05:23 2005
Media Recovery Start
Starting datafile 1 recovery in thread 1 sequence 52617
Datafile 1: '/user01/oracle9i/oradata/iobasprd/system01.dbf'
Starting datafile 2 recovery in thread 1 sequence 52617
Datafile 2: '/user01/oracle9i/oradata/iobasprd/TBMS_TS_005.dbf'
Starting datafile 3 recovery in thread 1 sequence 52617
Datafile 3: '/user01/oracle9i/oradata/iobasprd/drsys01.dbf'
Starting datafile 4 recovery in thread 1 sequence 52617
Datafile 132: '/user01/oracle9i/oradata/iobasprd/TBMS_TS_002.dbf'
Starting datafile 133 recovery in thread 1 sequence 52617
Datafile 133: '/user01/oracle9i/oradata/iobasprd/TBMS_TS_003.dbf'
Starting datafile 134 recovery in thread 1 sequence 52617
Datafile 134: '/user01/oracle9i/oradata/iobasprd/TBMS_TS_004.dbf'
Media Recovery Log
Media Recovery Log /user02/oracle9i/oradata/iobasprd/archive/archive_16849.dbf
Errors with log /user02/oracle9i/oradata/iobasprd/archive/archive_16849.dbf.
ORA-279 signalled during: alter database recover automatic standby database...
Mon Oct 24 12:06:01 2005
Restarting dead background process QMN0
QMN0 started with pid=9
The snap of alertIOBASPRD.log can understand me that it requiring the
ARCHIVELOG 52617 only
and its lying in LOG_ARCHIVE_DET location also as
$ pwd
/user02/oracle9i/oradata/iobasprd/archive
$ ls archive_5261*.dbf
archive_52610.dbf archive_52613.dbf archive_52616.dbf archive_52619.dbf
archive_52611.dbf archive_52614.dbf archive_52617.dbf
archive_52612.dbf archive_52615.dbf archive_52618.dbf
$
now, even the files are lying , why ORACLE requing the old archive logs ?????

You haven't given any usefuly information on your problem.
show parameter log_archive_dest
show parameter fal
show parameter dg
What errors are in your alert logs ?
What command are you using to recover ?
Check the contents of v$archived_log
# run on primary to detect failures :-
select destination, status, fail_date, valid_now
from v$archive_dest
where status != 'VALID' or VALID_NOW != 'YES';
# run on standby to get exact position of rollforward :-
select thread#, to_char(snapshot_time,'dd-mon-yyyy:hh24:mi'),
to_char(applied_time,'dd-mon-yyyy:hh24:mi'),
to_char(newest_time,'dd-mon-yyyy:hh24:mi') from V$STANDBY_APPLY_SNAPSHOT;
Are you using dataguard broker ?

Script for auto recovery of standby node - Simple dataguard

Hi.
I have set up several solutions with Oracle SE and simple dataguard on linux.
On physical standby, I have created a script which performs the recovery every 15 minuts:
source /u01/app/oracle/sb_scripts/.profile_websb
/u01/app/oracle/product/10.2.0/bin/sqlplus "/ as sysdba" <<EOFSQL
recover automatic standby database;
exit;
EOFSQL
However, I am trying to perform the same on a windows environment but struggles a bit with the script.
Initally I tried %ORACLE_HOME%\bin\sqlplus / as sysdba @c:\scripts\recover.sql
Where recover.sql has been:
recover automatic standby database;
exit;
and :
recover automatic standby database until cancel;
alter database recover cancel;
exit;
Neither of these exits the bat scripts but awaits user input on CANCEL after the last archived log has been added.
Anyone with a bright idea on how to solve this?
Thanks.
Kjell Ove

Kjell wrote:
Hi.
I have set up several solutions with Oracle SE and simple dataguard on linux.
On physical standby, I have created a script which performs the recovery every 15 minuts:
source /u01/app/oracle/sb_scripts/.profile_websb
/u01/app/oracle/product/10.2.0/bin/sqlplus "/ as sysdba" <<EOFSQL
recover automatic standby database;
exit;
EOFSQL
However, I am trying to perform the same on a windows environment but struggles a bit with the script.
Initally I tried %ORACLE_HOME%\bin\sqlplus / as sysdba @c:\scripts\recover.sql
Where recover.sql has been:
recover automatic standby database;
exit;
and :
recover automatic standby database until cancel;
alter database recover cancel;
exit;
Neither of these exits the bat scripts but awaits user input on CANCEL after the last archived log has been added.
Anyone with a bright idea on how to solve this?
Thanks.
Kjell OveKjell
This script I use for windows (linked from my old site at http://www.niall.litchfield.dial.pipex.com/ ) uses
alter database recover automatic standby database until cancel;
alter database recover cancel;Note the extra alter database I'll admit I haven't run this personally in 2 or 3 years now.
Niall Litchfield
http://www.orawin.info/
Edited by: Niall Litchfield on Apr 23, 2009 10:21 AM can't use bold in code apparently.

Recovery Logical Standby with RMAN

Hi All,
I have a test environment with Primary DB Server, Physical Standby and Logical Standby.
The Logical Standby DB (cur_log_stdb) is backed up every evening by RMAN and I have a question:
If I recover my Logical Standby DB from backup and switch replication to new Logical Standby DB (new_log_stdb) it will work or not?
My steps e.g.:
1. Make a new server for my new_log_stdb and repair structure of catalogs;
2. Repair listener.ora and tnsnames.ora files from cur_log_stdb to new_log_stdb;
3. Restore DB with RMAN from backup to new_log_stdb;
4. On cur_log_stdb execute "alter database stop logical standby apply";
5. Change a DNS name from cur_log_stdb to new_log_stdb;
6. On new_log_stdb execute "alter database start logical standby apply immediate";
I'm not sure that archivelogs will apply to the new_log_stdb for period since rman backup was created.
Configuration:
Oracle Linux 6.4
Oracle Database 11.2.0.3
Primary and Physical with Data Guard

You might get better responses in the DataGuard forum ("space").
I am sceptical if this plan would work.
Hemant K Chitale

Switching between Primary and Standby database

Hi,
I managed to setup a standby database that is updated by the primary db either when doing a log file switch or when changing the role of the primary db to standby.
Now I want to put the standby database (that was in primary role for a short period) back into its standby role. I entered
"Alter database commit to switchover to physical standby with session shutdown;"
The archived redo logs as well as the control file are updated on the primary database (which was in standby role for the same short period). When I enter
"Alter database commit to switchover to primary" I am receiving the following error message:
SQL> alter database commit to switchover to primary;
alter database commit to switchover to primary
ERROR at line 1:
ORA-16139: media recovery required
After issuing the recovery statement I get this message:
SQL> recover database
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
At the same time this log entry is written into the alert log:
Database not available for switchover
End-Of-REDO archived log file has been received
Archived log files detected beyond End-Of-REDO
Incomplete recovery SCN:0:962365 archive SCN:0:977340
Switchover: Media recovery required - standby not in limbo
ORA-16139 signalled during: alter database commit to switchover to primary...
But when I try to use the BACKUP CONTROLFILE statement during recovery I get this error message:
SQL> recover database using backup controlfile;
ORA-00283: recovery session canceled due to errors
ORA-01666: control file is for a standby database
Although being quite a newbie it's obvious that the primary database (which was standby for a short period) is worried that there are older archived redo logs than online logs. I guess this happens because of the log_archive_dest definition on the standby database :
*.LOG_ARCHIVE_DEST_3='SERVICE=ORAMPPRD REOPEN=60 MAX_FAILURE=3 LGWR SYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ORAMPPRD'
Changes are applied immediately and only written to the archive.
But how can it be managed that the online redo logs on the primary system are also updated when switching back from standby ???
Thanks,
Philipp.

Thanks, it's working now.
I think it's important to explizitely follow the steps to switchover standby and primary for it to work. I maybe shutdown the standby to early.
Cheers,
Philipp.

Standby database error

Hi Guys..
I am using oracle 10.2.0.4.0 on windows 2003 server. I created a physical standby database successfully.
On standby database, I fired the following query
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#
SEQUENCE# FIRST_TIM NEXT_TIME
10715 02-AUG-10 02-AUG-10
10716 02-AUG-10 02-AUG-10
10717 02-AUG-10 03-AUG-10
10718 03-AUG-10 03-AUG-10
10719 03-AUG-10 03-AUG-10
10720 03-AUG-10 03-AUG-10
10721 03-AUG-10 03-AUG-10
10722 03-AUG-10 03-AUG-10
10723 03-AUG-10 03-AUG-10
10724 03-AUG-10 03-AUG-10
10725 03-AUG-10 03-AUG-10
SEQUENCE# FIRST_TIM NEXT_TIME
10726 03-AUG-10 03-AUG-10
10727 03-AUG-10 03-AUG-10
10728 03-AUG-10 03-AUG-10
10729 03-AUG-10 03-AUG-10
I then did alter system switch logfile on primary database
Then on standby I fired the above query
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#
SEQUENCE# FIRST_TIM NEXT_TIME
10715 02-AUG-10 02-AUG-10
10716 02-AUG-10 02-AUG-10
10717 02-AUG-10 03-AUG-10
10718 03-AUG-10 03-AUG-10
10719 03-AUG-10 03-AUG-10
10720 03-AUG-10 03-AUG-10
10721 03-AUG-10 03-AUG-10
10722 03-AUG-10 03-AUG-10
10723 03-AUG-10 03-AUG-10
10724 03-AUG-10 03-AUG-10
10725 03-AUG-10 03-AUG-10
SEQUENCE# FIRST_TIM NEXT_TIME
10726 03-AUG-10 03-AUG-10
10727 03-AUG-10 03-AUG-10
10728 03-AUG-10 03-AUG-10
10729 03-AUG-10 03-AUG-10
*10730 03-AUG-10 03-AUG-10*
My question is everytime I do alter systyem switch logfile on primary , two trace files are generated on primary database which are:
stutest_lns1_5764.trc
Dump file c:\oracle\admin\stutest\bdump\stutest_lns1_5764.trc
Tue Aug 03 15:50:35 2010
ORACLE V10.2.0.4.0 - 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows Server 2003 Version V5.2 Service Pack 2
CPU : 8 - type 8664, 2 Physical Cores
Process Affinity : 0x0000000000000000
Memory (Avail/Total): Ph:8414M/16378M, Ph+PgF:10750M/17814M
Instance name: stutest
Redo thread mounted by this instance: 1
Oracle process number: 43
Windows thread id: 5764, image: ORACLE.EXE (LNS1)
*** SERVICE NAME:(SYS$BACKGROUND) 2010-08-03 15:50:35.996
*** SESSION ID:(213.29604) 2010-08-03 15:50:35.996
*** 2010-08-03 15:50:35.996 60512 kcrr.c
LNS1: initializing for LGWR communication
LNS1: connecting to KSR channel
Success
LNS1: subscribing to KSR channel
Success
*** 2010-08-03 15:50:35.996 60565 kcrr.c
LNS1: initialized successfully ASYNC=1
Destination is specified with ASYNC=61440
Redo shipping client performing standby login
*** 2010-08-03 15:50:36.043 68145 kcrr.c
Logged on to standby successfully
Client logon and security negotiation successful!
Archiving to destination STUSTDBY ASYNC blocks=20480
Allocate ASYNC blocks: Previous blocks=0 New blocks=20480
Log file opened [logno 2]
*** 2010-08-03 16:00:58.344
Archiving to destination STUSTDBY ASYNC blocks=20480
Log file opened [logno 1]
*** 2010-08-03 16:04:44.383
Archiving to destination STUSTDBY ASYNC blocks=20480
Log file opened [logno 3]
*** 2010-08-03 16:07:36.794
Archiving to destination STUSTDBY ASYNC blocks=20480
Log file opened [logno 2]
stutest_lgwr_4092.trc
Dump file c:\oracle\admin\stutest\bdump\stutest_lgwr_4092.trc
Fri Jul 30 17:01:59 2010
ORACLE V10.2.0.4.0 - 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows Server 2003 Version V5.2 Service Pack 2
CPU : 8 - type 8664, 2 Physical Cores
Process Affinity : 0x0000000000000000
Memory (Avail/Total): Ph:13601M/16378M, Ph+PgF:10927M/17814M
Instance name: stutest
Redo thread mounted by this instance: 1
Oracle process number: 6
Windows thread id: 4092, image: ORACLE.EXE (LGWR)
*** 2010-07-30 17:01:59.622
*** SERVICE NAME:() 2010-07-30 17:01:59.606
*** SESSION ID:(221.1) 2010-07-30 17:01:59.606
Maximum redo generation record size = 156160 bytes
Maximum redo generation change vector size = 150676 bytes
*** 2010-07-30 22:01:00.446
Warning: log write time 770ms, size 2KB
*** 2010-07-30 22:08:37.586
Warning: log write time 1120ms, size 9KB
*** 2010-07-30 22:08:41.258
Warning: log write time 680ms, size 7KB
*** 2010-07-30 22:09:58.244
Warning: log write time 660ms, size 1KB
*** 2010-07-30 22:11:21.388
Warning: log write time 860ms, size 6KB
*** 2010-07-30 23:42:11.203
Warning: log write time 580ms, size 1KB
*** 2010-07-31 00:04:13.917
Warning: log write time 980ms, size 8KB
*** 2010-07-31 00:06:40.422
Warning: log write time 930ms, size 22KB
*** 2010-07-31 00:08:11.940
Warning: log write time 1800ms, size 23KB
*** 2010-07-31 21:13:33.694
Warning: log write time 1460ms, size 40KB
*** 2010-07-31 21:13:39.522
Warning: log write time 2790ms, size 87KB
*** 2010-07-31 21:13:46.054
Warning: log write time 4940ms, size 69KB
*** 2010-07-31 21:13:50.038
Warning: log write time 3980ms, size 81KB
*** 2010-07-31 21:13:55.616
Warning: log write time 5580ms, size 61KB
*** 2010-07-31 21:14:01.726
Warning: log write time 6110ms, size 77KB
*** 2010-07-31 21:14:08.258
Warning: log write time 3530ms, size 140KB
*** 2010-07-31 21:14:19.508
Warning: log write time 1500ms, size 3KB
*** 2010-07-31 22:07:49.954
Warning: log write time 930ms, size 1KB
*** 2010-07-31 23:16:01.054
Warning: log write time 1080ms, size 103KB
*** 2010-07-31 23:17:52.854
Warning: log write time 1360ms, size 3KB
*** 2010-07-31 23:23:26.631
Warning: log write time 710ms, size 2KB
*** 2010-08-01 00:04:58.476
Warning: log write time 690ms, size 13KB
*** 2010-08-01 00:06:51.980
Warning: log write time 590ms, size 20KB
*** 2010-08-01 00:07:38.153
Warning: log write time 1540ms, size 28KB
*** 2010-08-01 00:08:02.748
Warning: log write time 770ms, size 64KB
*** 2010-08-01 00:11:04.628
Warning: log write time 1140ms, size 43KB
*** 2010-08-01 17:05:49.886
Warning: log write time 780ms, size 3KB
*** 2010-08-01 21:00:46.571
Warning: log write time 910ms, size 365KB
*** 2010-08-01 21:09:22.447
Warning: log write time 2910ms, size 22KB
*** 2010-08-01 21:09:27.932
Warning: log write time 4430ms, size 62KB
*** 2010-08-01 21:09:34.010
Warning: log write time 6060ms, size 74KB
*** 2010-08-01 21:09:40.088
Warning: log write time 3080ms, size 150KB
*** 2010-08-01 21:09:45.495
Warning: log write time 2410ms, size 99KB
*** 2010-08-01 21:09:50.370
Warning: log write time 4870ms, size 40KB
*** 2010-08-01 21:09:55.401
Warning: log write time 5030ms, size 82KB
*** 2010-08-01 21:09:59.151
Warning: log write time 3610ms, size 65KB
*** 2010-08-01 23:05:40.560
Warning: log write time 720ms, size 4KB
*** 2010-08-01 23:06:05.030
Warning: log write time 1670ms, size 21KB
*** 2010-08-01 23:17:55.537
Warning: log write time 1540ms, size 116KB
*** 2010-08-01 23:23:35.891
Warning: log write time 600ms, size 1KB
*** 2010-08-02 00:05:52.363
Warning: log write time 1340ms, size 48KB
*** 2010-08-02 00:06:43.427
Warning: log write time 1060ms, size 24KB
*** 2010-08-02 00:06:50.177
Warning: log write time 1730ms, size 209KB
*** 2010-08-02 00:07:08.256
Warning: log write time 950ms, size 17KB
*** 2010-08-02 00:11:25.436
Warning: log write time 1690ms, size 8KB
*** 2010-08-02 00:12:11.313
Warning: log write time 850ms, size 45KB
*** 2010-08-02 00:13:55.754
Warning: log write time 560ms, size 3KB
*** 2010-08-02 11:27:52.686
Warning: log write time 1440ms, size 46KB
*** 2010-08-02 11:27:58.780
Warning: log write time 3790ms, size 54KB
*** 2010-08-02 11:28:02.546
Warning: log write time 3760ms, size 70KB
*** 2010-08-02 11:28:08.483
Warning: log write time 5940ms, size 74KB
*** 2010-08-02 11:28:13.812
Warning: log write time 2330ms, size 139KB
*** 2010-08-02 11:28:18.796
Warning: log write time 1980ms, size 79KB
*** 2010-08-02 11:28:25.093
Warning: log write time 3360ms, size 88KB
*** 2010-08-02 11:28:29.421
Warning: log write time 4330ms, size 38KB
*** 2010-08-02 16:10:45.927
Warning: log write time 590ms, size 3KB
*** 2010-08-02 22:08:57.806
Warning: log write time 700ms, size 37KB
*** 2010-08-02 23:07:22.262
Warning: log write time 1750ms, size 234KB
*** 2010-08-02 23:13:44.993
Warning: log write time 1410ms, size 17KB
*** 2010-08-03 00:04:08.387
Warning: log write time 670ms, size 6KB
*** 2010-08-03 00:07:44.347
Warning: log write time 1890ms, size 1024KB
*** 2010-08-03 00:08:14.395
Warning: log write time 1680ms, size 1024KB
*** 2010-08-03 00:08:26.817
Warning: log write time 570ms, size 36KB
*** 2010-08-03 00:08:39.427
Warning: log write time 1540ms, size 1024KB
*** 2010-08-03 00:08:50.818
Warning: log write time 1810ms, size 1025KB
*** 2010-08-03 00:08:58.990
Warning: log write time 1640ms, size 942KB
*** 2010-08-03 00:09:21.303
Warning: log write time 1580ms, size 1024KB
*** 2010-08-03 00:09:33.710
Warning: log write time 1790ms, size 1025KB
*** 2010-08-03 00:09:42.382
Warning: log write time 1860ms, size 1024KB
*** 2010-08-03 00:09:50.945
Warning: log write time 1590ms, size 1024KB
*** 2010-08-03 10:28:34.753
Warning: log write time 2330ms, size 47KB
*** 2010-08-03 10:29:44.440
Warning: log write time 810ms, size 1KB
*** 2010-08-03 10:32:27.392
Warning: log write time 890ms, size 1KB
*** 2010-08-03 10:36:02.536
Warning: log write time 2070ms, size 8KB
*** 2010-08-03 10:44:34.174
Warning: log write time 740ms, size 7KB
*** 2010-08-03 12:04:46.687
Warning: log write time 2850ms, size 86KB
*** 2010-08-03 12:04:52.656
Warning: log write time 2970ms, size 85KB
*** 2010-08-03 12:04:54.547
Warning: log write time 1810ms, size 45KB
*** 2010-08-03 14:06:20.827
Warning: log write time 500ms, size 0KB
*** 2010-08-03 14:13:46.404
Warning: log write time 820ms, size 0KB
*** 2010-08-03 15:50:32.996
*** 2010-08-03 15:50:32.996 57052 kcrr.c
Initializing NetServer[LNS1] for dest=STUSTDBY mode ASYNC
Initializing PGA storage for Netserver communication
LNSb is not running anymore.
Check if new Async LNS1 needs to be started..
.. yes it needs to be started
Starting LNS1 ...
Subscribing to KSR Channel [id=1]
success!
Indicating recv buffer for KSR Channel [id=1]
success
Waiting for LNS1 to initialize itself
*** 2010-08-03 15:50:36.012 57343 kcrr.c
Netserver LNS1 [pid 5764] for mode ASYNC has been initialized
Performing a channel reset to ignore previous responses
Connecting as publisher to KSR Channel [id=1]
Successfully started LNS1 [pid 5764] for dest STUSTDBY mode ASYNC ocis=0x00000000144AE5B0
*** 2010-08-03 15:50:36.012 57846 kcrr.c
Making upiahm request to LNS1 [pid 5764]: Begin Time is <08/03/2010 15:50:32>. NET_TIMEOUT = <10> seconds
*** 2010-08-03 16:00:58.266
*** 2010-08-03 16:00:58.266 57052 kcrr.c
Initializing NetServer[LNS1] for dest=STUSTDBY mode ASYNC
LNSb is not running anymore.
Check if new Async LNS1 needs to be started..
Previous Async LNS1 [pid 5764] is running .. no need to start another one
LGWR detected that Async LNS1 [pid 5764] is already running
*** 2010-08-03 16:04:44.289
*** 2010-08-03 16:04:44.289 57052 kcrr.c
Initializing NetServer[LNS1] for dest=STUSTDBY mode ASYNC
LNSb is not running anymore.
Check if new Async LNS1 needs to be started..
Previous Async LNS1 [pid 5764] is running .. no need to start another one
LGWR detected that Async LNS1 [pid 5764] is already running
*** 2010-08-03 16:07:36.747
*** 2010-08-03 16:07:36.747 57052 kcrr.c
Initializing NetServer[LNS1] for dest=STUSTDBY mode ASYNC
LNSb is not running anymore.
Check if new Async LNS1 needs to be started..
Previous Async LNS1 [pid 5764] is running .. no need to start another one
LGWR detected that Async LNS1 [pid 5764] is already running
*** 2010-08-03 16:13:06.633
Warning: log write time 570ms, size 0KB
Did I miss something while creating standby.???
Thanks for the help

are these databases on same server.
BTW These are not errors, they are warning ... I have also seen these kind of warning many times. they can be ignored if ur shipping and recovery on standby is Preperly happening.
Regards
jasbir

How to find the timestamp and SCN in the standby database?

Hai,
I have Oracle 9.2.0.4 RAC with 2 nodes in the production. The logs generated at these servers will be manully moved to my standby database and will be applied. To know what isthe maximum log files applied in the standby database, i am using the below mentioned query in the standby database,
Select thread#,max(sequence#) from v$log_history group by thread#
In general i am using "recover standby database until cancel" command and then checking the database with the above mentioned query whether all the logs are applied or not.
If i use time based or scn based recovery in standby database i.e., "recover standby database until time <time>" or "recover standby database until change <scn number>" , after completion of the recovery, apart from the message "Media recovery complete" or by seeing the alert log, is there any way to query the standby database, so that i can identify the time or scn upto which the archived redo log files got applied.

Hi Sridhar,
There should be some view which will have applied_scn information. There is one more option i can suggest, you can create a heart beat table in production with 2 column like scn and timestamp. Update this table every minute. From standby db you can query this table and get fair idea on applied_scn and timestamp.
While exporting you can export using flashback_scn by taking the value from heartbeat table of standby.
This heartbeat table is used very common in streams environment. Just see if this helps you.
hth,
http://borndba.com

Is that possible to convert logical standby to physical standby ?

Hi guys,
My steps for testing as below:
1.create a primary database
2.duplicate a physical standby database;
3.turn on flashback on both databases.
4.record SCN xxx on physical standby database.
5.convert physical standby to logical standby (using keep identity statement)
6.flashback to logical standby to xxx
7.convert logical standby to physical standby
8.using real time apply
I got errors:
Fast Parallel Media Recovery enabled
Managed Standby Recovery starting Real Time Apply
MRP0: Background Media Recovery waiting for new incarnation during transient logical upgrade procedure
Errors in file /home/ora/app/oracle/diag/rdbms/ora11gr1dg/ora11gr1dg/trace/ora11gr1dg_mrp0_10120.trc:
ORA-19906: recovery target incarnation changed during recovery
Managed Standby Recovery not using Real Time Apply
Errors in file /home/ora/app/oracle/diag/rdbms/ora11gr1dg/ora11gr1dg/trace/ora11gr1dg_mrp0_10120.trc:
ORA-19906: recovery target incarnation changed during recovery
Errors appears every 10 seconds. Seems MPR0 is waiting for new incarnation for a long time. So am I.
Standby database incarnation:
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
1 1 ORA11GR1 3853851354 CURRENT 1 08/09/2013 01:02:18
2 2 ORA11GR1 3853851354 ORPHAN 2127877 08/28/2013 19:22:01 BGV

Hello;
Because of limitations for specific data types and objects with a logical database I going to say no.
Best Regards
mseberg

Standby Database

Hi all,
Its ciirctical
We have prodution database in 10.2.0.1 on sun solaris and its standby with same configuration on remote site.
Both the database are operating in maximum avaialbilty mode:
select protection_mode,protection_level name ,db_unique_name from v$database;
PROTECTION_MODE NAME DB_UNIQUE_NAME
MAXIMUM AVAILABILITY RESYNCHRONIZATION STANDBY
I have switched primary to standby and it worked fine but when i reverting back i am getting below error:
SQL> /
alter database commit to switchover to standby
ERROR at line 1:
ORA-16416: Switchover target is not synchronized with the primary
When i tried to perform recovery on standby machine it completed successfully. And all archived are applied . But still i am getting same error on primary site when i am trying to switch over to standby.
Please refer alert log file of primary:
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
LNSb started with pid=20, OS id=1252
Sat Oct 23 14:53:50 2010
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
Sat Oct 23 14:53:50 2010
Errors in file /export/home/oracle/product/10.2.0/db1/admin/PRIMARY/bdump/standby_lgwr_1104.trc:
ORA-16086: standby database does not contain available standby log files
LGWR: Failed to archive log 2 thread 1 sequence 190 (16086)
Thread 1 advanced to log sequence 190
Current log# 2 seq# 190 mem# 0: /export/home/oracle/product/10.2.0/db1/oradata/PRIMARY/redo02.log
Please refer standby alert_log :
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
LNSb started with pid=20, OS id=1252
Sat Oct 23 14:53:50 2010
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
Sat Oct 23 14:53:50 2010
Errors in file /export/home/oracle/product/10.2.0/db1/admin/PRIMARY/bdump/standby_lgwr_1104.trc:
ORA-16086: standby database does not contain available standby log files
LGWR: Failed to archive log 2 thread 1 sequence 190 (16086)
Thread 1 advanced to log sequence 190
Current log# 2 seq# 190 mem# 0: /export/home/oracle/product/10.2.0/db1/oradata/PRIMARY/redo02.log
Sat Oct 23 15:00:49 2010
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
LNSb started with pid=20, OS id=1270
Sat Oct 23 15:00:52 2010
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
Sat Oct 23 15:00:52 2010
Errors in file /export/home/oracle/product/10.2.0/db1/admin/PRIMARY/bdump/standby_lgwr_1104.trc:
ORA-16086: standby database does not contain available standby log files
LGWR: Failed to archive log 3 thread 1 sequence 191 (16086)
Thread 1 advanced to log sequence 191
Current log# 3 seq# 191 mem# 0: /export/home/oracle/product/10.2.0/db1/oradata/PRIMARY/redo03.log

Add one or more standby log files to the standby database. This can be done while the standby database is mounted.
Errors in file /export/home/oracle/product/10.2.0/db1/admin/PRIMARY/bdump/standby_lgwr_1104.trc
Please check standby_lgwr_1104.trc file.

Standby database can't work !!!

hi,
i set up a standby db for my production db .
However, below error occurs while i perform "recovery managed standby database" :
ORA-00283: recovery session canceled due to
errors
ORA-16016: archived log for thread 1
sequence# 436 unavailable
i tried to fix the problem with the following method:
1) apply "alter system archive log current"
on production server;
2) download the log 436 to standby host;
3) recover standby database until the time
generated the log 436;
4) re-apply the command;
BUT, this time it asked for log 437 !!!!!!!!
can anybody help ???
Thanks a lot
stephen

If the standby hasn't work for years, it's not quite possible to sync it with primary. Of course if you have all the archive logs in these years, you could but it's not as efficient and fast as rebuilding it.
Follow the Oracle doc to build a new standby.
http://download-west.oracle.com/docs/cd/A87860_01/doc/server.817/a76995/toc.htm
btw, it's time to plan upgrade your server.

Error in adding datafile in standby databse.

Hi all.
My Environment is as below:
Oracle-8.1.7.4.0
OS-HP Unix-11
Primary database (only 1): Production
Standby database: Different Machine but same location (HP box)
Yesterday I have added 2 datafiles to the two different tablespace. I have checked file is available at Production box and one of the file also avilable at standby databse.
When I am following steps for applying redo log to the standby manually.
I got error.
SVRMGRL>connect internal
SVRMGRL>show parameter db_name
SVRMGRL>recover standby databse
After above step I got the Error:
ORA-00283 recovery session canceled due to error
ORA-01157 can not identify/lock datafile 24 -see DBWR trace file
ORA-01110 data file 24: '/location of .dbf file on standby databse disk'
Please let me know in detail because I am new in this field.
Thanks in advance

You will have the datafile information on the standby alert log.
Something like '/u01/app/oracle/product/8174/db/<filename>.dbf'.
1. connect as sysdba on standby database.
2. alter database create datafile 'Production datafile name' as 'alert log filename';
Example :
alter database create datafile '/u01/data/user1.dbf'
as '/u01/app/oracle/product/8174/db/<filename>.dbf';
3. Recovery managed standby database;
HTH.
Regards,
Arun

Regrading standby database in standard edition

hi gurus
i m facing problem in configuring standby database in standard edition windows 2008 .
os-windows 2008 standard
oracle 11gr2
i have copied files from primary n copied it to same location on standby...at that time database was in noarchivelog mode
then i made it archive n create standby controlfile...also i have created same service name thru oradim with mentioning pfile and same password as on primary
so it created pfile and password file...
i opened the database in nomount with pfile
then mount with standby controlfile it got mounted n the mode is automatically archivelog mode but as i didn't taken the same pfile of primary it didnt take the destinations as such n made archive in flash recovery area
now i m a bit confused how to apply archive..i copied some archive and placed it in flash rec area
i tried all options managed recovery.recover standby database,recover database until cancel
but all give error
please tell how i proceed..what shud b the right process in standby standard edition
if possible send me a good link for standby database creation in windows 2008 standard with how to ftp files with mget mput..
anyone if kindly provide a good link...wud b of great help
thanks all

on your standby database you can use:
set logsource path_to_archives
This will let Oracle know where the archive files are on the standby database.
Then you can apply the archives with:
recover standby database
Another option is to use Dbvisit Standby to automate the whole standby database (including creation) for you when you have Oracle Standard One or Oracle Standard Edition One.

Standby database failover flashback restart as standby gap 1-100

Hi,
I have setup a physical standby database for a 3 node RAC primary database and configured the database to run in MAXIMUM AVAILABILITY mode. Both the primary and standby databases use ASM for managing the IO. I have enabled FLASHBACK ON on both the databases.
I did failover to standby database with primary db SHUTDOWN for doing some testing. After testing is done, I flashbacked the (standby, currently primary)database to the point when it became primary and start it as standby again and the old primary as primary.
Following are the steps:
Failover steps
.Shutdown the primary database
To finisish the recovery at standby
SQL>alter database recover managed standby database finish;
To start as primary
SQL>alter database commit to switchover to primary;
do some DML on the new primary
SQL>flashback database to scn <standby_became_primary_scn>;
SQL>alter database create standby controlfile as '/backup/standby.ctl';
Changed the spfile to point control_files to '/backup/standby.ctl';
Restarted the standby db in mount mode and
created the required stanbdy logs on it.
Then issued
SQL>alter database recover managed standby database using current logfile disconnect;
I have the following message in v$dataguard_status at standby db;
Fetching gap sequence in thread 1 branch(resetlogs_id) 653234404, gap seq 1-100
DBID 2651011616 branch 653234404
GAP - thread 1 sequence 1-100
FAL[client]: Failed to request gap sequence
FAL[client]: All defined FAL servers have been attempted.
The same error is found in alert log file also.
The status of the varioud managed standby db are as follows.
SQL> select process, status from v$managed_standby;
PROCESS STATUS
ARCH CLOSING
ARCH CLOSING
ARCH CLOSING
MRP0 WAIT_FOR_GAP
RFS IDLE
RFS IDLE
RFS IDLE
RFS IDLE
RFS IDLE
RFS IDLE
RFS IDLE
PROCESS STATUS
RFS IDLE
RFS IDLE
RFS IDLE
RFS IDLE
15 rows selected.
SQL>
Could you please help me how to resolve the above error.
Thanks,
Sreekanth

Sreekanth,
I think your steps are right on for your requirement, except instead of
alter database create standby controlfile as '/backup/standby.ctl';
you can do this:
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
(although perhaps it achieves the same thing internally but you don't need to repoint to new controlfile).
So far as the GAP - thread 1 sequence 1-100
Let me guess, your current sequences are probably well ahead of this reported gap?
If so, this is a bogus gap in a sense that your standby has long ago applied them, but for some reason standby controlfile gets a little confused and starts asking for them again.
I have had this issue and opened multiple TAR's with Oracle since 10.2.0.1, got a few patches and advises to upgrade, but still occasionally get it now in 10.2.0.3
I strongly believe this is related to combination of RAC (i.e. multiple threads of redo) and dataguard.
It is also pretty hard to reproduce (I have not figured out how to reproduce this reliably, if you have, let me know), so I can understand why Oracle has so far been unable to fix this.
Anyway, the workaround is to re-create standby controlfile with a copy generated on primary, and move it in place of the existing (and confused) controlfiles on standby.

Relocating datafiles on standby database after mount point on stanby is ful

Hi,
We have a physical standby database.
The location of datafiles on primary database are at /oracle/oradata/ and the location of datafiles on standby database are at /oracle/oradata/
Now we are facing a situation of mount mount getting full on standby database so we need to move some tablespaces to another location on standby.
Say old location is /oracle/oradata/ and new location is /oradata_new/ and the tablespaces to be relocated are say tab1 and tab2.
Can anybody tell me whether following steps are correct.
1. Stop managed recovery on standby database
alter database recover managed standby database cancel;
2. Shutdown standby database
shutdown immediate;
3. Open standby database in mount stage
startup mount;
4. Copy the datafiles to new location say /oradata_new/ using os level command
4. Rename the datafile
alter database rename file
'/oracle/oradata/tab1.123451.dbf', '/oracle/oradata/tab1.123452.dbf','/oracle/oradata/tab2.123451.dbf',''/oracle/oradata/tab2.123452.dbf'
to '/oradata_new/tab1.123451.dbf', '/oradata_new/tab1.123452.dbf','/oradata_new/tab2.123451.dbf',''/oradata_new/tab2.123452.dbf';
5. Edit the parameter db_file_name_convert
alter system set db_file_name_convert='/oracle/oradata/tab1','/oradata_new/tab1','/oracle/oradata/tab2','/oradata_new/tab2'
6. Start a managed recovery on standby database
alter database recover managed standby database disconnect from session;
I am littelbit confused in step 5 as we want to relocate only two tablespaces and not all tablespaces so we have used.
Can we use db_file_name_convert like this i.e. does this work for only two tablespaces tab1 and tab2.
Thanks & Regards
GirishA

http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/manage_ps.htm#i1010428
8.3.4 Renaming a Datafile in the Primary Database
When you rename one or more datafiles in the primary database, the change is not propagated to the standby database. Therefore, if you want to rename the same datafiles on the standby database, you must manually make the equivalent modifications on the standby database because the modifications are not performed automatically, even if the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO.
The following steps describe how to rename a datafile in the primary database and manually propagate the changes to the standby database.
To rename the datafile in the primary database, take the tablespace offline:
SQL> ALTER TABLESPACE tbs_4 OFFLINE;
Exit from the SQL prompt and issue an operating system command, such as the following UNIX mv command, to rename the datafile on the primary system:
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf
/disk1/oracle/oradata/payroll/tbs_x.dbf
Rename the datafile in the primary database and bring the tablespace back online:
SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE 2> '/disk1/oracle/oradata/payroll/tbs_4.dbf'
3> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
SQL> ALTER TABLESPACE tbs_4 ONLINE;
Connect to the standby database, query the V$ARCHIVED_LOG view to verify all of the archived redo log files are applied, and then stop Redo Apply:
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# APP
8 YES
9 YES
10 YES
11 YES
4 rows selected.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
Shut down the standby database:
SQL> SHUTDOWN;
Rename the datafile at the standby site using an operating system command, such as the UNIX mv command:
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
Start and mount the standby database:
SQL> STARTUP MOUNT;
Rename the datafile in the standby control file. Note that the STANDBY_FILE_MANAGEMENT initialization parameter must be set to MANUAL.
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf'
2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
On the standby database, restart Redo Apply:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
If you do not rename the corresponding datafile at the standby system, and then try to refresh the standby database control file, the standby database will attempt to use the renamed datafile, but it will not find it. Consequently, you will see error messages similar to the following in the alert log:
ORA-00283: recovery session canceled due to errors
ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file
ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'

Recovery in standby

Similar Messages

Maybe you are looking for