ORA-00600[3020]もSTUCK RECOVERYとよばれる。一般的な原因はあるデータブロックがリカバリされた途中で、そのブロックにAPPLYする必要があるredoログでそのブロックを検証するときに、ORACLEのアルゴリズムとマッチしていない。つまり認証redoとdata blockの間に一致していないから、エラになる。

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

ORA-00600[3020]エラに関連するargumentは9.2での意味は：

Arg [a] Block DBA
Arg [b] Redo Thread
Arg [c] Redo RBA Seq
Arg [d] Redo RBA Block No
Arg [e] Redo RBA Offset.

 

ORACLE 10.1での意味は：

Arg [a] Absolute file number of the datafile.
Arg [b] Block number
Arg [c] Block DBA

 

このエラのモジュールはカーネルに属し、parallelメモリーリカバリを実行する。これによる影響はロールフォワードの時にエラになって、データベースを起動できなくなる。

 

解決策： recoverコマンドでこのエラを導く可能性はいくつもある。よくあるのはデータファイルがデータファイルをまともにディスクにrestoreされていないから、あるいはrestoreは不完全なものだった。それで、まずはバックアップごとにrestoreされたことを確保してください。Restoreがデータベースをリカバリした前に済ませてください。。

 

Restoreは完全であったことを確認できたが、トラブルがまだ残っている場合に、restoreを再びバックアップして、時点に基づき、POINT-IN-TIMのリカバリを実行してください。この時点はORA-600[3020]エラが指定した時点より早い。

例えば：

SQL> recover database until time ‘YYYY-MON-DD:HH:MI:SS’;

もちろん、このエラの原因はlost updateかもしれない。

普通の操作プロセスで、ブロックについてのアップグレードや書くことは一連のデータファイル、redoログ及びアーカイブログで進めている。どんなファイルをなくしてもORA-00600[3020]エラになる。それで、トラブルが起こったオペレーションシステムとディスクハードウェアを全面的にテストしてください。

書き込みをなくした場合に、より古いバックアップからrestoreして、リカバリとロールフォワードを試してください。

必要な診断情報は主にalert.logと一部のtraceに含んでいた。例えば、ロールフォワードを実行するプロセス：traceとSMONのtrace。

 

 

 

ORA-600 [3020]に関連するbugリスト：

 

NB	Bug	Fixed	Description
	9847338		Session hang after applying the patch for Bug 9587912 which causes ORA-600 [3020]
+	13467683	11.2.0.2.BP15, 11.2.0.3.3, 11.2.0.3.BP04, 12.1.0.0	Join of temp and permanent tables in RAC might cause corruption of permanent table. Regression by bug 10352368
	12831782	11.2.0.2.BP11, 11.2.0.3.BP01, 12.1.0.0	ORA-600 [3020] / ORA-333 Recovery of datafile or async transport do not read mirror if there is a stale block
	12582839	11.2.0.3, 12.1.0.0	ORA-8103/ORA-600 [3020] on RMAN recovered locally managed tablespace
	11689702	11.2.0.2.5, 11.2.0.2.BP13, 11.2.0.2.GIPSU05, 11.2.0.3, 12.1.0.0	ORA-600 [3020] during recovery after datafile RESIZE (to smaller size)
	10329146	11.2.0.1.BP10, 11.2.0.2.2, 11.2.0.2.BP03, 11.2.0.2.GIBUNDLE02, 11.2.0.2.GIPSU02, 11.2.0.3, 12.1.0.0	Lost write in ASM with multiple DBWs and a disk is offlined and then onlined
	10218814	11.2.0.2.2, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.0	ORA-600 [3020] during recovery / on standby
+	10209232	11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.0	ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM
*	10205230	11.2.0.1.6, 11.2.0.1.BP09, 11.2.0.2.2, 11.2.0.2.BP04, 11.2.0.3, 12.1.0.0	ORA-600 / corruption possible during shutdown in RAC
	10094823	11.2.0.2.4, 11.2.0.2.BP09, 11.2.0.3, 12.1.0.0	Block change tracking on physical standby can cause data loss
	10071193	11.2.0.2.BP02, 11.2.0.3, 12.1.0.0	Lost write / ORA-600 [kclchkblk_3] / ORA-600 [3020] in RAC – superceded
	9587912	11.2.0.2, 12.1.0.0	ORA-600 [3020] in datafile that went offline/online in a RAC instance
	8774868	11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.0	OERI[3020] reinstating primary
+	8769473	11.2.0.2, 12.1.0.0	ORA-600 [kcbzib_5] on multi block read in RAC. Invalid lock in RAC. ORA-600 [3020] in Recovery
P	8635179	10.2.0.5, 11.2.0.2, 12.1.0.0	Solaris: directio may be disabled for RAC file access. Corruption / Lost Write
+	8597106	11.2.0.1.BP06, 11.2.0.2, 12.1.0.0	Lost Write in ASM when normal redundancy is used
P	12330911	12.1	EXADATA LSI firmware for lost writes
+	10425010	11.2.0.3, 12.1	Stale data blocks may be returned by Exadata FlashCache
	8826708	10.2.0.5, 11.2.0.2	ORA-600 [3020] for block type 0x3a (58) during recovery for block restored by RMAN backup
	11684626	11.2.0.1	ORA-600 [3020] on standby involving “BRR” redo when db_lost_write_protect is enabled
	8230457	10.2.0.4.1, 10.2.0.5, 11.1.0.7.1, 11.2.0.1	Physical standby media recovery gets OERI[krr_media_12]
+	7680907	10.2.0.5, 11.1.0.7.1, 11.2.0.1	ORA-600 [kclexpandlock_2] in LMS / instance crash. Incorrect locks in RAC. ORA-600 [3020] in recovery
	4637668	10.2.0.3, 11.1.0.6	IMU transactions can produce out-of-order redo (OERI [3020] on recovery)
	4594917	9.2.0.8, 10.2.0.2, 11.1.0.6	Write IO error can cause incorrect file header checkpoint information
	4453449	10.2.0.2, 11.1.0.6	OERI:3020 / corruption errors from multiple FLASHBACK DATABASE
	7197445	10.2.0.4.1, 10.2.0.5	Standby Recovery session cancelled due to ORA-600 [3020] “CHANGE IN FUTURE OF BLOCK”
	5610267	10.2.0.5	MRP terminated by ORA-600[krr_media_12] / OERI:3020 after flashback
	3762714	9.2.0.7, 10.1.0.4, 10.2.0.1	ALTER DATABASE RECOVER MANAGED STANDBY fails with OERI[3020]
	3560209	10.2.0.1	OERI[3020] stuck recovery under RAC
	3397181	9.2.0.5, 10.1.0.3, 10.2.0.1	ALTER SYSTEM KILL SESSION of recovery slave causes stuck recovery
*	3381950	10.2.0.1	Backups from RAC DB before Data Guard Failover cannot be used
	3535712	9.2.0.6, 10.1.0.4	OERI[3020] / ORA-10567 from RAC with standby in max performance mode
	4594912	9.2.0.8, 10.1.0.2	Incorrect checkpoint possible in datafile headers
	3635331	9.2.0.6, 10.1.0.4	Stuck recovery (OERI:3020) / ORA-1172 on startup after a crash
	2322620	9.2.0.1	OERI:3020 possible on recovery of LOB DATA
P+	656370	7.3.3.4, 7.3.4.0, 8.0.3.0	AlphaNT only: Corrupt Redo (zeroed byte) OERI:3020

 

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

SQL> select count(*) from WWork;

COUNT(*)
———-
116114

select count(*) from WWork where Work_WorkID = 100;
select count(*) from WWork where Work_WorkID = 100
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [25012], [15], [8], [], [], [], [],
[]

Tablespace id 15 is the same where the index is created.

analyze table livelink.WWORK validate structure cascade;

analyze table livelink.WWORK validate structure cascade
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [25012], [15], [8], [], [], [], [],
[]

analyze index livelink.WWORK_PRIMARY validate structure;
analyze index livelink.WWORK_PRIMARY validate structure
*
ERROR at line 1:
ORA-08100: index is not valid – see trace file for diagnostics

I’m wondering if the issue could be resolved recreating the index.

alter index WWORK_PRIMARY rebuild online noparallel;

