Auto specified any value after ran RECOVER STANDBY DATABASE;

Dear all,
When i ran the RECOVER STANDBY DATABASE command.It 's will prompt as
below :
SQL> RECOVER STANDBY DATABASE;
ORA-00279: change 302927 generated at 09/10/2007 14:08:24 needed for thread 1
ORA-00289: suggestion : D:\ORACLE\ORADATA\DB817\ARCHIVE\DB817T001S00021.ARC
ORA-00280: change 302927 for thread 1 is in sequence #21
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Is there anyway to force specified "AUTO" automatically ?
Because i will to create a scripts file for run automatic .
Thanks for advance !
Chara

ORA-00289: suggestion : D:\ORACLE\ORADATA\DB817\ARCHIVE\DB817T001S00021.ARCFirst check if the required Archive / Redo log is present on your system under the directory "D:\ORACLE\ORADATA\DB817\ARCHIVE".
For automatic recovery use:
ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE;
or
RECOVER AUTOMATIC STANDBY DATABASE;
Cheers!

Similar Messages

Recover Standby Database suggests wrong filename

Hi,
I am running Oracle Database 10g Release 10.2.0.3.0 - 64bit Production Standard Edition on Linux version 2.6.9-42.0.8.ELsmp ([email protected]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3))
I've created a physical standby database, but since I am running Standard Edition, I am not using the DataGuard features. I use the rsync utility to copy over the archivelogs to the standby database, and I apply them periodically to the standby database.
The standby database is started this way :
startup nomount pfile='/u01/oradata/orcl/initorcl.stdby';
alter database mount standby database;
And the archives are applied this way :
recover standby database;
AUTO
(AUTO for the command to apply all available archive logs automatically, using the suggested paths and filenames)
My problem is that once in a while (maybe once every 2-3 weeks), the suggested filename does not have the same format as the rest of the time. I then have to manually specify the correct filename and it goes fine after that.
Example :
In this example, you will see that it is first looking for sequence 22907 (o1_mf_1_22907_5n3m1xrf_.arc), then 22908 (o1_mf_1_22908_5n3m4kf0_.arc) [Notice the format of the file name] and then tries to look for sequence 22909, but looks for filename ".o1_mf_1_22909_5n3md1h5_.arc.qXMz5s"
Mon Jan 4 06:22:01 2010
ALTER DATABASE RECOVER standby database
Media Recovery Start
Managed Standby Recovery not using Real Time Apply
ORA-279 signalled during: ALTER DATABASE RECOVER standby database ...
Mon Jan 4 06:22:02 2010
ALTER DATABASE RECOVER CONTINUE DEFAULT
Mon Jan 4 06:22:02 2010
Media Recovery Log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/o1_mf_1_22907_5n3m1xrf_.arc
Mon Jan 4 06:24:20 2010
ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Mon Jan 4 06:24:20 2010
ALTER DATABASE RECOVER CONTINUE DEFAULT
Mon Jan 4 06:24:20 2010
Media Recovery Log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/o1_mf_1_22908_5n3m4kf0_.arc
Mon Jan 4 06:24:46 2010
ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Mon Jan 4 06:24:46 2010
ALTER DATABASE RECOVER CONTINUE DEFAULT
Mon Jan 4 06:24:46 2010
Media Recovery Log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/.o1_mf_1_22909_5n3md1h5_.arc.qXMz5s
Errors with log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/.o1_mf_1_22909_5n3md1h5_.arc.qXMz5s
ORA-308 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Mon Jan 4 06:24:46 2010
ALTER DATABASE RECOVER CANCEL
Mon Jan 4 06:24:46 2010
Media Recovery Canceled
Completed: ALTER DATABASE RECOVER CANCEL
Can someone explain to me why is this happening please ?
Thanks a lot,
Mat

@fjfranken
Yes. If I manually enter the name of the file for the sequence requested instead of passing the suggested fielname, it works fine.
And the log_archive_format is not defined, I am using the flash_recovery_area and let Oracle manage this automatically.
@Hemant K Chitale
Unfortunately, those sequences are not listed anymore in the V$ARCHIVED_LOG view.
Well, I think the the problem might be related to files that are being written to at some time...
Thanks,
Mat

Recover standby database

