Oracle standby ORA-00600:[3020] ORA-10567
現象
Oracle Database 11g Enterprise Edition Release11.2.0.1.0 - 64bit Production
Red Hat Enterprise Linux Server release 5.3(Tikanga) 64bit
在主庫執行將文件從4G改小為2G后
ALTERDATABASEDATAFILE'/data/orcl/undotbs04.dbf'RESIZE2000M;
Standby DB中
SELECT OPEN_MODE FROMV$database
READ ONLY WITH APPLY 變為了READ ONLY
Standby alert.log
Wed Mar 25 13:24:25 2015
Errors in file /u01/product/diag/rdbms/orcldg/orcl/trace/orcl_mrp0_7554.trc (incident=592209):
ORA-00600:internal error code, arguments: [3020], [6], [2343], [25168167], [], [], ORA-10567: Redo is inconsistent with datablock (file# 6, block# 2343, file offset is 38387712 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: data file 6: '/data/orcl/undotbs03.dbf'
ORA-10560: block type 'KTU UNDO BLOCK'
Incident details in:/u01/product/diag/rdbms/orcldg/orcl/incident/incdir_592209/orcl_mrp0_7554_i592209.trc
Recovery Slave PR05 previously exited withexception 600
Wed Mar 25 13:24:26 2015
MRP0: Background Media Recovery terminated witherror 448
Errors in file/u01/product/diag/rdbms/orcldg/orcl/trace/orcl_pr00_7689.trc:
ORA-00448: normal completion of background process
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Trace dumping is performingid=[cdmp_20150325132426]
Recovered data files to a consistent state atchange 8924400385
Errors in file/u01/product/diag/rdbms/orcldg/orcl/trace/orcl_pr00_7689.trc:
ORA-00448: normal completion of background process
Errors in file/u01/product/diag/rdbms/orcldg/orcl/trace/orcl_mrp0_7554.trc:
ORA-00600: internal error code, arguments: [3020],[6], [2343], [25168167], [], [], [],
ORA-10567: Redo is inconsistent with data block(file# 6, block# 2343, file offset is 38387712 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: data file 6: '/data/orcl/undotbs03.dbf'
ORA-10560: block type 'KTU UNDO BLOCK'
MRP0: Background Media Recovery process shutdown(orcl)
Wed Mar 25 13:24:28 2015
Sweep [inc][592249]: completed
Sweep [inc][592209]: completed
Sweep [inc2][592249]: completed
Sweep [inc2][592209]: completed
手動執行alterdatabase recover managed standby database using current logfile disconnect 報錯依舊。關閉standby再開啟問題依舊
處理：
主庫altertablespace UNDOTBS1 begin backup;
主庫Scp/data/orcl/undotbs03.dbf -> 從庫
主庫altertablespace UNDOTBS1 end backup;
主庫 alter database create standby controlfile as ‘/data/standby.ctl’
主庫Scp/data/standby.ctl -> 從庫
從庫 startup
ALTER DATABASEADDSTANDBYLOGFILEGROUP15 ('/data/orcl/standbylog15.log')size50M;
……
alter database recover managed standby databaseusing current logfile disconnect
恢復OK
Bug11689702ORA-600 [3020] during recovery after datafile RESIZE (tosmaller size)
This note gives a brief overview of bug 11689702.
The content was last updated on: 28-JUN-2013
Click here for details of each ofthe sections below.
Affects:
Product (Component)
Oracle Server (Rdbms)
Range of versions believed to be affected
Versions >= 11.2 but BELOW 12.1
Versions confirmed as being affected
11.2.0.211.2.0.1Platforms affected
Generic (all / most platforms affected)
Fixed:
This issue is fixed in
12.1.0.1 (Base Release)11.2.0.3 (Server Patch Set)11.2.0.2.5 Database Patch Set Update11.2.0.2.5 Grid Infrastructure Patch Set Update (GI PSU)11.2.0.2 Bundle Patch 13 for Exadata Database11.2.0.2 Patch 14 on Windows PlatformsSymptoms:
Related To:
Internal Error May Occur (ORA-600)ORA-600 [3020]RecoveryPhysical Standby Database / DataguardRESIZEDescription
Media recovery (either at a standby or standardmedia recovery)
may get stuck and stop due to an ORA-600 [3020]following a datafile
resize operation (to resize a datafile smaller)on the primary.
Rediscovery Notes:
Look forall the following:
- Mediarecovery fails with ORA-600 [3020],[<file#>],[<block#>]
- Anyattempt to restart media recovery fails with exactly the
sameerror (most likely this is a primary/standby congifuration
and themedia recovery is failing with ORA-600 [3020] on the
standby)
- look atthe alert log for the time period covering the media
recovery session, and search for the ORA-600 [3020] message,
then:
1. seewhich log seq# was being applied at the time of the
ORA-600 [3020], and then look at
2. seewhich filename it was reported for:
ORA-1110: data file <file#>: '<datafile_name>'
thenlook at the alert log messages that were generated while
thatlog seq# was current and originally being written to,
thereshould be a resize operation for that datafile:
"alter database datafile '<datafile_filename>' resize<n>"
Theresize should be resizing the datafile smaller, but it
willonly be possible to confirm this if there are other
resizeoperations for the same file earlier in the alert log
toprove the datafile initially had a larger size just prior
to thisresize.
- themain ORA-600 [3020] tracefile (not the incident tracefile)
shouldhave the following contents:
-----
KCOX_FUTURE: CHANGE IN FUTURE OF BLOCK
and
RECOVERY STUCK AT BLOCK <block#> OF FILE <file#>
and
CHANGE ...
(this is a dump of the individual redo change vector which
recovery got stuck on and could not apply)
and
ORA-01110: data file <file#>: '<datafile_name>'
ORA-10560: block type ...
and
buffer tsn: ...
(this is a dump of the cache header stored at the front of
theblock, which the redo change could not be applied to)
and
DUMPREDO
(adump of the recent redo, filtered for the file#/block#)
ENDOF DUMP REDO
and
ORA-00600: [3020], [<file#>], [<block#>], [<DBA>]
ORA-10567: Redo is inconsistent with data block (file# ...
ORA-10564: tablespace <tablespace_name>
ORA-01110: data file <file#>: '<datafile_name>'
ORA-10560: block type ...
-----
examinethe redo dump, and find the redo record containing the
changevector (for file#/block#) which recovery got stuck on -
itshould appear near the end of the redo dump, then go backwards
fromthat redo record, to find the immediately previous change to
file#/block#, and note the scn of that redo record, then at that
samescn there should be a datafile resize marker redo record
whichshinks the file (ie old size is greater than new size).
Eg:
REDORECORD - Thread:1 RBA: 0x000004.00001394.0198 LEN: 0x0128 VLD: 0x01
SCN:0x0000.00072bbd SUBSCN: 43 02/28/2011 11:49:14
CHANGE#2 TYP:0 CLS:1 AFN:4 DBA:0x0100000c OBJ:64299 SCN:0x0000.00072bbd
SEQ:42OP:11.3 ENC:0 RBL:0
...
REDORECORD - Thread:1 RBA: 0x000004.00001395.00d0 LEN: 0x0044 VLD: 0x01
SCN:0x0000.00072bbd SUBSCN: 43 02/28/2011 11:49:14
CHANGE#1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:0 OP:17.4 ENC:0
Datafile resize marker - file: 4 old size: 12800 new size: 12672
...
REDORECORD - Thread:1 RBA: 0x000004.00001396.0010 LEN: 0x0150 VLD: 0x05
SCN:0x0000.00072bbf SUBSCN: 1 02/28/201111:49:14
Getting a Fix
Use oneof the "Fixed" versions listed above
(forPatch Sets / bundles use the latest version available as
contentsare cumulative - the "Fixed" version listed above is
thefirst version where the fix is included)
or
Click here forsuggestions on how to get a fix for this issue
HOOKS INCLUDE:FIXHELP OERI:3020"SQL:RESIZE" LIKELYAFFECTS XAFFECTS_11.2.0.1 XAFFECTS_V11020001AFFECTS=11.2.0.1 XAFFECTS_11.2.0.2 XAFFECTS_V11020002 AFFECTS=11.2.0.2XPRODID_5 PRODUCT_ID=5 PRODID-5 RDBMS XCOMP_RDBMS COMPONENT=RDBMS TAG_OERI TAG_RECOVERYTAG_STANDBY OERI RECOVERY STANDBY FIXED_11.2.0.2.5 FIXED_11.2.0.2.BP13FIXED_11.2.0.2.GIPSU05 FIXED_11.2.0.3 FIXED_12.1.0.1 FIXED_WIN:B202P14
Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support.
References
Bug:11689702 (This link will onlywork for PUBLISHED bugs)
Note:245840.1 Information on thesections in this article
声明：本站所有文章资源内容，如无特殊说明或标注，均为采集网络资源。如若本站内容侵犯了原著者的合法权益，可联系本站删除。