On the alert log file, ORA-00600 began at:
Sun Jun 5 23:29:10 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_26554.trc:
ORA-00600: internal error code, arguments: [ktbair1], [1], [6], [], [], [], [], []
Mon Jun 6 00:35:51 2011
Thread 1 advanced to log sequence 303722
Current log# 19 seq# 303722 mem# 0: /u002/oradata/motpcom/redo19.log
Mon Jun 6 00:35:51 2011
And then below error often raised in alert log:
Mon Jun 6 02:45:00 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_28348.trc:
ORA-00600: internal error code, arguments: [25012], [15], [8], [], [], [], [], []
Mon Jun 6 02:50:01 2011
I also found other errors:
Mon Jun 6 05:00:01 2011
ORA-01555 caused by SQL statement below (Query Duration=18448 sec, SCN: 0x09f0.52bb91c8):
Mon Jun 6 05:00:01 2011
SELECT COUNT(d.dataid)
FROM allemployees a, networks_dataids d, kuaf k, dversdata v
WHERE k.name=a.user_id(+) AND d.userid=k.id AND a.user_id is null
Mon Jun 6 05:00:13 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_28348.trc:
ORA-00600: internal error code, arguments: [25012], [15], [8], [], [], [], [], []
Mon Jun 6 05:05:13 2011
And
Tue Jun 7 02:02:14 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_25842.trc:
ORA-07445: exception encountered: core dump [00000001011B8AD8] [SIGSEGV] [Address not mapped to object] [0x000000A88] [] []
Tue Jun 7 02:03:11 2011
And
Tue Jun 7 02:41:35 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_27325.trc:
ORA-00600: internal error code, arguments: [2662], [2544], [1396224900], [28954], [3445424704], [786437], [], []
Tue Jun 7 02:41:35 2011
Errors in file /u001/app/oracle/admin/motpcom/udump/motpcom_ora_27325.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [2544], [1396224900], [28954], [3445424704], [786437], [], []
Tue Jun 7 02:41:59 2011

SQL> select count(*) FROM WWork where Work_WorkID=100;
select count(*) FROM WWork where Work_WorkID=100
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [25012], [15], [8], [], [], [], [],
[]
SQL> alter index WWORK_PRIMARY rebuild online noparallel;

Index altered.

SQL> select count(*) FROM WWork where Work_WorkID=100;

COUNT(*)
———-
0

Index corruptions do not always mean that there is a Bug.
Indexes corrupt when the transaction ID that associates it with its data does not match.
In majority of the cases, this happens when a table has a large amount of DDL or DML processing as in a OLAP
processing. The index buffer cache is over written with an incorrect transaction id and an error results.
The error could be a ORA-00600 [25027] error, an ORA-8102/8103, or another ORA-00600 error.
Possibly, adding another index may resolve the issue of relying on just one index.

In addition, the index space must be reviewed to determine whether there is enough space.
As in the first example above, if there isn’t space, then the index can be overwritten and an error can appear.
I suggest reading My Oracle Knowledge Note 33343.1 “How to Find Out How Much Space an Index is Using” which provides select
statements to show the actual usage of blocks within an index. This gives an idea of how ‘full’ an index is and
allows the DBA to adjust next extent sizes etc.

In addition, you can start the Index Tuning Wizard from Enterprise Manager in order to get advice on the indexes within the database.

We would like to emphasize that the best method to resolve a corrupt index is to drop and recreate it and not use a rebuild.
If this index corrupts again, then we suggest that it be dropped and recreated.
ORA-600 [25012] “Relative to Absolute File Number Conversion Error”
Note: For additional ORA-600 related information please read Note:146580.1

PURPOSE:
This article discusses the internal error “ORA-600 [25012]”, what
it means and possible actions. The information here is only applicable
to the versions listed and is provided only for guidance.

ERROR:
ORA-600 [25012] [a] [b] [c]

VERSIONS:
versions 8.0 and above

DESCRIPTION:

We are trying to generate the absolute file number given a tablespace
number and relative file number and cannot find a matching file number
or the file number is zero.

ARGUMENTS:
Arg [a] Tablespace Number
Arg [b] Relative file number
Arg [c] Absolute file number (This arg is present is more recent releases)

FUNCTIONALITY:
KERNEL FILE MANAGEMENT TABLESPACE COMPONENT

IMPACT:
POSSIBLE PHYSICAL CORRUPTION

SUGGESTIONS:

The possibility of physical corruption exists.

Obtain the trace files and alert.log for this error and log a Service Request
with Oracle Support Services for diagnosis.

If the Arg [b] Relative file number returns 0 (zero), look for fake indexes
that can cause this error.

The following query list fake indexes :

select a.*,b.flags from dba_objects a, sys.ind$ b
where a.object_id = b.obj#
and bitand(b.flags,4096)=4096;

Known Issues:
Known Bugs
You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button:
NB Bug Fixed Description
5653641 11.2.0.1 Corrupt dictionary from DROP TABLESPACE containing _offline_rollback_segments
* 8198906 10.2.0.5, 11.2.0.1 OERI [kddummy_blkchk] / OERI [5467] for an aborted transaction of allocating extents
4925342 9.2.0.8, 10.2.0.3, 11.1.0.6 OERI [25027] / OERI [25012] on IOT analyze estimate statistics
3258674 9.2.0.7, 10.1.0.4, 10.2.0.1 QMN process may dump or raise an internal error during DML
4186885 10.2.0.1 Partition numbers for IOT index/overflow segments are not synchronized
3751874 9.2.0.6, 10.1.0.4, 10.2.0.1 OERI[25012] can occur when _old_connect_by_enabled set to true
3430832 9.2.0.6, 10.1.0.3, 10.2.0.1 OERI[25012] in DML after ONLINE create index against PARTITIONED table
3915343 9.2.0.7, 10.1.0.5, 10.2.0.1 OERI [25012] on COMMIT with refresh ON-COMMIT Materialized view over cluster
4305391 9.2.0.7, 10.1.0.5, 10.2.0.1 OERI[25012] with kditalp can occur during a temporary LOB operation
P* 6047085 Linux x64-64: SGA corruption / crash following any ORA-7445
2526334 9.2.0.3, 10.1.0.2 OERI:25012 from AND EQUAL with B-Tree and DOMAIN index
2531519 9.2.0.3, 10.1.0.2 OERI:[25012] from parallel direct load of bitmap managed segments
3150268 9.2.0.5, 10.1.0.2 OERI[kcbgcur_1] / OERI:25012 deleting rows from PARENT table with LIST subpartitions
3070856 9.2.0.5, 10.1.0.2 OERI:12700 / 25012 / ktrexc_1 on transported tablespace with SMU
3771508 9.2.0.7 OERI[kcbgtcr_1] / OERI[25012] selecting from V$AQ in a shared server
3900237 9.2.0.7 OERI[25012] changing length of indexed column for a global temporary table
1834530 8.1.7.4, 9.0.1.4, 9.2.0.1 OERI:25012 / wrong results after EXCHANGE
PARTITION with indexes with different FREELIST /FREELIST GROUPS
1698789 9.2.0.1 Wrong results, ORA-1410, ORA-8103, OERI:25012 on SELECT of UNSCOPED REF with ROWID
2189615 8.1.7.4, 9.0.1.4, 9.2.0.1 OERI:25012 / OERI:504 [cache buffers chains] selecting from certain V$ tables
1784708 8.1.7.3, 9.0.1.1, 9.2.0.1 OERI:KCBGTCR_1/OERI:25012 accessing LONG / LONG RAW in a HASH CLUSTER
1872985 9.0.1.2, 9.2.0.1 Dump / OERI:25012 from BITMAP CONVERSION of INDEX on GLOBAL TEMPORARY TABLE
1968815 9.0.1.2, 9.2.0.1 OERI:25012 possible from SMON following DROP TABLESPACE command
2287815 9.0.1.4, 9.2.0.1 OERI:KTSPISCHNT / OERI:25012 after exchange PARTITION with bitmap managed segments
2184731 8.1.7.4, 9.2.0.1 OERI:25012 possible from index prefetch
1837529 8.1.7.3, 9.0.1.1, 9.2.0.1 OERI:KFTR2BZ_1/OERI:25012 from CREATE sub-partitioned local INDEX ONLINE
2214167 9.0.1.4, 9.2.0.1 OERI:25012 / wrong results possible after TRUNCATE of bitmap managed index
2212389 9.0.1.4, 9.2.0.1 OERI:25012 / Cursor frame memory corruption when cursor with BINDS aged out / reloaded
1788648 8.1.7.3, 9.0.1.1, 9.2.0.1 OERI:25012 [2147483647] possible selecting from certain V$ views
1527982 8.1.7.2, 9.0.1.0 OERI:25012 / Bitmap indextable mismatch after UPDATE of PARTITION KEY moves rows
1949273 8.1.7.3, 9.0.1.0 OERI:25012 / ORA-1555 / ORA-22922 accessing LOB data after ALTER TABLE MOVE lob
1264970 8.1.7.1, 9.0.1.0 OERI:25012 / OERI:6050 possible coalescing index with freelists
1396571 8.0.6.3, 8.1.6.3, 8.1.7.1, 9.0.1.0 OERI:25012 possible importing with TRANSPORT_TABLESPACE=Y
1678963 8.1.7.2, 9.0.1.0 OERI:25012 / OERI:4142 possible on TRUNCATE of a table with a CLOB column
1297674 8.0.6.2, 8.1.6.3, 8.1.7.0 OERI:25012 Analyzing partitioned table with ESTIMATE
1138239 8.1.6.2, 8.1.7.0 OERI-25012 possible on direct read from plugged in (transportable) tablespace
1228658 8.1.6.2, 8.1.7.0 Create INDEX on SNAPSHOT/MV can produce corrupt index (OERI:13004 / OERI:25012 / ORA-1499)
1108002 8.1.7.0 OERI:25012 when DBMS_STATS tries to gather stats for a GLOBAL TEMPORARY table
986928 8.1.7.0 DBMS_SPACE.UNUSED_SPACE reports OERI:25012 for TEMPORARY tables
1312233 8.1.6.3, 8.1.7.0 OERI:25012 / OERI:KCBGCUR_1 possible on PQ STAR query with PARTITIONED fact table
718499 8.0.6.1, 8.1.5.0 OERI:25012 possible on OPS parallel create index
677243 8.0.6.0 OERI:kdddgbX on DELETE / UPDATE / SELECT for UPDATE with an invalid ROWID
679817 8.0.5.1 OERI:25012 from view containing 2+ LOB columns
595698 8.0.4.3, 8.0.5.0 DELETE on table with many child constraints may dump.