Our primary linux 10g db is in standard edition and we would like to manually create a standby database
After copying the control and datafiles from primary to standby database, started the standby instance ..
SQL> startup nomount pfile=/path/to/pfile/initSID.standby
SQL> alter database mount standby database;
SQL> recover standby database;
ORA-00279: change 2342934 generated at 8/27/2009 21:10:35 needed for thread 1
ORA-00289: suggestion : /opt/oracle/arch/SID/1_833_682861383.arc
ORA-00280: change 2342934 for thread 1 is in sequence #833
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00308: cannot open archived log
'/opt/oracle/arch/SID/1_833_682861383.arc'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/SID/system01.dbf'
How do I resolve this problem? Log sequence 833 is the current log on the primary db, archive log haven't been written yet. When I try to "alter database open read only" on the standby db, I get an error "ORA-01156: recovery in progress may need access to file".
I then went back to my primary database, which already had another log switch to 834, log 833 is now available, I then moved that archive log file to the standby db. Try to recover standby database again, but still got errors..
SQL> startup nomount pfile=/path/to/pfile/initSID.standby
SQL> alter database mount standby database;
SQL> recover standby database;
ORA-00279: change 2342934 generated at 8/27/2009 21:10:35 needed for thread 1
ORA-00289: suggestion : /opt/oracle/arch/SID/1_833_682861383.arc
ORA-00280: change 2342934 for thread 1 is in sequence #833
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00317: file type 0 in header is not log file
ORA-00334: archived log: '/opt/oracle/arch/SID/1_833_682861383.arc'
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/SID/system01.dbf'
SQL> alter database open read only;
ERROR at line 1:
ORA-16004: backup database requires recovery
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/SID/system01.dbf'
Would something please explain this to me? What am I doing wrong? Thanks in advance.

I copied the missing archive log over to standby db, still got the same error.
1) SQL> recover standby database;
ORA-00279: change 2342934 generated at 8/27/2009 21:10:35 needed for thread 1
ORA-00289: suggestion : /opt/oracle/arch/SID/1_833_682861383.arc
ORA-00280: change 2342934 for thread 1 is in sequence #833
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00317: file type 0 in header is not log file
ORA-00334: archived log: '/opt/oracle/arch/SID/1_833_682861383.arc'
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/SID/system01.dbf'
I also tried..
2) SQL> recover standby database using backup controlfile until cancel;
ORA-00279: change 2342934 generated at 8/27/2009 21:10:35 needed for thread 1
ORA-00289: suggestion : /opt/oracle/arch/SID/1_833_682861383.arc
ORA-00280: change 2342934 for thread 1 is in sequence #833
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00317: file type 0 in header is not log file
ORA-00334: archived log: '/opt/oracle/arch/SID/1_833_682861383.arc'
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01195: online backup of file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/opt/oracle/oradata/SID/system01.dbf'
Edited by: user10427867 on Aug 28, 2009 5:56 AM

The password file is getting corrupted after rebooting the standby database

Hi,
The password file is getting corrupted after rebooting the standby database.
Since the databases are not in sync, I had to copy the pwfile from primary to standby to make 'em sync.
(BUT.... the pwfile is not getting corrupted every time I reboot the standby by)
Could somebody please explain the reason for the pwfile on the standby database getting corrupted while rebooting ?
Env: Oracle 11g on Windows 7
Thanks in advance

Moderator Action:
This thread was originally posted to the Oracle/Sun Servers HARDWARE forum.
This is definitely not an issue related to any hardware components.
... it's now moved to Database General Questions, hopefully for closer topic alignment.

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

DBhanging in open stage after creating physical standby database

alter database open read only hanging after creating the standby database using rman.

