Automatic Loc Recover in Standby Database

Hello,
i'm trying to recover logs from a master DB in a standby db with a script which will be started every 8 hours by a task planner. I've found the autorecover command, but I don't know how to use the command.
MaxDB 7.5 is installed on Windows 2003 Server.
The last lines from backup_history_list output:
4718A5F20004 | LOG_000000004 | SAVE WARM | 2007-10-19 14:36:39| 2007-10-19 14:41:08| 2007-10-19 14:41:22 | 2007-10-19 14:41:23 | 1779 | 5823 | | TESTDB_LOG_BACKUP | 232 | 1 | 0 | |
Thanks for you help!

Hello Kilian,
The autorecover command can currently not be used to transport log backups into a standby database, as it is based on the backup history of the database to be recovered and as it always tries to restarts the database into mode ONLINE.
Best regards,
Tilo Heinrich

Similar Messages

Recover the standby database

Hi, I have both primary and standby database in ASM and I need to recover the standby database as it's falling behind for too long. The steps I did are:
1. backup full database on primary
2. create a standby controlfile and copy to /tmp on the standby
3. on the standby, RMAN>restore standby controlfile from '/tmp/std.ctl';
4. RMAN>restore database;
5. SQL>recover managed standby database disconnect;
However, the recovery always shuts down and I get the error:
ORA-01110: data file 1: '+W08_DATA_DG/w08p/datafile/system.295.662256331'
What's wrong with my steps?
Your suggestion is greatly appreciated!

the directory structures are the same. The standby was working before. It's just falling behind so I want to restore it from the new backup. Here is the init.ora
*.audit_file_dest='/opt/app/oracle/admin/W08P/adump'
*.background_dump_dest='/opt/app/oracle/admin/W08P/bdump'
*.cluster_database_instances=2
*.cluster_database=false
*.compatible='10.2.0.3.0'
*.control_files='+W08_DATA_DG/w08p/control01.ctl','+W08_RECOVERY_DG/w08p/control02.ctl','+W08_DATA_DG/w08p/control03.ctl'
*.core_dump_dest='/opt/app/oracle/admin/W08P/cdump'
*.db_block_size=8192
*.db_create_file_dest='+W08_DATA_DG'
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='W08P'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=W08PXDB)'
*.event='10298 trace name context forever, level 32'
*.job_queue_processes=10
*.log_archive_dest_1='LOCATION=+W08_RECOVERY_DG/W08P/'
*.log_archive_format='%t_%s_%r.arc'
*.log_archive_max_processes=6
*.open_cursors=1000
*.optimizer_index_caching=70
*.optimizer_index_cost_adj=30
*.pga_aggregate_target=1459617792
*.processes=300
*.remote_login_passwordfile='exclusive'
*.sessions=1000
*.sga_target=1610612736
*.undo_management='AUTO'
*.undo_retention=26000
W08P.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/opt/app/oracle/admin/W08P/udump'
standby_archive_dest='LOCATION=+W08_RECOVERY_DG/W08P'
CONTROL_FILE_RECORD_KEEP_TIME=0
standby_file_management=auto
fal_server=w08p
fal_client=w08p_stby
control_file_record_keep_time=90
~

Problem in recover physical standby database(Data Guard) by rman