‘*’ against a bug indicates that an alert exists for that issue.
‘+’ indicates a particularly notable bug.
‘P’ indicates a port specific bug.
“OERI:nnnnn” is used as shorthand for ORA-600 [nnnnn].

Symptom(s)
~~~~~~~~~~

ORA-600 [25012] errors with same first argument and different
second arguments (second arguments changes during every SELECT Run)

Eg.:

ORA-600 [25012], [5], [1023], [], [], [], []
The first argument corresponds to a tablespace and second argument
corresponds to a file number.

The tablespace points to an index tablespace
Cause
~~~~~

Bug:2184731
Fix
~~~~

Bug:2184731 is fixed in 8.1.7.4 and 9.2

The workaround is to set _db_file_noncontig_mblock_read_count=1.
References
~~~~~~~~~~

Note:100073.1 ORA-600 [25012] “Relative to Absolute File Number
Conversion Error”

Bug:2184731 ORA-600 [25012] WHEN SELECT FROM A TABLE USING AN INDEX

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

Linux10.2.0.4システムが異常リカバリした（_allow_resetlogs_corruption隠しバラメタで起動した後にORA-00600:[40xx]に関連する内部的なエラを現れた。作成して新たな取り消しテーブルスペースに切り替える)ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], []内部的なエラが現れた。その内部的なエラは(non-fatal)百回以上に現れたときに、アラームログで記録が現れる。
それにインディクスをcrashさせるかもしれない。具体的なログは以下の通り:

 

Errors in file /s01/10gdb/admin/clinica/bdump/clinica_smon_21463.trc:
ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], []
Tue Jan 4 23:13:19 2011
Non-fatal internal error happenned while SMON was doing logging scn->time mapping.
SMON encountered 1 out of maximum 100 non-fatal internal errors.

clinica_smon_21463.trc:
Dump of buffer cache at level 4 for tsn=1, rdba=8388633
BH (0x91fdf428) file#: 2 rdba: 0x00800019 (2/25) class: 19 ba: 0x91c62000
set: 3 blksize: 8192 bsi: 0 set-flg: 0 pwbcnt: 0
dbwrid: 0 obj: -1 objn: 0 tsn: 1 afn: 2
hash: [fcf7dd68,fcf7dd68] lru: [91fdf5b8,91fdf398]
ckptq: [NULL] fileq: [NULL] objq: [f5b53d60,f5b53d60]
use: [fa694970,fa694970] wait: [NULL]
st: XCURRENT md: SHR tch: 0
flags: gotten_in_current_mode
LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
buffer tsn: 1 rdba: 0x00800019 (2/25)
scn: 0x0000.0352d07c seq: 0x01 flg: 0x00 tail: 0xd07c2601
frmt: 0x02 chkval: 0x0000 type: 0x26=KTU SMU HEADER BLOCK

/* ここであるtsn=1,file#=2のデータブロックをダンプした。
このタイプはKTU SMU HEADER BLOCKでつまりあるロールバックセグメントヘッダ
*/

Hex dump of block: st=0, typ_found=1
……………………
ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], []
Current SQL statement for this session:
insert into smon_scn_time (thread, time_mp, time_dp, scn, scn_wrp, scn_bas, num_mappings, tim_scn_map)
values (0, :1, :2, :3, :4, :5, :6, :7)
—– Call Stack Trace —–
calling call entry argument values in hex
location type point (? means dubious value)
——————– ——– ——————– —————————-
ksedst()+31 call ksedst1() 000000000 ? 000000001 ?
7FFFF53BC160 ? 7FFFF53BC1C0 ?
7FFFF53BC100 ? 000000000 ?
ksedmp()+610 call ksedst() 000000000 ? 000000001 ?
7FFFF53BC160 ? 7FFFF53BC1C0 ?
7FFFF53BC100 ? 000000000 ?
ksfdmp()+21 call ksedmp() 000000003 ? 000000001 ?
7FFFF53BC160 ? 7FFFF53BC1C0 ?
7FFFF53BC100 ? 000000000 ?
kgeriv()+176 call ksfdmp() 000000003 ? 000000001 ?
7FFFF53BC160 ? 7FFFF53BC1C0 ?
7FFFF53BC100 ? 000000000 ?
kgesiv()+119 call kgeriv() 0068C97C0 ? 2ABDF1D42BF0 ?
000000000 ? 0F4A33EA0 ?
7FFFF53BC100 ? 000000000 ?
ksesic0()+209 call kgesiv() 0068C97C0 ? 2ABDF1D42BF0 ?
000001001 ? 000000000 ?
7FFFF53BCEE0 ? 000000000 ?
ktugti()+3200 call ksesic0() 000001001 ? 0068C9940 ?
000000000 ? 00000009A ?
000000010 ? 101010101010101 ?
ktsftcmove()+4149 call ktugti() 0B73F111C ? 7FFFF53BD278 ?
7FFFF53BD280 ? 000000000 ?
7FFFF53BD27C ? 7FFFF53BD270 ?
ktsf_gsp()+1937 call ktsftcmove() 00000000A ? 000000000 ?
000000000 ? 000000000 ?
7FFFF53BD27C ? 7FFFF53BD270 ?
kdtgsp()+512 call ktsf_gsp() 000000000 ? 7FFFF53BF460 ?
000000024 ? 000000002 ?
7FFFF53BF460 ? 000000000 ?
kdccak()+111 call kdtgsp() 2ABDF1D6A2D8 ? 7FFF00000000 ?
2ABDF1D68530 ? 000000002 ?
7FFFF53BF460 ? 000000000 ?
kdcgcs()+5419 call kdccak() 2ABDF1D6A2D8 ? 000000001 ?
0F4A3BBA8 ? 000000000 ?
2ABDF1D6A370 ? 000000000 ?
kdcgsp()+1372 call kdcgcs() 2ABDF1D6A2D8 ? 000000001 ?
0F4A3BBA8 ? 000000000 ?
2ABDF1D6A370 ? 000000000 ?
kdtInsRow()+1808 call kdcgsp() 2ABDF1D6A2D8 ? 000000001 ?
0F4A3BBA8 ? 000000000 ?
2ABDF1D6A370 ? 000000000 ?
insrow()+342 call kdtInsRow() 2ABDF1D6A2D8 ? 000000001 ?
0F4A3BBA8 ? 000000000 ?
2ABDF1D6A370 ? 000000000 ?
insdrv()+594 call insrow() 2ABDF1D6A2D8 ? 7FFFF53BFCC8 ?
000000000 ? 0F4A33DE0 ?
2ABDF1D6A370 ? 000000000 ?
inscovexe()+404 call insdrv() 2ABDF1D6A2D8 ? 7FFFF53BFCC8 ?
000000000 ? 2ABDF1D6D908 ?
2ABDF1D6A370 ? 000000000 ?
insExecStmtExecIniE call inscovexe() 0F4A33DE0 ? 0F4A3C230 ?
ngine()+85 7FFFF53C0EF0 ? 2ABDF1D69F20 ?
2ABDF1D6A370 ? 000000000 ?
insexe()+386 call insExecStmtExecIniE 0F4A33DE0 ? 0F4A3C230 ?
ngine() 2ABDF1D69F20 ? 2ABDF1D69F20 ?
2ABDF1D6A370 ? 000000000 ?
opiexe()+9182 call insexe() 0F4A333A8 ? 7FFFF53C0EF0 ?
0F4A33DE0 ? 2ABDF1D69F20 ?
2ABDF1D6A370 ? 2ABDF1D69F20 ?
opiall0()+1842 call opiexe() 000000049 ? 000000003 ?
7FFFF53C12F8 ? 000000001 ?
…………..
そのORA-00600:[4097]内部的なエラに対して、metalinkのNote [ID 1030620.6]でworkaroundの方法を紹介した:
An ORA-600 [4097] can be encountered through various activities that use
rollback segments.

Solution Description:
=====================

