| |
Today met a dataguard in 10gR2 the bug, no matter what is really at a particular time to do the specific results of the operation encountered particular problems.
The problem is in 10gR2 version 10.2.0.4.0 of a library, and found the time to do the inspection table space utilization is already high, ready to add data files to fix this issue, arguably this is a routine operation, there is no place to be little circle.
But after you've added the data file, after a while, they received the alarm, said library equipment is some problem, he still wondered in the end is what causes, with doubt use dgmgrl to see a bit.
DGMGRL> show configuration;
Configuration
Name: test
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
test - Primary database
stest4 - Physical standby database
stest2 - Physical standby database
Current status for "test":
Warning: ORA-16607: one or more databases have failed
Through this, the standby database did find out some problems, and quickly connect to the standby database, view the results of the data log on to discover that the MRP process stopped.
Fri Sep 11 17:58:53 2015
Errors in file /U01/app/Oracle/admin/test/bdump/test_mrp0_10953.trc:
ORA-00600: internal error code, arguments: [3689], [21], [], [], [], [], [], []
Errors with log /U01/app/oracle/flash_recovery_area/STEST4/archivelog/2015_09_11/o1_mf_1_7414_bz598mqc_.arc
MRP0: Background Media Recovery terminated with error 600
Fri Sep 11 17:58:55 2015
Errors in file /U01/app/oracle/admin/test/bdump/test_mrp0_10953.trc:
ORA-00600: internal error code, arguments: [3689], [21], [], [], [], [], [], []
Fri Sep 11 17:59:04 2015
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Fri Sep 11 17:59:04 2015
See this error, found the problem seems a little strange, because the error associated with the ora ora-600
With this question, the first thought is met before their own MRP unable to start, dataguard the MRP can not start to analyze and solve problems
According to the results of their problems was also thinking similar analysis, the results really found the problem.
Use the following statement to view data files.
In standby database view:
select file #, df.name, df.ts #, ts.name, df.RFILE # from v $ datafile df, v $ tablespace ts
where df.ts # = ts.ts #;
FILE # NAME TS # NAME
---------- ---------------------------------------- -------------------- ---------- --------------------
20 /U01/app/oracle/oradata/test/test_new_data04.dbf 9 TEST_NEW_DATA
21 /U01/app/oracle/oradata/test/test_new_index04.dbf 9 TEST_NEW_DATA
Check the main library
FILE # NAME TS # NAME
---------- ---------------------------------------- -------------------- ---------- --------------------
20 /U01/app/oracle/oradata/test/test_new_data04.dbf 9 TEST_NEW_DATA
21 /U01/app/oracle/oradata/test/test_new_index04.dbf 10 TEST_NEW_INDEX
Through this can be found in table space data files are inconsistent in two libraries.
In fact, this time linking ora600 which has hinted at the wrong meaning out of 21
ORA-00600: internal error code, arguments: [3689], [21], [], [], [], [], [], []
This time it dawned own, in their own time table space TEST_NEW_DATA to add data files accidentally added became test_new_index04.dbf, created after the good results found the problem,
On the use of alter tablespace test_new_data drop datafile 'xxxxx' way to delete, and then create a new data file test_new_data04.dbf
Such an operation there is no criticism of the place, but in 10gR2 10.2.0.4.0 Lane is not, because there is a bug
Bug 5623467 - Corrupt redo from ALTER TABLESPACE DROP DATAFILE (Document ID 5623467.8)
This bug, oracle gave no other practical advice, in addition to the upgrade patch, the advice is not to use drop datafile command, but I've run, how do you say, we can only be prepared to rebuild the library.
Of course, in addition to the reconstruction of the library prepared hard work I wanted to do something to try.
Since the data dictionary is not synchronized, the drop operation is not supported, I'll just use alter database datafile 'xxxxxx' offline drop to get this problem, the last issue of MRP in 11g can be so resolved.
SQL> alter database datafile '/U01/app/oracle/oradata/test/test_new_index04.dbf' offline drop;
Database altered.
Command is successful, but the view datafile did not change.
FILE # NAME TS # NAME
---------- ---------------------------------------- -------------------- ---------- --------------------
20 /U01/app/oracle/oradata/test/test_new_data04.dbf 9 TEST_NEW_DATA
21 /U01/app/oracle/oradata/test/test_new_index04.dbf 9 TEST_NEW_DATA
Try to recover managed standby database disconnect from session again found the problem persists, or ora-600 error.
This time when you want to start the database to read only a problem also.
SQL> alter database open read only;
alter database open read only
*
ERROR at line 1:
ORA-16004: backup database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/U01/app/oracle/oradata/test/system01.dbf'
So there is no way to rebuild the standby database, people really no choice. |
|
|
|