hi,
when i starts the database in restricted mode it is asking resetlogs;
when i openthe database using the
alter database open resetlogs;
it is showing following errors
alter database open RESETLOGS
Errors in file /oracle/app/oradev/db/tech_st/11.2.0/admin/stdby_developmentDR/diag/rdbms/stdby/stdby/trace/stdby_ora_442500.trc:
ORA-00367: checksum error in log file header
ORA-00338: log 1 of thread 1 is more recent than control file
ORA-00312: online log 1 thread 1: '/dev/stage/oradev/db/apps_st/data/group_1.314.731945051'
RESETLOGS after complete recovery through change 28393568059
Resetting resetlogs activation ID 3821641494 (0xe3c99f16)
Errors in file /oracle/app/oradev/db/tech_st/11.2.0/admin/stdby_developmentDR/diag/rdbms/stdby/stdby/trace/stdby_ora_442500.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: '/dev/stage/oradev/db/apps_st/data/group_1.314.731945051'
Thu Feb 24 20:05:42 2011
Errors in file /oracle/app/oradev/db/tech_st/11.2.0/admin/stdby_developmentDR/diag/rdbms/stdby/stdby/trace/stdby_m000_348380.trc:
ORA-00316: log 1 of thread 1, type 0 in header is not log file
ORA-00312: online log 1 thread 1: '/dev/stage/oradev/db/apps_st/data/group_1.314.731945051'
Errors in file /oracle/app/oradev/db/tech_st/11.2.0/admin/stdby_developmentDR/diag/rdbms/stdby/stdby/trace/stdby_m000_348380.trc:
ORA-00322: log 2 of thread 1 is not current copy
ORA-00312: online log 2 thread 1: '/dev/stage/oradev/db/apps_st/data/group_2.313.731945057'
Errors in file /oracle/app/oradev/db/tech_st/11.2.0/admin/stdby_developmentDR/diag/rdbms/stdby/stdby/trace/stdby_m000_348380.trc:
ORA-00322: log 3 of thread 2 is not current copy
ORA-00312: online log 3 thread 2: '/dev/stage/oradev/db/apps_st/data/group_3.316.731945065'
Errors in file /oracle/app/oradev/db/tech_st/11.2.0/admin/stdby_developmentDR/diag/rdbms/stdby/stdby/trace/stdby_m000_348380.trc:
ORA-00322: log 4 of thread 2 is not current copy
ORA-00312: online log 4 thread 2: '/dev/stage/oradev/db/apps_st/data/group_4.315.731945069'
Errors in file /oracle/app/oradev/db/tech_st/11.2.0/admin/stdby_developmentDR/diag/rdbms/stdby/stdby/trace/stdby_ora_442500.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 2 of thread 1 is not current copy
ORA-00312: online log 2 thread 1: '/dev/stage/oradev/db/apps_st/data/group_2.313.731945057'
Thu Feb 24 20:05:58 2011
Errors in file /oracle/app/oradev/db/tech_st/11.2.0/admin/stdby_developmentDR/diag/rdbms/stdby/stdby/trace/stdby_ora_442500.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 3 of thread 2 is not current copy
ORA-00312: online log 3 thread 2: '/dev/stage/oradev/db/apps_st/data/group_3.316.731945065'
Errors in file /oracle/app/oradev/db/tech_st/11.2.0/admin/stdby_developmentDR/diag/rdbms/stdby/stdby/trace/stdby_ora_442500.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 4 of thread 2 is not current copy
ORA-00312: online log 4 thread 2: '/dev/stage/oradev/db/apps_st/data/group_4.315.731945069'
thanks in advance

Windows 8 won't find any airport after resuming from standby

Hi,
I have had a windows 7 PC with both airport express (2nd and 3rd generation) working flawlessly. I bought a new Windows 8 Laptop. Initially everything worked fine, but after resuming from standby mode (closed the display and reopened) my itunes stopped working, and the airport utility software was unable to find both airport express. After shutdown and restart they both worked again until the next standby mode.
I've read somewhere that it might be a conflict with IPv6 so I disabled it from registry, but the problem remains.....
any thoughts
Regards,
German

Did you upgrade the drivers from the wireless card manufacturer in win8 machine.. ??
If that doesn't work.. do some more basic wireless investigation..
1. Are wireless names SMB compliant.. ie short, no spaces and pure alphanumeric?
2. WPA2 Personal security with a password which also conforms to the above.
3. Test with fixed wireless channels. 11, 6, 1
4. If none of the above work.. turn off security for a few minutes and see if that works.

Recover standby database after primary failed

Hi,
I'm having 11g setup with 2 standby databases. My scenario is i'm doing failover on one standby[new primary] and converting old primary as a standby. Question is what is the status of another standby? have to create new standby or can recover using flash option?
regards,
jp

'11g' is not a version, it is a marketing label. You need to post your version in the format <x>.<x>.<x>.<x>
Yes, I know this is asked much.
Also your question sadly lacks on details, as in this version of Oracle you can cascade standby databases (standby 1 can cascade to standby 2)
This begs the simple question:
Did you try?
If so, what happened?
If you didn't try, why didn't you try? What can happen?
Sybrand Bakker
Senior Oracle DBA

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
---------------------------------------

Recovered standby database, still it is looking for gap sequence

I have lost archive logs in both primary and standby database(deleted due to low space).
So folloed the below steps.
1.Identified minimum SCN from standby database.
2.Took inremental backup from primary database according this SCN(nnnnn)
3.Transfer this backup file to standby side
4. Cataloged database backups and recovered the database.
But medial recovery is searching for missing archived logs. Please advice.