The most likely cause of this is BUG 427389. This BUG is fixed in
version 7.3.3.3. The BUG is caused when Rollback Segments are dropped and
recreated after a shutdown abort. It is encountered through a very specific
set of circumstances:

When an instance has a rollback segment offline and the instance crashes, or
the user does a shutdown abort, the rollback segment wrap number does not get
updated. If that segment is then dropped and recreated immediately after the
instance is restarted, the wrap number could be lower than existing wrap
numbers. This will cause the ORA-600[4097] to occur in subsequent
transactions using Rollback.

To avoid encountering this bug, rollback segments should only be dropped and
recreated after the instance has been shutdown normal and restarted. If you
have already encountered the bug, use the following workaround:

Select segment_name, segment_id from dba_rollback_segs;

Drop all Rollback Segments except for SYSTEM.

Recreate dummy (small) rollback segments with the same names in their place.

Then, recreate additional rollback segments you want to keep with their
permanent storage parameters.

Now drop the dummy ones. This should ensure that the segment_ids are not
reused.

If you ever want to add a rollback segment you have to use the workaround steps
again. If you do not fill the dummy slots you may see the problem re-appear.
異常リカバリする前に既存したトラブルがあったrollback segmentをドロップして、このトラブルを避けられる。10gの場合にAMU(automatic managed undo)で同じようなこともできる:
SQL> alter system set “_smu_debug_mode”=4;
System altered.

/*人工的にロールバックセグメントを管理するために、 SMU debugモードを4と設定してください。*/

SQL> set heading off

SQL> select ‘drop rollback segment “‘||segment_name||'”;’ from dba_rollback_segs where segment_name!=’SYSTEM’;

drop rollback segment “_SYSSMU1$”;
drop rollback segment “_SYSSMU2$”;
drop rollback segment “_SYSSMU3$”;
drop rollback segment “_SYSSMU4$”;
drop rollback segment “_SYSSMU5$”;
drop rollback segment “_SYSSMU6$”;
drop rollback segment “_SYSSMU7$”;
drop rollback segment “_SYSSMU8$”;
drop rollback segment “_SYSSMU9$”;
drop rollback segment “_SYSSMU10$”;
drop rollback segment “_SYSSMU11$”;
drop rollback segment “_SYSSMU12$”;
drop rollback segment “_SYSSMU13$”;
drop rollback segment “_SYSSMU14$”;
drop rollback segment “_SYSSMU15$”;
drop rollback segment “_SYSSMU16$”;
drop rollback segment “_SYSSMU17$”;
drop rollback segment “_SYSSMU18$”;
drop rollback segment “_SYSSMU19$”;
drop rollback segment “_SYSSMU20$”;
drop rollback segment “_SYSSMU21$”;
drop rollback segment “_SYSSMU22$”;
drop rollback segment “_SYSSMU23$”;
drop rollback segment “_SYSSMU24$”;
drop rollback segment “_SYSSMU25$”;
drop rollback segment “_SYSSMU26$”;
drop rollback segment “_SYSSMU27$”;
drop rollback segment “_SYSSMU28$”;
drop rollback segment “_SYSSMU29$”;
drop rollback segment “_SYSSMU30$”;

30 rows selected.

/* 以上のdrop rollback segmentロールバックセグメントのコマンドを実行する
既存する取り消しテーブルスペースのロールバックスペースがofflineできるがdropできない。
実際にやるべきことも前のundoテーブルスペースにトラブルがあるセグメントをドロップする。
*/

SQL> alter rollback segment “_SYSSMU30$” offline;
Rollback segment altered.

SQL> drop rollback segment “_SYSSMU30$”;
drop rollback segment “_SYSSMU30$”
*
ERROR at line 1:
ORA-30025: DROP segment ‘_SYSSMU30$’ (in undo tablespace) not allowed

SQL> alter rollback segment “_SYSSMU30$” online;
Rollback segment altered.
以上のdropトラブルロールバックセグメントをリカバリした後に、システムに二度とORA-00600:[4097]内部エラを現れていない。インスタンスは正常にリカバリした。そして、前の”_smu_debug_mode”UNDO、debugモードを管理する隠しバラメタをもう一度設定してください。

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

あるユーザーが11.1.0.6のシステムで電源が切れた後にORA-600 [4194]エラが起こった：

Starting background process QMNC
Wed Dec 10 21:26:24 2014
QMNC started with pid=21, OS id=2932
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_smon_3612.trc (incident=33600227):
ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_33600227\erp_smon_3612_i33600227.trc
Doing block recovery for file 3 block 4378
Block recovery from logseq 1, block 127 to scn 1309041534
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ERP\REDO01.LOG
Block recovery stopped at EOT rba 1.129.16
Block recovery completed at rba 1.129.16, scn 0.1309041534
Doing block recovery for file 3 block 121
Block recovery from logseq 1, block 127 to scn 1309041531
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ERP\REDO01.LOG
Block recovery completed at rba 1.128.16, scn 0.1309041533
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_smon_3612.trc:
ORA-01595: 解放エリア (2)セグメント (8)を ロールバックするときにエラになった。
ORA-00607: データブロックを変更するときに内部的なエラになった
ORA-00600: 内部的なエラコード、バラメタ: [4194], [60], [59], [], [], [], [], []
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Wed Dec 10 21:26:26 2014
Trace dumping is performing id=[cdmp_20141210212626]
Wed Dec 10 21:26:31 2014
Sweep Incident[33600227]: completed
Wed Dec 10 21:26:31 2014
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_m004_4524.trc (incident=33600347):
ORA-00600: 内部的なエラコード、バラメタ:: [4194], [60], [59], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_33600347\erp_m004_4524_i33600347.trc
Trace dumping is performing id=[cdmp_20141210212632]
Doing block recovery for file 3 block 4378
Block recovery from logseq 1, block 127 to scn 1309041534

ump of buffer cache at level 4 for tsn=2, rdba=12587290
BH (0x000000016BFB7308) file#: 3 rdba: 0x00c0111a (3/4378) class: 32 ba: 0x000000016B7EA000
set: 11 bsz: 8192 bsi: 0 sflg: 2 pwc: 51 lid: 0x00000000,0x00000000
dbwrid: 0 obj: -1 objn: 0 tsn: 2 afn: 3
hash: [0x00000001E2F7DCC0,0x00000001E2F7DCC0] lru: [0x000000016BFB74C8,0x000000016BFB7268]
obj-flags: object_ckpt_list
ckptq: [0x000000016BF8F7F8,0x000000016BFB7478] fileq: [0x00000001E3BDB698,0x000000016BFB7488] objq: [0x000000016BFEAFC8,0x000000016BF821D8]
use: [0x00000001D8653448,0x00000001D8653448] wait: [NULL]
st: XCURRENT md: EXCL tch: 0
flags: buffer_dirty mod_started gotten_in_current_mode
change state: ACTIVE
change count: 1
LRBA: [0x14.7d.0] LSCN: [0x0.4e0c7c32] HSCN: [0x0.4e0c7c32] HSUB: [65535]
cr pin refcnt: 0 sh pin refcnt: 0
buffer tsn: 2 rdba: 0x00c0111a (3/4378)
scn: 0x0000.4e0662ff seq: 0x02 flg: 0x04 tail: 0x62ff0202
frmt: 0x02 chkval: 0xa54a type: 0x02=KTU UNDO BLOCK
*** ktuc_diag_dmp: dump of redo for rdba 0x00c0111a
Cleaning up copy latch 0
Copy latch cleanup completed
DUMP REDO
Opcodes *.*
DBAs (file#, block#):
(3, 4378) .
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
**NOTE: Only Dumping Redo less then 12 hours**
Times: 12/10/2014 21:23:27 thru eternity

*** 2014-12-11 09:23:27.382
SCN Start Scan Point: scn: 0x0000.4e0bd8c2 (1309399234)
INCARNATION:
START: scn: 0x0000.4e0662ee (1309041390) Timestamp: 12/10/2014 21:26:17
END: scn: 0xffff.ffffffff
descrip:”Thread 0001, Seq# 0000000018, SCN 0x00004e0bd8c2-0x00004e0c295e”

REDO RECORD – Thread:1 RBA: 0x000012.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0bd8c4 SUBSCN: 1 12/11/2014 09:19:10
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
descrip:”Thread 0001, Seq# 0000000019, SCN 0x00004e0c295e-0x00004e0c79f5″

REDO RECORD – Thread:1 RBA: 0x000013.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0c2960 SUBSCN: 1 12/11/2014 09:20:14
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
descrip:”Thread 0001, Seq# 0000000020, SCN 0x00004e0c79f5-0xffffffffffff”

REDO RECORD – Thread:1 RBA: 0x000014.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0c79f7 SUBSCN: 1 12/11/2014 09:23:13
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
END OF DUMP REDO
Incident 35120409 created, dump file: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_35120409\erp_ora_548_i35120409.trc
ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], []