Hello to all
I have created a physical standby database ,I want make backup of it by rman and when I lose it's datafile I can restore it ,making backup and restore is fine but in recovery I encounter some problem
scenarios is follow
1- In rman I create a backup of standby database by this command:
backup database plus archivelog delete all input;
2- I run this comman in rman for recover standby database
run{
2> set until scn 1392701;
3> restore database;
4> recover database;
5> }
(1392701 is extracted from this query "SELECT MAX(NEXT_CHANGE#)+1 UNTIL_SCN FROM V$LOG_HISTORY LH,
V$DATABASE DB WHERE LH.RESETLOGS_CHANGE#=DB.RESETLOGS_CHANGE# AND LH.RESETLOGS_TIME =
DB.RESETLOGS_TIME;" "http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/rman.htm")
but RMAN result is like this:
executing command: SET until clause
Starting restore at 13-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from
backup set
restoring datafile 00001 to /u01/app/oracle/oradata/sari/system01.dbf
restoring datafile 00002 to /u01/app/oracle/oradata/sari/undotbs01.dbf
restoring datafile 00003 to /u01/app/oracle/oradata/sari/sysaux01.dbf
restoring datafile 00004 to /u01/app/oracle/oradata/sari/users01.dbf
restoring datafile 00005 to /u01/app/oracle/oradata/sari/example01.dbf
restoring datafile 00006 to /u01/app/oracle/oradata/sari/users02.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/0ek24dt4_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/backup/0ek24dt4_1_1
tag=TAG20081213T042506
channel ORA_DISK_1: restore complete, elapsed time: 00:01:07
Finished restore at 13-DEC-08
Starting recover at 13-DEC-08
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 116 is already on disk as file /u01/app/oracle/oradata/archive/1_116_666786084.arc
archive log thread 1 sequence 117 is already on disk as file /u01/app/oracle/oradata/archive/1_117_666786084.arc
archive log filename=/u01/app/oracle/oradata/archive/1_116_666786084.arc thread=1 sequence=116
archive log filename=/u01/app/oracle/oradata/archive/1_117_666786084.arc thread=1 sequence=117
unable to find archive log
archive log thread=1 sequence=118
RMAN-03002: failure of recover command at 12/13/2008 05:14:13
RMAN-06054: media recovery requesting unknown log: thread 1
seq 118 lowscn 1392700
3- then I decline 1392701 to 1392700 and i run this command
run{
2> set until scn 1392700;
3> restore database ;
4> recover database;
5> }
executing command: SET until clause
Starting restore at 13-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from
backup set
restoring datafile 00001 to /u01/app/oracle/oradata/sari/system01.dbf
restoring datafile 00002 to /u01/app/oracle/oradata/sari/undotbs01.dbf
restoring datafile 00003 to /u01/app/oracle/oradata/sari/sysaux01.dbf
restoring datafile 00004 to /u01/app/oracle/oradata/sari/users01.dbf
restoring datafile 00005 to /u01/app/oracle/oradata/sari/example01.dbf
restoring datafile 00006 to /u01/app/oracle/oradata/sari/users02.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/backup/0ek24dt4_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/backup/0ek24dt4_1_1 tag=TAG20081213T042506
channel ORA_DISK_1: restore complete, elapsed time: 00:01:08
Finished restore at 13-DEC-08
Starting recover at 13-DEC-08
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 116 is already on disk as
file /u01/app/oracle/oradata/archive/1_116_666786084.arc
archive log thread 1 sequence 117 is already on disk as
file /u01/app/oracle/oradata/archive/1_117_666786084.arc
archive log filename=/u01/app/oracle/oradata/archive/1_116_666786084.arc thread=1
sequence=116archive log
filename=/u01/app/oracle/oradata/archive/1_117_666786084.arc
thread=1 sequence=117Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS
would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/u01/app/oracle/oradata/sari/system01.dbf'
media recovery complete, elapsed time: 00:00:10
Finished recover at 13-DEC-08
4- if I run
run{
restore database;
recover database;
I will recieve that error of step 2 (RMAN-06054: media recovery requesting unknown log: thread 1
seq 118 lowscn 1392700)
5- if I just restore the database and I don't perform recovery by rman and I restart redo apply all thing seem fine
but in opening database I'll recieve ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/u01/app/oracle/oradata/sari/system01.dbf' error)
do you know what is problem
thanks
Edited by: ARKH on Dec 12, 2008 11:06 PM

hi
I myself have found the solution , when I recover the standby database
it do recovery but at the end of recovery it raise the error(RMAN-06054: media recovery requesting unknown log: thread 1
seq 118 lowscn 1392700) but if I begain redo apply before open the database
and I wait till all redo apply process start and communication between the
standby database and the primary database start, then I can
open the standby database and no error will raise
but if befor restarting redo apply I open the database I'll recieve the
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/u01/app/oracle/oradata/sari/system01.dbf' error
thanks

ALTER DATABASE RECOVER MANAGE STANDBY DATABASE

During the creation of Logical Standby database (NOAA2), after issuing the statement:
"ALTER DATABASE RECOVER MANAGE STANDBY DATABASE"
the following error appears:
FAL[server, ARC1]: Complete FAL noexpedite archive (thread 1 sequence 46 destination NOAA2)
ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
PING[ARC1]: Error 3113 when pinging standby NOAA2.
Can someone please shed any light on the problem.
Thank you.

Perform these steps on Standby and see if it works
%lsnrctl stop
%lsnrctl start

Trying to recover an standby database

- Oracle 10.2.0.4 Standard Edition
- O/S: Windows Server 2003
- Phisically Standby
We have primary and a standby database. My standby database was synchronized through copying archive redo logs from Primary to Standby. They were copied every 15 min to standby server and then they were recovered from there. Because a lot of archive logs were missed for ever, now my standby database is not synchronized with my primary.
In order to recover my Standby, one week ago I followed these instructions:
Step 1: On the standby database check the current scn.
STDBY> select current_scn from v$database;
CURRENT_SCN
2527075174
Step 2: On the primary database create the needed incremental backup from the above SCN
C:\Documents and Settings\frego>rman target /
run {
allocate channel c1 type disk;
BACKUP INCREMENTAL FROM SCN 2527075174 DATABASE
format '\\srvbackup\archiveslogs-35\arch\incr_bkp_%U';
Step 3: Cancel managed recovery at the standby database
STDBY>alter database recover managed standby database cancel;
Media recovery complete.
Copied the backup files to standby server to "D:\arch\" folder.
Step 4: Catalog the Incremental Backup Files at the Standby Database
D:\arch> rman target /
RMAN> CATALOG START WITH 'D:\arch\';
Step 5: Apply the Incremental Backup to the Standby Database
RMAN> RECOVER DATABASE NOREDO;
Step 6: Put the standby database back to managed recovery mode.
STDBY>> recover managed standby database disconnect;
Media recovery complete.
Step 7: On the primary create new standby controlfile
PRIM>alter database create standby controlfile as 'C:\incr_bkp\standby01.ctl';
System altered.
Step 8: At Standby .. Replace standby controlfile at all location as shown by controle_files parameter.
Copy the standby control file to the standby site. Shutdown the standby database and replace the stanby controlfiles and restart the >standby database in managed recovery mode...
Problem was that there were new datafiles created in primary that didn't exist in standby. I had to created them manually on standby:
ALTER DATABASE CREATE DATAFILE 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB3.ORA' AS 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB3.ORA';
ALTER DATABASE CREATE DATAFILE 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB4.ORA' AS 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB4.ORA';
ALTER DATABASE CREATE DATAFILE 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BKP.ORA' AS 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BKP.ORA';
ALTER DATABASE CREATE DATAFILE 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB5.ORA' AS 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB5.ORA';
ALTER DATABASE CREATE DATAFILE 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB_A.ORA' AS 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB_A.ORA';
ALTER DATABASE CREATE DATAFILE 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB_B.ORA' AS 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB_B.ORA';
ALTER DATABASE CREATE DATAFILE 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB_C.ORA' AS 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB_C.ORA';
ALTER DATABASE CREATE DATAFILE 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB_D.ORA' AS 'D:\ORADATA\PROD\OPEXT\DATAFILES_DATA\SIPESG_BLOB_D.ORA';
ALTER DATABASE CREATE DATAFILE 'D:\ORADATA\PROD\OPEXT\DATAFILES_IDX\PADRONIDX17.ORA' AS 'D:\ORADATA\PROD\OPEXT\DATAFILES_IDX\PADRONIDX17.ORA';
Also, I tried this commands:
On Standby:
RMAN> SHUTDOWN;
RMAN> STARTUP NOMOUNT;
RMAN> RESTORE STANDBY CONTROLFILE FROM 'D:\arch\standby01.ctl';
RMAN> SHUTDOWN;
RMAN> STARTUP MOUNT;
STDB> ALTER DATABASE CLEAR LOGFILE GROUP 1;
STDB> ALTER DATABASE CLEAR LOGFILE GROUP 2;
STDB> ALTER DATABASE CLEAR LOGFILE GROUP 3;
STDB> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Database altered.
SQL> alter database open read only;
alter database open read only
ERROR at line 1:
ORA-01154: database busy. Open, close, mount, and dismount not allowed now
SQL> recover managed standby database cancel;
Media recovery complete.
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: 'D:\ORADATA\PROD\OPEXT\SYSTEM01.DBF'My Questions:
- What is missing in order to open standby database?
- Can I again generate rman incremental backups on Primary (from SCN 2527075174), copy them to Standby and start recovery again? Would it generate duplicate records on tables?
- Should I generate new rman incremental backup pieces on Primary (from last SCN of Standby), copy them to standby and apply there?
Remember that my Primary is growing every day and those rman backup pieces and standby01.ctl, that are copied on my standby server, are from one week ago.
Thanks
Edited by: user521219 on 22-jun-2012 9:31

user521219 wrote:
Should I restart and mount my standby database again?
If I apply Step 3 now:
STB> alter database recover managed standby database cancel;
ERROR at line 1:
ORA-16136: Managed Standby Recovery not activeRefer the above mentioned link. First restore controlfile & then perform recovery on standby database.
>
user521219
     Newbie
Handle:      user521219
Status Level:      Newbie
Registered:      Jul 20, 2006
Total Posts:      48
Total Questions:      29 (23 unresolved)
>
Consider closing your threads and keep the forum clean.
Edited by: CKPT on Jun 22, 2012 10:43 PM

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

Hi,
on 10g R2, how to know if :
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT;
is already applied ?
thank you.

user522961 wrote:
thanks to all.
Should I issue the following and others on standby or on primary ?
select process,status from v$managed_standby;
Regards.You need execute that from standby instance.In additionally you can see standby instances alert.log.And if this process is active then if you execute this command again then you will get an error like "Media recover is active".

DR in deferred state-methods to recover the standby database.

Hi all,
i am new to Data guard.
1.yesterday only i came to know the Log-ship from live to DR in deferred state before 6 months.
2.Now i am in the situation to resolve the problem.
3.only 5days log sequence only we have before that it will purge(shell script)
4.so there is no log collecting folder on DR server also.
5.so kindly provide me what are the methods to recover the standby database.
Its urgent.
thank you in advance,
regards,
Jumbo.

Hi SRP,
DB status:
1.*No ASM storage.*
2.*oracle 9i.*
3.*Archive logs deleted on both Primary and Standby.*
my question:
1.without recreate standby.*is their any method to recover the standby database?*
Regards,
Jumbo.

Recovering Physical Standby Database

I created a simple script to recover/synchronies physical standby database. This script runs on schedule basis and finds if any recovery is required and if so, it applies the required archived files, or otherwise it will give an error showing the suggested file is not found. I want to suppress that error message and I wonder if there is a way to do that, so Oracle will exit the session without displaying the error message.
Thanks

in earlier u ask about the error controling now younis u r asking about manual setup for standby.
anyways yes it is possible.
u create the replica of your database
like install the other server with same version and same datafile location and alll...
there is no automatic transmission from oracle but u can automate from script like using rpc and in windows its more easy to copy archive anyways
shutdown ur primary database copy all relevant files
and paste it to ur secondary database
now your database is ready in other machine as well.
now what routine you have to follow for doing manual standby is
you have copy all archives daily after copy of physical db files and also your control file from the primary database.
than recover database;
regards,
umair

Restoring and recovering datafiles in standby database

Hi,
oracle version : 8i(8.1.7.0.0)
os : sun solaris
I have scenerio where i lost some of the datafiles in standby database(physical standby) and i do have standby cold backup 3 months older since database size is 1TB is can i restore the the only lost files from cold backup and recover using archivelog files. since i only lost 4 data files of size 4gb each it will be faster compare to restoring the whole TB size database.
appreciated for valuable inputs.
Thanks
Prakash GR

Normal copy command can do your work:
sys@SANTU> startup
ORACLE instance started.
Total System Global Area 535662592 bytes
Fixed Size                  1334380 bytes
Variable Size             180355988 bytes
Database Buffers          348127232 bytes
Redo Buffers                5844992 bytes
Database mounted.
Database opened.
sys@SANTU> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     4
Next log sequence to archive   6
Current log sequence           6
sys@SANTU> host copy D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF d:\
        1 file(s) copied.
sys@SANTU> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
*Renamed the datafile 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF' to 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS011.DBF'*
sys@SANTU> startup
ORACLE instance started.
Total System Global Area 535662592 bytes
Fixed Size                  1334380 bytes
Variable Size             180355988 bytes
Database Buffers          348127232 bytes
Redo Buffers                5844992 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF'
sys@SANTU> host move d:\USERS01.DBF D:\APP\SANTOSKU\ORADATA\SANTU\
sys@SANTU> shu immediate
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
sys@SANTU> startup
ORACLE instance started.
Total System Global Area 535662592 bytes
Fixed Size                  1334380 bytes
Variable Size             180355988 bytes
Database Buffers          348127232 bytes
Redo Buffers                5844992 bytes
Database mounted.
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF'
sys@SANTU> recover datafile 'D:\APP\SANTOSKU\ORADATA\SANTU\USERS01.DBF';
Media recovery complete.
sys@SANTU> alter database open;
Database altered.
sys@SANTU>N.B. I have not done the demo on standby database.
but just i want to know is this procedure is valid that is instead of taking the lost datafiles from production can i use lost datafiles from standby database to recover other standby database.That would be fine.
Regards,
S.K.
Edited by: Santosh Kumar on Oct 8, 2009 11:09 AM

Recover standby database apply archivelog slow

1.recover managed standby database disconnect from session;
2.view alert file,find apply a achivelog last block need 10m
3.view metalink MAA - Data Guard Redo Apply and Media Recovery Best Practices 10gR1
modify database parameter,still is slow
3.view v$managed_standby
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:49:09
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:51:56
SQL> /
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:51:57
SQL> /
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:51:57
SQL> /
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:51:58
SQL> /
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:51:58
SQL> /
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:51:58
SQL> /
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:51:59
SQL> /
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:51:59
SQL>
SQL> //
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:51:59
SQL> //
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
SQL> //
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
SQL> /
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
SQL> /
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:52:00
SQL> //
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:52:01
SQL> /
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:52:01
SQL> //
PROCESS SEQUENCE# THREAD# BLOCK# BLOCKS TIME
MRP0 133538 1 581533 581534 15-APR-2011 10:52:01
4. dump mrp
SO: 0xc103c9b58, type: 4, owner: 0xc172b7820, flag: INIT/-/-/0x00
(session) sid: 1087 trans: (nil), creator: 0xc172b7820, flag: (51) USR/- BSY/-/-/-/-/-
DID: 0001-0013-00000002, short-term DID: 0000-0000-00000000
txn branch: (nil)
oct: 0, prv: 0, sql: (nil), psql: (nil), user: 0/SYS
service name: SYS$BACKGROUND
waiting for 'PX Deq: Par Recov Reply' blocking sess=0x(nil) seq=6397 wait_time=0 seconds since wait started=3
sleeptime/senderid=10010000, passes=19f, =0
Dumping Session Wait History
for 'PX Deq: Par Recov Reply' count=1 wait_time=1953964
sleeptime/senderid=10010000, passes=19e, =0
for 'PX Deq: Par Recov Reply' count=1 wait_time=1954140
sleeptime/senderid=10010000, passes=19d, =0
for 'PX Deq: Par Recov Reply' count=1 wait_time=1954066
sleeptime/senderid=10010000, passes=19c, =0
for 'PX Deq: Par Recov Reply' count=1 wait_time=1954065
sleeptime/senderid=10010000, passes=19b, =0
for 'PX Deq: Par Recov Reply' count=1 wait_time=1954129
sleeptime/senderid=10010000, passes=19a, =0
for 'PX Deq: Par Recov Reply' count=1 wait_time=1954061
sleeptime/senderid=10010000, passes=199, =0
for 'PX Deq: Par Recov Reply' count=1 wait_time=1953991
sleeptime/senderid=10010000, passes=198, =0
for 'PX Deq: Par Recov Reply' count=1 wait_time=1954123
sleeptime/senderid=10010000, passes=197, =0
for 'PX Deq: Par Recov Reply' count=1 wait_time=1954120
sleeptime/senderid=10010000, passes=196, =0
for 'PX Deq: Par Recov Reply' count=1 wait_time=1954073
sleeptime/senderid=10010000, passes=195, =0
5.how to read dump process file
Edited by: 852786 on 2011-4-16 上午1:46

SO: 0xbf34d65b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f4990d0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-0000001A-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17426408, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426418
SO: 0xbf34d6570, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f499020, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000019-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17426380, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426390
SO: 0xbf34d6530, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498f88, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000018-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc174262f8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426308
SO: 0xbf34d64f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498ef0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000017-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17426270, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426280
SO: 0xbf34d64b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498e58, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000016-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc174261e8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174261f8
SO: 0xbf34d6470, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498dc0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000015-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17426160, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426170
SO: 0xbf34d6430, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498d28, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000014-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc174260d8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174260e8
SO: 0xbf34d63f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498c90, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000013-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17426050, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17426060
SO: 0xbf34d63b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498bf8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000012-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425fc8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425fd8
SO: 0xbf34d6370, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498b60, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000011-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425f40, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425f50
SO: 0xbf34d6330, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498ac8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000010-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425eb8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425ec8
SO: 0xbf34d62f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498a30, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-0000000F-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425e30, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425e40
SO: 0xbf34d62b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498998, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-0000000E-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425da8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425db8
SO: 0xbf34d6270, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498900, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-0000000D-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425d20, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425d30
SO: 0xbf34d6230, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498868, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-0000000C-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425c80, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425c90
SO: 0xbf34d61f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f4987d0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-0000000B-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425bf8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425c08
SO: 0xbf34d61b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498738, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-0000000A-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425b70, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425b80
SO: 0xbf34d6170, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498688, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000009-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425ae8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425af8
SO: 0xbf34d6130, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f4985f0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000008-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425a60, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425a70
SO: 0xbf34d60f0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498558, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000007-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc174259d8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174259e8
SO: 0xbf34d60b0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f4984c0, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000006-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425950, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425960
SO: 0xbf34d6070, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498428, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000005-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc174258c8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174258d8
SO: 0xbf34d6030, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498390, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000004-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425840, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425850
SO: 0xbf34d5ff0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f4982f8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000003-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc174257b8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174257c8
SO: 0xbf34d5fb0, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f498260, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000002-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425730, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425740
SO: 0xbf34d5f70, type: 27, owner: 0xbfce71e80, flag: INIT/-/-/0x00
SO: 0xc0f4981c8, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000001-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc174256a8, mode: SSX, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc174256b8
SO: 0xc0f498130, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) FS-00000000-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425510, mode: S, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425520
SO: 0xc0f498000, type: 5, owner: 0xbfce71e80, flag: INIT/-/-/0x00
(enqueue) MR-00000000-00000000     DID: 0001-0016-00000002
lv: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 res_flag: 0x2
res: 0xc17425488, mode: S, lock_flag: 0x0
own: 0xc0e403c70, sess: 0xc0e403c70, proc: 0xc0c28ae80, prv: 0xc17425498
SO: 0xc13fe20e8, type: 61, owner: 0xc0e403c70, flag: INIT/-/-/0x00
Process Queue--kxfpq: 0x0xc13fe20e8, serial: 513, # of qrefs: 16,
inc: 0
client 2, detached proc: 0x(nil), QC qref 0x(nil), flags: FEML
Queue Descriptor--kxfpqd: 0x0xc13fe2140, remote queue addr: 0x0xc1
3fe20e8
instance id: 1, server id: 65535, flags: ISQC
SO: 0xc13fdd200, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fdd200, ser: 513, seq: 1123, err
or: 0
opp qref: 0x0xc13fdbb50, process: 0x0xc0e2c33e8, bufs: {0x(nil),
0x0xb3fe124f8}
state: 00000, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fdd310, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fdd248, remote queue addr: 0x
0xc13fdfb40
instance id: 1, server id: 15, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3fe124f8, 0x0xb3fe224f8}, sta
te: 10011
Message Buffer--kxfpmh: 0x0xb3fe124f8, type: DTA, bufnum: 1
ser: 513, seq: 1117, flags: STRE, status: FRE, err: 0
to qref: 0x0xc13fdbb50, from qref: 0x0xc13fdd200, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3fe12550, remote queue addr:
0x0xc13fe20e8
instance id: 1, server id: 65535, flags: ISQC
SO: 0xc13fdd410, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fdd410, ser: 513, seq: 936, erro
r: 0
opp qref: 0x0xc13fdbd60, process: 0x0xc172b8fd8, bufs: {0x(nil),
0x0xb3fe024f8}
state: 00000, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fdd520, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fdd458, remote queue addr: 0x
0xc13fdfd98
instance id: 1, server id: 14, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3fe024f8, 0x0xb3fdf24f8}, sta
te: 10011
Message Buffer--kxfpmh: 0x0xb3fe024f8, type: DTA, bufnum: 1
ser: 513, seq: 926, flags: STRE, status: FRE, err: 0
to qref: 0x0xc13fdbd60, from qref: 0x0xc13fdd410, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3fe02550, remote queue addr:
0x0xc13fe20e8
instance id: 1, server id: 65535, flags: ISQC
SO: 0xc13fdd620, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fdd620, ser: 513, seq: 1076, err
or: 0
opp qref: 0x0xc13fdc5a0, process: 0x0xc0f28aa28, bufs: {0x0xb3fd
d24f8, 0x0xb3fdc24f8}
state: 10010, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fdd730, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fdd668, remote queue addr: 0x
0xc13fdfff0
instance id: 1, server id: 13, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3fdd24f8, 0x0xb3fdc24f8}, sta
te: 10011
Message Buffer--kxfpmh: 0x0xb3fdd24f8, type: DTA, bufnum: 0
ser: 513, seq: 1069, flags: STRE, status: FRE, err: 0
to qref: 0x0xc13fdc5a0, from qref: 0x0xc13fdd620, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3fdd2550, remote queue addr:
0x0xc13fe20e8
instance id: 1, server id: 65535, flags: ISQC
Message Buffer--kxfpmh: 0x0xb3fdc24f8, type: DTA, bufnum: 1
ser: 513, seq: 1076, flags: DIAL, status: RCV, err: 0
to qref: 0x0xc13fdd620, from qref: 0x0xc13fdc5a0, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3fdc2550, remote queue addr:
0x0xc13fdfff0
instance id: 1, server id: 13, flags: INIT
can't dump contents, client unknown
SO: 0xc13fdda40, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fdda40, ser: 513, seq: 1209, err
or: 0
opp qref: 0x0xc13fdc7b0, process: 0x0xc102860a8, bufs: {0x(nil),
0x0xb3fe324f8}
state: 00000, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fddb50, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fdda88, remote queue addr: 0x
0xc13fe0248
instance id: 1, server id: 12, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3fe324f8, 0x0xb3fda24f8}, sta
te: 10011
Message Buffer--kxfpmh: 0x0xb3fe324f8, type: DTA, bufnum: 1
ser: 513, seq: 1203, flags: STRE, status: FRE, err: 0
to qref: 0x0xc13fdc7b0, from qref: 0x0xc13fdda40, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3fe32550, remote queue addr:
0x0xc13fe20e8
instance id: 1, server id: 65535, flags: ISQC
SO: 0xc13fddc50, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fddc50, ser: 513, seq: 822, erro
r: 0
opp qref: 0x0xc13fdc180, process: 0x0xc0c28be50, bufs: {0x(nil),
0x0xb3fd924f8}
state: 00000, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fddd60, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fddc98, remote queue addr: 0x
0xc13fe04a0
instance id: 1, server id: 11, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3fd924f8, 0x0xb3f069230}, sta
te: 10011
Message Buffer--kxfpmh: 0x0xb3fd924f8, type: DTA, bufnum: 1
ser: 513, seq: 816, flags: STRE, status: FRE, err: 0
to qref: 0x0xc13fdc180, from qref: 0x0xc13fddc50, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3fd92550, remote queue addr:
0x0xc13fe20e8
instance id: 1, server id: 65535, flags: ISQC
SO: 0xc13fdde60, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fdde60, ser: 513, seq: 829, erro
r: 0
opp qref: 0x0xc13fdbf70, process: 0x0xc0d2a44f8, bufs: {0x(nil),
0x0xb3f456dc8}
state: 00000, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fddf70, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fddea8, remote queue addr: 0x
0xc13fe06f8
instance id: 1, server id: 10, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3f456dc8, 0x0xb3fd724f8}, sta
te: 10011
Message Buffer--kxfpmh: 0x0xb3f456dc8, type: DTA, bufnum: 1
ser: 513, seq: 823, flags: STRE, status: FRE, err: 0
to qref: 0x0xc13fdbf70, from qref: 0x0xc13fdde60, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3f456e20, remote queue addr:
0x0xc13fe20e8
instance id: 1, server id: 65535, flags: ISQC
SO: 0xc13fde070, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fde070, ser: 513, seq: 1321, err
or: 0
opp qref: 0x0xc13fdb940, process: 0x0xc0e2c2c00, bufs: {0x(nil),
0x0xb3fd424f8}
state: 00000, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fde180, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fde0b8, remote queue addr: 0x
0xc13fe0950
instance id: 1, server id: 9, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3fd424f8, 0x0xb3f854960}, sta
te: 10011
Message Buffer--kxfpmh: 0x0xb3fd424f8, type: DTA, bufnum: 1
ser: 513, seq: 1315, flags: STRE, status: FRE, err: 0
to qref: 0x0xc13fdb940, from qref: 0x0xc13fde070, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3fd42550, remote queue addr:
0x0xc13fe20e8
instance id: 1, server id: 65535, flags: ISQC
SO: 0xc13fde490, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fde490, ser: 513, seq: 1002, err
or: 0
opp qref: 0x0xc13fdd830, process: 0x0xc172b87f0, bufs: {0x(nil),
0x0xb3fde24f8}
state: 00000, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fde5a0, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fde4d8, remote queue addr: 0x
0xc13fe0ba8
instance id: 1, server id: 8, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3fde24f8, 0x0xb3fd224f8}, sta
te: 10011
Message Buffer--kxfpmh: 0x0xb3fde24f8, type: DTA, bufnum: 1
ser: 513, seq: 995, flags: STRE, status: FRE, err: 0
to qref: 0x0xc13fdd830, from qref: 0x0xc13fde490, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3fde2550, remote queue addr:
0x0xc13fe20e8
instance id: 1, server id: 65535, flags: ISQC
SO: 0xc13fde6a0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fde6a0, ser: 513, seq: 1198, err
or: 0
opp qref: 0x0xc13fdcbd0, process: 0x0xc0f28a240, bufs: {0x(nil),
0x0xb3fd024f8}
state: 00000, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fde7b0, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fde6e8, remote queue addr: 0x
0xc13fe0e00
instance id: 1, server id: 7, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3fd024f8, 0x0xb3f059230}, sta
te: 10011
Message Buffer--kxfpmh: 0x0xb3fd024f8, type: DTA, bufnum: 1
ser: 513, seq: 1191, flags: STRE, status: FRE, err: 0
to qref: 0x0xc13fdcbd0, from qref: 0x0xc13fde6a0, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3fd02550, remote queue addr:
0x0xc13fe20e8
instance id: 1, server id: 65535, flags: ISQC
SO: 0xc13fdeac0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fdeac0, ser: 513, seq: 1080, err
or: 0
opp qref: 0x0xc13fdcde0, process: 0x0xc102858c0, bufs: {0x(nil),
0x0xb3f436dc8}
state: 00000, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fdebd0, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fdeb08, remote queue addr: 0x
0xc13fe1058
instance id: 1, server id: 6, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3f436dc8, 0x0xb3fce24f8}, sta
te: 10011
Message Buffer--kxfpmh: 0x0xb3f436dc8, type: DTA, bufnum: 1
ser: 513, seq: 1074, flags: STRE, status: FRE, err: 0
to qref: 0x0xc13fdcde0, from qref: 0x0xc13fdeac0, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3f436e20, remote queue addr:
0x0xc13fe20e8
instance id: 1, server id: 65535, flags: ISQC
SO: 0xc13fdeee0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fdeee0, ser: 513, seq: 1418, err
or: 0
opp qref: 0x0xc13fde280, process: 0x0xc0c28b668, bufs: {0x(nil),
0x0xb3f824960}
state: 00000, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fdeff0, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fdef28, remote queue addr: 0x
0xc13fe12b0
instance id: 1, server id: 5, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3f824960, 0x0xb3fcc24f8}, sta
te: 10011
Message Buffer--kxfpmh: 0x0xb3f824960, type: NUL, bufnum: 1
ser: 513, seq: 1407, flags: DIAL, status: FRE, err: 0
to qref: 0x0xc13fdeee0, from qref: 0x0xc13fde280, inc: 0, send
er:
Queue Descriptor--kxfpqd: 0x0xb3f8249b8, remote queue addr:
0x0xc13fe12b0
instance id: 1, server id: 5, flags: INIT
SO: 0xc13fdf0f0, type: 62, owner: 0xc13fe20e8, flag: -/-/-/0x00
Queue Reference--kxfpqr: 0x0xc13fdf0f0, ser: 513, seq: 949, erro
r: 0
opp qref: 0x0xc13fdc390, process: 0x0xc0d2a3d10, bufs: {0x(nil),
0x0xb3fc924f8}
state: 00000, flags: SMEM, nulls 0, hint 0x1
latch 0x0xc13fdf200, remote descriptor:
Queue Descriptor--kxfpqd: 0x0xc13fdf138, remote queue addr: 0x
0xc13fe1508
instance id: 1, server id: 4, flags: INIT
recovery info--opr: 0, bufs: {0x0xb3fc924f8, 0x0xb3fca24f8}, sta
te: 10011
---------------------------------------