957905 wrote:
I have lost archive logs in both primary and standby database(deleted due to low space).
So folloed the below steps.
1.Identified minimum SCN from standby database.
2.Took inremental backup from primary database according this SCN(nnnnn)
3.Transfer this backup file to standby side
4. Cataloged database backups and recovered the database.
But medial recovery is searching for missing archived logs. Please advice.Probably you have not restored new standby controlfile before performing recovery.

Query to get parameter name and value after ran the conccurent program

Hi All,
Query to get the parameter name and value for completed concurrent program using the request id. can any one help me in this regard.
Thanks,
Red.

Red,
I have tried the same query and it works properly here.
I have submitted "Purge Signon Audit data" concurrent program with "Audit Date" parameter set to 01-06-2009, and here is the query output:
SQL> select request_id, phase_code, status_code,
argument_text, argument1
from fnd_concurrent_requests
where request_id = '739664';
REQUEST_ID P S ARGUMENT_TEXT ARGUMENT1
739664 C C 2009/06/01 00:00:00 2009/06/01 00:00:00Regards,
Hussein

Archive apply issue for standby database in Standard Edition.

We have setup standby database in Oracle standard edition. the archive log cannot be send by oracle automatically. So we manually send the archive over. But do not see the database apply the archive log file. What could be wrong and where should we check on it?
We also used following when finishing the standby DB after running "recover standby database;" for a few archive log file:
alter database recover managed standby database disconnect from session;
======================================================================================
This is the status:
SQL> select OPEN_MODE, SWITCHOVER# ,REMOTE_ARCHIVE ,ARCHIVELOG_CHANGE#,SWITCHOVER_STATUS, DATABASE_ROLE from v$database;
OPEN_MODE SWITCHOVER# REMOTE_A ARCHIVELOG_CHANGE# SWITCHOVER_STATUS DATABASE_ROLE
MOUNTED 495550636 ENABLED 1.2201E+13 SESSIONS ACTIVE PHYSICAL STANDBY

The DB version is 10.2.0.5
I can do this to apply at standby DB:
SQL> set autorecovery on
SQL> recover standby database;
Then I tried to run this to leave the session:
alter database recover managed standby database disconnect from session;
Do not seen any apply.
=============================
Here is the last lines of alert log:
Errors in file /oracle/admin/cntus/bdump/cntus_mrp0_12389.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u03/cntus/redolog/redo01b.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/u02/cntus/redolog/redo01a.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Thu Sep 06 15:08:34 EDT 2012
Errors in file /oracle/admin/cntus/bdump/cntus_mrp0_12389.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u03/cntus/redolog/redo01b.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/u02/cntus/redolog/redo01a.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Clearing online redo logfile 1 /u02/cntus/redolog/redo01a.log
Clearing online log 1 of thread 1 sequence number 10158
Thu Sep 06 15:08:34 EDT 2012
Errors in file /oracle/admin/cntus/bdump/cntus_mrp0_12389.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u03/cntus/redolog/redo01b.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/u02/cntus/redolog/redo01a.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Thu Sep 06 15:08:34 EDT 2012
Errors in file /oracle/admin/cntus/bdump/cntus_mrp0_12389.trc:
ORA-19527: physical standby redo log must be renamed
ORA-00312: online log 1 thread 1: '/u02/cntus/redolog/redo01a.log'
Clearing online redo logfile 1 complete
Media Recovery Waiting for thread 1 sequence 10166
Thu Sep 06 15:08:35 EDT 2012
Completed: alter database recover managed standby database disconnect from session
======
We have the directory /u02/cntus/redolog and /u03/cntus/redolog. But nothing in there. Should we create redo for it? Is this a separate issue?
Thanks!

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

Which formula(a) do I use to select any value that is than 0 but 7 out of a range of cells and sum them.

I'm working on a sheet that I want to use to select a specific part based on values created by the sum of values in other cells. I am down to the point where I need to select a low range of numbers
If the sum of cell D5 equals any sum between 1-15 will equal = part 1
If the sum of cell D5 equals any sum between 16-23 will equal = part 2 ,
If the sum of cell D5 equal antsy sum between 24-32 will equal part 3.
I'm at a loss how to make one formula or combination of formulas do this.
Thanks in advance.
Big Al Hur