Error 607 in redo application callback
Dump of change vector:
TYP:0 CLS:32 AFN:3 DBA:0x00c0111a OBJ:4294967295 SCN:0x0000.4e0662ff SEQ: 2 OP:5.1
ktudb redo: siz: 208 spc: 1094 flg: 0x0012 seq: 0x91a4 rec: 0x3b
xid: 0x0008.01d.001511ce
ktubl redo: slt: 29 rci: 0 opc: 11.1 objn: 74 objd: 74 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00c0111a.91a4.39
prev ctl max cmt scn: 0x0000.4e065bc8 prev tx cmt scn: 0x0000.4e065be6
txn start scn: 0xffff.ffffffff logon user: 0 prev brb: 12587289 prev bcl: 0 BuExt idx: 0 flg2: 0
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
compat bit: 4 (post-11) padding: 0
op: L itl: xid: 0x000d.012.000346f7 uba: 0x00c01d8e.1899.2a
flg: C— lkc: 0 scn: 0x0000.4e0c7c3e
KDO Op code: URP row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x00400222 hdba: 0x00400221
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 8(0x8) flag: 0x2c lock: 0 ckix: 0
ncol: 10 nnew: 9 size: 0
Vector content:
col 1: [ 2] c1 02
col 2: [ 2] c1 02
col 3: [ 2] c5 15
col 4: [ 2] c1 02
col 5: [ 1] 80
col 6: [ 2] c3 02
col 7: [ 5] c4 06 4a 13 0b
col 8: [32]
2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d
2d 2d 2d 2d 2d 2d 2d
col 9: [ 1] 80
Block after image is corrupt:
buffer rdba: 0x00c0111a
scn: 0x0000.4e0662ff seq: 0x02 flg: 0x04 tail: 0x62ff0202
frmt: 0x02 chkval: 0xa54a type: 0x02=KTU UNDO BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000016B7EA000 to 0x000000016B7EC000
16B7EA000 0000A202 00C0111A 4E0662FF 04020000 [………b.N….]

ORA-00600: 内部的なエラコード。バラメタ: [4194]エラは前に何度も言った。
【Oracleデータリカバリ】 BBEDでORA-600[4193]とORA-600[4194]をリカバリした例
【Oracleデータリカバリ】ORA-600[4194]エラ一例

ORA-600[4194]内部エラはredo記録とロールバック記録がマッチしていないことによって引き起こされる。OracleがUndo record numberを検証するときにredo change とロールバックセグメントのundo record numberを比べる。二つには相違が現れたら。4194エラになる。そのエラargument[a][b]にはaはロールバックブロックに最大のundo record numberと意味していて、bはredoログに記録されたundo record numberと意味している。このようなエラの原因はロールバックセグメントあるいはredo logログファイルにエラによって引き起こされたものである。
ORA-00600[4194]エラに根本的な原因は redo記録とロールバックセグメントの間に(rollback/undo)一致していないから。ORACLEはundo記録を検証するときに、該当する変化はundoデータブロックの最大のundo記録に応用する必要がある。検証するときにトラブルが起こったら、ORA-00600[4194]になる。

ORA-600[4194]の二つの意味：
Arg [a] Maximum Undo record number in Undo block
Arg [b] Undo record number from Redo block

以上はtraceでトラブルが起こそうなデータブロックrdba: 0x00c0111a (3/4378)と検証できた。そのトラブルはEVENT、隠しバラメタあるいはBBEDを設定することによってリカバリできる。

ORA-00600 [KDSGRP1]エラが起こったら、例えば：

 

 

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []
Current SQL statement for this session:
create table SYSMAN.MGMT_METRICS_RAW_COPY as select * from SYSMAN.MGMT_METRICS_RAW

$cold_kdsgrp()+1456 call kgeasnmierr() 60000000000318D0 ?
9FFFFFFFBF3A11F8 ?
9FFFFFFFBF3A1208 ?
6000000000032D00 ?
C000000040E13740 ?
60000000000CAB08 ?
00001BD3A ?
kdsgnp()+832 call $cold_kdsgrp() 60000000000C74B0 ?
60000000000C6D38 ?
0003FFFFF ?
C000000219E58720 ?
kafger()+4288 call kdsgnp() 9FFFFFFFBF336E60 ?
000C07EED ?
9FFFFFFFBF336E7C ?
60000000000BA348 ?
C000000000004F25 ?
4000000002ED0F70 ?
0000182ED ?
qerixGetNonKeyCol() call kafger() 000000000 ?
+7344 9FFFFFFFFFFF22E0 ?
C0000002168BA718 ?
000000001 ? 000000001 ?
000000000 ? 000000000 ?
9FFFFFFFBF3DD228 ?
qerixFetchFastFullS call qerixGetNonKeyCol() C000000219E58720 ?
can()+23536 9FFFFFFFBF336518 ?
 

 

まずはBug 8771916 – OERI [kdsgrp1] during CR readをHITしたかを確認してください了。そのBUGを引き起こしたのはインデックスのはインディクスのキ探し出せる；このBUGもORA-00600 [KDSGRP1]の唯一の原因ではない。

 

保守的なアドバイスは以下の通り：

8771916パッチを応用した同時に、ROW CR特性_row_cr=FALSEを閉めることを考えてください。二つのインディクス”RowCR hits”/”RowCR attempts” を設定することによってその特性が閉めていたを確かめられる。

 

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

11.2.0.1後のバーションでORA-600 [KCRF_RESILVER_LOG_1]エラになるかもしれない。エラスタックを以下の通り：

 

—– Current SQL Statement for this session (sql_id=1h50ks4ncswfn) —–

ALTER DATABASE OPEN

—– Call Stack Trace —–

kgeasnmierr

kcrf_write_zeroblks

kcrfis

kcrfais

kcrfr_read_disk

kcrfr_read

kcrfrgv

kcratr_scan

kcratr

kctrec

kcvcrv

 

ORA-00600[kcrf_resilver_log_1]は起動することを失敗させる。これは公表されていないug 9056657: BOX REBOOT DURING UPGRADE CAUSED ORA-600 [KCRF_RESILVER_LOG_1]に関連している。

これを引き起こした原因はインスタンスが崩壊して、online redo logfileがなくしたから、ロールフォワードを失敗させる。そしてデータベースをrestoreして、トラブルが起こる時点前にリカバリできる。

 

以下の情報を収集してください：

 

 

set pagesize 20000

set linesize 180

set pause off

set serveroutput on

set feedback on

set echo on

set numformat 999999999999999

select HXFIL File_num,substr(HXFNM,1,60) File_name,FHTYP Type,HXERR Validity,FHSCN SCN, FHTNM TABLESPACE_NAME,FHSTA status ,FHAFS,FHRBA_SEQ Sequence from X$KCVFH;

select fhrba_seq, count(*) from x$kcvfh group by fhrba_seq order by fhrba_seq;

 

あるアーカイブもバックアップもないテストデータベースを強制的に起動した。前にアクティブログファイル損害もあったから、隠しバラメタしか起動できない。

_allow_resetlogs_corruption= TRUE

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

まずはORA-600[2662]エラの場合:

Mon Aug 23 09:37:00 2010

Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_852096.trc:

ORA-00600: internal error code, arguments: [2662], [0], [130131504], [0], [130254136], [4264285], [], []

Mon Aug 23 09:37:02 2010

Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_852096.trc:

ORA-00600: internal error code, arguments: [2662], [0], [130131506], [0], [130254136], [4264285], [], []

ORA-600 [2662] “Block SCN is ahead of Current SCN”エラは今のデータブロックのSCNがcurrent SCNを上回っていると意味している。バックグラウンドプロセスあるいはサビースプロセスはUGAのdependent　SCNとデータベースに既存するSCNと比べるから、ORA-600 [2662]エラになる。もしサビースプロセスでこのエラが起こったら、そのプロセスは中止される。バックグラウンドプロセスでこのエラが起こったら、インスタンスをCRASHさせる。
ORA-600 [2662]エラの原因は主に以下の通り:
1.隠しバラメタ_ALLOW_RESETLOGS_CORRUPTIONを運用したあと、resetlogs形式でデータベースを起動する；この場合に2662エラが起こったら、原因はロールフォワードが完成していないから、コントローラーファイルのSCNがデータブロックのSCNより遅くなった。
2.ハードウェアトラブルでデータベースがコントローラーファイルとオンラインログファイルを書けない。
3.トラブルが起こった一部のデータベースをリカバリする
4.コントローラーファイルをリカバリしたが、recover database using backup controlfileを使っていない。
5.データベースがcrashしたあとに_DISABLE_LOGGINGの隠しバラメタを設定した
6.Parallel Server環境でDLMにトラブルが起こった。

そのエラの五つのバラメタの意味は以下の通り:
ARGUMENTS:
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [c] dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.

これらのケースでdependent SCNは130254136だが、今のSCNが130131506で差値が122630である；以上のアラームログで、データベース今のSCNは持続的に増やしている。2662エラになった場合に、データベースを再起動することを繰り返して、current SCNが持続的に増やしていることを確保していれば、2662エラがなくなる。もちろん、こんなばかなやり方を取らなくとも、10015トランザクションでデータベースのSCNを調整できる:

/* データベースがmount状態にいれば、10015トランザクションでscnを調整できる */

 

alter session  set events ‘10015 trace name adjust_scn level 1’;

 

/*ここで level 2..10などを設定する (level 1はデータベースを起動するたびにscnが1000kを増やす)*/

 

/* 10gのあるバーションは9iと違って、隠しバラメタ_allow_error_simulationを設定する必要がある。 */

 

SQL> select * from v$version;

BANNER

—————————————————————-

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bi

PL/SQL Release 10.2.0.4.0 – Production

CORE    10.2.0.4.0      Production

TNS for Linux: Version 10.2.0.4.0 – Production

NLSRTL Version 10.2.0.4.0 – Production

 

SQL> col current_scn format 999,999,999,999

 

SQL> select current_scn from v$database;

CURRENT_SCN

———–

1141408

 

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area 1653518336 bytes

Fixed Size                  2213896 bytes

Variable Size             989857784 bytes

Database Buffers          654311424 bytes

Redo Buffers                7135232 bytes

Database mounted.

 

SQL> alter session set events ‘10015 trace name adjust_scn level 1’;

Session altered.

 

SQL> alter database open;

Database altered.

 

SQL>  select current_scn from v$database;

CURRENT_SCN

———–

1142031

 

/* current_scnが大量に増やしていないことを見られる。10.2.0.4でディフォルトは10015 adjust_scnを起こせない */

 

SQL>  alter system set “_allow_error_simulation”=true scope=spfile;

System altered.

 

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

 

SQL> startup mount;

ORACLE instance started.

Total System Global Area 1653518336 bytes

Fixed Size                  2213896 bytes

Variable Size             989857784 bytes

Database Buffers          654311424 bytes

Redo Buffers                7135232 bytes

Database mounted.

 

SQL> alter session set events ‘10015 trace name adjust_scn level 1′;

Session altered.

 

SQL> alter database open;

Database altered.

 

SQL>select current_scn from v$database;

CURRENT_SCN

—————-

1,073,741,980

ユーザーがデータベースを再起動することを繰り返すことで今のSCNをdependent SCNの127037138に高めた；これでデータベースを原以为这样就可以打开数据库了，谁知道又出现了一下错误:

Wed Aug 25 07:43:53 2010

Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_929958.trc:

ORA-00600: internal error code, arguments: [4000], [8], [], [], [], [], [], []

Wed Aug 25 07:43:53 2010

Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_929958.trc:

ORA-00704: bootstrap process failure

ORA-00704: bootstrap process failure

ORA-00600: internal error code, arguments: [4000], [8], [], [], [], [], [], []

Wed Aug 25 07:43:53 2010

Error 704 happened during db open, shutting down database

BootstrapはブートストラッププロセスでORA-600 [4000]エラが起こった。そのエラはOracleがデータファイルを読み取るときに（主にundo$ベーステーブル)記録されたUSNが該当するロールバックセグメント失敗したことで引き起こした。隠しバラメタ_corrupted_rollback_segmentsを設定することによって、このエラを避けられて、データベースを強制的に起動できる。そのArgument[a]は読み取りが失敗したUSN(undo segment number)と意味しているが実際にトラブルがあるロールバックセグメントはこれだけではない。

/* stringsツールでsystemテーブルスペースから各ロールバックセグメントの名前を見つけ出せる。*/

$strings system.dbf |grep _SYSSMU|less

_SYSSMU1$

_SYSSMU2$

_SYSSMU3$

_SYSSMU4$

_SYSSMU5$

_SYSSMU6$

_SYSSMU7$

_SYSSMU8$

_SYSSMU9$

………

alter system set “_corrupted_rollback_segments”='(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$, _SYSSMU5$, _SYSSMU6$, _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$, _SYSSMU11$, _SYSSMU12$)’ scope=spfile;

System altered.

 

/* たとえ_corrupted_rollback_segments隠しバラメタを設定したところで、4000エラも現れるかもしれない。10513トランザクションを加えて、データベースを再起動することを繰り返してください。*/

 

SQL> alter system set event=’10513 trace name context forever,level 2′ scope=spfile;

System altered.

 

/* 再び4000エラになった */

Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_1016014.trc:

ORA-00600: internal error code, arguments: [4000], [8], [], [], [], [], [], []

Thu Aug 26 09:43:39 2010

Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_1016014.trc:

ORA-00704: bootstrap process failure

ORA-00704: bootstrap process failure

ORA-00600: internal error code, arguments: [4000], [8], [], [], [], [], [], []

Thu Aug 26 09:43:39 2010

Error 704 happened during db open, shutting down database

 