Recover standby database error

Hi
here is the error message i got when i run this command
09:30:35 SYS@MOZAI> alter database recover standby database until cancel;
alter database recover standby database until cancel
ERROR at line 1:
ORA-00279: change 126425376421 generated at 02/26/2012 09:26:00 needed for thread 2
ORA-00289: suggestion : +ARCH
ORA-00280: change 126425376421 for thread 2 is in sequence #312362
Any suggestion is highly apprciated .
Thanks

Hello;
You probably started the recovery ( to apply redo from the Primary )
Cancel this before doing the command you trying :
alter database recover managed standby database cancel;Then issue your command again.
Best Regards
mseberg

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
Sadiq

Hi,
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.

ERROR in creating a Physical Standby Database

Hello all,
I am using a Windows Vista O/S and Oracle 10g Enterprise Edition. Both my primary and standby are on the same host. Created standby instance using oradim.
I have followed instruction in the documentation and created a manual standby database.
primary database is 'orcl'
standby database is 'stby'
My primary archives is not being copied to the the stby location as confirmed by an error shown:
SQL> select dest_name, status from v$archive_dest_status
DEST_NAME
STATUS
LOG_ARCHIVE_DEST_1
VALID
LOG_ARCHIVE_DEST_2
ERROR
Also my standby does not open in read only mode, error:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION
ERROR at line 1:
ORA-01153: an incompatible media recovery is active
SQL> ALTER DATABASE open read only;
ALTER DATABASE open read only
ERROR at line 1:
ORA-01154: database busy. Open, close, mount, and dismount not allowed now
I have copied both my prim and stby init.ora here for your reference
PRIMARY INIT
============================================
orcl.__db_cache_size=394264576
orcl.__java_pool_size=20971520
orcl.__large_pool_size=4194304
orcl.__shared_pool_size=184549376
orcl.__streams_pool_size=0
*.audit_file_dest='E:\oracle\product\10.2.0\admin\orcl\adump'
*.background_dump_dest='E:\oracle\product\10.2.0\admin\orcl\bdump'
*.compatible='10.2.0.3.0'
*.control_files='E:\oracle\product\10.2.0\oradata\orcl\control01.ctl'
*.core_dump_dest='E:\oracle\product\10.2.0\admin\orcl\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='orcl'
*.db_unique_name=orcl
*.db_recovery_file_dest_size=2147483648
*.db_recovery_file_dest='E:\oracle\product\10.2.0\flash_recovery_area'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.job_queue_processes=10
*.nls_language='ENGLISH'
*.nls_territory='UNITED KINGDOM'
*.open_cursors=300
*.pga_aggregate_target=203423744
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=611319808
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='E:\oracle\product\10.2.0\admin\orcl\udump'
*.standby_file_management=AUTO
*.log_archive_dest_1='location=E:\oracle\product\10.2.0\flash_recovery_area\orcl\archivelog valid_for=(all_logfiles,primary_role) db_unique_name=orcl'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_2='SERVICE=stby LGWR ASYNC valid_for=(online_logfiles,primary_role) db_unique_name=stby'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_config='DG_CONFIG=(orcl,stby)'
*.db_file_name_convert='orcl','stby'
*.fal_client='orcl'
*.fal_server='stby'
*.db_file_name_convert='E:\oracle\product\10.2.0\oradata\stby', 'E:\oracle\product\10.2.0\oradata\orcl'
*.log_file_name_convert='E:\oracle\product\10.2.0\oradata\stby', 'E:\oracle\product\10.2.0\oradata\orcl'
*.standby_file_management=AUTO
======================================
STANDBY INIT.ora
stby.__db_cache_size=423624704
stby.__java_pool_size=4194304
tby.__large_pool_size=4194304
stby.__large_pool_size=4194304
stby.__shared_pool_size=171966464
stby.__streams_pool_size=0
*.audit_file_dest='E:\oracle\product\10.2.0\admin\stby\adump'
*.background_dump_dest='E:\oracle\product\10.2.0\admin\stby\bdump'
*.compatible='10.2.0.3.0'
*.control_files='E:\oracle\product\10.2.0\oradata\stby\CONTROL_SB01.CTL'
*.core_dump_dest='E:\oracle\product\10.2.0\admin\stby\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_file_name_convert='orcl','stby'
*.db_name='orcl'
*.db_recovery_file_dest_size=2147483648
*.db_recovery_file_dest='E:\oracle\product\10.2.0\flash_recovery_area\STBY'
*.db_unique_name='stby'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.fal_client='stby'
*.fal_server='orcl'
*.job_queue_processes=10
*.log_archive_config='DG_CONFIG=(orcl,stby)'
*.log_archive_dest_1='location=E:\oracle\product\10.2.0\flash_recovery_area\stby valid_for=(all_logfiles,primary_role) db_unique_name=stby'
*.log_archive_dest_2='SERVICE=stby LGWR ASYNC valid_for=(online_logfiles,primary_role) db_unique_name=orcl'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_file_name_convert='E:\oracle\product\10.2.0\oradata\orcl','E:\oracle\product\10.2.0\oradata\stby'
*.nls_language='ENGLISH'
*.nls_territory='UNITED KINGDOM'
*.open_cursors=300
*.pga_aggregate_target=203423744
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=611319808
*.standby_archive_dest='USE_DB_RECOVERY_FILE_DEST'
*.standby_file_management='AUTO'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='E:\oracle\product\10.2.0\admin\stby\udump'
=================================================
Any help would be much appreciated. Apologies for my ignorance!
Thanks!
null
null