Hi Al,
The confusion arises from your having asked two separate questions, one in the subject line, the other in the body of your initial post.
1.
How do I sum only the values greater than zero and less than 7 in a range of cells?
This formula supplied by SGIII does what you have asked there:
=SUMIFS(A,A,">0",A,"<7")
The syntax is:
SUMIFS(sum-values, test-values, condition, test-values, condition…)
sum-values ( A ) is the range of cells containing the values to be summed (all the body cells in column A)
test-values and condition come in pairs. the first names the range of values to be tested, the second names the condition that must be met.
In this formula, the test-values in each pair are the same as the sum values.
condition ( ">0" ) is the first condition that must be met by these values. (greater than zero)
the second condition ( "<7" ) is the second condition that must be met (less than seven)
To be included in the sum, a value in the list must meet both conditions: It must be greater than 0 AND less than 7. IN SG's example, there are two values that meet both conditions, 2 in A2 and 6 in A5, that meet both conditions. Their sum, 8, is shown in A10, whch is the cell containing the formula.
2
If the sum of cell D5 equals any sum between 1-15 will equal = part 1
If the sum of cell D5 equals any sum between 16-23 will equal = part 2 ,
If the sum of cell D5 equals any sum between 24-32 will equal part 3.
This formula supplied by SGIII, and the Lookup table that goes with it, does what you have asked here.
=VLOOKUP(D5,Lookup::A:B,2,close-match)
Close-match means 'the largest value that is less than or equal to' the search-value.
The search-value is the value in D5
VLOOKUP searches in the leftmost column (A) of the lookup table (columns A and B of the table named Lookup).
With "close-match" specified:
any value that is equal to or greater than 0 and less than 16 will be matched by the 0 in A2. VLOOKUP will return the value in the same row of column 2 (B) of the table: "Part 1"
any value that is equal to or greater than 16 and less than 24 will be matched by the 16 in A3. VLOOKUP will return the value in the same row of column 2 (B) of the table: "Part 2"
any value that is equal to or greater than 24 will be matched by the 24 in A4. VLOOKUP will return the value in the same row of column 2 (B) of the table: "Part 3"
While this is not an exact match with your description above, it will perform exactly as you requested IF the value in D5 is never less than 1 and never greater than 32.
If the possible range is greater than that, I would suggest the changes shown below to the formula and to the lookup table. The column containing numbers is column D, and represents values in D5. Column E shows the result for each value using the given formula and lookup table (LU A). Column F shows results for the same values using the revised formula and lookup tble (LU B):
Original =VLOOKUP(D,LU A :: A:B,2,1)
Revised formula: =IFERROR(VLOOKUP(D,LU B :: A:B,2,1),"N//A")
In the revision, IFERROR takes care of the negative values in D2 and D3. The zero value in D4 and in the last row of column D and the overflow values (greater than 32) are handled by the revisions to the lookup table.
Regards,
Barry

Restore standby database 10gR2 after crash

The RMAN do a full backup of the physical standby of the DataGuard 10gR2 everyday.
If the standby was dead, disks corrupted, and replaced with a new server.
Can we restore the standby from the RMAN backup, apply the archivelogs or we have re-create the standby db from the primary ?
If possible to restore the standby from the RMAN backup, what are the procedure exactly ?
Is it like this:
     RMAN>     Startup force nomount;
     RMAN>     Restore spfile;
     RMAN>     Restore controlfile;
     RMAN>     Shutdown
     RMAN>     Startup mount
     RMAN>     Restore database
     SQL> Recover standby database until cancel;
## to start Redo Apply
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

user565394 wrote:
The RMAN backup of the standby db is not obsolete and the archivelogs are still available for the last 30 dayson the RMAN backup.
I believe there is no need to re-create the standby db from the primary because the RMAN backup is still valid so it's must be possible to get the standby db back from the RMAN. If anyone who has experience and could confirm this with the procedure. That would be great.Why not test it by your own? Create a standby database and practice. You can check my video tutorial on creating standby database:
http://kamranagayev.wordpress.com/2010/06/25/rman-video-tutorial-series-creating-duplicate-and-standby-database-using-rman/
Moreover, read the "Backing Up a Standby Database with RMAN" of the following documentation:
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96566/rcmbackp.htm#445993
Use the RMAN BACKUP command to back up the standby database. A backup of the standby database is exactly the same as a backup of the primary database, except that the backup takes place on the standby site. The primary database has no influence on the backup of the standby database. Note that when you connect to the standby database to perform the backup, you connect using the TARGET keyword and not the AUXILIARY keyword.
Whether the standby database backup is consistent or inconsistent depends on the state of the standby database when the backup is made. Only a consistent backup can be restored without performing media recovery.

Auto specified any value after ran RECOVER STANDBY DATABASE;

Similar Messages

Maybe you are looking for