/* 再起動したら4000エラが現れていない。 * /

再起動したら4000エラが現れていないが、ディクショナリー検証段階でOracleはデータファイル227が今のincarnationとマッチしていないと見なされている:

Thu Aug 26 11:13:22 2010

Dictionary check beginning

Thu Aug 26 09:46:00 2010

Errors in file /oracle/QAS/saptrace/usertrace/qas_ora_897162.trc:

ORA-01177: data file does not match dictionary – probably old incarnation

ORA-01110: data file 227: ‘/oracle/QAS/sapdata2/qas_192/qas.data196’

Error 1177 happened during db open, shutting down database

USER: terminating instance due to error 1177

Instance terminated by USER, pid = 897162

ORA-01177の原因は主に二つがある:
1.データディクショナリーがエラになり，227ファイルに該当するincarnation情報は正確ではない。
2.前回のresetlogs openプロセスで、227号ファイルヘッダがある原因で正確にincarnation情報をアップグレードしていない。

このような場合に対して、データファイルのデータをリカバリしたい場合に、人工的にデータディクショナリーあるいはファイルヘッダを修正するしかない。
そしてコントロールファイルを再構造することで済ませた:

CREATE CONTROLFILE REUSE DATABASE “QAS” RESETLOGS  NOARCHIVELOG

—  SET STANDBY TO MAXIMIZE PERFORMANCE

MAXLOGFILES 255

MAXLOGMEMBERS 3

MAXDATAFILES 254

MAXINSTANCES 50

MAXLOGHISTORY 36302

LOGFILE

GROUP 1 (

‘/oracle/QAS/redolog/redolog11A.dbf’,

‘/oracle/QAS/redolog/redolog11B.dbf’

) SIZE 500M,

GROUP 2 (

‘/oracle/QAS/redolog/redolog12A.dbf’,

‘/oracle/QAS/redolog/redolog12B.dbf’

) SIZE 500M

— STANDBY LOGFILE

DATAFILE

‘/oracle/QAS/sapdata1/system_1/system.data1’,

……..

‘/oracle/QAS/sapdata2/qas_192/qas.data195’

CHARACTER SET WE8DEC

Thu Aug 26 14:04:50 2010

Successful mount of redo thread 1, with mount id 2117500093

Thu Aug 26 14:04:50 2010

Completed: CREATE CONTROLFILE REUSE DATABASE “QAS” RESETLOGS

Thu Aug 26 14:05:05 2010

alter database mount

Thu Aug 26 14:05:05 2010

ORA-1100 signalled during: alter database mount…

Thu Aug 26 14:05:15 2010

alter database open resetlogs

RESETLOGS is being done without consistancy checks. This may result

in a corrupted database. The database should be recreated.

RESETLOGS after incomplete recovery UNTIL CHANGE 1125281471596

Resetting resetlogs activation ID 0 (0x0)

Online log 1 of thread 1 was previously cleared

Thu Aug 26 14:05:36 2010

Assigning activation ID 2117500093 (0x7e367cbd)

Thread 1 opened at log sequence 1

Current log# 2 seq# 1 mem# 0: /oracle/QAS/redolog/redolog12A.dbf

Current log# 2 seq# 1 mem# 1: /oracle/QAS/redolog/redolog12B.dbf

Successful open of redo thread 1

Thu Aug 26 14:05:36 2010

SMON: enabling cache recovery

Thu Aug 26 14:05:36 2010

Dictionary check beginning

Tablespace ‘PSAPTEMP’ #2 found in data dictionary,

but not in the controlfile. Adding to controlfile.

File #227 found in data dictionary but not in controlfile.

Creating OFFLINE file ‘MISSING00227’ in the controlfile.

This file can no longer be recovered so it must be dropped.

File #228 found in data dictionary but not in controlfile.

Creating OFFLINE file ‘MISSING00228’ in the controlfile.

This file can no longer be recovered so it must be dropped.

File #229 found in data dictionary but not in controlfile.

Creating OFFLINE file ‘MISSING00229’ in the controlfile.

This file can no longer be recovered so it must be dropped.

Dictionary check complete

Thu Aug 26 14:05:38 2010

SMON: enabling tx recovery

Thu Aug 26 14:05:38 2010

Database Characterset is WE8DEC

replication_dependency_tracking turned off (no async multimaster replication found)

Completed: alter database open resetlogs

 

一般的に、ORA-1578はデータブロックが物理的に壊されたと見なされている。エラ情報は以下の通り：

 

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

[oracle@oel8 dirdat]$ oerr ora 1578

01578, 00000, “ORACLE data block corrupted (file # %s, block # %s)”

// *Cause:  The data block indicated was corrupted, mostly due to software

//          errors.

// *Action: Try to restore the segment containing the block indicated. This

//          may involve dropping the segment and recreating it. If there

//          is a trace file, report the errors in it to your ORACLE

//          representative

 

SQL> select * from scott.emp;

select * from scott.emp

*

ERROR at line 1:

ORA-01578: ORACLE data block corrupted (file # 11, block # 34) ここのFILE#はRFNである

ORA-01110: data file 6:’/home/oracle/corrclass.dbf’   ここはAFNである

 

 

壊れたデータブロックractured Block：

 

Corrupt block relative dba: 0x0380e573 (file 14, block 58739)

Fractured block found during buffer read

Data in bad block –

type: 6 format: 2 rdba: 0x0380e573

last change scn: 0x0288.8e5a2f78 seq: 0x1 flg: 0x04

consistency value in tail: 0x00780601

check value in block header: 0x8739, computed block checksum: 0x2f00

spare1: 0x0, spare2: 0x0, spare3: 0x0

***

Reread of rdba: 0x0380e573 (file 14, block 58739) found same corrupted data

あるいは誤った検証とchecksum

 

Corrupt block relative dba: 0x0380a58f (file 14, block 42383)

Bad check value found during buffer read

Data in bad block –

type: 6 format: 2 rdba: 0x0380a58f

last change scn: 0x0288.7784c5ee seq: 0x1 flg: 0x06

consistency value in tail: 0xc5ee0601

check value in block header: 0x68a7, computed block checksum: 0x2f00

spare1: 0x0, spare2: 0x0, spare3: 0x0

***

Reread of rdba: 0x0380a58f (file 14, block 42383) found same corrupted data

 

あるいは誤ったブロックヘッダ

 

Corrupt block relative dba: 0x0d805a89 (file 54, block 23177)

Bad header found during buffer read

Data in bad block –

type: 6 format: 2 rdba: 0x0d805b08

last change scn: 0x0692.86dc08e3 seq: 0x1 flg: 0x04

consistency value in tail: 0x08e30601

check value in block header: 0x2a6e, computed block checksum: 0x0

spare1: 0x0, spare2: 0x0, spare3: 0x0

***

Reread of rdba: 0x0d805a89 (file 54, block 23177) found valid data

 

一部のORA-1578を引き起こす可能性があるBUGリストは以下の通り：

 

NB	Bug	Fixed	Description
	13804294	11.2.0.3.4, 11.2.0.3.BP07, 12.1.0.0	Internal errors, corruptions, using pipelined function whose rows raise exceptions
	11707302	11.2.0.2.3, 11.2.0.2.BP06, 11.2.0.3, 12.1.0.0	Corruption from ASM crash during rebalance diskgroup. Misplaced Blocks
	11659016	11.2.0.3, 12.1.0.0	ORA-1578 against recently create tablespace that once was encrypted
+	10209232	11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.0	ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM
*	10205230	11.2.0.1.6, 11.2.0.1.BP09, 11.2.0.2.2, 11.2.0.2.BP04, 11.2.0.3, 12.1.0.0	ORA-600 / corruption possible during shutdown in RAC
	9965568	12.1.0.0	Block dumps are not formatted if there is a chkval error
	9965085	11.2.0.3, 12.1.0.0	ORA-1578 / ORA-8103 Temporary table block corruption / space wastage from PDML
	9739664	11.2.0.2, 12.1.0.0	ORA-1578 / ORA-26040 MANUAL RECOVER marks block as corrupt NOLOGGING in even if LOGGING is enabled
+	9724970	11.2.0.1.BP08, 11.2.0.2.2, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.0	Block Corruption with PDML UPDATE. ORA_600 [4511] OERI[kdblkcheckerror] by block check
	9407198	11.2.0.3, 12.1.0.0	“LOG ERRORS INTO” can cause ORA-600 [kcb***] or hang scenarios
*	9406607	11.2.0.1.3, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.0	Corrupt blocks in 11.2 in table with unique key. OERI[kdBlkCheckError] by block check
*	8943287	11.2.0.2, 12.1.0.0	ORA-1578 corrupt block with AUTH SQL*Net strings
*	8898852	11.1.0.7.2, 11.2.0.1.1, 11.2.0.1.BP04, 11.2.0.2, 12.1.0.0	ORA-1578 Blocks misplaced in ASM when file created with compatible.asm < 11 and resized
	8885304	11.2.0.2, 12.1.0.0	ORA-7445 [ktu_format_nr] during RMAN CONVERT or Corrupt fractured block of UNDO tablespace datafile
*	8768374	10.2.0.5, 11.1.0.7.8, 11.2.0.1.BP11, 11.2.0.2, 12.1.0.0	RFS in Standby with a wrong location for archived log corrupting/overwriting database files when max_connections > 1
	8760225	11.2.0.2, 12.1.0.0	Auto Block Media Recovery reports ORA-1578 on first query
	8731617	11.2.0.3, 12.1.0.0	ORA-1578 from DESCRIBE or CTAS even if table not accessed / ORA-959 from DBMS_STATS
	8720802	10.2.0.5, 11.2.0.1.BP07, 11.2.0.2, 12.1.0.0	Add check for row piece pointing to itself (db_block_checking,dbv,rman,analyze)
	8493978	11.2.0.2, 12.1.0.0	Reserve file descriptors for datafile access
P	12330911	12.1	EXADATA LSI firmware for lost writes
	10025963	11.2.0.1.BP09, 11.2.0.2	Block corruption of LOB blocks with checksum value but block has checksum disabled
	8714541	11.2.0.2	ORA-1578 Corrupt Block in ASM with 0xbadfda7a after ASM block repair due to disk read error when ASM mirror is used
	13101288		ORA-600, corruption or check errors dropping a column in a OLTP compressed table
+	8354682	11.2.0.1	ORA-1578 – Blocks can be misplaced in ASM when there is IO error and AU > 1MB
+	8339404	10.2.0.5, 11.1.0.7.1, 11.2.0.1	ORA-1578 – Blocks can be misplaced in ASM during a REBALANCE
	8227257	11.2.0.1	ORA-1578 corruption found after media recovery on encrypted datafile
	7396077	10.2.0.5, 11.2.0.1	RMAN does not differentiate NOLOGGING corrupt blocks that produce ORA-1578/ORA-26040
	6471351	10.2.0.5, 11.1.0.7, 11.2.0.1	ORA-1578 / ORA-26040 due to NOLOGGING after recovery despite of FORCE LOGGING
	6674196	10.2.0.4, 10.2.0.5, 11.1.0.6	OERI / buffer cache corruption using ASM, OCFS or any ksfd client like ODM
	5515492	10.2.0.3, 11.1.0.6	ORA-1578 corruption with Block Misplaced during ASM rebalance after IO error
	5031712	10.2.0.4, 11.1.0.6	DBV enhanced to report NOLOGGING corrupt blocks with DBV-201 instead of DBV-200
+	4724358	11.1.0.6	ORA-27045 ORA-1578 ORA-27047 corruption caused by DBMS_LDAP
	4684074	10.2.0.2, 11.1.0.6	OERI:510 / block corruption (ORA-1578) with DB_BLOCK_CHECKING
	4655520	9.2.0.8, 10.2.0.3, 11.1.0.6	Block corrupted during write not noticed
	4411228	9.2.0.8, 10.2.0.3, 11.1.0.6	ORA-1578 Block misplaced with mixture of file system and RAW files
	4344935	10.2.0.4, 11.1.0.6	OERI from DML on TEMPORARY TABLE after autonomous TRUNCATE
	7381632	11.1.0.6	ORA-1578 Free corrupt blocks may not be reformatted when Flashback is enabled
	8976928	10.2.0.5	ORA-1578 caused by a former free corrupt block and remains unformatted
	8684999	10.2.0.5	ORA-1578 caused by a former free corrupt block and remains unformatted
+	3544995	9.2.0.6, 10.1.0.3, 10.2.0.1	LOB segments with “CACHE READS” generate no REDO even with the logging option
+	1281962	9.2.0.1	Media recovery after ORA-1578 on rollback can cause logical inconsistency
	589855	7.3.3.6, 7.3.4.1	ORA:1578 or ORA:8103 selecting invalid ROWID
	406863	7.3.3.4, 7.3.4.0, 8.0.3.0	ORA-1578 using PQ with heavy simultaneous INSERTS
P	707304	7.3.4.4	AIX: Resizing RAW datafile can corrupt a DB block
	603502	7.3.4.3, 8.0.4.4, 8.0.5.0	Possible Corruption if a session with LOOPBACK DB Links aborts.

 

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

 

 

ORA-00600[4511]エラを引き起こす条件はORACLEがある行ロックを検証するときに、そのロックが運用されていないと、エラになる。あるいはデータブロックに4095以上の行を格納したときに、エラになる。一般的に、32kbのブロックを使った場合に限って、これだけの行を格納できる。この場合に対して、workaroundでpctfreeをより高い数値に設定することによって、ブロックにあるデータ行数を制約できる。

ORA-00600[4511]エラはカーネルトランザクションによって処理される。このエラはプロセスを失敗させるあるブロックを壊せる。

 

ユーザーどこのテーブルにORA-00600[4511]エラを引き起こすトラブルデータブロックがあることを知っていたら、トラブルを検出するために、ANALYZE TABLE <テーブル名> VALIDATE STRUCTURE CASCADE;を実行してください。DBVツールでテーブルを含むデータファイルをスキャンしてもいい。

これもConsistent Readの一致性によるトラブルかもしれない。では、lter system flush buffer_cacheを実行することあるいはインスタンスを再起動することもこのトラブルを避けられる。

 

ORA-00600[4511]に関連するBUG 情報：

9724970 11.2.0.1.BP08, 11.2.0.2.2, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.1 Block Corruption with PDML UPDATE. ORA_600 [4511] OERI[kdblkcheckerror] by block check

4000840 9.2.0.7, 10.1.0.4, 10.2.0.1 Update of a row with more than 255 columns can cause block corruption

 

プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com

 

ORA-600[4194]内部的なエラはredo記録とロールバック記録が一致していないから引き起こしたOracleがUndo record numberを検証するときに、redo changeとロールバックセグメントのundo record numberを比べる。相違が現れたら4194エラになる。そのエラargument[a][b]に，aはロールバックで最大のundo record numberと意味していて、bはredoログで記録されたundo record numberと意味している。このエラはロールバックセグメントあるいはredo logログファイルのエラで引き起こしている。

ORA-00600[4194]エラの根本的な原因は redo記録とロールバックセグメント(rollback/undo)記録の間で一致していないから。ORACLEがundo記録を検証するときに、記録するときに該当する変化をundoデータブロックの最大undo記録に応用する。この場合にエラになるとORA-00600[4194]と報告する。

 

 

 

ORA-600[2662]あるいはORA-600[4000]エラの場合に、データベースを起動できなくなるが。このエラはロールフォワードするときにめったり現れないから、データベースを起動できる。データベースを起動したら、smonはトランザクションリカバリを実行することあるいはロールバックセグメントの管理することによってこのエラになるかもしれない。

 

ORA-600[4194]二つの意味：

Arg [a] Maximum Undo record number in Undo block
Arg [b] Undo record number from Redo block

 

このORA-600[4194] エラはORACLEカーネルに属して、cache層からトランザクションundoに処理される。プロセスが失敗するあるいはブロックが壊れるかもしれない

 

bug は以下の通り：

 

8240762  10.2.0.5,
11.1.0.7.10,
11.2.0.1
Undo corruptions with ORA-600 [4193]/ORA-600 [4194] or ORA-600 [4137] /
SMON may spin to recover transaction

 

3210520 9.2.0.5, 10.1.0.2 OERI[kjccqmg:esm] / OERI[4194] / corruption possible in RAC

792610 8.0.6.0, 8.1.6.0 Rollback segment corruption

 

非ブートストラップオブジェクトnon-bootstrapに該当するundo記録を以下の方法を実行してください。関連するオブジェクトはbootstrapシステムオブジェクトの場合に、人工的にbbedでリカバリしてください。うまくいかない場合に私たちに連絡してください。

 

 

 

エラ記録を見てください：

 

 

 

Thu Aug 26 18:58:50 2010

Errors in file /s01/10gdb/admin/YOUYUS/bdump/youyus_smon_6587.trc:

ORA-01595: error freeing extent (3) of rollback segment (4))

ORA-00600: internal error code, arguments: [4194], [53], [41], [], [], [], [], []

Thu Aug 26 18:58:50 2010

…………..

Errors in file /s01/10gdb/admin/YOUYUS/bdump/youyus_j000_6630.trc:

ORA-00354: corrupt redo log block header

ORA-00353: log corruption near block 2 change 1617922 time 08/26/2010 18:35:39

ORA-00334: archived log: ‘/s01/10gdb/flash_recovery_area/YOUYUS/onlinelog/o1_mf_3_65psr4on_.log’

Thu Aug 26 19:00:31 2010

Errors in file /s01/10gdb/admin/YOUYUS/bdump/youyus_j000_6630.trc:

ORA-00600: internal error code, arguments: [4194], [53], [41], [], [], [], [], []

Thu Aug 26 19:00:34 2010

Errors in file /s01/10gdb/admin/YOUYUS/bdump/youyus_j000_6630.trc:

ORA-00354: corrupt redo log block header

ORA-00353: log corruption near block 2 change 1617922 time 08/26/2010 18:35:39

ORA-00334: archived log: ‘/s01/10gdb/flash_recovery_area/YOUYUS/onlinelog/o1_mf_3_65psr4on_.log’

ORA-00600: internal error code, arguments: [4194], [53], [41], [], [], [], [], []

Thu Aug 26 19:00:35 2010

Errors in file /s01/10gdb/admin/YOUYUS/bdump/youyus_j000_6630.trc:

ORA-00354: corrupt redo log block header

ORA-00353: log corruption near block 2 change 1617922 time 08/26/2010 18:35:39

ORA-00334: archived log: ‘/s01/10gdb/flash_recovery_area/YOUYUS/onlinelog/o1_mf_3_65psr4on_.log’

 

ORA-00600: internal error code, arguments: [4194], [53], [41], [], [], [], [], []

 

 

 

ORA-600[4194]エラのせいでデータベースを起動できない場合に、以下のトランザクションを設定してください：

 

 

SQL> alter system set event=’10513 trace name context forever,level 2 : 10512 trace name context forever,level 1: 10511 trace name context forever,level 2: 10510 trace name context forever,level 1′ scope=spfile;

System altered.

 

/* 10513トランザクションはSMONがデータベースを起動した後にトランザクションリカバリすることを阻止できる。(transaction recovery) */