OK that solves part of the problem.
Now this is very strange error I am getting. The path it looks to recover from archive is not right, it should point as per my actual archive log dest. See below.
Standby:
=================
SQL> alter database open;
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: 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\STBY\SYSTEM01.DBF'
SQL> recover standby database until cancel;
ORA-00279: change 619067 generated at 06/22/2008 13:20:14 needed for thread 1
ORA-00289: suggestion :
E:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC00006_0658028298.001
ORA-00280: change 619067 for thread 1 is in sequence #6
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log
'E:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC00006_0658028298.001'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) The system cannot find the file specified.
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\STBY\SYSTEM01.DBF'
==================================================
Why is not pointing to the destination below, where the above archives reside??
=====================================
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination E:\oracle\product\10.2.0\flash_recovery_area\stby
Oldest online log sequence 12
Next log sequence to archive 0
Current log sequence 14
=================

Issue with physical standby database not in sync with primary

Hi,
I created an physical standby database couple of Hours back . I am trying to keep the standby database in Managed recovery mode to make the standby in sync with primary but it is throwing the below erros. Please share your suggestion ...
SQL> select thread#,max(sequence#) from v$log_history group by thread#;
THREAD# MAX(SEQUENCE#)
1 7
PROCESS STATUS THREAD# SEQUENCE#
ARCH CONNECTED 0 0
ARCH CONNECTED 0 0
RFS OPENING 1 12
ALERT LOG :
Tue Mar 20 07:31:32 2012
alter database recover managed standby database disconnect from session
Tue Mar 20 07:31:32 2012
Attempt to start background Managed Standby Recovery process (PRIMARY)
MRP0 started with pid=18, OS id=16370
Tue Mar 20 07:31:32 2012
MRP0: Background Managed Standby Recovery process started (PRIMARY)
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 8 processes
Media Recovery Log /oracle/STDBY/arch/1_3_777567883.dbf
Tue Mar 20 07:31:39 2012
Completed: alter database recover managed standby database disconnect from session
Tue Mar 20 07:31:54 2012
Incomplete recovery applied all redo ever generated.
Recovery completed through change 9677325080303
Tue Mar 20 07:31:54 2012
MRP0: Media Recovery Complete (PRIMARY)
Tue Mar 20 07:31:55 2012
MRP0: Background Media Recovery process shutdown (PRIMARY)
Thanks,
Rakesh

