Corrupted archlog in standby
Hi,
I have typical scenario for my standby database.
My standby was out of sync at archlog sequence 350 since the archlog destination went out of space. I have noticed it after 8 days. however, i cleaned the space today and the new logs started shipping to stnadby location except 351. Log sequence gap is at 351 as per alert log.
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 351-351
I now tried to copy the archlog 351 to the standby from primary. It was copied but did not copy all the bytes. So, its corrupted. I have overlooked it and issued the command
alter database register logfile '/u01/dev/kpmf/archlogs/archlog351.dbf';
Because of this corrupted log it gave the error.
ORA-00332: archived log is too small - may be incompletely archived
ORA-00334: archived log: '/u01/dev/kpmf/archlogs/archlog351.dbf'
Tue Sep 1 12:10:11 2009
MRP0: Background Media Recovery process shutdown (dgupP)
I noticed that it was corrupt file and i tried to copy the file again and tried to register it but it was denied.
Please specify the solution now how i can make my standby in sync with primary.
Regards,
Vasu.
a suggestion to you would be to run your database in flashback mode. we have had several instances where we were forced to flashback the standby database and start applying redo again. This is helpful to prevent a full recreation of the standby.
Similar Messages
-
Corrupted datafiles in standby
Hello
I used to have three indexes in nologging mode in primary database.
When I scan the datafiles of these indexes in standby database, I notice that datafiles are logically corrupted.
Today, I dropped these indexes in primary database and recreated them with logging. Archivelogs of these steps were also applied to standby.
Even there is no obect in nologging mode, When I scan the datafiles in standby, somehow they are still logically corrupted !!!!!!!!!!
What is the reason for that?
CheersMr Sb;
They are created as logging.
It is really difficult to grasp this.
Here is the output of one of the corrupted datafile with dbv
DBV-00200: Block, dba -2126348425, already marked corrupted
DBV-00200: Block, dba -2126348424, already marked corrupted
DBV-00200: Block, dba -2126348423, already marked corrupted
DBV-00200: Block, dba -2126348422, already marked corrupted
DBV-00200: Block, dba -2126348421, already marked corrupted
DBV-00200: Block, dba -2126348420, already marked corrupted
DBV-00200: Block, dba -2126348419, already marked corrupted
DBV-00200: Block, dba -2126348418, already marked corrupted
DBV-00200: Block, dba -2126348417, already marked corrupted
DBV-00200: Block, dba -2126348416, already marked corrupted
DBV-00200: Block, dba -2126348415, already marked corrupted
DBV-00200: Block, dba -2126348414, already marked corrupted
DBV-00200: Block, dba -2126348413, already marked corrupted
DBV-00200: Block, dba -2126348412, already marked corrupted
DBV-00200: Block, dba -2126348411, already marked corrupted
DBV-00200: Block, dba -2126348410, already marked corrupted
DBV-00200: Block, dba -2126348409, already marked corrupted
DBV-00200: Block, dba -2126348408, already marked corrupted
DBV-00200: Block, dba -2126348407, already marked corrupted -
Corrupt Block and Standby Database
Guys,
I created a standby database recently. I then discovered a corrupt block on my primary, I assume the corruption is also on the standby since the files were coppied. If I repair the corrupt block on the primary how do I move the correction to the standby, do I have to recreate it?
DB version is 9iR2
DeltonHi Delton,
How do you plan to repair the corrupt block ?
* Drop and re-create the object
* Restore from backup
In both cases, changes are replicated to the standby database, so nothing to worry about. As Sybrand has mentioned, make sure the changes are done with LOGGING option.
Regards
Asif Momen
http://momendba.blogspot.com -
Logically corrupted blocks in standby
Hi
Assume I have a primary database and standby database.
Accidentally, Some of the objects (indexes and tables) are in nologging mode in primary database.
Force logging is not set.
When I scan the datafiles in standby I realize that some datafiles are logically corrupted because of this issue.
How can I get rid of these corrupted blocks?
If I rebuild indexes with logging option, and recreate table as logging,
Will it solve the problem? or any other suggestion
Many thanksSivok wrote:
Hi
Assume I have a primary database and standby database.
Accidentally, Some of the objects (indexes and tables) are in nologging mode in primary database.
Force logging is not set.
When I scan the datafiles in standby I realize that some datafiles are logically corrupted because of this issue.
How can I get rid of these corrupted blocks?
If I rebuild indexes with logging option, and recreate table as logging,
Will it solve the problem? or any other suggestion
Many thanksyour primary should run in force logging mode (ALTER DATABASE FORCE LOGGING) then the object level setting is ignored for direct path operations. You can apply an incremental backup to the standby to catchup (or just recreate the standby which might be as quick depending on volumes).
Niall Litchfield
http://www.orawin.info/ -
DBV-0200,block already marked corrupted on physical standby database
Dear all,
we are facing the problem of *'DBV-200 that is block already marked corupted on standby database'* on all index datafile, we facing this error in oracle 10.2.0.3 version of database when we are running dbv utility.
but this error can't found on our production database. It is only on standby database.
We canot find the root cause of this error so any body tell me the cause and solution on this.
Thanks
Kiran Rane.Hi Ravi,
i checked all indexes on our primary database some indexes is in logging mode and more than half indexes is in nologging mode but i have some doubt about index logging and nologging mode,
when our primary database is running on 9.2.0.8 version of database this kind of error not observe but after upgrading to 10.2.0.3 version of database we are getting this kind of error so if this version having some bugs or for avoiding this error any patch is available. so tell me what is the exact reason behind this error.
Thanks
Kiran Rane. -
Datafile corrupted On standby database
one of the datafile got corrupted in the standby database . when backing up with rman i got ora-15966 error .
i found the corrupted datafile but i did not have any backups to recover .
is there any way to recover the block corruption ?Hello,
What's your Oracle version? OS? following link shows how to fix it , you can search oracle documentation according to your version.
http://www.mpi-inf.mpg.de/departments/d5/teaching/ss05/is05/oracle/server.920/a96521/repair.htm#11355
Regards -
Data Guard Logical Standby DB Questions
Hi,
I am creating Oracle 9i Logical Standby database on AIX 5 on same server ( for
testing only ).
In Data Guard Manual ( PDF file page no : 86 ) it is said that
Step 4 Create a backup copy of the control file for the standby database. On the
primary database, create a backup copy of the control file for the standby database:
SQL> ALTER DATABASE BACKUP CONTROLFILE TO
2> '/disk1/oracle/oradata/payroll/standby/payroll3.ctl';
My Questions regarding this are
1. Does it missing "backup standby controlfile" word ? if not what is the use of
this control file ? Because as per this manual section 4.2.2 step no 1 and 2 I
have stopped the primary database and copied datafiles,logfiles and controlfiles
as specified which are having consistent stage.
2. On primary database I am mirroring 2 controlfiles at two diffrent locations.
On Standby Database I am going to keep same policy. Then on standby database do I have to copy this controlfile to two locations and rename datafiles or I have
to user controlfiles which I have backed up along with datafiles ?
3. Suppose my primary database is "infod" and standby database is "standby".
Then what should be value of log_file_format parameter of standby database ? On
primary db I have defined "infod LOG_ARCHIVE_FORMAT=infod_log%s_%t.arc. Do I have to keep same or change it ? If on standby db I change the value do I
require other parameters to be set ?
regards & thanks
pjpQ/A1) Its correct you dont need the standby keyword. Not sure abut the reason why but we have created logical standby running in prod using the oracle doc.
Q/A2) Yo can specify any location and name for your controlfiles as it is instance specific and not depending on primary database.
Q/A3) You can set any format for your archlogs on standby side. It doesnt bother the primary db or DG configuration.
Regards,
http://askyogesh.com -
ORA-01578 about standby database in read only mode
Hi,
I have an ORA-05178 (data block corrupted) about a standby database which in read-only mode. About production database, there is no problem.
After analyze, this is an index segment :
SELECT segment_name , segment_type , owner , tablespace_name
FROM sys.dba_extents
WHERE file_id = 58
AND 218173 BETWEEN block_id and block_id + blocks -1
SEGMENT_NAME SEGMENT_TYPE OWNER TABLESPACE_NAME
SICINHIS01 INDEX MOWIN IDX_DATA01
There is no constraint.
How can I repair this problem ?
NicolasHi,
I have an ORA-05178 (data block corrupted) about a standby database which in read-only mode. About production database, there is no problem.
After analyze, this is an index segment :
SELECT segment_name , segment_type , owner , tablespace_name
FROM sys.dba_extents
WHERE file_id = 58
AND 218173 BETWEEN block_id and block_id + blocks -1
SEGMENT_NAME SEGMENT_TYPE OWNER TABLESPACE_NAME
SICINHIS01 INDEX MOWIN IDX_DATA01
There is no constraint.
How can I repair this problem ?
Nicolas -
How to validate a manual standby
Hi all,
I am setting up a manual physical standby and I want to periodically check the standby database for physical and logical corruption.
I am not sure what is the best way to do it:
1) should I only use dbv?
2) should I open the database read only and use RMAN "validate database check logical ;" ?
3) should I open the database read only and use anlter table ... validate structure cascade ; for every table?
4) Do steps 2 and 3 do the same checks?
Thanks,
Andreauser585511 wrote:
Hi all,
I am setting up a manual physical standby and I want to periodically check the standby database for physical and logical corruption.
I am not sure what is the best way to do it:
1) should I only use dbv?
2) should I open the database read only and use RMAN "validate database check logical ;" ?
3) should I open the database read only and use anlter table ... validate structure cascade ; for every table?
4) Do steps 2 and 3 do the same checks?May be physical corruption can occur, But logical corruption only on standby have less chances..
as always, Standby is image copy so if any logical corruption in primary you will have those in standby too..
May be due to some mount point issues (or) any other there is chance for physical corruption.
So either you can go for DBV, Even you can check by RMAN too.
Better, if you perform some tests like creating a user with tables(schema) & open standby and keep track the status. I think if you able to open and count is same. You are fine.
Another point , If any corruption in your database, MRP process will be died and no recovery will be performed, So until unless you able to perform Recover, then there is no issue at the most.+
Edited by: CKPT on May 18, 2012 4:22 PM -
Hi Gurus,
1. Is it possible to use dataguard set different availability for different tables?
and
2. Is it possible to set availability of entire database at 99.7% with dataguard?
Oracle Version-10g
Please help...
Regds
SabyIf you use logical dataguard you can set rules to skip certain objects (e.g don't run transactions for large temporary tables).
If you are running physical dataguard, and you don't force logging at the database level, than a nologging transaction can cause block corruption on the standby.
Not sure if this answers your question. Can you give more detail on what you are trying to do ?
http://blog.ContractOracle.com -
I saw this over at Warp2Search.
Windows XP Patch: Hard Disk May Become Corrupted When Entering Standby or Hibernation
Hard Disk May Become Corrupted When Entering Standby or Hibernation
Now, this Windows Update is related to corrupted hard drives when entering Standby or Hibernation, but it's possible it could also prevent the issue some have witnessed with hard drive BkSODs. It may not prevent the actual BkSOD, but at least it won't kill the hard drive. Who knows, maybe both. Regardless, the update is certainly worth installing.
FYI =]
-SkippyI know it won't fix mine.Mine was dead as a hammer.The bios didn't even pick it up anymore.I wish it would have just been corrupted data.At least it was still under warrenty.I would have been so pissed off.
It may help others though. -
Corrupting the block to continue recovery in physical standby
Hi,
Just like to inquire how I will be able to corrupt the block to be able to continue the recovery in the physical standby.
DB Version: 11.1.0.7
Database Type: Data Warehouse
The setup we have is primary database and standby database, we are not using dataguard, and our standby setup is another physical copy of production which act as standby and being sync using script that being run from time to time to apply the archive log came from production (its not configured to sync using ARCH or LGWR and its corresponding configurations).
Then, the standby database is not sync due to errors encountered while trying to apply the archive log, error is below:
Fri Feb 11 05:50:59 2011
ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /u01/archive/<sid>/1_50741_651679913.arch
Fri Feb 11 05:52:06 2011
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x7FFFD2F18FF8] [PC:0x60197E0, kdr9ir2rst0()+326]
Errors in file /u01/app/oracle/diag/rdbms/<sid>/<sid>/trace/<sid>pr0028085.trc (incident=631460):
ORA-07445: exception encountered: core dump [kdr9ir2rst0()+326] [SIGSEGV] [ADDR:0x7FFFD2F18FF8] [PC:0x60197E0] [Address not mapped to object] []
Incident details in: /u01/app/oracle/diag/rdbms/<sid>/<sid>/incident/incdir_631460/<sid>pr0028085_i631460.trc
Fri Feb 11 05:52:10 2011
Trace dumping is performing id=[cdmp_20110211055210]
Fri Feb 11 05:52:14 2011
Sweep Incident[631460]: completed
Fri Feb 11 05:52:17 2011
Slave exiting with ORA-10562 exception
Errors in file /u01/app/oracle/diag/rdbms/<sid>/<sid>/trace/<sid>pr0028085.trc:
ORA-10562: Error occurred while applying redo to data block (file# 36, block# 1576118)
ORA-10564: tablespace <tablespace name>
ORA-01110: data file 36: '/u02/oradata/<sid>/<datafile>.dbf'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 14877145
ORA-00607: Internal error occurred while making a change to a data block
ORA-00602: internal programming exception
ORA-07445: exception encountered: core dump [kdr9ir2rst0()+326] [SIGSEGV] [ADDR:0x7FFFD2F18FF8] [PC:0x60197E0] [Address not mapped to object] []
Based on the error log it seems we are hitting some bug from metalink (document id 460169.1 and 882851.1)
my question is, the datafile # is given, block# is known too and the data object is also identified. I just verified that object is not that important, is there a way to set the block# to corrupted to be able the recovery to continue? Then I will just drop the table from production so that will also happen in standby, and the block corrupted will be gone too. Is this feasible?
If its not, can you suggest what's next I can do so the the physical standby will be able to sync again to prod aside from rebuilding the standby?
Please take note that I also tried to dbv the file to confirm if there is marked as corrupted and the result for that datafile is also good:
dbv file=/u02/oradata/<sid>/<datafile>_19.dbf logfile=dbv_file_36.log blocksize=16384
oracle@<server>:[~] $ cat dbv_file_36.log
DBVERIFY: Release 11.1.0.7.0 - Production on Sun Feb 13 04:35:28 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
DBVERIFY - Verification starting : FILE = /u02/oradata/<sid>/<datafile>_19.dbf
DBVERIFY - Verification complete
Total Pages Examined : 3840000
Total Pages Processed (Data) : 700644
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 417545
Total Pages Failing (Index): 0
Total Pages Processed (Other): 88910
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 2632901
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Total Pages Encrypted : 0
Highest block SCN : 3811184883 (1.3811184883)
Any help is really appreciated. I hope to hear feedback from you.
Thanksdamorgan, i understand the opinion.
just new with the organization and just inherit a data warehouse database without rman backup. I am still setting up the rman backup thats why i can't use rman to resolve the issue, the only i have is physical standby and its not a standby that automatically sync using dataguard or standard standby setup, i am just checking solution that is applicable in the current situation -
Manual Standby and Archlogs application
Hi There,
I need to set up a manual standby database for one of our production databases. We are using oracle 11g (11.1.0.7) 64x STANDARD EDITION on Windows 2008 server 64x.
I shutdown the database, copied the data files and redo logs to a new server (same directories structure to the production database); I created a standby controlfile and a pfile and copied both across to the new host.
I created the oracle windows service on the new machine and started the database as follows:
C:\Users\oracle>
C:\Users\oracle>SQLPLUS "/AS SYSDBA"
SQL*Plus: Release 11.1.0.7.0 - Production on Tue Apr 13 15:04:53 2010
Copyright (c) 1982, 2008, Oracle. All rights reserved.
Connected to an idle instance.
SQL> STARTUP PFILE='C:\oracle\product\11.1.0.7\database\INITSTDBT.ORA' NOMOUNT;
ORA-32006: STANDBY_ARCHIVE_DEST initialization parameter has been deprecated
ORACLE instance started.
Total System Global Area 542814208 bytes
Fixed Size 2131248 bytes
Variable Size 419433168 bytes
Database Buffers 117440512 bytes
Redo Buffers 3809280 bytes
SQL>
SQL>
SQL> SELECT STATUS FROM V$INSTANCE;
STATUS
STARTED
SQL> alter database mount standby database;
Database altered.The production database has forced logging enabled in it so that we can capture all the DDL statemtents.
We created a dummy schema, a dummy table (with few rows); issued a commit, and then switched the logs few times to create the necessary archive logs. We then manually moved the archive logs to the new standby host, and put them under the appropriate directory (D:\oracle\flash_recovery_area\STDBT\ARCHIVELOG\2010_04_13).
Now we tried to recover the database by applying the new shipped logs:
SQL> recover standby database
ORA-00279: change 606666 generated at 04/13/2010 14:37:19 needed for thread 1
ORA-00289: suggestion :
D:\ORACLE\FLASH_RECOVERY_AREA\STDBT\ARCHIVELOG\2010_04_13\O1_MF_1_46_%U_.ARC
ORA-00280: change 606666 for thread 1 is in sequence #46
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00308: cannot open archived log
'D:\ORACLE\FLASH_RECOVERY_AREA\STDBT\ARCHIVELOG\2010_04_13\O1_MF_1_46_%U_.ARC'
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: 'D:\ORACLE\ORADATA\STDBT\SYSTEM01.DBF'So we thought we'll try the recovery again by manually putting the filename in:
SQL> recover standby database
ORA-00279: change 606666 generated at 04/13/2010 14:37:19 needed for thread 1
ORA-00289: suggestion :
D:\ORACLE\FLASH_RECOVERY_AREA\STDBT\ARCHIVELOG\2010_04_13\O1_MF_1_46_%U_.ARC
ORA-00280: change 606666 for thread 1 is in sequence #46
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
D:\oracle\flash_recovery_area\STDBT\ARCHIVELOG\2010_04_13\O1_MF_1_46_5W9W3LT3_.ARC
ORA-00279: change 608376 generated at 04/13/2010 15:30:10 needed for thread 1
ORA-00289: suggestion :
D:\ORACLE\FLASH_RECOVERY_AREA\STDBT\ARCHIVELOG\2010_04_13\O1_MF_1_47_%U_.ARC
ORA-00280: change 608376 for thread 1 is in sequence #47
ORA-00278: log file
'D:\oracle\flash_recovery_area\STDBT\ARCHIVELOG\2010_04_13\O1_MF_1_46_5W9W3LT3_.
ARC' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
D:\oracle\flash_recovery_area\STDBT\ARCHIVELOG\2010_04_13\O1_MF_1_47_5W9W7P6D_.ARC
ORA-00279: change 608426 generated at 04/13/2010 15:32:20 needed for thread 1
ORA-00289: suggestion :
D:\ORACLE\FLASH_RECOVERY_AREA\STDBT\ARCHIVELOG\2010_04_13\O1_MF_1_48_%U_.ARC
ORA-00280: change 608426 for thread 1 is in sequence #48
ORA-00278: log file
'D:\oracle\flash_recovery_area\STDBT\ARCHIVELOG\2010_04_13\O1_MF_1_47_5W9W7P6D_.
ARC' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
Media recovery cancelled.So, the issue here is that even though the archive logs did exist in the correct directory, when we hit enter to accept the default, oracle didn't find the logs and it was looking for a file with the format "O1_MF_1_46_%U_.ARC" instead of "O1_MF_1_46_5W9W3LT3_.ARC" and so the recovery failed.. How can we fix this so that oracle will detect the correct archlog name so that when we automate the applying of the logs it will work (and we don't have to do enter them manually one by one)?
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
Database altered.
SQL> select status from v$instance;
STATUS
MOUNTED
SQL>
SQL>
SQL>
SQL> alter database open read only;
alter database open read only
ERROR at line 1:
ORA-16433: The database has not been opened in read-write modeAnother question, once we activated the standby database, we tried to open it but it failed with above error; do we have to shut it down 1st and then do a normal STARTUP command? or do we have to open it with resetlogs??
If someone can shed some light here that will be great.
Thanks
Edited by: rsar001 on Apr 13, 2010 4:27 PMSQL> show parameter log_archive_dest
NAME TYPE VALUE
log_archive_dest string
log_archive_dest_1 string
log_archive_dest_10 string
log_archive_dest_2 string
log_archive_dest_3 string
log_archive_dest_4 string
log_archive_dest_5 string
log_archive_dest_6 string
log_archive_dest_7 string
log_archive_dest_8 string
log_archive_dest_9 string
log_archive_dest_state_1 string enable
log_archive_dest_state_10 string enable
log_archive_dest_state_2 string enable
log_archive_dest_state_3 string enable
log_archive_dest_state_4 string enable
log_archive_dest_state_5 string enable
log_archive_dest_state_6 string enable
log_archive_dest_state_7 string enable
log_archive_dest_state_8 string enable
log_archive_dest_state_9 string enable
SQL> show parameter recover
NAME TYPE VALUE
db_recovery_file_dest string D:\oracle\flash_recovery_area
db_recovery_file_dest_size big integer 2G
recovery_parallelism integer 0
SQL> -
Recovery is repairing media corrupt block x of file x in standby alert log
Hi,
oracle version:8.1.7.0.0
os version :solaris 5.9
we have oracle 8i primary and standby database. i am getting erorr in alert log file:
Thu Aug 28 22:48:12 2008
Media Recovery Log /oratranslog/arch_1_1827391.arc
Thu Aug 28 22:50:42 2008
Media Recovery Log /oratranslog/arch_1_1827392.arc
bash-2.05$ tail -f alert_pindb.log
Recovery is repairing media corrupt block 991886 of file 179
Recovery is repairing media corrupt block 70257 of file 184
Recovery is repairing media corrupt block 70258 of file 184
Recovery is repairing media corrupt block 70259 of file 184
Recovery is repairing media corrupt block 70260 of file 184
Recovery is repairing media corrupt block 70261 of file 184
Thu Aug 28 22:48:12 2008
Media Recovery Log /oratranslog/arch_1_1827391.arc
Thu Aug 28 22:50:42 2008
Media Recovery Log /oratranslog/arch_1_1827392.arc
Recovery is repairing media corrupt block 500027 of file 181
Recovery is repairing media corrupt block 500028 of file 181
Recovery is repairing media corrupt block 500029 of file 181
Recovery is repairing media corrupt block 500030 of file 181
Recovery is repairing media corrupt block 500031 of file 181
Recovery is repairing media corrupt block 991837 of file 179
Recovery is repairing media corrupt block 991838 of file 179
how i can resolve this.
[pre]
Thanks
Prakash
Edited by: user612485 on Aug 28, 2008 10:53 AMDear satish kandi,
recently we have created index for one table with nologgign option, i think for that reason i am getting that error.
if i run dbv utility on the files which are shown in alert log file i am getting the following results.
bash-2.05$ dbv file=/oracle15/oradata/pindb/pinx055.dbf blocksize=4096
DBVERIFY: Release 8.1.7.0.0 - Production on Fri Aug 29 12:18:27 2008
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /oracle15/oradata/pindb/pinx053.dbf
Block Checking: DBA = 751593895, Block Type =
Found block already marked corrupted
Block Checking: DBA = 751593896, Block Type =
.DBVERIFY - Verification complete
Total Pages Examined : 1048576
Total Pages Processed (Data) : 0
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 1036952
Total Pages Failing (Index): 0
Total Pages Processed (Other): 7342
Total Pages Empty : 4282
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
bash-2.05$ dbv file=/oracle15/oradata/pindb/pinx053.dbf blocksize=4096
DBVERIFY: Release 8.1.7.0.0 - Production on Fri Aug 29 12:23:12 2008
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /oracle15/oradata/pindb/pinx054.dbf
Block Checking: DBA = 759492966, Block Type =
Found block already marked corrupted
Block Checking: DBA = 759492967, Block Type =
Found block already marked corrupted
Block Checking: DBA = 759492968, Block Type =
.DBVERIFY - Verification complete
Total Pages Examined : 1048576
Total Pages Processed (Data) : 0
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 585068
Total Pages Failing (Index): 0
Total Pages Processed (Other): 8709
Total Pages Empty : 454799
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
bash-2.05$ dbv file=/oracle15/oradata/pindb/pinx054.dbf blocksize=4096
DBVERIFY: Release 8.1.7.0.0 - Production on Fri Aug 29 12:32:28 2008
(c) Copyright 2000 Oracle Corporation. All rights reserved.
DBVERIFY - Verification starting : FILE = /oracle15/oradata/pindb/pinx055.dbf
Block Checking: DBA = 771822208, Block Type =
Found block already marked corrupted
Block Checking: DBA = 771822209, Block Type =
Found block already marked corrupted
Block Checking: DBA = 771822210, Block Type =
.DBVERIFY - Verification complete
Total Pages Examined : 1048576
Total Pages Processed (Data) : 0
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 157125
Total Pages Failing (Index): 0
Total Pages Processed (Other): 4203
Total Pages Empty : 887248
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
My doubts are :
1.if i drop the index and recreate the index with logging option will this error won't repeat in alert log file
2.in future if i activate the standby database will database is going to open without any error.
Thanks
Prakash
. -
Standby Log corruption -- in Recover phase
Hi All,
I am trying to set up RAC to RAC dataguard between 2 databases in different data centers.
I am able to ship archivelogs from primary to DR. The logs are not getting applied.
In the standby alert log -- I see the following errors (several of these CORRUPTION DETECTED Errors)
CORRUPTION DETECTED: In redo blocks starting at block 4097count 2048 for thread 4 sequence 15019
RFS[1185]: Possible network disconnect with primary database *Deleted Oracle managed file
+FR1/drdb/archivelog/2012_07_02/thread_4_seq_15019.578.787560321*
RFS[1186]: Possible network disconnect with primary database Mon Jul 02 06:45:36 2012
RFS[1189]: Assigned to RFS process 5016
RFS[1189]: Opened log for thread 2 sequence 12872 dbid 832151255 branch
782279895
*CORRUPTION DETECTED: In redo blocks starting at block 1count 2048 for thread 2 sequence 12872 Deleted Oracle managed file
+FR1/drdb/archivelog/2012_07_02/thread_2_seq_12872.578.787560337*
Mon Jul 02 06:45:38 2012
another thing is -- I have another application, where there is dataguard from RAC to single instance. For this I dont see any problem..
can anybody throw some light on this problem?
Thanks in advance..
Krishna
Edited by: user10697869 on Jul 2, 2012 4:02 AMRight now, I dont have any corruption.
INST_ID PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
1 ARCH CLOSING 1 31 10240 1775
1 ARCH CLOSING 3 32 8192 1243
1 ARCH CONNECTED 0 0 0 0
1 ARCH CLOSING 2 29 4096 1063
1 ARCH CLOSING 4 31 4096 719
1 RFS IDLE 0 0 0 0
2 ARCH CLOSING 3 34 6144 1046
2 ARCH CONNECTED 0 0 0 0
2 ARCH CLOSING 1 22 6144 911
2 ARCH CLOSING 3 35 10240 1556
2 ARCH CLOSING 4 23 1 1946
INST_ID PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
2 RFS IDLE 0 0 0 0
2 RFS IDLE 0 0 0 0
2 RFS IDLE 0 0 0 0
2 RFS IDLE 0 0 0 0
2 RFS IDLE 0 0 0 0
2 MRP0 WAIT_FOR_LOG 3 11753 0 0
MRP0 is running -- but primary node say.. it cannot create archivelog..
this is from broker log.
Redo transport problem detected: redo transport for database drdb has the following error:
ORA-00270: error creating archive log
07/03/2012 01:45:28
Redo transport problem detected: redo transport for database drdb has the following error:
ORA-00270: error creating archive log
07/03/2012 01:46:28
Redo transport problem detected: redo transport for database drdb has the following error:
ORA-00270: error creating archive log
i dont understand why there is an error in creating archivelog..
I am printing my output of gv$logfile for both primary and standby..
Is there any thing wrong in this config??
"INST_ID" "GROUP#" "STATUS" "TYPE" "MEMBER" "IS_RECOVERY_DEST_FILE"
1 12 "" "ONLINE" "+DG1/primdb/onlinelog/group_12.257.783544139" "NO"
1 10 "" "ONLINE" "+REDO/primdb/onlinelog/group_10.257.784552287" "NO"
1 29 "" "STANDBY" "+DG1/primdb/onlinelog/group_29.264.787264987" "NO"
1 11 "" "ONLINE" "+REDO/primdb/onlinelog/group_11.258.784552299" "NO"
1 12 "" "ONLINE" "+REDO/primdb/onlinelog/group_12.259.784552311" "NO"
1 13 "" "ONLINE" "+REDO/primdb/onlinelog/group_13.260.784552323" "NO"
1 14 "" "ONLINE" "+REDO/primdb/onlinelog/group_14.261.784552335" "NO"
1 15 "" "ONLINE" "+REDO/primdb/onlinelog/group_15.262.784552347" "NO"
1 16 "" "ONLINE" "+REDO/primdb/onlinelog/group_16.263.784552363" "NO"
1 17 "" "ONLINE" "+REDO/primdb/onlinelog/group_17.264.784552377" "NO"
1 18 "" "ONLINE" "+REDO/primdb/onlinelog/group_18.265.784552391" "NO"
1 19 "" "ONLINE" "+REDO/primdb/onlinelog/group_19.266.784552403" "NO"
1 20 "" "ONLINE" "+REDO/primdb/onlinelog/group_20.267.784552413" "NO"
1 21 "" "ONLINE" "+REDO/primdb/onlinelog/group_21.268.784552423" "NO"
1 22 "" "ONLINE" "+REDO/primdb/onlinelog/group_22.269.784552433" "NO"
1 23 "" "ONLINE" "+REDO/primdb/onlinelog/group_23.270.784552445" "NO"
1 10 "" "ONLINE" "+DG1/primdb/onlinelog/group_10.284.783543933" "NO"
1 24 "" "ONLINE" "+REDO/primdb/onlinelog/group_24.271.784552453" "NO"
1 11 "" "ONLINE" "+DG1/primdb/onlinelog/group_11.285.783543979" "NO"
1 13 "" "ONLINE" "+DG1/primdb/onlinelog/group_13.286.783544253" "NO"
1 14 "" "ONLINE" "+DG1/primdb/onlinelog/group_14.287.783544347" "NO"
1 15 "" "ONLINE" "+DG1/primdb/onlinelog/group_15.288.783544531" "NO"
1 16 "" "ONLINE" "+DG1/primdb/onlinelog/group_16.289.783544655" "NO"
1 17 "" "ONLINE" "+DG1/primdb/onlinelog/group_17.290.783544659" "NO"
1 18 "" "ONLINE" "+DG1/primdb/onlinelog/group_18.291.783544685" "NO"
1 19 "" "ONLINE" "+DG1/primdb/onlinelog/group_19.292.783544691" "NO"
1 20 "" "ONLINE" "+DG1/primdb/onlinelog/group_20.293.783544697" "NO"
1 21 "" "ONLINE" "+DG1/primdb/onlinelog/group_21.294.783544701" "NO"
1 22 "" "ONLINE" "+DG1/primdb/onlinelog/group_22.295.783544717" "NO"
1 23 "" "ONLINE" "+DG1/primdb/onlinelog/group_23.296.783544721" "NO"
1 24 "" "ONLINE" "+DG1/primdb/onlinelog/group_24.297.783544727" "NO"
1 25 "" "ONLINE" "+DG1/primdb/onlinelog/group_25.298.783544731" "NO"
1 25 "" "ONLINE" "+REDO/primdb/onlinelog/group_25.272.784552459" "NO"
1 29 "" "STANDBY" "+FR1/primdb/onlinelog/group_29.4913.787264989" "NO"
1 30 "" "STANDBY" "+DG1/primdb/onlinelog/group_30.320.787264993" "NO"
1 30 "" "STANDBY" "+FR1/primdb/onlinelog/group_30.4912.787264995" "NO"
1 31 "" "STANDBY" "+DG1/primdb/onlinelog/group_31.319.787264997" "NO"
1 31 "" "STANDBY" "+FR1/primdb/onlinelog/group_31.4911.787264999" "NO"
1 32 "" "STANDBY" "+DG1/primdb/onlinelog/group_32.318.787265001" "NO"
1 32 "" "STANDBY" "+FR1/primdb/onlinelog/group_32.4910.787265003" "NO"
1 33 "" "STANDBY" "+DG1/primdb/onlinelog/group_33.317.787265005" "NO"
1 33 "" "STANDBY" "+FR1/primdb/onlinelog/group_33.4909.787265007" "NO"
1 34 "" "STANDBY" "+DG1/primdb/onlinelog/group_34.316.787265009" "NO"
1 34 "" "STANDBY" "+FR1/primdb/onlinelog/group_34.4908.787265011" "NO"
1 35 "" "STANDBY" "+DG1/primdb/onlinelog/group_35.315.787265013" "NO"
1 35 "" "STANDBY" "+FR1/primdb/onlinelog/group_35.4905.787265015" "NO"
1 36 "" "STANDBY" "+DG1/primdb/onlinelog/group_36.314.787265019" "NO"
1 36 "" "STANDBY" "+FR1/primdb/onlinelog/group_36.4904.787265021" "NO"
1 37 "" "STANDBY" "+DG1/primdb/onlinelog/group_37.313.787265023" "NO"
1 37 "" "STANDBY" "+FR1/primdb/onlinelog/group_37.4903.787265027" "NO"
1 38 "" "STANDBY" "+DG1/primdb/onlinelog/group_38.312.787265029" "NO"
1 38 "" "STANDBY" "+FR1/primdb/onlinelog/group_38.4902.787265031" "NO"
1 39 "" "STANDBY" "+DG1/primdb/onlinelog/group_39.263.787265033" "NO"
1 39 "" "STANDBY" "+FR1/primdb/onlinelog/group_39.4901.787265035" "NO"
1 40 "" "STANDBY" "+DG1/primdb/onlinelog/group_40.278.787265037" "NO"
1 40 "" "STANDBY" "+FR1/primdb/onlinelog/group_40.4899.787265039" "NO"
1 41 "" "STANDBY" "+DG1/primdb/onlinelog/group_41.279.787265041" "NO"
1 41 "" "STANDBY" "+FR1/primdb/onlinelog/group_41.4898.787265043" "NO"
1 42 "" "STANDBY" "+DG1/primdb/onlinelog/group_42.277.787265047" "NO"
1 42 "" "STANDBY" "+FR1/primdb/onlinelog/group_42.4897.787265049" "NO"
1 43 "" "STANDBY" "+DG1/primdb/onlinelog/group_43.276.787265051" "NO"
1 43 "" "STANDBY" "+FR1/primdb/onlinelog/group_43.4896.787265053" "NO"
1 44 "" "STANDBY" "+DG1/primdb/onlinelog/group_44.275.787265055" "NO"
1 44 "" "STANDBY" "+FR1/primdb/onlinelog/group_44.4894.787265057" "NO"
1 45 "" "STANDBY" "+DG1/primdb/onlinelog/group_45.282.787265259" "NO"
1 45 "" "STANDBY" "+FR1/primdb/onlinelog/group_45.4893.787265261" "NO"
1 47 "" "STANDBY" "+DG1/primdb/onlinelog/group_47.324.787265263" "NO"
1 47 "" "STANDBY" "+FR1/primdb/onlinelog/group_47.4892.787265265" "NO"
1 48 "" "STANDBY" "+DG1/primdb/onlinelog/group_48.325.787265267" "NO"
1 48 "" "STANDBY" "+FR1/primdb/onlinelog/group_48.4891.787265269" "NO"
1 46 "" "STANDBY" "+DG1/primdb/onlinelog/group_46.326.787265279" "NO"
1 46 "" "STANDBY" "+FR1/primdb/onlinelog/group_46.4890.787265281" "NO"
3 12 "" "ONLINE" "+DG1/primdb/onlinelog/group_12.257.783544139" "NO"
3 10 "" "ONLINE" "+REDO/primdb/onlinelog/group_10.257.784552287" "NO"
3 29 "" "STANDBY" "+DG1/primdb/onlinelog/group_29.264.787264987" "NO"
3 11 "" "ONLINE" "+REDO/primdb/onlinelog/group_11.258.784552299" "NO"
3 12 "" "ONLINE" "+REDO/primdb/onlinelog/group_12.259.784552311" "NO"
3 13 "" "ONLINE" "+REDO/primdb/onlinelog/group_13.260.784552323" "NO"
3 14 "" "ONLINE" "+REDO/primdb/onlinelog/group_14.261.784552335" "NO"
3 15 "" "ONLINE" "+REDO/primdb/onlinelog/group_15.262.784552347" "NO"
3 16 "" "ONLINE" "+REDO/primdb/onlinelog/group_16.263.784552363" "NO"
3 17 "" "ONLINE" "+REDO/primdb/onlinelog/group_17.264.784552377" "NO"
3 18 "" "ONLINE" "+REDO/primdb/onlinelog/group_18.265.784552391" "NO"
3 19 "" "ONLINE" "+REDO/primdb/onlinelog/group_19.266.784552403" "NO"
3 20 "" "ONLINE" "+REDO/primdb/onlinelog/group_20.267.784552413" "NO"
3 21 "" "ONLINE" "+REDO/primdb/onlinelog/group_21.268.784552423" "NO"
3 22 "" "ONLINE" "+REDO/primdb/onlinelog/group_22.269.784552433" "NO"
3 23 "" "ONLINE" "+REDO/primdb/onlinelog/group_23.270.784552445" "NO"
3 10 "" "ONLINE" "+DG1/primdb/onlinelog/group_10.284.783543933" "NO"
3 24 "" "ONLINE" "+REDO/primdb/onlinelog/group_24.271.784552453" "NO"
3 11 "" "ONLINE" "+DG1/primdb/onlinelog/group_11.285.783543979" "NO"
3 13 "" "ONLINE" "+DG1/primdb/onlinelog/group_13.286.783544253" "NO"
3 14 "" "ONLINE" "+DG1/primdb/onlinelog/group_14.287.783544347" "NO"
3 15 "" "ONLINE" "+DG1/primdb/onlinelog/group_15.288.783544531" "NO"
3 16 "" "ONLINE" "+DG1/primdb/onlinelog/group_16.289.783544655" "NO"
3 17 "" "ONLINE" "+DG1/primdb/onlinelog/group_17.290.783544659" "NO"
3 18 "" "ONLINE" "+DG1/primdb/onlinelog/group_18.291.783544685" "NO"
3 19 "" "ONLINE" "+DG1/primdb/onlinelog/group_19.292.783544691" "NO"
3 20 "" "ONLINE" "+DG1/primdb/onlinelog/group_20.293.783544697" "NO"
3 21 "" "ONLINE" "+DG1/primdb/onlinelog/group_21.294.783544701" "NO"
3 22 "" "ONLINE" "+DG1/primdb/onlinelog/group_22.295.783544717" "NO"
3 23 "" "ONLINE" "+DG1/primdb/onlinelog/group_23.296.783544721" "NO"
3 24 "" "ONLINE" "+DG1/primdb/onlinelog/group_24.297.783544727" "NO"
3 25 "" "ONLINE" "+DG1/primdb/onlinelog/group_25.298.783544731" "NO"
3 25 "" "ONLINE" "+REDO/primdb/onlinelog/group_25.272.784552459" "NO"
3 29 "" "STANDBY" "+FR1/primdb/onlinelog/group_29.4913.787264989" "NO"
3 30 "" "STANDBY" "+DG1/primdb/onlinelog/group_30.320.787264993" "NO"
3 30 "" "STANDBY" "+FR1/primdb/onlinelog/group_30.4912.787264995" "NO"
3 31 "" "STANDBY" "+DG1/primdb/onlinelog/group_31.319.787264997" "NO"
3 31 "" "STANDBY" "+FR1/primdb/onlinelog/group_31.4911.787264999" "NO"
3 32 "" "STANDBY" "+DG1/primdb/onlinelog/group_32.318.787265001" "NO"
3 32 "" "STANDBY" "+FR1/primdb/onlinelog/group_32.4910.787265003" "NO"
3 33 "" "STANDBY" "+DG1/primdb/onlinelog/group_33.317.787265005" "NO"
3 33 "" "STANDBY" "+FR1/primdb/onlinelog/group_33.4909.787265007" "NO"
3 34 "" "STANDBY" "+DG1/primdb/onlinelog/group_34.316.787265009" "NO"
3 34 "" "STANDBY" "+FR1/primdb/onlinelog/group_34.4908.787265011" "NO"
3 35 "" "STANDBY" "+DG1/primdb/onlinelog/group_35.315.787265013" "NO"
3 35 "" "STANDBY" "+FR1/primdb/onlinelog/group_35.4905.787265015" "NO"
3 36 "" "STANDBY" "+DG1/primdb/onlinelog/group_36.314.787265019" "NO"
3 36 "" "STANDBY" "+FR1/primdb/onlinelog/group_36.4904.787265021" "NO"
3 37 "" "STANDBY" "+DG1/primdb/onlinelog/group_37.313.787265023" "NO"
3 37 "" "STANDBY" "+FR1/primdb/onlinelog/group_37.4903.787265027" "NO"
3 38 "" "STANDBY" "+DG1/primdb/onlinelog/group_38.312.787265029" "NO"
3 38 "" "STANDBY" "+FR1/primdb/onlinelog/group_38.4902.787265031" "NO"
3 39 "" "STANDBY" "+DG1/primdb/onlinelog/group_39.263.787265033" "NO"
3 39 "" "STANDBY" "+FR1/primdb/onlinelog/group_39.4901.787265035" "NO"
3 40 "" "STANDBY" "+DG1/primdb/onlinelog/group_40.278.787265037" "NO"
3 40 "" "STANDBY" "+FR1/primdb/onlinelog/group_40.4899.787265039" "NO"
3 41 "" "STANDBY" "+DG1/primdb/onlinelog/group_41.279.787265041" "NO"
3 41 "" "STANDBY" "+FR1/primdb/onlinelog/group_41.4898.787265043" "NO"
3 42 "" "STANDBY" "+DG1/primdb/onlinelog/group_42.277.787265047" "NO"
3 42 "" "STANDBY" "+FR1/primdb/onlinelog/group_42.4897.787265049" "NO"
3 43 "" "STANDBY" "+DG1/primdb/onlinelog/group_43.276.787265051" "NO"
3 43 "" "STANDBY" "+FR1/primdb/onlinelog/group_43.4896.787265053" "NO"
3 44 "" "STANDBY" "+DG1/primdb/onlinelog/group_44.275.787265055" "NO"
3 44 "" "STANDBY" "+FR1/primdb/onlinelog/group_44.4894.787265057" "NO"
3 45 "" "STANDBY" "+DG1/primdb/onlinelog/group_45.282.787265259" "NO"
3 45 "" "STANDBY" "+FR1/primdb/onlinelog/group_45.4893.787265261" "NO"
3 47 "" "STANDBY" "+DG1/primdb/onlinelog/group_47.324.787265263" "NO"
3 47 "" "STANDBY" "+FR1/primdb/onlinelog/group_47.4892.787265265" "NO"
3 48 "" "STANDBY" "+DG1/primdb/onlinelog/group_48.325.787265267" "NO"
3 48 "" "STANDBY" "+FR1/primdb/onlinelog/group_48.4891.787265269" "NO"
3 46 "" "STANDBY" "+DG1/primdb/onlinelog/group_46.326.787265279" "NO"
3 46 "" "STANDBY" "+FR1/primdb/onlinelog/group_46.4890.787265281" "NO"
2 12 "" "ONLINE" "+DG1/primdb/onlinelog/group_12.257.783544139" "NO"
2 10 "" "ONLINE" "+REDO/primdb/onlinelog/group_10.257.784552287" "NO"
2 29 "" "STANDBY" "+DG1/primdb/onlinelog/group_29.264.787264987" "NO"
2 11 "" "ONLINE" "+REDO/primdb/onlinelog/group_11.258.784552299" "NO"
2 12 "" "ONLINE" "+REDO/primdb/onlinelog/group_12.259.784552311" "NO"
2 13 "" "ONLINE" "+REDO/primdb/onlinelog/group_13.260.784552323" "NO"
2 14 "" "ONLINE" "+REDO/primdb/onlinelog/group_14.261.784552335" "NO"
2 15 "" "ONLINE" "+REDO/primdb/onlinelog/group_15.262.784552347" "NO"
2 16 "" "ONLINE" "+REDO/primdb/onlinelog/group_16.263.784552363" "NO"
2 17 "" "ONLINE" "+REDO/primdb/onlinelog/group_17.264.784552377" "NO"
2 18 "" "ONLINE" "+REDO/primdb/onlinelog/group_18.265.784552391" "NO"
2 19 "" "ONLINE" "+REDO/primdb/onlinelog/group_19.266.784552403" "NO"
2 20 "" "ONLINE" "+REDO/primdb/onlinelog/group_20.267.784552413" "NO"
2 21 "" "ONLINE" "+REDO/primdb/onlinelog/group_21.268.784552423" "NO"
2 22 "" "ONLINE" "+REDO/primdb/onlinelog/group_22.269.784552433" "NO"
2 23 "" "ONLINE" "+REDO/primdb/onlinelog/group_23.270.784552445" "NO"
2 10 "" "ONLINE" "+DG1/primdb/onlinelog/group_10.284.783543933" "NO"
2 24 "" "ONLINE" "+REDO/primdb/onlinelog/group_24.271.784552453" "NO"
2 11 "" "ONLINE" "+DG1/primdb/onlinelog/group_11.285.783543979" "NO"
2 13 "" "ONLINE" "+DG1/primdb/onlinelog/group_13.286.783544253" "NO"
2 14 "" "ONLINE" "+DG1/primdb/onlinelog/group_14.287.783544347" "NO"
2 15 "" "ONLINE" "+DG1/primdb/onlinelog/group_15.288.783544531" "NO"
2 16 "" "ONLINE" "+DG1/primdb/onlinelog/group_16.289.783544655" "NO"
2 17 "" "ONLINE" "+DG1/primdb/onlinelog/group_17.290.783544659" "NO"
2 18 "" "ONLINE" "+DG1/primdb/onlinelog/group_18.291.783544685" "NO"
2 19 "" "ONLINE" "+DG1/primdb/onlinelog/group_19.292.783544691" "NO"
2 20 "" "ONLINE" "+DG1/primdb/onlinelog/group_20.293.783544697" "NO"
2 21 "" "ONLINE" "+DG1/primdb/onlinelog/group_21.294.783544701" "NO"
2 22 "" "ONLINE" "+DG1/primdb/onlinelog/group_22.295.783544717" "NO"
2 23 "" "ONLINE" "+DG1/primdb/onlinelog/group_23.296.783544721" "NO"
2 24 "" "ONLINE" "+DG1/primdb/onlinelog/group_24.297.783544727" "NO"
2 25 "" "ONLINE" "+DG1/primdb/onlinelog/group_25.298.783544731" "NO"
2 25 "" "ONLINE" "+REDO/primdb/onlinelog/group_25.272.784552459" "NO"
2 29 "" "STANDBY" "+FR1/primdb/onlinelog/group_29.4913.787264989" "NO"
2 30 "" "STANDBY" "+DG1/primdb/onlinelog/group_30.320.787264993" "NO"
2 30 "" "STANDBY" "+FR1/primdb/onlinelog/group_30.4912.787264995" "NO"
2 31 "" "STANDBY" "+DG1/primdb/onlinelog/group_31.319.787264997" "NO"
2 31 "" "STANDBY" "+FR1/primdb/onlinelog/group_31.4911.787264999" "NO"
2 32 "" "STANDBY" "+DG1/primdb/onlinelog/group_32.318.787265001" "NO"
2 32 "" "STANDBY" "+FR1/primdb/onlinelog/group_32.4910.787265003" "NO"
2 33 "" "STANDBY" "+DG1/primdb/onlinelog/group_33.317.787265005" "NO"
2 33 "" "STANDBY" "+FR1/primdb/onlinelog/group_33.4909.787265007" "NO"
2 34 "" "STANDBY" "+DG1/primdb/onlinelog/group_34.316.787265009" "NO"
2 34 "" "STANDBY" "+FR1/primdb/onlinelog/group_34.4908.787265011" "NO"
2 35 "" "STANDBY" "+DG1/primdb/onlinelog/group_35.315.787265013" "NO"
2 35 "" "STANDBY" "+FR1/primdb/onlinelog/group_35.4905.787265015" "NO"
2 36 "" "STANDBY" "+DG1/primdb/onlinelog/group_36.314.787265019" "NO"
2 36 "" "STANDBY" "+FR1/primdb/onlinelog/group_36.4904.787265021" "NO"
2 37 "" "STANDBY" "+DG1/primdb/onlinelog/group_37.313.787265023" "NO"
2 37 "" "STANDBY" "+FR1/primdb/onlinelog/group_37.4903.787265027" "NO"
2 38 "" "STANDBY" "+DG1/primdb/onlinelog/group_38.312.787265029" "NO"
2 38 "" "STANDBY" "+FR1/primdb/onlinelog/group_38.4902.787265031" "NO"
2 39 "" "STANDBY" "+DG1/primdb/onlinelog/group_39.263.787265033" "NO"
2 39 "" "STANDBY" "+FR1/primdb/onlinelog/group_39.4901.787265035" "NO"
2 40 "" "STANDBY" "+DG1/primdb/onlinelog/group_40.278.787265037" "NO"
2 40 "" "STANDBY" "+FR1/primdb/onlinelog/group_40.4899.787265039" "NO"
2 41 "" "STANDBY" "+DG1/primdb/onlinelog/group_41.279.787265041" "NO"
2 41 "" "STANDBY" "+FR1/primdb/onlinelog/group_41.4898.787265043" "NO"
2 42 "" "STANDBY" "+DG1/primdb/onlinelog/group_42.277.787265047" "NO"
2 42 "" "STANDBY" "+FR1/primdb/onlinelog/group_42.4897.787265049" "NO"
2 43 "" "STANDBY" "+DG1/primdb/onlinelog/group_43.276.787265051" "NO"
2 43 "" "STANDBY" "+FR1/primdb/onlinelog/group_43.4896.787265053" "NO"
2 44 "" "STANDBY" "+DG1/primdb/onlinelog/group_44.275.787265055" "NO"
2 44 "" "STANDBY" "+FR1/primdb/onlinelog/group_44.4894.787265057" "NO"
2 45 "" "STANDBY" "+DG1/primdb/onlinelog/group_45.282.787265259" "NO"
2 45 "" "STANDBY" "+FR1/primdb/onlinelog/group_45.4893.787265261" "NO"
2 47 "" "STANDBY" "+DG1/primdb/onlinelog/group_47.324.787265263" "NO"
2 47 "" "STANDBY" "+FR1/primdb/onlinelog/group_47.4892.787265265" "NO"
2 48 "" "STANDBY" "+DG1/primdb/onlinelog/group_48.325.787265267" "NO"
2 48 "" "STANDBY" "+FR1/primdb/onlinelog/group_48.4891.787265269" "NO"
2 46 "" "STANDBY" "+DG1/primdb/onlinelog/group_46.326.787265279" "NO"
2 46 "" "STANDBY" "+FR1/primdb/onlinelog/group_46.4890.787265281" "NO"
4 12 "" "ONLINE" "+DG1/primdb/onlinelog/group_12.257.783544139" "NO"
4 10 "" "ONLINE" "+REDO/primdb/onlinelog/group_10.257.784552287" "NO"
4 29 "" "STANDBY" "+DG1/primdb/onlinelog/group_29.264.787264987" "NO"
4 11 "" "ONLINE" "+REDO/primdb/onlinelog/group_11.258.784552299" "NO"
4 12 "" "ONLINE" "+REDO/primdb/onlinelog/group_12.259.784552311" "NO"
4 13 "" "ONLINE" "+REDO/primdb/onlinelog/group_13.260.784552323" "NO"
4 14 "" "ONLINE" "+REDO/primdb/onlinelog/group_14.261.784552335" "NO"
4 15 "" "ONLINE" "+REDO/primdb/onlinelog/group_15.262.784552347" "NO"
4 16 "" "ONLINE" "+REDO/primdb/onlinelog/group_16.263.784552363" "NO"
4 17 "" "ONLINE" "+REDO/primdb/onlinelog/group_17.264.784552377" "NO"
4 18 "" "ONLINE" "+REDO/primdb/onlinelog/group_18.265.784552391" "NO"
4 19 "" "ONLINE" "+REDO/primdb/onlinelog/group_19.266.784552403" "NO"
4 20 "" "ONLINE" "+REDO/primdb/onlinelog/group_20.267.784552413" "NO"
4 21 "" "ONLINE" "+REDO/primdb/onlinelog/group_21.268.784552423" "NO"
4 22 "" "ONLINE" "+REDO/primdb/onlinelog/group_22.269.784552433" "NO"
4 23 "" "ONLINE" "+REDO/primdb/onlinelog/group_23.270.784552445" "NO"
4 10 "" "ONLINE" "+DG1/primdb/onlinelog/group_10.284.783543933" "NO"
4 24 "" "ONLINE" "+REDO/primdb/onlinelog/group_24.271.784552453" "NO"
4 11 "" "ONLINE" "+DG1/primdb/onlinelog/group_11.285.783543979" "NO"
4 13 "" "ONLINE" "+DG1/primdb/onlinelog/group_13.286.783544253" "NO"
4 14 "" "ONLINE" "+DG1/primdb/onlinelog/group_14.287.783544347" "NO"
4 15 "" "ONLINE" "+DG1/primdb/onlinelog/group_15.288.783544531" "NO"
4 16 "" "ONLINE" "+DG1/primdb/onlinelog/group_16.289.783544655" "NO"
4 17 "" "ONLINE" "+DG1/primdb/onlinelog/group_17.290.783544659" "NO"
4 18 "" "ONLINE" "+DG1/primdb/onlinelog/group_18.291.783544685" "NO"
4 19 "" "ONLINE" "+DG1/primdb/onlinelog/group_19.292.783544691" "NO"
4 20 "" "ONLINE" "+DG1/primdb/onlinelog/group_20.293.783544697" "NO"
4 21 "" "ONLINE" "+DG1/primdb/onlinelog/group_21.294.783544701" "NO"
4 22 "" "ONLINE" "+DG1/primdb/onlinelog/group_22.295.783544717" "NO"
4 23 "" "ONLINE" "+DG1/primdb/onlinelog/group_23.296.783544721" "NO"
4 24 "" "ONLINE" "+DG1/primdb/onlinelog/group_24.297.783544727" "NO"
4 25 "" "ONLINE" "+DG1/primdb/onlinelog/group_25.298.783544731" "NO"
4 25 "" "ONLINE" "+REDO/primdb/onlinelog/group_25.272.784552459" "NO"
4 29 "" "STANDBY" "+FR1/primdb/onlinelog/group_29.4913.787264989" "NO"
4 30 "" "STANDBY" "+DG1/primdb/onlinelog/group_30.320.787264993" "NO"
4 30 "" "STANDBY" "+FR1/primdb/onlinelog/group_30.4912.787264995" "NO"
4 31 "" "STANDBY" "+DG1/primdb/onlinelog/group_31.319.787264997" "NO"
4 31 "" "STANDBY" "+FR1/primdb/onlinelog/group_31.4911.787264999" "NO"
4 32 "" "STANDBY" "+DG1/primdb/onlinelog/group_32.318.787265001" "NO"
4 32 "" "STANDBY" "+FR1/primdb/onlinelog/group_32.4910.787265003" "NO"
4 33 "" "STANDBY" "+DG1/primdb/onlinelog/group_33.317.787265005" "NO"
4 33 "" "STANDBY" "+FR1/primdb/onlinelog/group_33.4909.787265007" "NO"
4 34 "" "STANDBY" "+DG1/primdb/onlinelog/group_34.316.787265009" "NO"
4 34 "" "STANDBY" "+FR1/primdb/onlinelog/group_34.4908.787265011" "NO"
4 35 "" "STANDBY" "+DG1/primdb/onlinelog/group_35.315.787265013" "NO"
4 35 "" "STANDBY" "+FR1/primdb/onlinelog/group_35.4905.787265015" "NO"
4 36 "" "STANDBY" "+DG1/primdb/onlinelog/group_36.314.787265019" "NO"
4 36 "" "STANDBY" "+FR1/primdb/onlinelog/group_36.4904.787265021" "NO"
4 37 "" "STANDBY" "+DG1/primdb/onlinelog/group_37.313.787265023" "NO"
4 37 "" "STANDBY" "+FR1/primdb/onlinelog/group_37.4903.787265027" "NO"
4 38 "" "STANDBY" "+DG1/primdb/onlinelog/group_38.312.787265029" "NO"
4 38 "" "STANDBY" "+FR1/primdb/onlinelog/group_38.4902.787265031" "NO"
4 39 "" "STANDBY" "+DG1/primdb/onlinelog/group_39.263.787265033" "NO"
4 39 "" "STANDBY" "+FR1/primdb/onlinelog/group_39.4901.787265035" "NO"
4 40 "" "STANDBY" "+DG1/primdb/onlinelog/group_40.278.787265037" "NO"
4 40 "" "STANDBY" "+FR1/primdb/onlinelog/group_40.4899.787265039" "NO"
4 41 "" "STANDBY" "+DG1/primdb/onlinelog/group_41.279.787265041" "NO"
4 41 "" "STANDBY" "+FR1/primdb/onlinelog/group_41.4898.787265043" "NO"
4 42 "" "STANDBY" "+DG1/primdb/onlinelog/group_42.277.787265047" "NO"
4 42 "" "STANDBY" "+FR1/primdb/onlinelog/group_42.4897.787265049" "NO"
4 43 "" "STANDBY" "+DG1/primdb/onlinelog/group_43.276.787265051" "NO"
4 43 "" "STANDBY" "+FR1/primdb/onlinelog/group_43.4896.787265053" "NO"
4 44 "" "STANDBY" "+DG1/primdb/onlinelog/group_44.275.787265055" "NO"
4 44 "" "STANDBY" "+FR1/primdb/onlinelog/group_44.4894.787265057" "NO"
4 45 "" "STANDBY" "+DG1/primdb/onlinelog/group_45.282.787265259" "NO"
4 45 "" "STANDBY" "+FR1/primdb/onlinelog/group_45.4893.787265261" "NO"
4 47 "" "STANDBY" "+DG1/primdb/onlinelog/group_47.324.787265263" "NO"
4 47 "" "STANDBY" "+FR1/primdb/onlinelog/group_47.4892.787265265" "NO"
4 48 "" "STANDBY" "+DG1/primdb/onlinelog/group_48.325.787265267" "NO"
4 48 "" "STANDBY" "+FR1/primdb/onlinelog/group_48.4891.787265269" "NO"
4 46 "" "STANDBY" "+DG1/primdb/onlinelog/group_46.326.787265279" "NO"
4 46 "" "STANDBY" "+FR1/primdb/onlinelog/group_46.4890.787265281" "NO"
Maybe you are looking for
-
Links embedded in OS X Mail will no longer open in Firefox 3.6.12.. open in all other browsers
When a link in an email is clicked, application switches to Firefox 3.6.12, but will not open a new tab or go to the desired link. In 3.6.11 and previous versions, this was never a problem. If I switch my default browser to Safari, IE8 (in a virtual
-
Jsp, struts, problem in session invalidation
Hello, Though have seen many topics here related to this, still cudn't get a proper solution. I'm having a struts application with many jsp's. have used session.invalidate for expiring sessions. Now the problem is my jsp have both button specific act
-
SAPehp tool does not know the host for Java stack
I am running SAPehp tool to apply enhp2 to a dual stack with ABAP and JAVA on seperated Windows boxes. I started SAPehp at the ABAP box. Because there is no way to tell where is the Java host, how do I apply the enhp2 to the Java side? How to make A
-
RegExp for replacing specific HTML tags.
Hi All, I need to replace some of the HTML tags in flex. for eg:- in the follwing html i have to replace "span","div" and "a" <h2>AAAAAAAAA<br /><span >BBBBBBBBBBB</span></h2><div><p>QQQQQQ</p><p>EE<br />FFFF<br />TTT<br /></p <a href="#">Click</a> <
-
Hi my Mac doesn't want go sleep. This is the log: 10/13/11 1:50:38.000 AM kernel: hibernate image path: /var/vm/sleepimage 10/13/11 1:50:38.000 AM kernel: sizeof(IOHibernateImageHeader) == 512 10/13/11 1:50:38.000 AM kernel: error 0xe00002db opening