/* 10512トランザクションはSMON shrink rollback segment */を阻止する

/* 10511トランザクションはSMON check to cleanup undo dictionary */を阻止する

/* 10500トランザクションはSMON check to offline pending offline rollback segment */を阻止する

 

SQL> alter system set undo_management=MANUAL scope=spfile;

System altered.

 

SQL> shutdown immediate;

ORA-03113: end-of-file on communication channel

 

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area 2634022912 bytes

Fixed Size                  2086288 bytes

Variable Size            2382367344 bytes

Database Buffers          234881024 bytes

Redo Buffers               14688256 bytes

Database mounted.

SQL> alter database open;

 

Database altered.

 

SQL>  create undo tablespace undoc datafile size 300M;

 

SQL> alter system set undo_management=AUTO scope=spfile;

System altered.

 

SQL>  alter system set undo_tablespace=undoc scope=spfile;

System altered.

 

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area 2634022912 bytes

Fixed Size                  2086288 bytes

Variable Size            2382367344 bytes

Database Buffers          234881024 bytes

Redo Buffers               14688256 bytes

Database mounted.

 

SQL> alter database open;

Database altered.

 

/* undoテーブルスペースを再構造することで、一部の4194エラを避けられるが、すべてのエラを避けられるわけではない */

 

/* このリポジトリはいつでもcrashになるから、データを新たなデータベースにエクスポートしてください * /

 

/* この場合のdirect方法で一部の予想外のエラを避けられる。 */

 

[maclean@rh2 dump]$ exp maclean/maclean file=full_maclean.dmp owner=maclean  direct=y statistics=none

Export: Release 10.2.0.4.0 – Production on Thu Aug 26 21:18:40 2010

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Export done in ZHS16GBK character set and UTF8 NCHAR character set

 

About to export specified users …

. exporting pre-schema procedural objects and actions

. exporting foreign function library names for user MACLEAN

. exporting PUBLIC type synonyms

. exporting private type synonyms

. exporting object type definitions for user MACLEAN

About to export MACLEAN’s objects …

. exporting database links

. exporting sequence numbers

. exporting cluster definitions

. about to export MACLEAN’s tables via Direct Path …

Table SYS_EXPORT_TABLE_01 will be exported in conventional path.

. . exporting table            SYS_EXPORT_TABLE_01        256 rows exported

Table SYS_EXPORT_TABLE_02 will be exported in conventional path.

. . exporting table            SYS_EXPORT_TABLE_02        257 rows exported

Table SYS_EXPORT_TABLE_03 will be exported in conventional path.

…………..

exporting refresh groups and children

. exporting dimensions

. exporting post-schema procedural objects and actions

. exporting statistics

Export terminated successfully with warnings.

 

/* we are lucky! */