HI CKPT,
Thanks for the reply. All the Archives from primary are transferred to the standby by RFS. Also i tried to register the log files manually even but it says already registered. They are no errors in the primary instance alert log file. Please find the log
SEVERITY ERROR_CODE MESSAGE TO_CHAR(TIMESTAMP,'D
Informational 0 ARC0: Archival started 20-MAR-2012 06:51:36
Informational 0 ARC1: Archival started 20-MAR-2012 06:51:36
Informational 0 ARC0: Becoming the 'no FAL' ARCH 20-MAR-2012 06:51:36
Informational 0 ARC0: Becoming the 'no SRL' ARCH 20-MAR-2012 06:51:36
Informational 0 ARC1: Becoming the heartbeat ARCH 20-MAR-2012 06:51:36
Informational 0 Redo Shipping Client Connected as PUBLIC 20-MAR-2012 06:52:07
Informational 0 -- Connected User is Valid 20-MAR-2012 06:52:07
Informational 0 RFS[1]: Assigned to RFS process 15934 20-MAR-2012 06:52:07
Informational 0 RFS[1]: Identified database type as 'physical standby' 20-MAR-2012 06:52:07
Warning 0 RFS[1]: No standby redo logfiles created 20-MAR-2012 06:52:07
Control 0 Attempt to start background Managed Standby Recovery process 20-MAR-2012 06:52:42
Control 0 MRP0: Background Managed Standby Recovery process started 20-MAR-2012 06:52:42
Informational 0 Managed Standby Recovery not using Real Time Apply 20-MAR-2012 06:52:47
Informational 0 Media Recovery Log /oracle/STDBY/arch/1_3_777567883.d 20-MAR-2012 06:52:49
bf
Control 0 MRP0: Media Recovery Complete 20-MAR-2012 06:53:04
Control 0 MRP0: Background Media Recovery process shutdown 20-MAR-2012 06:53:06
Informational 0 Managed Standby Recovery not using Real Time Apply 20-MAR-2012 06:53:24
Control 0 Media Recovery Complete 20-MAR-2012 06:53:43
Control 0 Attempt to start background Managed Standby Recovery process 20-MAR-2012 06:54:55
Control 0 MRP0: Background Managed Standby Recovery process started 20-MAR-2012 06:54:55
Informational 0 Managed Standby Recovery not using Real Time Apply 20-MAR-2012 06:55:00
Informational 0 Media Recovery Log /oracle/STDBY/arch/1_3_777567883.d 20-MAR-2012 06:55:01
bf
Control 0 MRP0: Media Recovery Complete 20-MAR-2012 06:55:17
Control 0 MRP0: Background Media Recovery process shutdown 20-MAR-2012 06:55:18
Informational 0 Redo Shipping Client Connected as PUBLIC 20-MAR-2012 07:31:03
Informational 0 -- Connected User is Valid 20-MAR-2012 07:31:03
Informational 0 RFS[2]: Assigned to RFS process 16366 20-MAR-2012 07:31:03
Informational 0 RFS[2]: Identified database type as 'physical standby' 20-MAR-2012 07:31:03
Warning 0 RFS[2]: No standby redo logfiles created 20-MAR-2012 07:31:04
Warning 0 RFS[2]: No standby redo logfiles created 20-MAR-2012 07:31:06
Control 0 Attempt to start background Managed Standby Recovery process 20-MAR-2012 07:31:32
Control 0 MRP0: Background Managed Standby Recovery process started 20-MAR-2012 07:31:32
Informational 0 Managed Standby Recovery not using Real Time Apply 20-MAR-2012 07:31:37
Informational 0 Media Recovery Log /oracle/STDBY/arch/1_3_777567883.d 20-MAR-2012 07:31:38
bf
Control 0 MRP0: Media Recovery Complete 20-MAR-2012 07:31:54
Control 0 MRP0: Background Media Recovery process shutdown 20-MAR-2012 07:31:55
36 rows selected.
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /oracle/STDBY/arch/
Oldest online log sequence 13
Next log sequence to archive 0
Current log sequence 14
SQL> ho ls -ltra /oracle/STDBY/arch/
total 3754456
drwxr-xr-x 4 oracle dba 4096 Feb 13 17:38 ..
-rw-r----- 1 oracle dba 908516864 Mar 20 06:37 1_8_777567883.dbf
-rw-r----- 1 oracle dba 770419200 Mar 20 06:40 1_3_777567883.dbf
-rw-r----- 1 oracle dba 757698048 Mar 20 06:41 1_4_777567883.dbf
-rw-r----- 1 oracle dba 5171712 Mar 20 06:41 1_5_777567883.dbf
-rw-r----- 1 oracle dba 1060801024 Mar 20 06:43 1_6_777567883.dbf
-rw-r----- 1 oracle dba 323025920 Mar 20 06:43 1_7_777567883.dbf
-rw-r----- 1 oracle dba 1558016 Mar 20 06:43 1_9_777567883.dbf
-rw-r----- 1 oracle dba 4608 Mar 20 06:43 1_10_777567883.dbf
-rw-r----- 1 oracle dba 1579008 Mar 20 06:52 1_11_777567883.dbf
-rw-r----- 1 oracle dba 11876864 Mar 20 07:31 1_12_777567883.dbf
-rw-r----- 1 oracle dba 2560 Mar 20 07:31 1_13_777567883.dbf
drwxr-xr-x 2 oracle dba 36864 Mar 20 07:31 .
SQL>

Manual Standby Database (10.2.0.2.0) on Windows 2003 R2

Hi,
We are setting up a standby database on a remote site for a simple oracle DB. As we already have a standby/master for another Oracle DB (from SAP) we want to stay as close as possible as what already exist.
For the SAP Oracle standby, we are copying manualy all archive to the stand by and apply them with brarchive. All is working fine.
For the new standby, we can not use brarchive as there is no SAP install on the standby but we stay with the "manual" copy of the archive from the master to the standby (using robocpy). It means all archive are on the standby (K:\oracle\oradata\archive).
The creation of the standby DB seems to be OK as i can open it, but i can't manage to apply de redo logs.
I'm quite new to oracle, so it's maybe a very basic issue, but i've already spent 3 days on it...
To start the DB, we lauch a bat script :
sqlplus /nolog @c:\backup\standby.sql
pause
the standby.sql:
connect /@TECDB01 as sysdba
startup nomount;
alter database mount standby database;
exit;
Then i connect to sqlplus and enter:
alter database recover managed standby database;
In another sqlplus session :
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
wich give me :
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
MR(fg) WAIT_FOR_GAP 1 45400 0 0
RFS IDLE 0 0 0 0
The sequence 45400 seems to be ok regarding the time of the backup restored on the standby.
The archive is well on the server, but it won't apply it.
The Alert_TECDB01.log :
Fri Oct 29 11:03:43 2010
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =121
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.2.0.
System parameters with non-default values:
processes                = 999
sga_target               = 7214202880
control_files            = I:\ORACLE\ORADATA\CNTRL\STANDBY.CTL, J:\ORACLE\ORADATA\CNTRL\STANDBY.CTL, K:\ORACLE\ORADATA\CNTRL\STANDBY.CTL
db_block_size            = 8192
compatible               = 10.2.0.2.0
log_archive_dest_1       = LOCATION=K:\oracle\oradata\archive
log_archive_dest_2       = SERVICE=TECDB01
log_archive_dest_state_1 = enable
log_archive_dest_state_2 = enable
standby_archive_dest     = K:\oracle\oradata\archive
archive_lag_target       = 1800
db_file_multiblock_read_count= 16
undo_management          = AUTO
undo_tablespace          = RBS
undo_retention           = 10800
recyclebin               = OFF
remote_login_passwordfile= EXCLUSIVE
db_domain                = WORLD
dispatchers              = (ADDRESS=(PROTOCOL=tcp)(HOST=xxx.xxx.xxx.92))(DISPATCHERS=4)(CONNECTIONS=1000)
shared_servers           = 100
local_listener           = (ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxx.xxx.92)(PORT=1521))
session_cached_cursors   = 300
utl_file_dir             = \\srvuniway.vrithoff.srwt.tec-wl.be\hotspots
job_queue_processes      = 10
audit_file_dest          = I:\ORACLE\ADMIN\TECDB01\ADUMP
background_dump_dest     = I:\ORACLE\ADMIN\TECDB01\BDUMP
user_dump_dest           = I:\ORACLE\ADMIN\TECDB01\UDUMP
core_dump_dest           = I:\ORACLE\ADMIN\TECDB01\CDUMP
db_name                  = TECDB01
open_cursors             = 3000
pga_aggregate_target     = 1086324736
PMON started with pid=2, OS id=4012
PSP0 started with pid=3, OS id=3856
MMAN started with pid=4, OS id=3580
DBW0 started with pid=5, OS id=1084
LGWR started with pid=6, OS id=576
CKPT started with pid=7, OS id=3516
SMON started with pid=8, OS id=508
RECO started with pid=9, OS id=3068
CJQ0 started with pid=10, OS id=2448
MMON started with pid=11, OS id=2840
MMNL started with pid=12, OS id=3024
Fri Oct 29 11:03:44 2010
starting up 4 dispatcher(s) for network address '(ADDRESS=(PROTOCOL=tcp)(HOST=xxx.xxx.xxx.92))'...
starting up 100 shared server(s) ...
Fri Oct 29 11:03:45 2010
alter database mount standby database
Fri Oct 29 11:03:51 2010
Setting recovery target incarnation to 2
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=118, OS id=3584
Fri Oct 29 11:03:51 2010
ARC0: Archival started
ARC1 started with pid=119, OS id=3688
Fri Oct 29 11:03:51 2010
ARC1: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
Fri Oct 29 11:03:51 2010
ARC0: Becoming the 'no FAL' ARCH
Fri Oct 29 11:03:51 2010
Successful mount of redo thread 1, with mount id 3987142355
Fri Oct 29 11:03:51 2010
ARC0: Becoming the 'no SRL' ARCH
Fri Oct 29 11:03:51 2010
ARC1: Becoming the heartbeat ARCH
Fri Oct 29 11:03:51 2010
Physical Standby Database mounted.
Completed: alter database mount standby database
Fri Oct 29 11:04:06 2010
alter database recover managed standby database
Fri Oct 29 11:04:06 2010
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 7 processes
Media Recovery Waiting for thread 1 sequence 45400
Fetching gap sequence in thread 1, gap sequence 45400-45499
+FAL[client]: Error fetching gap sequence, no FAL server specified+
Fri Oct 29 11:04:37 2010
+FAL[client]: Failed to request gap sequence+
GAP - thread 1 sequence 45400-45499
DBID 3776455083 branch 670241032
+FAL[client]: All defined FAL servers have been attempted.+
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
Fri Oct 29 11:04:51 2010
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 3452
RFS[1]: Identified database type as 'physical standby'
Fri Oct 29 11:04:51 2010
RFS LogMiner: Client disabled from further notification
The tecdb01_arc1_3688.trc :
Dump file i:\oracle\admin\tecdb01\bdump\tecdb01_arc1_3688.trc
Fri Oct 29 11:03:51 2010
ORACLE V10.2.0.2.0 - 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
Windows NT Version V5.2 Service Pack 2
CPU                 : 8 - type 8664, 2 Physical Cores
Process Affinity    : 0x0000000000000000
Memory (Avail/Total): Ph:7467M/9215M, PhPgF:2454M/10796M+
Instance name: tecdb01
Redo thread mounted by this instance: 1
Oracle process number: 119
Windows thread id: 3688, image: ORACLE.EXE (ARC1)
*** SERVICE NAME:() 2010-10-29 11:03:51.177
*** SESSION ID:(1088.1) 2010-10-29 11:03:51.177
kcrrwkx: nothing to do (start)
*** 2010-10-29 11:04:51.129
Redo shipping client performing standby login
*** 2010-10-29 11:04:51.176 64529 kcrr.c
Logged on to standby successfully
Client logon and security negotiation successful!
kcrrwkx: nothing to do (end)
*** 2010-10-29 11:05:51.285
kcrrwkx: nothing to do (end)
*** 2010-10-29 11:06:51.300
kcrrwkx: nothing to do (end)
The initTECDB01.ora :
# Copyright (c) 1991, 2001, 2002 by Oracle Corporation
# Archive
archive_lag_target=1800
log_archive_dest_1='LOCATION=K:\oracle\oradata\archive'
# Cache and I/O
db_block_size=8192
db_file_multiblock_read_count=16
# Cursors and Library Cache
open_cursors=3000
session_cached_cursors=300
# Database Identification
db_domain=WORLD
db_name=TECDB01
# Diagnostics and Statistics
background_dump_dest=I:\oracle\admin\TECDB01\bdump
core_dump_dest=I:\oracle\admin\TECDB01\cdump
user_dump_dest=I:\oracle\admin\TECDB01\udump
# File Configuration
control_files=("I:\oracle\oradata\cntrl\standby.ctl", "J:\oracle\oradata\cntrl\standby.ctl", "K:\oracle\oradata\cntrl\standby.ctl")
# Job Queues
job_queue_processes=10
# Miscellaneous
compatible=10.2.0.2.0
recyclebin=OFF
# Processes and Sessions
processes=999
# SGA Memory
sga_target=6880M
# Pools
#java_pool_size=150M
# Security and Auditing
audit_file_dest=I:\oracle\admin\TECDB01\adump
remote_login_passwordfile=EXCLUSIVE
# Shared Server
shared_servers=100
dispatchers="(ADDRESS=(PROTOCOL=tcp)(HOST=xxx.xxx.xxx.92))(DISPATCHERS=4)(CONNECTIONS=1000)"
#dispatchers="(PROTOCOL=TCP) (SERVICE=TECDB01XDB)"
# Sort, Hash Joins, Bitmap Indexes
pga_aggregate_target=1036M
# System Managed Undo and Rollback Segments
undo_management=AUTO
undo_retention=10800
undo_tablespace=RBS
local_listener="(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxx.xxx.92)(PORT=1521))"
# NIDA - 28.10.2010 - redo apply
log_archive_dest_state_1=enable
log_archive_dest_2 = 'SERVICE=TECDB01'
log_archive_dest_state_2=enable
#standby_file_management=auto
standby_archive_dest=K:\oracle\oradata\archive
And the TNSNAMES.ora :
# tnsnames.ora Network Configuration File: C:\oracle\102\network\admin\tnsnames.ora
# Generated by Oracle configuration tools.
#this is the standby
TECDB01.VRITHOFF.SRWT.TEC-WL.BE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = xxx.xxx.xxx.92)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = TECDB01)
# This file is written by Oracle Services For MSCS
# on Sat Nov 08 10:44:27 2008
#this is the master
PRIMARY.VRITHOFF.SRWT.TEC-WL.BE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = xxx.xxx.xxx.246)(PORT = 1521))
(CONNECT_DATA =
(SID = TECDB01)
EXTPROC_CONNECTION_DATA.VRITHOFF.SRWT.TEC-WL.BE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = TECDB01))
(CONNECT_DATA =
(SERVICE_NAME = TECDB01)
Hope you have all information to bring me in the right way.
Regards,
Nicolas

Hi,
The recover automatic is working fine, but I still have problems with the recover managed
Here is the Alert log :(the 46626 was there at 11:30)
Mon Nov 15 11:31:13 2010
alter database recover managed standby database using current logfile
Managed Standby Recovery starting Real Time Apply
parallel recovery started with 7 processes
Media Recovery Waiting for thread 1 sequence 46626
Mon Nov 15 16:36:01 2010
alter database recover managed standby database cancel
Mon Nov 15 16:36:05 2010
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Mon Nov 15 16:36:06 2010
Media Recovery user canceled with status 16037
ORA-16043 signalled during: alter database recover managed standby database using current logfile...
Mon Nov 15 16:36:07 2010
Completed: alter database recover managed standby database cancel
Mon Nov 15 16:36:37 2010
ALTER DATABASE RECOVER automatic standby database until time'2010-11-15:15:50:00'
Mon Nov 15 16:36:37 2010
Media Recovery Start
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 7 processes
Mon Nov 15 16:36:39 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46626_0670241032.001
Mon Nov 15 16:36:45 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46627_0670241032.001
Mon Nov 15 16:37:11 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46628_0670241032.001
Mon Nov 15 16:37:30 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46629_0670241032.001
Mon Nov 15 16:37:48 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46630_0670241032.001
Mon Nov 15 16:37:59 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46631_0670241032.001
Mon Nov 15 16:38:15 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46632_0670241032.001
Mon Nov 15 16:38:28 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46633_0670241032.001
Mon Nov 15 16:38:47 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46634_0670241032.001
Mon Nov 15 16:39:34 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46635_0670241032.001
Mon Nov 15 16:40:43 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46636_0670241032.001
Mon Nov 15 16:42:03 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46637_0670241032.001
Mon Nov 15 16:43:18 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46638_0670241032.001
Mon Nov 15 16:44:38 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46639_0670241032.001
Mon Nov 15 16:45:45 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46640_0670241032.001
Mon Nov 15 16:46:37 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46641_0670241032.001
Mon Nov 15 16:47:48 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46642_0670241032.001
Mon Nov 15 16:49:07 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46643_0670241032.001
Mon Nov 15 16:50:04 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46644_0670241032.001
Mon Nov 15 16:51:13 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46645_0670241032.001
Mon Nov 15 16:52:16 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46646_0670241032.001
Mon Nov 15 16:53:07 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46647_0670241032.001
Mon Nov 15 16:54:28 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46648_0670241032.001
Mon Nov 15 16:55:47 2010
Media Recovery Log K:\ORACLE\ORADATA\ARCHIVE\ARC46649_0670241032.001
Mon Nov 15 16:56:35 2010
Incomplete Recovery applied until change 4037420604
Completed: ALTER DATABASE RECOVER automatic standby database until time'2010-11-15:15:50:00'
I don't catch why the system wait for a sequence that is available...
Regards,
Nico

Automatic Loc Recover in Standby Database

Similar Messages

Maybe you are looking for