ORACLEデータベース によくあるエラ の解決策

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

前に研究したdulはディスクを識別できない。そのときに、ある過ちを犯した、普通の環境（非exadata環境）はホストにディスクをスキャンする。Exadataのホストにディスクをスキャンしたが、ダメだった。具体的には以下を参考してください：

Exadataで、なぜ DULと ODUがASMデータベースのデータを読み取れないが、Kfedなら読み取れるか？

今日はexadataのストレージノード（cellノード）に配置したが、dulもoduもディスクをスキャンできる。もし、またexadataでoracleデータベースが壊されたときに、わたしに連絡してくださいO(∩_∩)O
具体的なテストは以下の通り：

[root@dm01cel01 lunar]# ./dul
 
Data UnLoader: 10.2.0.6.5 - Internal Only - on Tue Jun 23 20:30:37 2015
with 64-bit io functions
 
Copyright (c) 1994 2015 Bernard van Duijnen All rights reserved.
 
 Strictly Oracle Internal Use Only
 
 
DUL: Warning: Could not open parameter file 
DUL: Warning: Compatible is set to 10 Values can be 6|7|8|9|10
DUL: Warning: no parameter file means no logfile
 
DUL: Warning: block 0 is not a disk header block
DUL: Warning: ASM Block type 32 not handled yet
...................
DUL>ディスクスキャン
 
............
DUL: Error: INCSEQ mismatch[8388877!=427426078]
DUL: Error: While processing unknown file unknown block
offset 33605120 possible block of size 512
DUL: Error: INCSEQ mismatch[8388892!=23134477]
DUL: Error: While processing unknown file unknown block
DUL: Error: block trailer mismatch found 0X0080011C expect 0X0A611C80
DUL: Error: checksum should be unused: 0x0a64
DUL: Error: While processing unknown file unknown block
DUL: Error: block trailer mismatch found 0X0080011B expect 0X02540C80
 
............
 
DUL: Error: block trailer mismatch found 0X00800888 expect 0X021B0D80
DUL: Error: checksum should be unused: 0x0229
DUL: Error: While processing unknown file unknown block
DUL: Error: INCSEQ mismatch[8390800!=961087622]
DUL: Error: While processing unknown file unknown block
Found file   2 block 88576 type 32 offs 46137344 delta 69398953984
extent of 512 blocks
Found file   1 block 102400 type 6 offs 50331648 delta 35148267520
extent of 473 blocks
Found file   2 block 98816 type 32 offs 54525952 delta 69474451456
extent of 512 blocks
Found file   2 block 107008 type 32 offs 58720256 delta 69537366016
extent of 512 blocks
Found file   2 block 111104 type 32 offs 62914560 delta 69566726144
extent of 512 blocks
Found file   2 block 125440 type 32 offs 67108864 delta 69679972352
extent of 512 blocks
Found file 352 block  7168 type 6 offs 71303168 delta 12094615322624
extent of 512 blocks
Found file 352 block 25600 type 6 offs 75497472 delta 12094762123264
extent of 512 blocks
Found file 352 block 44032 type 32 offs 79691776 delta 12094908923904
extent of 512 blocks
Found file 352 block 46592 type 6 offs 83886080 delta 12094925701120
extent of 512 blocks
Found file 352 block 58880 type 6 offs 88080384 delta 12095022170112
extent of 512 blocks
Found file 352 block 62464 type 32 offs 92274688 delta 12095047335936
extent of 512 blocks
Found file 352 block 66048 type 6 offs 96468992 delta 12095072501760
extent of 512 blocks
Found file 352 block 78848 type 32 offs 100663296 delta 12095173165056
extent of 512 blocks
Found file 352 block 80896 type 6 offs 104857600 delta 12095185747968
extent of 512 blocks
Found file 352 block 87552 type 6 offs 109051904 delta 12095236079616
extent of 512 blocks
Found file 352 block 89600 type 6 offs 113246208 delta 12095248662528
extent of 512 blocks
Found file 352 block 98304 type 6 offs 117440512 delta 12095315771392
extent of 512 blocks
Found file 352 block 99328 type 6 offs 121634816 delta 12095319965696
 
Found file 381 block 2410496 type 6 offs 54836330496 delta 13055970770944
extent of 512 blocks
Found file 381 block 2422272 type 32 offs 54840524800 delta 13056063045632
^C
[root@dm01cel01 lunar]# 

ここでcontrol+Cで中止したが、ディスクが大きすぎて、スキャン時間も長すぎた。上の情報はスキャンできると証明した。
normal externalについて、また後日で。
ファイルスキャンは以下の通り：

[root@dm01cel01 lunar]# ll
total 3172
-rw-r--r-- 1 root      root      71 Jun 23 20:30 control.dul
-rwxrwxr-x 1 celladmin 1000 1101896 May  5 00:14 dul
-rw-r--r-- 1 root      root  487424 Jun 23 20:36 IDX_DATA1.dat
[root@dm01cel01 lunar]# head IDX_DATA1.dat
D /dev/sdc
B 46137344 8477184 1 6687
T 46145536 8477185 7 6687
T 46202880 8477192 8 6643
T 46268416 8477200 8 6649
T 46333952 8477208 8 6651
T 46399488 8477216 8 6657
T 46465024 8477224 8 6653
T 46530560 8477232 8 6655
T 46596096 8477240 8 6687
[root@dm01cel01 lunar]#

ORACLEデータベース によくあるエラ の解決策

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

1988年に、OracleがOracle V6をリリースした。このバーションに、Oracleはホットバックアップを導入した。同時に、SCN、48位ストレージの文法はコードに使えなくなった。12cまで使い続けた。（12cに八つのバイトでＳＣＮをストレージする）。OracleのＳＣＮは48位で表したから、最大値がは２の48乗に超えられない。
Oracleは48位のＳＣＮが５００年も使い続けるために、ＳＣＮを制約した。秒ごとにＳＣＮの最大増速は16Ｋに超えられない。Oracleは1988年1月1日0点0分0秒を基準時間として、既存する秒を16Ｋに掛ける。つまり、既存するＳＣＮの最大値はSCN HEADROOMである。
それで、SCN最大値の計算式は以下の通り：
(今の時間-19880101 000000)*16384–(current_scn)その中 16384はSCNの内部増速は16kで、これはコードの制約である。
この制約は11.2.0.2バーションの前に、scn の最大の伸び率は16k,在11.2.0.2版本开始，为32k。
この行は以下のようなバラメタ_max_reasonable_scn_rateによって、コントロールされる：

SQL> @paras
Enter value for paras: scn
old   6: AND x.ksppinm LIKE '%&paras%'
new   6: AND x.ksppinm LIKE '%scn%'
 
NAME                                               VALUE                DESCRIB
-------------------------------------------------- -------------------- ------------------------------------------------------------
。。。。。。。
_external_scn_rejection_threshold_hours            24                   Lag in hours between max allowed SCN and an external SCN
_max_reasonable_scn_rate                           32768                Max reasonable SCN rate
。。。。。
 
17 rows selected.
 
SQL> 

11.2でOracleはSCNの各秒の最大増速を16Kから32Kに増やして、SCN HEADROOMトラブルがあるシステムがその故障を別のシステムに伝えないために、しきい値も追加した。
この修正は以下のバッチに含んでいる：

もしＳＣＮが突然増やしたら、alertに以下のようなアラームが現れる：

それで、以上のようなバッチを追加したら、前のバラメタでＳＣＮを修正することができなくなった。

そして、データベースに一部の異常的なエラが現れる。ＳＣＮをふさわしい数値に変更する必要がある。例えば、一部のよくあるエラはデータベースに一部のブロックがデータベースＳＣＮが一致していない。あるいは一部のundo$を持っているデータベースを起動するときに、失敗する：
ORA-600 [2256]
ORA-600 [2662]
ORA-600 [4000]
ORA-600 [kcsadjn1]

この前に、バラメタでＳＣＮを修正した。例えば：
event=”10015 trace name adjust_scn level x” あるいは _minimum_giga_scn バラメタを使う。
前に言っていたとおり、前のバッチとバーションを利用したあと、使えなくなった。この場合に、以下のような方法を利用してください：
1，bbed直に修正（場合によってめんどくさくなる場合もある。例えば、修正する必要があるファイルが多い場合である）
2，ORACDEBUG で kcsgscnを修正する
3，制御ファイルを修正する
ここで、ORACDEBUG で kcsgscnを修正するという方法をテストする。
注意： 違ったENDIANとワード長と違っている。例えば、AIXではWRAP SCNが前にあって、BASE SCNが後ろにある。Linuxの場合はBASE SCNが前にあって、WRAP SCNが後ろにあるというフォーマットである。

今のデータベースのSCN

[oracle@lunar ~]$ ss
 
SQL*Plus: Release 11.2.0.4.0 Production on Tue Aug 5 06:16:39 2014
 
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
 
 
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
 
SQL> 
SQL> select checkpoint_change#,to_char(checkpoint_change#,'XXXXXXXXXXXXXXXXX')  from v$database;
 
CHECKPOINT_CHANGE# TO_CHAR(CHECKPOINT
------------------ ------------------
           1723797             1A4D95
 
SQL>


ここで、今のデータベースSCNが1723797で、１００万を増やせば、2723797になる。




SQL> oradebug setmypid
Statement processed.
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000
SQL> select checkpoint_change#,to_char(checkpoint_change#,'XXXXXXXXXXXXXXXXX')  from v$database;
 
CHECKPOINT_CHANGE# TO_CHAR(CHECKPOINT
------------------ ------------------
           1723797             1A4D95
 
SQL>



データベースがmount状態だから、ここで見られるkcsgscn_のSCNの数値が0である。
次に2723797に修正して、計算する：


SQL> select to_char(2723797,'XXXXXXXXXXXXXXXX') from dual;
 
TO_CHAR(2723797,'
-----------------
           298FD5
 
SQL> oradebug setmypid
Statement processed.
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000
SQL> oradebug poke 0x06001AE70 8 0x0000000000298FD5 
BEFORE: [06001AE70, 06001AE78) = 00000000 00000000
AFTER:  [06001AE70, 06001AE78) = 00298FD5 00000000
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [06001AE70, 06001AEA0) = 00298FD5 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 6001AB50 00000000
SQL> 
SQL> alter database  open;
 
Database altered.
 
SQL>  select checkpoint_change#,checkpoint_change#/1024/1024/1024 SCN_WARP  from v$database;
 
CHECKPOINT_CHANGE#   SCN_WARP
------------------ ----------
           2723798 .002536735
 
SQL> 


ここで2723797になった。

ORACLEデータベース によくあるエラ の解決策

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

このテストは前回のoradebug修正の後でＳＣＮを修正する。ここで使っているのはコントロールファイルＳＣＮと関連するフラグを修正するという方法である：

SQL> startup mount
ORACLE instance started.
 
Total System Global Area  626327552 bytes
Fixed Size                  2255832 bytes
Variable Size             184550440 bytes
Database Buffers          432013312 bytes
Redo Buffers                7507968 bytes
Database mounted.
SQL> select checkpoint_change#,to_char(checkpoint_change#,'XXXXXXXXXXXXXXXXX')  from v$database;
 
CHECKPOINT_CHANGE# TO_CHAR(CHECKPOINT
------------------ ------------------
           2726293             299995

このテストにＳＣＮを百万増やす。つまり、SCNを 2726293から 3726293に変更する。

SQL> select '3726293',to_char(3726293,'XXXXXXXXXXXXXXXXX')  from v$database;
 
'372629 TO_CHAR(3726293,'X
------- ------------------
3726293             38DBD5
 
SQL> 

今のコントロールファイルの位置を確認する：

SQL> show parameter control
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_file_record_keep_time        integer     7
control_files                        string      +DATA/lunars/control01.ctl, +D
                                                 ATA/lunars/control02.ctl
control_management_pack_access       string      DIAGNOSTIC+TUNING
SQL>

コントロールファイルをローカルに取り戻して修正する。プロセスは以下の通り：
まずはデータベースSCNを探し出す：
________________________________________

ＳＣＮと関連するフラグを修正する：

データベースshutdownして、修正できたコントロールファイルをASMにコピして、このコントロールファイルでデータベースを起動する：

ASMCMD> ls
CONTROLFILE/
DATAFILE/
ONLINELOG/
TEMPFILE/
control01.ctl
control02.ctl
lunar01.dbf
redo01.log
redo02.log
redo03.log
soe01.dbf
sysaux01.dbf
system01.dbf
temp01.dbf
undotbs01.dbf
users01.dbf
ASMCMD> rm control01.ctl
ASMCMD> rm control02.ctl
ASMCMD> cp /tmp/control01.dbf +DATA/lunars/control01.ctl
copying /tmp/control01.dbf -> +DATA/lunars/control01.ctl
ASMCMD> cp /tmp/control01.dbf +DATA/lunars/control02.ctl
copying /tmp/control01.dbf -> +DATA/lunars/control02.ctl
ASMCMD>

データベースをMountして、データベースＳＣＮを確認する：

SQL> startup mount
ORACLE instance started.
Total System Global Area  626327552 bytes
Fixed Size                  2255832 bytes
Variable Size             184550440 bytes
Database Buffers          432013312 bytes
Redo Buffers                7507968 bytes
Database mounted.
SQL> select checkpoint_change#,to_char(checkpoint_change#,'XXXXXXXXXXXXXXXXX')  from v$database;
CHECKPOINT_CHANGE# TO_CHAR(CHECKPOINT
------------------ ------------------
           3726293             38DBD5
SQL> alter database open;
Database altered.
SQL> select checkpoint_change#,to_char(checkpoint_change#,'XXXXXXXXXXXXXXXXX')  from v$database;
CHECKPOINT_CHANGE# TO_CHAR(CHECKPOINT
------------------ ------------------
           3726296             38DBD8
SQL> 
SQL>

ORACLEデータベース によくあるエラ の解決策

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

一般的なOracleのbootstrap index（テーブルのインディクスと一部のコアオブジェクトをガイドする）も似たような方法で対応できる。例えば以下のクエリ文のI_OBJxxxxx。
.
テスト環境 11.2.0.3データベース：

[oracle@lunarpri ~]$ ss

SQL*Plus: Release 11.2.0.3.0 Production on Fri Mar 27 19:12:57 2015

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


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning and Real Application Testing options
SYS@lunar>col OBJECT_NAME for a30
SYS@lunar>select OWNER,OBJECT_NAME,OBJECT_TYPE,status,LAST_DDL_TIME from dba_objects where OBJECT_NAME like 'I_OBJ%';

OWNER                          OBJECT_NAME                    OBJECT_TYPE         STATUS  LAST_DDL_
------------------------------ ------------------------------ ------------------- ------- ---------
SYS                            I_OBJ#                         INDEX               VALID   08-FEB-13
SYS                            I_OBJ5                         INDEX               VALID   08-FEB-13
SYS                            I_OBJ3                         INDEX               VALID   08-FEB-13
SYS                            I_OBJ1                         INDEX               VALID   08-FEB-13
SYS                            I_OBJ2                         INDEX               VALID   08-FEB-13
SYS                            I_OBJ4                         INDEX               VALID   08-FEB-13
SYS                            I_OBJAUTH1                     INDEX               VALID   08-FEB-13
SYS                            I_OBJAUTH2                     INDEX               VALID   08-FEB-13
SYS                            I_OBJ#_INTCOL#                 INDEX               VALID   08-FEB-13
SYS                            I_OBJTYPE                      INDEX               VALID   08-FEB-13

10 rows selected.

Elapsed: 00:00:00.06
SYS@lunar>

データベースで、bootstrap indexを操作出来ない、例えば：
あるbootstrapインディクスはupgradeモードで修正できなくなる：

SYS@lunar>alter index SYS.I_OBJ5 unusable
*
ERROR at line 1:
ORA-00701: object necessary for warmstarting database cannot be altered


Elapsed: 00:00:00.01
SYS@lunar>alter index SYS.I_OBJ3 unusable
*
ERROR at line 1:
ORA-00701: object necessary for warmstarting database cannot be altered


Elapsed: 00:00:00.02
SYS@lunar>alter index SYS.I_OBJ1 unusable
*
ERROR at line 1:
ORA-00701: object necessary for warmstarting database cannot be altered


Elapsed: 00:00:00.01
SYS@lunar>

アップグレードモードを起動できる。このモードでデータベースは自動的にsystem triggerを禁止する操作を増やす。
一部のbootstrageオブジェクトの操作を実行できる、例えば：

SYS@lunar>startup upgrade
ORACLE instance started.

Total System Global Area        626327552 bytes
Fixed Size                        2230952 bytes
Variable Size                   184550744 bytes
Database Buffers                432013312 bytes
Redo Buffers                      7532544 bytes
Database mounted.
Database opened.
SYS@lunar>
SYS@lunar>alter index SYS.I_OBJAUTH2 unusable;
alter index SYS.I_OBJ#_INTCOL# unusable;
alter index SYS.I_OBJTYPE unusable;

Index altered.

Elapsed: 00:00:00.04
SYS@lunar>alter index SYS.I_OBJ# unusable

Index altered.

Elapsed: 00:00:00.20
SYS@lunar>
Index altered.

Elapsed: 00:00:00.03
SYS@lunar>
Index altered.

Elapsed: 00:00:00.03
SYS@lunar> 

アップグレードモード自動追加のバラメタは以下の通り：

Fri Mar 27 19:21:48 2015
MMNL started with pid=16, OS id=15218
ALTER SYSTEM enable restricted session;
ALTER SYSTEM SET _system_trig_enabled=FALSE SCOPE=MEMORY;
Autotune of undo retention is turned off.
ALTER SYSTEM SET _undo_autotune=FALSE SCOPE=MEMORY;
ALTER SYSTEM SET undo_retention=900 SCOPE=MEMORY;
ALTER SYSTEM SET aq_tm_processes=0 SCOPE=MEMORY;
ALTER SYSTEM SET enable_ddl_logging=FALSE SCOPE=MEMORY;
Resource Manager disabled during database migration: plan '' not set
ALTER SYSTEM SET resource_manager_plan='' SCOPE=MEMORY;
ALTER SYSTEM SET recyclebin='OFF' DEFERRED SCOPE=MEMORY;
Resource Manager disabled during database migration
replication_dependency_tracking turned off (no async multimaster replication found)

ここで、データディクショナリーが破壊されたから、それについての機能も効かなくなった：

SYS@lunar>col OBJECT_NAME for a30
SYS@lunar>select OWNER,OBJECT_NAME,OBJECT_TYPE,status,LAST_DDL_TIME from dba_objects where OBJECT_NAME like 'I_OBJ%';
select OWNER,OBJECT_NAME,OBJECT_TYPE,status,LAST_DDL_TIME from dba_objects where OBJECT_NAME like 'I_OBJ%'
                                                               *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01502: index 'SYS.I_OBJ#_INTCOL#' or partition of such index is in unusable state


Elapsed: 00:00:00.20
SYS@lunar>

起動するときにORA-00604 ORA-04024エラになる:

SYS@lunar>startup
ORACLE instance started.

Total System Global Area        626327552 bytes
Fixed Size                        2230952 bytes
Variable Size                   184550744 bytes
Database Buffers                432013312 bytes
Redo Buffers                      7532544 bytes
Database mounted.
ORA-00604: error occurred at recursive SQL level 4
ORA-04024: self-deadlock detected while trying to mutex pin cursor 0x07EF125E8


SYS@lunar>

正常にデータベースをクロスするのもできない。なら、原因は一部のコアアーカイブSQLを実行するときにトラブルがあったと意味している。shutdown abortしかできない：

SYS@lunar>shutdown immediate
ORA-00604: error occurred at recursive SQL level 4
ORA-04024: self-deadlock detected while trying to mutex pin cursor 0x07EF125E8
SYS@lunar>shutdown abort 
ORACLE instance shut down
SYS@lunar>

アップグレードモードでデータベースを起動して、インディクスをリカバリする：.

SYS@lunar>startup upgrade
ORACLE instance started.

Total System Global Area        626327552 bytes
Fixed Size                        2230952 bytes
Variable Size                   184550744 bytes
Database Buffers                432013312 bytes
Redo Buffers                      7532544 bytes
Database mounted.
Database opened.
SYS@lunar>

SYS@lunar>show parameter NLS_LENGTH_SEMANTICS
ORA-00604: error occurred at recursive SQL level 1
ORA-01502: index 'SYS.I_OBJ#_INTCOL#' or partition of such index is in unusable state


SYS@lunar>

ミニアップグレードスクリプトを実行してリカバリする：

SYS@lunar>ALTER SESSION SET NLS_LENGTH_SEMANTICS = BYTE;

Session altered.

Elapsed: 00:00:00.00
SYS@lunar>@?/rdbms/admin/utlmmig.sql

View created.

Elapsed: 00:00:01.32

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.34

Commit complete.

Elapsed: 00:00:00.01

Table dropped.

Elapsed: 00:00:00.01

Table created.

Elapsed: 00:00:00.53

Index created.

Elapsed: 00:00:00.12

Index created.

Elapsed: 00:00:00.05

Index created.

Elapsed: 00:00:00.02

Index created.

Elapsed: 00:00:00.03

Index created.

Elapsed: 00:00:00.04

Table dropped.

Elapsed: 00:00:00.02

Table created.

Elapsed: 00:00:00.07

Index created.

Elapsed: 00:00:00.03

Index created.

Elapsed: 00:00:00.03

Table dropped.

Elapsed: 00:00:00.00

Table created.

Elapsed: 00:00:00.04

Table dropped.

Elapsed: 00:00:00.01

Table created.

Elapsed: 00:00:00.05
declare
*
ERROR at line 1:
ORA-01502: index 'SYS.I_OBJ#_INTCOL#' or partition of such index is in unusable state
ORA-06512: at line 13
ORA-06512: at line 137


Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning and Real Application Testing options
[oracle@lunarpri ~]$ 

ここでSYS.I_OBJ#_INTCOL#インディクスはunusableと見られる。アップグレードモードでリカバリできない。
けど10gのあと、このインディクスはevent 38003で禁止できる：

SYS@lunar>create pfile='/tmp/spfile.bak' from spfile;

File created.

Elapsed: 00:00:00.01
SYS@lunar>show parameter spfile 
ORA-00604: error occurred at recursive SQL level 1
ORA-01502: index 'SYS.I_OBJ#_INTCOL#' or partition of such index is in unusable state

SYS@lunar>shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@lunar>

[oracle@lunarpri ~]$ tail /tmp/spfile.bak 
*.db_recovery_file_dest_size=10485760000
*.deferred_segment_creation=FALSE
*.diagnostic_dest='/u01/app/oracle'
*.open_cursors=300
*.pga_aggregate_target=153092096
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=629145600
*.undo_tablespace='UNDOTBS1'
*.EVENT="38003 trace name context forever, level 10"
[oracle@lunarpri ~]$ 

SYS@lunar>startup pfile=/tmp/spfile.bak  upgrade
ORACLE instance started.

Total System Global Area        626327552 bytes
Fixed Size                        2230952 bytes
Variable Size                   184550744 bytes
Database Buffers                432013312 bytes
Redo Buffers                      7532544 bytes
Database mounted.
Database opened.
SYS@lunar>col OBJECT_NAME for a30
SYS@lunar>select OWNER,OBJECT_NAME,OBJECT_TYPE,status,LAST_DDL_TIME from dba_objects where OBJECT_NAME like 'I_OBJ%';
select OWNER,OBJECT_NAME,OBJECT_TYPE,status,LAST_DDL_TIME from dba_objects where OBJECT_NAME like 'I_OBJ%'
                                                               *
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01502: index 'SYS.I_OBJ#_INTCOL#' or partition of such index is in unusable state


Elapsed: 00:00:00.08
SYS@lunar>alter index SYS.I_OBJ#_INTCOL# rebuild;

Index altered.

Elapsed: 00:00:00.46
SYS@lunar>



ここで、壊されたインディクスをリカバリした。
そして、再び、ミニアップグレードスクリプトを実行する：
SYS@lunar>select OWNER,OBJECT_NAME,OBJECT_TYPE,status,LAST_DDL_TIME from dba_objects where OBJECT_NAME like 'I_OBJ%';

OWNER                          OBJECT_NAME                    OBJECT_TYPE         STATUS  LAST_DDL_
------------------------------ ------------------------------ ------------------- ------- ---------
SYS                            I_OBJ#                         INDEX               VALID   08-FEB-13
SYS                            I_OBJ5                         INDEX               VALID   08-FEB-13
SYS                            I_OBJ3                         INDEX               VALID   08-FEB-13
SYS                            I_OBJ1                         INDEX               VALID   08-FEB-13
SYS                            I_OBJ2                         INDEX               VALID   08-FEB-13
SYS                            I_OBJ4                         INDEX               VALID   08-FEB-13
SYS                            I_OBJAUTH1                     INDEX               VALID   27-MAR-15
SYS                            I_OBJAUTH2                     INDEX               VALID   27-MAR-15
SYS                            I_OBJ#_INTCOL#                 INDEX               VALID   27-MAR-15
SYS                            I_OBJTYPE                      INDEX               VALID   27-MAR-15
SYS                            I_OBJ_MIG1                     INDEX               VALID   27-MAR-15
SYS                            I_OBJ_MIG2                     INDEX               VALID   27-MAR-15
SYS                            I_OBJ_MIG3                     INDEX               VALID   27-MAR-15
SYS                            I_OBJ_MIG4                     INDEX               VALID   27-MAR-15
SYS                            I_OBJ_MIG5                     INDEX               VALID   27-MAR-15

15 rows selected.

Elapsed: 00:00:00.49
SYS@lunar>@?/rdbms/admin/utlmmig.sql

View created.

Elapsed: 00:00:00.69

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.07

Commit complete.

Elapsed: 00:00:00.00

Table dropped.

Elapsed: 00:00:00.28

Table created.

Elapsed: 00:00:00.08

Index created.

Elapsed: 00:00:00.09

Index created.

Elapsed: 00:00:00.03

Index created.

Elapsed: 00:00:00.02

Index created.

Elapsed: 00:00:00.03

Index created.

Elapsed: 00:00:00.03

Table dropped.

Elapsed: 00:00:00.12

Table created.

Elapsed: 00:00:00.08

Index created.

Elapsed: 00:00:00.02

Index created.

Elapsed: 00:00:00.03

Table dropped.

Elapsed: 00:00:00.08

Table created.

Elapsed: 00:00:00.03

Table dropped.

Elapsed: 00:00:00.06

Table created.

Elapsed: 00:00:00.03

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.20

PL/SQL procedure successfully completed.

Elapsed: 00:00:26.30

49 rows created.

Elapsed: 00:00:00.03

60 rows created.

Elapsed: 00:00:00.00

Commit complete.

Elapsed: 00:00:00.01

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.14

PL/SQL procedure successfully completed.

Elapsed: 00:00:11.16

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.09

10 rows deleted.

Elapsed: 00:00:00.03

Commit complete.

Elapsed: 00:00:00.00

10 rows created.

Elapsed: 00:00:00.01

Commit complete.

Elapsed: 00:00:00.00

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.82

        COUNT(*)
----------------
              60

Elapsed: 00:00:00.00

        COUNT(*)
----------------
              60

Elapsed: 00:00:00.00

        COUNT(*)
----------------
              60

Elapsed: 00:00:00.01

        COUNT(*)
----------------
              60

Elapsed: 00:00:00.01

        COUNT(*)
----------------
              60

Elapsed: 00:00:00.00

        COUNT(*)
----------------
              60

Elapsed: 00:00:00.00

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.15
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@lunar>

そして、データベースを起動する：
SYS@lunar>startup
ORACLE instance started.

Total System Global Area        626327552 bytes
Fixed Size                        2230952 bytes
Variable Size                   184550744 bytes
Database Buffers                432013312 bytes
Redo Buffers                      7532544 bytes
Database mounted.
Database opened.
SYS@lunar>
SYS@lunar>col OBJECT_NAME for a30
SYS@lunar>select OWNER,OBJECT_NAME,OBJECT_TYPE,status,LAST_DDL_TIME from dba_objects where OBJECT_NAME like 'I_OBJ%';

OWNER                          OBJECT_NAME                    OBJECT_TYPE         STATUS  LAST_DDL_
------------------------------ ------------------------------ ------------------- ------- ---------
SYS                            I_OBJ#                         INDEX               VALID   08-FEB-13
SYS                            I_OBJ_MIG1                     INDEX               VALID   08-FEB-13
SYS                            I_OBJ_MIG2                     INDEX               VALID   08-FEB-13
SYS                            I_OBJ_MIG3                     INDEX               VALID   08-FEB-13
SYS                            I_OBJ_MIG4                     INDEX               VALID   08-FEB-13
SYS                            I_OBJ_MIG5                     INDEX               VALID   08-FEB-13
SYS                            I_OBJAUTH1                     INDEX               VALID   27-MAR-15
SYS                            I_OBJAUTH2                     INDEX               VALID   27-MAR-15
SYS                            I_OBJ#_INTCOL#                 INDEX               VALID   27-MAR-15
SYS                            I_OBJTYPE                      INDEX               VALID   27-MAR-15
SYS                            I_OBJ1                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ2                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ3                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ4                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ5                         INDEX               VALID   27-MAR-15

15 rows selected.

Elapsed: 00:00:00.14
SYS@lunar>
初めて実行したミニアップグレードスクリプトを削除したのはエラによって、データベースに残された一時的なインディクスを削除する：
SYS@lunar>DROP INDEX SYS.I_OBJ_MIG1;

Index dropped.

Elapsed: 00:00:00.44
SYS@lunar>C/1/2          
  1* DROP INDEX SYS.I_OBJ_MIG2
SYS@lunar>/

Index dropped.

Elapsed: 00:00:00.06
SYS@lunar>C/2/3
  1* DROP INDEX SYS.I_OBJ_MIG3
SYS@lunar>/

Index dropped.

Elapsed: 00:00:00.05
SYS@lunar>C/3/4
  1* DROP INDEX SYS.I_OBJ_MIG4
SYS@lunar>/

Index dropped.

Elapsed: 00:00:00.08
SYS@lunar>C/4/5
  1* DROP INDEX SYS.I_OBJ_MIG5
SYS@lunar>/

Index dropped.

Elapsed: 00:00:00.05
SYS@lunar>
SYS@lunar>col OBJECT_NAME for a30
SYS@lunar>select OWNER,OBJECT_NAME,OBJECT_TYPE,status,LAST_DDL_TIME from dba_objects where OBJECT_NAME like 'I_OBJ%';

OWNER                          OBJECT_NAME                    OBJECT_TYPE         STATUS  LAST_DDL_
------------------------------ ------------------------------ ------------------- ------- ---------
SYS                            I_OBJ#                         INDEX               VALID   08-FEB-13
SYS                            I_OBJAUTH1                     INDEX               VALID   27-MAR-15
SYS                            I_OBJAUTH2                     INDEX               VALID   27-MAR-15
SYS                            I_OBJ#_INTCOL#                 INDEX               VALID   27-MAR-15
SYS                            I_OBJTYPE                      INDEX               VALID   27-MAR-15
SYS                            I_OBJ1                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ2                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ3                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ4                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ5                         INDEX               VALID   27-MAR-15

10 rows selected.

Elapsed: 00:00:00.07
SYS@lunar>shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@lunar>startup
ORACLE instance started.

Total System Global Area        626327552 bytes
Fixed Size                        2230952 bytes
Variable Size                   184550744 bytes
Database Buffers                432013312 bytes
Redo Buffers                      7532544 bytes
Database mounted.
Database opened.
SYS@lunar>
SYS@lunar>col OBJECT_NAME for a30
SYS@lunar>select OWNER,OBJECT_NAME,OBJECT_TYPE,status,LAST_DDL_TIME from dba_objects where OBJECT_NAME like 'I_OBJ%';

OWNER                          OBJECT_NAME                    OBJECT_TYPE         STATUS  LAST_DDL_
------------------------------ ------------------------------ ------------------- ------- ---------
SYS                            I_OBJ#                         INDEX               VALID   08-FEB-13
SYS                            I_OBJAUTH1                     INDEX               VALID   27-MAR-15
SYS                            I_OBJAUTH2                     INDEX               VALID   27-MAR-15
SYS                            I_OBJ#_INTCOL#                 INDEX               VALID   27-MAR-15
SYS                            I_OBJTYPE                      INDEX               VALID   27-MAR-15
SYS                            I_OBJ1                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ2                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ3                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ4                         INDEX               VALID   27-MAR-15
SYS                            I_OBJ5                         INDEX               VALID   27-MAR-15

10 rows selected.

Elapsed: 00:00:00.13
SYS@lunar>
ここで、完璧にリカバリした！

ORACLEデータベース によくあるエラ の解決策

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

データベースは企業のコアとして、データベースが壊れて、まともに運用できなければ、取り換えれない損害を及ぼして、データがなくすかもしれない。データベースに故障が起きれば、有効なバックアップもない場合に、我々こそ最後のディフェンスである。我々必ず最善を尽くして、データを救って、損害をできるだけ低めにする。私たちは元々Oracle会社のアフターサービスリカバリエンジニア（ACS）として、中国でも名を知られたプロリカバリチームである。何百回のリカバリ経験があって；修復できたバーションはORACLE 7.3、ORACLE 8/8I，ORACLE 9I、ORACLE 10G，ORACLE 11G及びORACLE 12Cで、プラットフォームはLinux、Windows、AIX、HP-UNIX、SOLARIなどもある。私たちが勤めさせたお客様はチベットから上海まで、黒龍江から海南まで、中国にあるすべてのところどころに満ちている。お客様の分類もいろいろ：医療機関、軍隊、政府、製造業者、チェーンコンビニ、社会福祉センター、医療保険、物流センター、インターネット、金融機関、病院、警察署など。どんなデータベース故障であっても、いくつのリカバリ会社も訪ねて、リカバリできなかったとしても、私たちがリカバリできる。私たちの技術力が全国一だという大袈裟なこととも言えないが、私たちがリカバリできなかったら、誰でもリカバリできるわけがないと言える。すべてのデータベースがリカバリ出来ない限り、コミットメントを果たせなかったら、何の料金も受け取らない。

もし、プロOracleリカバリ技術サポートが必要とすれば、私たちに連絡してください。
支持しているデータベースリカバリ内容はそれだけではない

1. 誤ったdrop table リカバリ
2. 誤ったdelete/update リカバリ
3. 誤ったtruncate tableリカバリ
4. systemファイルデータベースをなくしたリカバリ
5. asm ディスクがフォーマットされた
6. bootstarp$にオブジェクトテストが壊された
7. asmディスク損害、mountできなかった
8. オペレーションシステムが削除されたデータファイルリカバリ
9. データベースがundo損害/喪失によって起動出来ない
10. データベースが一部のデータブロック損害でまともに運用出来ない
11. データベースがORA-600エラによって起動できない
12. exp dmpファイル損害、データベースリカバリをインポートできない
13. データベースがコントロールファイル損害/喪失で起動できなくなった
14. データベースがredo損害/喪失で起動できなくなった
15. データベースがデータファイル損害/喪失で起動できなくなった
16. データベースがアーカイブをなくして、データファイルがオンラインできなくなった
17. データベースがデータベースエラoffline systemで起動できなくなった
18. データベースがオペレーションシステムが壊された、データファイルだけがリカバリできる。
19. データベースがストレージ壊されたせいで、データベースが起動できなくなった
20. expdp dmpファイル損害、データベースリカバリがインポートできない。Asmディスクがなくし、asmで正常に使えなくなった
21. データベースが誤ったresetlogs操作によって、リカバリが続けない
22. データベースは電源切れたなどの原因で起動できなくなった

以下は典型的なOracle故障リカバリ
system rollback異常リカバリ
ORA-00604 ORA-00607 ORA-00600[4194]

Thu Jul 26 13:21:11 2012
Recovery of Online Redo Log: Thread 1 Group 1 Seq 3994 Reading mem 0
  Mem# 0: /orasvr/orcl/redo01.log
Block recovery completed at rba 3994.5.16, scn 0.89979533
Thu Jul 26 13:21:11 2012
Errors in file /orasvr/admin/orcl/udump/orcl_ora_2865.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4194], [31], [2], [], [], [], [], []
Error 604 happened during db open, shutting down database
USER: terminating instance due to error 604
Instance terminated by USER, pid = 2865
ORA-1092 signalled during: ALTER DATABASE OPEN...

undo segment異常リカバリ
ORA-00704 ORA-00604 ORA-01555

Fri May  4 21:04:21 2012
select ctime, mtime, stime from obj$ where obj# = :1
Fri May  4 21:04:21 2012
Errors in file /oracle/admin/standdb/udump/perfdb_ora_1286288.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 40 with name "_SYSSMU40$" too small
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 1286288
ORA-1092 signalled during: alter database open resetlogs...
ORA-00704 ORA-00604 ORA-01173
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Feb 12 10:16:00 2014
SMON: enabling cache recovery
Errors in file H:\ORACLE\diag\rdbms\orcl\orcl\trace\orcl_ora_9232.trc:
ORA-01173: data dictionary indicates missing data file from system tablespace
Errors in file H:\ORACLE\diag\rdbms\orcl\orcl\trace\orcl_ora_9232.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01173: data dictionary indicates missing data file from system tablespace
Errors in file H:\ORACLE\diag\rdbms\orcl\orcl\trace\orcl_ora_9232.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01173: data dictionary indicates missing data file from system tablespace
Error 704 happened during db open, shutting down database
USER (ospid: 9232): terminating the instance due to error 704
Instance terminated by USER, pid = 9232
ORA-1092 signalled during: alter database open resetlogs...

obj$トランザクション異常リカバリ

ORA-00704 ORA-00600[4000]
Thu Feb 28 19:29:10 2013
SMON: enabling cache recovery
Thu Feb 28 19:29:11 2013
Errors in file /u1/PROD/prodora/db/tech_st/10.2.0/admin/PROD_oracle/udump/prod_ora_20989.trc:
ORA-00600: internal error code, arguments: [4000], [50], [], [], [], [], [], []
Thu Feb 28 19:29:13 2013
Incremental checkpoint up to RBA [0x1.3.0], current log tail at RBA [0x1.3.0]
Thu Feb 28 19:29:13 2013
Errors in file /u1/PROD/prodora/db/tech_st/10.2.0/admin/PROD_oracle/udump/prod_ora_20989.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [50], [], [], [], [], [], []
Thu Feb 28 19:29:13 2013
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 20989
ORA-1092 signalled during: ALTER DATABASE OPEN RESETLOGS...

IO異常リカバリ

ORA-01115 ORA-01110 ORA-27070 OSD-04016
Tue May 14 15:32:10 2013
Completed redo scan
 16941 redo blocks read, 1106 data blocks need recovery
Tue May 14 15:32:17 2013
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_p002_1472.trc:
ORA-01115: IO error reading block from file 6 (block # 81951)
ORA-01110: data file 6: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\orcl\YD_DATA01.DBF'
ORA-27070: async read/write failed
OSD-04016: Error queuing an asynchronous I/O request
O/S-Error: (OS 1117) The request could not be performed because of an I/O device error. 

よくあるエラ情報
テーブルあるいはインディクスベッドブロックに関連するエラ
ORA-01578/ORA-08103/ORA-01410/ORA-08102/ORA-600 kdsgrp1/ORA-600 qertbfetchbyrowid/ORA-01499/ORA-01555/ORA-26040/ORA-27046

コントロールファイル異常
ORA-00202/ORA-600 kccsbck_first/ORA-600 kccscf_1/ORA-600[kccsbck_first]/ORA-600 kccsbck_first/ORA-00205/ORA-600 kccpb_sanity_check_2

REDOあるいはUNDO異常
ORA-00376/ORA-00600 4097/ORA-01595/ORA-600 4194/ORA-600 4193/ORA-600 kcfrbd_3/ORA-00600 4137/ORA-01594/ORA-01555/ORA-00704/ORA-00604/ORA-00607/ORA-600 4000/ORA-00600[3705]/ORA-00316/ORA-00312/ORA-00327/ORA-01623/ORA-01624/ORA-01194/ORA-600 2662/ORA-00368/ORA-00353/ORA-00305/ORA-00340/ORA-00345/ORA-00354

いろんなORA-600エラ
ORA-600 4497/ORA-600 6947/ORA-600 2662/ORA-600 4194/ORA-600 4193/ORA-00600 4137/ORA-600 4000/ORA- 600 kcrf_resilver_log_1/ORA- 600 kdxlin:psno out of range/ORA-600 3020/ORA-600 kccpb_sanity_check_2/ORA-600 3705/ORA-600 kccscf_1/ORA-600 kghstack_free2/ORA-600 kcfrbd_3/ORA-600 ktbdchk1: bad dscn/ORA-600 2252/ORA-600 kcratr_nab_less_than_odr/ORA-600 kccsbck_first/ORA-600 kcratr1_lostwrt/ORA-600 ktspNextL1:4/ORA-600 13013/ORA-600 kdsgrp1/ORA-600 kmgs_parameter_update_timeout_1/ORA-600 kcbgtcr_1/ORA-600 kcbgtcr_1a/ORA-600 kcbgtcr_3/ORA-600 kcbgtcr_4/ORA-600 kcbgtcr_5/ORA-600 kcbgtcr_6/ORA-600 kcbgtcr_7/ORA-600 kcbgtcr_10/ORA-600 kcbgtcr_12/ORA-600 kcbgtcr_13/ORA-600 qertbfetchbyrowid/ORA-600 kmgs_parameter_update_timeout_1

より速くデータベース故障を評価するために、Oracle Database Recovery Checkでデータベースをチェックしてください。html, alertログを作成して、トレースファイルをわたしに送信してください。 。

データベースcurrent/active redo異常なエラ
redoファイル損害エラ
Started redo scan
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_2960.trc (incident=214262):
ORA-00353: ログ損害がブロック 12014 を 9743799889 に、時間を 12/05/2011 09:21:11に変更してください
ORA-00312: オンラインログ 3 スレッド 1: ‘R:\ORADATA\orcl\REDO03.LOG’
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_214262\orcl_ora_2960_i214262.trc
Aborting crash recovery due to error 368
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_2960.trc:
ORA-00368: redoログブロックのテストとエラ
ORA-00353: ログ損害がブロック 12014を 9743799889 に、時間を 12/05/2011 09:21:11に変更してください
ORA-00312: オンラインログ 3 スレッド 1: ‘R:\ORADATA\orcl\REDO03.LOG’
ORA-368 signalled during: ALTER DATABASE OPEN…

redoファイルが別のインスタンスに占められて、エラになった
Wed May 16 17:03:11 2012
Started redo scan
Wed May 16 17:03:11 2012
Errors in file /oracle/admin/odsdb/udump/odsdb1_ora_2040024.trc:
ORA-00305: log 14 of thread 1 inconsistent; belongs to another database
ORA-00312: online log 14 thread 1: ‘/dev/rods_redo1_2_2′
ORA-00305: log 14 of thread 1 inconsistent; belongs to another database
ORA-00312: online log 14 thread 1: ‘/dev/rods_redo1_2_1′
ORA-305 signalled during: ALTER DATABASE OPEN…

ストレージ全体エラ
Mon Oct 17 09:35:09 2011
Errors in file /oracle/app/admin/orcl/bdump/orcl2_lgwr_348814.trc:
ORA-00340: IO error processing online log 4 of thread 2
ORA-00345: redo log write error block 6732 count 2
ORA-00312: online log 4 thread 2: ‘/dev/rredo21′
ORA-27063: number of bytes read/written is incorrect
IBM AIX RISC System/6000 Error: 6: No such device or address
Additional information: -1
Additional information: 1024
Mon Oct 17 09:35:09 2011
LGWR: terminating instance due to error 340

ストレージIOエラ
Fri Feb 21 08:44:42 2014
Thread 1 advanced to log sequence 591 (LGWR switch)
Current log# 1 seq# 591 mem# 0: J:\ORADATA\ORCL\REDO01.LOG
Fri Feb 21 15:31:20 2014
Errors in file c:\oracle\product\10.2.0\admin\orcl\bdump\orcl_lgwr_10312.trc:
ORA-00316: log 1 of thread 1, type 286 in header is not log file
ORA-00312: online log 1 thread 1: ‘J:\ORADATA\ORCL\REDO01.LOG’

_disable_loggingバラメタを使う
Sat May 14 23:16:49 2005
Errors in file d:\oracle\admin\rman\bdump\rman_arc0_736.trc:
ORA-16038: log 3 sequence# 72 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 3 thread 1: ‘D:\ORACLE\ORADATA\RMAN\REDO03.LOG’

自分でうまくいかない場合に、私たちに連絡してください、プロなデータベース技術を提供できる：

1.データファイルをなくした(ORA-01157)
SQL> startup
ORACLE instance started.

Total System Global Area 260046848 bytes
Fixed Size 1266896 bytes
Variable Size 83888944 bytes
Database Buffers 167772160 bytes
Redo Buffers 7118848 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 4 – see DBWR trace file
ORA-01110: data file 4: ‘/u01/oracle/oradata/orcl/users01.dbf’
データファイルがなくした。対応策：
1).バックアップでデータをリカバリする
2).非undo,systemなら、そのファイルoffline して、データベースを起動する
3). Undoの場合にORA-00376エラになるかもしれない
4).もしsystem offlineなら、ORA-01147になるかもしれない

2. Redoをなくした(ORA-00313)
SQL> startup
ORACLE instance started.

Total System Global Area 260046848 bytes
Fixed Size 1266896 bytes
Variable Size 83888944 bytes
Database Buffers 167772160 bytes
Redo Buffers 7118848 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: ‘/u01/oracle/oradata/orcl/redo01.log’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
redoファイルがなくした。対応策：
1). v$logを検索し、そのredoはcurrentかactiveかを確認する
2). Redoがアーカイブされたか
3). Inactiveならclear あるいは clear unarchivedを使ってください
4). Activeあるいはcurrentなら、不完全なリカバリ、隠しバラメタなどの方法で解決してください

3. Undoをなくした(ORA-01092 ORA-00376)
SQL> startup
ORACLE instance started.

Total System Global Area 260046848 bytes
Fixed Size 1266896 bytes
Variable Size 83888944 bytes
Database Buffers 167772160 bytes
Redo Buffers 7118848 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 2 – see DBWR trace file
ORA-01110: data file 2: ‘/u01/oracle/oradata/orcl/undotbs01.dbf’

SQL> alter database datafile 2 offline drop;

Database altered.

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-01092はフォアグラウンドエラで、alertログを検索することで探し出したバックグラウンドエラは主に：
Fri Oct 25 08:16:36 2013
Errors in file /u01/oracle/admin/orcl/bdump/orcl_smon_7437.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2: ‘/u01/oracle/oradata/orcl/undotbs01.dbf’
undoエラがなくしたことで、一部のトランザクションがロールバック出来ないから、エラになる。この場合に隠しバラメタを利用してください

4. Systemをなくした(ORA-01147)

SQL> startup
ORACLE instance started.

Total System Global Area 260046848 bytes
Fixed Size 1266896 bytes
Variable Size 83888944 bytes
Database Buffers 167772160 bytes
Redo Buffers 7118848 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 1 – see DBWR trace file
ORA-01110: data file 1: ‘/u01/oracle/oradata/orcl/system01.dbf’

SQL> alter database datafile 1 offline drop;

Database altered.

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01147: SYSTEM tablespace file 1 is offline
ORA-01110: data file 1: ‘/u01/oracle/oradata/orcl/system01.dbf’
systemテーブルスペースはシステムテーブルスペースで、そのテーブルスペースのデータファイルがオフラインできない。もしそのテーブルスペースデータファイルがなくしたら、データベース がまともに起動できない。Bbedでシステムファイルをシミュレーションして、データベースを騙す (非file# 1)あるいはdulでデータを抽出する

5. コントロールファイルをなくした(ORA-00205 ORA-00202)
SQL> startup
ORACLE instance started.

Total System Global Area 260046848 bytes
Fixed Size 1266896 bytes
Variable Size 83888944 bytes
Database Buffers 167772160 bytes
Redo Buffers 7118848 bytes
ORA-00205: error in identifying control file, check alert log for more info

ORA-00205はフォアグラウンドエラで、具体的にはログと一緒に分析する必要がある：
Fri Oct 25 08:35:40 2013
ALTER DATABASE MOUNT
Fri Oct 25 08:35:40 2013
ORA-00202: control file: ‘/u01/oracle/oradata/orcl/control01.ctl’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3

 
ここで、コントロールファイルがその数値がなくした、対応策は以下の通り：
1).バックアップでコントロールファイルをリカバリする
2).別のコントロールファイルを探し出して、コピする
3).データファイルをリストしてコントロールファイルを再構造する

ORACLEデータベース によくあるエラ の解決策

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

Dulによく使われるコマンド：
DUL> unload database ;
DUL> unload user ;
DUL> unload table ;
DUL> scan database;
DUL> scan tables;

テストテーブルの記録数を記してください：

SYS@lunar>select count(*) from lunar.lunar;
 
  COUNT(*)
----------
     17634  ここでは17634 行記録である
 
Elapsed: 00:00:00.09
SYS@lunar>

ほかの配置バラメタは第一篇に参考してくださいDUL 第一篇 —— DULは何か？
DULを起動してunpump headerを実行すれば、抽出できる：

DUL> unpump header dump file lunar.01.dmp;
Version is 769
check sum is 1864601239
data pump id is 6783164
master_obj_no is 18333
header blocks is 1
data pump file number is 1
block size is 4096
character set id is 873
master table block offset is 411
(Master table is at byte offset (411 -1) * 4096 = 1679360)
DUL> unpump table lunar.dmp (OWNER VARCHAR2(30),OBJECT_NAME VARCHAR2(128),SUBOBJECTNAME VARCHAR2(30),OBJECT_ID NUMBER,DATA_OBJECT_ID NUMBER,OBJECT_TYPE VARCHAR2(19),CREATED DATE,LAST_DDL_TIME DATE,TIMESTAMP VARCHAR2(19),STATUS VARCHAR2(7),TEMPORARY VARCHAR2(1),GENERATED VARCHAR2(1),SECONDARY VARCHAR2(1),NAMESPACE NUMBER,EDITION_NAME VARCHAR2(30)) dump file lunar.01.dmp from 15048 until 1676342; 
17634 rows unloaded
DUL> 

ここで17634 行記録は全部抽出できた。テストしたいであれば、より楽しくなる。一部のデータをｄｄして、dulがどうやって働くかを確認できる。。
そして、データをインポートする。O(∩_∩)O

[oracle@lunar dul]$ sqlldr userid=lunar/lunar control=/home/oracle/test/dul/dump000.ctl
 
SQL*Loader: Release 11.2.0.3.0 - Production on Thu Mar 6 13:11:44 2014
 
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 
Commit point reached - logical record count 64
Commit point reached - logical record count 128
Commit point reached - logical record count 192
Commit point reached - logical record count 256
Commit point reached - logical record count 320
Commit point reached - logical record count 384
Commit point reached - logical record count 448
Commit point reached - logical record count 512
Commit point reached - logical record count 576
Commit point reached - logical record count 640
Commit point reached - logical record count 704
Commit point reached - logical record count 768
Commit point reached - logical record count 832
Commit point reached - logical record count 896
................
Commit point reached - logical record count 17270
Commit point reached - logical record count 17334
Commit point reached - logical record count 17398
Commit point reached - logical record count 17462
Commit point reached - logical record count 17526
Commit point reached - logical record count 17590
Commit point reached - logical record count 17634
[oracle@lunar dul]$

ここで、17634 行データ、すべてもテーブルにインポートした。

ORACLEデータベース によくあるエラ の解決策

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

これは単なる自己満足で、何の実な意味もない。ついでに、テストに見つけ出したことも後で述べる（未だにデータベースを起動できていないが、試し続けたいと思う。O(∩_∩)O ~。。。）;
まずは言うべきなのは11.2の強さである。昔に大部分の場合のエラもリカバリできる。データベースを起動出来たら、損害に関係ないチェックを試す。
1， 11.2から、コントロールファイル自動バックアップが完成した情報はm000によって完成する。それに、ほかの仕事も完成できる。もちろん、別のプロセスが使われる時しか利用できない。
2，DBA_TABLESPACEとV$TABLESPACEの源が違っている。一つ目はコントロールファイルから、もう一つはベーステーブルts$から
3，ts$とfile$が番号をスキップできない。
4，DBMS_HMが強い（Health Manager）。定期的にデータベースにあるものをいちいちチェックして、m000プロセスでtraceを書く。
。。。

主なテストステップはあまり覚えていないが、主なシミュレーションステップは以下の通り：
私の環境： db 11.2.0.3 OEL 5.8
1，二つのテーブルスペースを作成し（一つもいい、数なんかどうでもいい、よりはっきり見えるためだけ）、ログを切り替えて、OSでUNDOTBSを含むデータファイル（普通なデータファイルとundoデータファイルでいい）
2，データベースを起動するときに、ファイルがなくしたあるいは壊された。このとき、エラになったファイルをoffline dropして、データベースが起動できるはず。バックグラウンドにm000によって作成されたtraceがあって、HealthManagerは持続的にm000を引き起こし、ほかの悪い情報をtraceに書き込む。
3，undo$のトラブルロールバックセグメントをクリンアップする
4，新たな普通データのテーブルスペースを作成して、例えば“UNDTBS333”、， UNDO_TABLESPACE=この普通のテーブルスペース（scope=spfile）を設定して、データベースを起動する————–これは当時初めての誤操作だった。
5，データベースがエラになった。具体的な内容も解決策も忘れていた。薄々覚えているのは、undoの隠しバラメタとか、正確なundoテーブルスペース（create undo tablespace …）を作成するだけ。
6，解決したあと、データベースが起動できた。delete from fs$ where name=前に誤操作したあの普通なデータテーブルスペースUNDTBS333’。こうするのはそのとき、リスクを考えず人工的にクリンアップした。
全部で人工的にやってもいいんだが、当時に考えすぎちゃったから、誤操作した。
7，実はこのようなデータベースがまだ起動できるが、DBMS_HM.RUN_CHECK(‘Dictionary Integrity Check’, ‘lunar-ck-Dict’)でテストして、データベースにundo$とts$ がfile$と一致していないが、ほかのデータオブジェクトに影響を与えていない。
けど、頭が熱くなって、二つ目の過ちを犯した：コントロールファイルを再構造する
v$tablespaceの内容が誤ったと映されているが、dba_tablespacesが正確だと映している。その定義を検索することで、v$tablespaceのデータはx$kcctsというベーステーブルから獲得できた。つまりコントロールファイルの情報から。それにdba_tablespacesはts$を元にしているから、コントロールファイルを再構造するという愚かな発想が生み出した。
8，コントロールファイルのプロセス自体が誤った、.。わかるよね。。。もちろん、後でこのトラブルを避けた。具体的なステップを忘れたが、いいんだ。別に難しくないから。
9，再びデータベースを救出できなかった
。。。。。

このプロセスは以下の文にエラがあった。Oracle2進数ファイルをテストすることで、みつかりやすい。これはデータベースを起動するときに、file$に対してインサートするから、つまり、bootstrap$によって、file$のブロックを見つけ出す。そのすべての内容をこのテーブルにインサートする：
select blocks,NVL(ts#,-1),status$,NVL(relfile#,0),maxextend,inc, crscnwrp,crscnbas,NVL(spare1,0) from file$ where file#=:1

それでbbedでfile$を修正するという手を考え出した。delete from fs$のテーブルスペースのデータファイルを削除状態に変更する。テストによると、ts$もfile$も番号をスキップできない。例えば、このfile#は３で、その状態を削除したと設定すれば、コントロールファイルを再構造するときに、file#>3が一致性テストの場合に削除する。

そして、仕方なくfile＄をリカバリした。fs$でdeleteの記録をリカバリすることを考えたが、いい方法が見つからない。
もう一つの方法は10046によってトレースして、エラ文を探し出して、上のようなトラブルは忽ち解決できる：
select name,online$,contents$,undofile#,undoblock#,blocksize,dflmaxext,dflinit,dflincr,dflextpct,dflminext, dflminlen, owner#,scnwrp,scnbas, NVL(pitrscnwrp, 0), NVL(pitrscnbas, 0), dflogging, bitmapped, inc#, flags, plugged, NVL(spare1,0), NVL(spare2,0), affstrength from ts$ where ts#=:1
ここでは避けていない。Oracle2進数ファイルを修正することもいい策だと思うが、うまく使いこなさなかった。これは最後の手を使う例だが、なんかそこまでしたくない。

ではディクショナリーテストをgdbでスキップしてください：

(gdb) commands 
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>set *0x60023388=0x0 
>cont 
>end 
(gdb) cont 
Continuing.
 
Breakpoint 1, 0x00000000022370e0 in kcfckdb ()
 
Program received signal SIGSEGV, Segmentation fault.
0x0000000002cbe19f in slaac_int ()
(gdb) 

そして、再びresetlogデータベースを起動するときに：

Sat Nov 30 12:03:37 2013
ARC3 started with pid=21, OS id=29788 
Undo initialization finished serial:0 start:127664534 end:127664564 diff:30 (0 seconds)
Verifying file header compatibility for 11g tablespace encryption..
Errors in file /u01/app/oracle/diag/rdbms/bb/bb/trace/bb_ora_28960.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-00376: file 1 cannot be read at this time
ORA-01110: data file 1: '/stage/system01.dbf'
Errors in file /u01/app/oracle/diag/rdbms/bb/bb/trace/bb_ora_28960.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-00376: file 1 cannot be read at this time
ORA-01110: data file 1: '/stage/system01.dbf'
Error 604 happened during db open, shutting down database
USER (ospid: 28960): terminating the instance due to error 604
Sat Nov 30 12:08:38 2013
USER (ospid: 29792): terminating the instance due to error 604
Termination issued to instance processes. Waiting for the processes to exit
Sat Nov 30 12:08:48 2013
Instance termination failed to kill one or more processes

それで、一つの断絶点を知る必要がある。どうやってその断絶点を設定するか。データベースを “Verifying file header compatibility for 11g tablespace encryption”しないようにしてください。

ORACLEデータベース によくあるエラ の解決策

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

適用範囲:

Oracle Database - Enterprise Edition - バージョン 8.1.5.0 から 12.1.0.1 [リリース 8.1.5 から 12.1]

この文書の内容はすべてのプラットフォームに適用されます。

目的

このノートの目的はエラーORA-1578またはRMAN / DBVERIFYなどのツールによって報告された破損オブジェクトを識別する手順を提供することです。

解決策

絶対ファイル番号(AFN)とブロック番号(BL)を指定します

絶対ファイル番号および相対ファイル番号(RFN)の同じ場合が多くありますが、異なる場合があります(特にデータベースがOracle7 から移行された場合またはトランスポータブル表領域が使用される場合)。正しいAFNおよびRFNを取得することが重要です。そうしないと、間違ったオブ ジェクトを特定する可能性があります。

ORA-1578からAFNの取得

ORA-1578の後に作成された ORA-1110によってAFNが提供されます。 次の例では AFNは5で、BLは34です。

DBVERIFYの出力からAFNの取得

異 なる方法で　dbverify　によって破損ブロックが報告される場合があります。 通常、DBVERIFY　は影響を受けるブロックに関連付 けられた RDBA を提供します。 RFN は dba_data_files から次の問合せで AFN を取得するために使用されます。  いくつか例を挙げます。

RFN=11 BL=34:

Dbverify は常に出力に相対データ・ブロック・アドレス (rdba/dba) をレポートします。 前述の例では相対 dba はメッセージ"Corrupt block relative dba: 0x02c00022 (file 11, block 34)"から取得された16進値 0x02c00022 になります。 rdba/dba は RFN を提供します。  The RFN is then 11. 次の問合せで dba_data_files から AFN を取得します。

dbverify の別の例は次のとおりです。

RFN=11 BL=35:

Dbv出力:

RFN とブロック番号取得するには次の問合せを使用します。

例：

RFN から dba_data_files を使用して AFN を取得します。
 

例：
 

AFN は 5 です。

RMANからAFNの取得

RMAN は v$database_block_corruption ビュー内で破損を報告します。

そのビューの FILE# 列は AFN です。BLOCK# 列は BL です。

破損オブジェクトの識別

AFNが識別されると、破損オブジェクトを識別するために次の問合せを実行します。
 

例：

前述の問合せで行が戻されない場合は破壊されたブロックがローカル管理の表領域(LMT)のセグメント・ヘッダーで可能性がありま す。破損したブロックが LMT のセグメント・ヘッダー・ブロックの場合、前述の問合せはアラートログに破損メッセージを生成しますが、問合せは失敗しません。  その場合、次の問い合わせを実行します。

ブロックが空きエクステント(オブジェクトに関連付けられていない)に属する場合やブロックが TEMPFILE の場合は前述の問合せによってデータは返されません。TEMPFILES の場合は「セグメント・タイプ」が「TEMPORARY」と表示されます。

ブロックが空きエクステントに属している場合、DBA_FREE_SPACE に表示されます。

注意：　Oracle10g 以降では ORA-1578 が発生する場合、アラート・ログにも破損オブジェクトの情報が更新されます。例：

破損の修正

破損オブジェクトを特定したら、次の記事に従って破損を修正します。:

If getting corruption error ORA-1578 エラーが発生している場合は、Doc ID 1578.1 の指示に従って破損を修正します。

その他の破損の修正については Doc ID 1635229.1　に従ってください。

適用範囲:

Oracle Database - Enterprise Edition - バージョン 11.2.0.4 から 12.1.0.2 [リリース 11.2 から 12.1]

Oracle Database - Standard Edition - バージョン 11.2.0.4 から 12.1.0.2 [リリース 11.2 から 12.1]

この文書の内容はすべてのプラットフォームに適用されます。

説明

Bug 18607546 により、行連鎖した行が自分自身を連鎖先として参照してしまうため、表データの破損や結果不正が生じます。

発生条件

列数の多い表（例：255列以上）で発生しやすいといえますが、それ以下の表でも発生する可能性があります。

既に行連鎖が発生していて、なおかつ表の最後の列の値がNULLだったものをNULL以外の値で UPDATE する際に
この問題が発生する可能があります。行連鎖が発生していない行や、表の最後の列が NOT NULL として定義されて
いる表では、この問題は発生しません。

また、SYSの所有するディクショナリ表は、行連鎖が殆ど発生しないことや、行の末尾のNULLの値をNULL以外の値に
更新することのないため、この問題は発生いたしません。

実際の発生報告は 11.2.0.4 のみです。それ以前のリリース（10.2.0.4, 11.1, 11.2.0.1）では
この問題に類似する問題に関するこちらのドキュメントも参照ください。 Doc ID 7705591.8

現象

ORA-600 [kdsgrp1] が発生します。

db_block_checking が MEDIUM または FULL と設定されていた場合には、以下のように 
ORA-600 [kdBlkCheckError] というエラーが発生し、破損が検出されます。この際に、不正な
変更はロールバックされますので、破損ブロックがディスク上に反映されるのを防ぐことができます。
 

db_block_checking が MEDIUM または FULL と設定されていない場合、ブロックの
不正な状態がディスク上にも反映され、その後に実行したSQL文の実行時に結果不正が生じたり、
以下のようなエラーが発生するという報告もあります。

回避策

破損が生じてしまった場合、以下の方法で対処を行います。

問題の生じている行をスキップして表を再作成する： "Create Table As Select (CTAS) where rowid != <rowid of head piece>"あるいは、query 句 (where rowid != <rowid of head piece>) を指定した datapump export を行い、表を truncate し、 import しなおす、などの方法が考えられます。

あるいは

dbms_repair パッケージを使用して問題のブロックを Soft Corrupt 状態とし、DMLでスキップされるようにする。

パッチ

Patch 18607546 をご利用ください。

この問題が修正されているバンドルパッチやリリース番号などの詳細は、 Doc ID 18607546.8 を参照ください。

ORACLEデータベース によくあるエラ の解決策

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

[概要]
LOB セグメントに破損が生じている場合、エクスポート実行時に以下のエラーが
発生する場合があります。

  ----------------------------------------------------------------------
  ORA-02354: error in exporting/importing data
  ORA-01555: snapshot too old: rollback segment number with name "" too
  small
  ORA-22924: snapshot too old
  ----------------------------------------------------------------------

本文書では、オリジナルの exp ユーティリティや DataPump export (expdp) を
使用して、LOB セグメントの破損を確認する方法について説明します。


[対象リリース]
Oracle Database 10g Release 2(10.2.0) および以降のすべてのリリース


[対象プラットフォーム]
すべてのプラットフォーム


[詳細]

1. LOB セグメントの破損を確認す方法
------------------------------------------------------------------------
Document 787004.1に記載されている PL/SQL プロシージャを実行することで、破損
した LOB セグメントが参照する表の rowid を特定します。

同様の PL/SQL プロシージャは Document 452341.1や Document 253131.1といった文書
に既に記載されており、この文書は、エクスポート・ユーティリティを使用して
破損したデータをエクスポートすることによって、LOB セグメントの破損を確認
するための方法を示すことを目的としております。

<<確認例>>
========================================================================
もし、EMP 表のエクスポート中に ORA-1555 を受けた場合、Document 787004.1に記
載されている PL/SQL プロシージャを実行します。なお、EMP 表は、LOB セグメ
ントを割り当てる LOB 列として EMP_XML 列が含まれており、SCOTT ユーザが所
有しているものとします。

* 一時表 "corrupted_lob_data"を作成した後に PL/SQL プロシージャを実行し
   ます。このテーブルには、破損している列の rowid が格納されます。

  SQL> create table corrupted_lob_data (corrupted_rowid rowid);

  SQL> set concat off

  SQL> declare
    2    error_1555 exception;
    3    pragma exception_init(error_1555,-1555);
    4    num number;
    5  begin
    6    for cursor_lob in (select rowid r, &&lob_column
    7                         from &table_owner.&table_with_lob)
    8    loop
    9      begin
   10        num:=dbms_lob.instr(cursor_lob.&&lob_column,hextoraw('889911')) ;
   11      exception
   12        when error_1555 then
   13          insert into corrupted_lob_data values (cursor_lob.r);
   14          commit;
   15      end;
   16    end loop;
   17  end;
   18  /

  上記のプロシージャを実行した後、プロンプトを入力します。

    Enter value for lob_column: EMP_XML
    Enter value for table_owner: SCOTT
    Enter value for table_with_lob: EMP

  SQL> undefine lob_column

  この方法ですべての LOB 列の破損をチェックできます。
  "corrupted_lob_data"表の出力は、破損した LOB セグメントを参照している
  3 つの rowid を示してます。

  SQL> select * from corrupted_lob_data;

  Corrupted_rowid
  ---------------------
  AAEWBsAAGAAACewAAC
  AAEWBsAAGAAACewAAF
  AAEWBsAAGAAACewAAG

  3 rows seleceted

* DataPump を使用して LOB の破損を確認します。

    % expdp scott/tiger directory=data_pump_dir dumpfile=test.dmp logfile=test.log
        tables=EMP query=\"where rowid=\'AAEWBsAAGAAACewAAC\' \"
    % expdp scott/tiger directory=data_pump_dir dumpfile=test1.dmp logfile=test1.log
        tables=EMP query=\"where rowid=\' AAEWBsAAGAAACewAAF \' \"
    % expdp scott/tiger directory=data_pump_dir dumpfile=test2.dmp logfile=test2.log
        tables=EMP query=\"where rowid=\' AAEWBsAAGAAACewAAG \' \"または

* オリジナルの exp ユーティリティを使用して LOB の破損を確認します。

    % exp scott/tiger file=test.dmp log=test.log tables=EMP 
        query=\"where rowid=\'AAEWBsAAGAAACewAAC\' \"
    % exp scott/tiger file=test1.dmp log=test1.log tables=EMP 
        query=\"where rowid=\' AAEWBsAAGAAACewAAF \' \"
    % exp scott/tiger file=test2.dmp log=test2.log tables=EMP 
        query=\"where rowid=\' AAEWBsAAGAAACewAAG \' \"もし、上記のエクスポートのいずかが失敗した場合は、LOB セグメントが破損し
ていることが確認できます。
========================================================================

2. 対処方法
------------------------------------------------------------------------
LOB セグメントの破損が確認された場合は、以下のいずれかの方法で対処できま
す。

1. 物理バックアップを使用して LOB セグメントをリストア／リカバリーする。

2. Document 787004.1に記載されているように、UPDATE 文を使用して影響を受けて
   いる LOB セグメントを空にする。

    SQL> update EMP set EMP_XML = empty_blob()
         where rowid in (select Corrupted_rowid from corrupted_lob_data);

3. 破損した rowid の行を除いてエクスポートする。

  DataPump を使用する方法:

    % expdp scott/tiger directory=data_pump_dir dumpfile=test.dmp logfile=test.log 
      tables=EMP query=\"where rowid not 
        in \(\'AAEWBsAAGAAACewAAC\',\'AAEWBsAAGAAACewAAF\' ,\'AAEWBsAAGAAACewAAG\'\)\" 

    * 表示上の都合により改行しております。実際に実行する際は改行せずに実
      行してください。

  オリジナルの exp ユーティリティを使用する場合:

    % exp scott/tiger file=test.dmp log=test.log tables=EMP query=\"where rowid 
      not in \(\'AAEWBsAAGAAACewAAC\',\'AAEWBsAAGAAACewAAF\' ,\'AAEWBsAAGAAACewAAG\'\)\"

    * 表示上の都合により改行しております。実際に実行する際は改行せずに実
      行してください。

ORACLEデータベース によくあるエラ の解決策

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

適用範囲:

Oracle – エンタプライズバーション 9.2.0.6

このトラブルはどんなプラットフォームにも起これる.

症状：

alter.logのエラ：

インスタンスをクロスして、使えない

アラーム！制御ファイルシーケンスが古すぎて、再び読み取ってください、、、

アラーム！制御ファイルシーケンスが古すぎて、再び読み取ってください、

アラーム！制御ファイルシーケンスが古すぎて、再び読み取ってください、

アラームログファイルでそのトラブルを報告する：

インスタンスをクロスして、使えない

アラーム！制御ファイルシーケンスが古すぎて、再び読み取ってください、

アラーム！制御ファイルシーケンスが古すぎて、再び読み取ってください、

アラーム！制御ファイルシーケンスが古すぎて、再び読み取ってください、

原因

これはあまり知られていないが、制御ファイルが古いコピによって上書きされたかもしれない。

alter.logは読み取れた制御ファイルが予想していたのより古いと示した：

“オペレーションシステムに返された制御ファイルブロックヘッダのシーケンスが古過ぎた。”

解決策

その解決策を実現するために、以下のようなステップを実行してください：

（1）分析のために、すべての制御ファイルのコピを格納して、オペレーションシステムスポンサーやOracle技術サポートに連絡する；

（2）インスタンスをmountして、以下のようなコマンドを実行してください：

ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS;

（3）データベースをクロスする  shutdown immediate;

（4）データベースを起動してnomount状態にする  startup nomount;

（5）制御ファイルを再構造してデータベースを起動する

（6）データベースをリカバリする recovery database;

（7）alter database open;

ORACLEデータベース によくあるエラ の解決策

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

目的：

内部エラ“ora-600[2662]”の意味と解決策を紹介する。

エラ：

フォーマット：ora-600[2662][a][b][c][d][e]

バーション：6.0到12.1

ディスクライブ：

データブロックのSCNが既存するSCNより大きい。

主に、UGA変数のdependent SCNと比べてみれば、既存するＳＣＮがそれより小さい場合に、データベースがORA-600 [2662]になる。

バラメタ：

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.

機能：

Redoログファイル管理とIOメモリ管理

影响：

インスタンスシャットダウン

物理的なエラが現れるかもしれない

アドバイス：

異なった場合にもORA-600[2662]エラになる：

これはデータベースを起動するときに起こるかもしれない。

もしパラレルサーバを使っていなければ、二つのインスタンスが同じデータベースに属しているか確認してください。

SMONのトレースファイルよアラームログファイルを確認する。

SCNの相違、バラメタdとバラメタbを確認する

SCNがかなり近づいていれば、クロスして再起動する。

一部の場合に、SCNがデータベースを起動すると増やすかもしれない。

もし、以下の情報でトラブルを確認できなければ、トレースファイルとアラームログはOracle技術サポートに提供してください。

二つのタイプのエラ

タイプ1：

4/5バラメタ形式

データブロックのSCNは既存するSCNより早い。

タイプ2：

一つのバラメタ形式（7.2.3前のバーションしかい起こらない）

タイプ1

もしSCNは既存するSCNから場合に、DBAを0と格納してください。もし、uodo$から場合に、ロールバックセグメントは使えないから、DBAがundoセグメント番号を格納する。０番号ファイルのブロックに見える。もしSCNはredoログから（つまり、ブロック番号== 0の変更数値）。では、DBAはブロック0に関連するデータファイル。もし、それは別のデータベースのトランザクションなら、DBAはDBAINF（）と意味している。もし、それはTXロックなら、DBAはUSN<<16 +と意味している。

タイプ2

ログブロック総計テスト

分析開始：

1、このエラはデータベースが運用しているうちに、あるいはデータベースを起動するときに現れる；

2、バラメタd及びバラメタbの違い

3、5つのバラメタの場合

DBAをファイル番号に変更する

データディクショナリーオブジェクトか否か（ファイル番号は1）

4、今のSQL文（trace次第）

どこのテーブルに指しているか？

前のステップで探し出したオブジェクトはここで指したものと同じなのか？

注意：これはDBAと関係ない。トラブルの原因は（blockdump）

より深刻に分析する：

（1）traceファイルを確認する：

これもまともなユーザートレースファイルあるいはsmonのトレースファイル。

（2）’buffer’を確認する

oracle7 dumpファイルの“buffer dba”

oracle8あるいはOracle9 dumpファイルの”buffer tsn”

これは2662エラの源を探し出せる。

このエラの原因：

1.隠しバラメタ_ALLOW_RESETLOGS_CORRUPTIONを使って、resetlogs、データベースを起動する

2.ハードウェアエラでデータベースが制御ファイルとredoログを書き込めなくなった。

3.データベースリカバリ

4.制御ファイルをリカバリしたが、recover database using backup controlfileを使っていない

5.データベースcrashしたあと_DISABLE_LOGGINGという隠しバラメタを設置した

6.パラレルサーバでDLMにトラブルが存在している

7、BUG

解决策：

（1）もしSCN番号の違いが小さい場合に、データベースを何度も再起動して、再起動するたびにSCN番号も増やす。dscn=scnの場合に、データベースを起動できる

（2）ADJUST_SCNトランザクションで既存するSCNを調整する。dependent SCNより大きいようにする。そして。データベースごとにエクスポートできることを保障してください。データベースを再構造してデータをインポートする。

ORACLEデータベース によくあるエラ の解決策

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

適用範囲

Oracleエンタプライズバーションデータベース、10.2.0.4あるいはより高いバーション

症状

alter database open resetlogs、以下のようなエラが現れた：

ORA-00704: bootstrap process failure

ORA-00704: bootstrap process failure

ORA-00604: error occurred at recursive SQL level 1

ORA-01555: snapshot too old: rollback segment number 11 with name “_SYSSMU11$” too small

Tue Jan 17 04:46:17 2012

Error 704 happened during db open, shutting down database

USER: terminating instance due to error 704

Instance terminated by USER, pid = 5496

ORA-1092 signalled during: ALTER DATABASE OPEN RESETLOGS…

変化

データベースを強制的に起動する

原因

データベースを強制的に起動したあるいはデータファイルが同期していない。ファイルに一部のブロックのSCNが既存するSCNより大きいである。

解决策

もし、Ora-1555エラについて、使用可能なトレースファイルがなければ、以下のような方法で、0ra-704とora-1555エラのトレースファイルを収集してください：

SQL>Startup mount ;

SQL>alter session set tracefile_identifier=new1555 ;

SQL>alter database open resetlogs ;

これでORA-1092エラになる。アラームログには、1555エラ情報が現れる。

それをディレクトリにudump/traceしてください：ls –lrt *new1555*

ロールバックセグメント名とアラームログにエラ情報を探し出す：

ORA-01555: snapshot too old: rollback segment number 11 with name “_SYSSMU11$” too small

ここのロールバックセグメント番号は11で、十六進数に変更する–> b

トレースファイルのテーブルあるいはインディクスのブロックヘッダダンプ情報のITLでどのトランザクションが11番号undoセグメントを使っているか探し出す。以上のブロックのblock header dumpを探し出す。

Search the trace file from Table or index block header dump whose transaction layer has an undo segment 11

been used in the ITL.Scroll up to get the Buffer header dump of that block

BH (0xacff8e48) file#: 1 rdba: 0x0040003e (1/62) class: 1 ba: 0xacf66000

set: 3 blksize: 8192 bsi: 0 set-flg: 2 pwbcnt: 0

dbwrid: 0 obj: 18 objn: 18 tsn: 0 afn: 1

hash: [d0e04c98,d0e04c98] lru: [acff8fd8,acff8db8]

ckptq: [NULL] fileq: [NULL] objq: [cc9a3d00,cc9a3d00]

use: [ce699910,ce699910] wait: [NULL]

st: CR md: EXCL tch: 0

cr: [scn: 0x0.4124e1e],[xid: 0x6.0.c28d],[uba: 0x820075.ea1.23],[cls: 0x0.46b5261],[sfl: 0x1]

flags:

Using State Objects

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

SO: 0xce6998d0, type: 24, owner: 0xd04439e8, flag: INIT/-/-/0x00

(buffer) (CR) PR: 0xd02fa378 FLG: 0x500000

class bit: (nil)

kcbbfbp: [BH: 0xacff8e48, LINK: 0xce699910]

where: kdswh02: kdsgrp, why: 0

buffer tsn: 0 rdba: 0x0040003e (1/62)

scn: 0x0000.046b527a seq: 0x00 flg: 0x00 tail: 0x527a0600

frmt: 0x02 chkval: 0x0000 type: 0x06=trans data

Hex dump of block: st=0, typ_found=1

Dump of memory from 0x00000000ACF66000 to 0x00000000ACF68000

0ACF67FF0 FFFF02C1 01FF8001 02C10280 527A0600 […………..zR]

.

.

.

Block header dump: 0x0040003e

Object id on Block? Y

seg/obj: 0x12 csc: 0x00.46b519e itc: 1 flg: – typ: 1 – DATA

fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck Scn/Fsc

0x01 0x000b.00b.00000e7a 0x00802042.00db.1a C— 0 scn 0x0000.04624228

So here we see ITL allocated is 0x01.

Transaction identifier –> <undo no>.<slot>.<wrap> —> 0x000b.00b.00000e7a

Undoセグメント番号 —> 0x000b –>十進数なら 11。

This block belong to 0x0040003e –(1/62)

Find the SCN of this block from the BH(Buffer header) for 0x0040003e –(1/62)

So in this case its the one highlighted above in trace scn: 0x0000.046b527a

上のSCNで_mimimum_giga_scnの数値を設定する

scn: 0x0000.046b527a

Convert 0x0000 –> Decimal –> 0

Convert 046b527a –> Decimal –>74142330

Convert –> 074142330 /1024/1024/1024 =0.069050

Add + 2G to the above value and round it up

_minimum_giga_scn = 3G

Pfileにこのバラメタを設定して、以下のステップを実行してください：

SQL>Startup mount pfile=<> ;

SQL>recover database using backup controlfile until cancel ;

Cancel

SQL>Alter database open resetlogs ;

データベースを強制的に起動できた。エクスポートして、データベースを再構造して、データをインポートしてください。

ORACLEデータベース によくあるエラ の解決策

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

適用範囲

Oracleデータベース – エンタプライズバーション – 11.2.0.3バーションあるいはより高いバーション
このファイルはどのプラットフォームにも適用できる。

症状

alert.logファイルを確認して、以下のようなエラになる：
Errors in file /u01/app/oracle/diag/rdbms/ps2jfmsm/ps2jfmsm1/trace/ps2jfmsm1_m000_27934.trc:
ORA-01157: cannot identify/lock data file 76 – see DBWR trace file
ORA-01110: data file 76: ‘/u01/app/oracle/product/11.2.0.3/db_1/dbs/glacloseindexdata’

变化

データファイルがオペレーションシステムから移された。

原因

そのファイルがなくなった。
/u01/app/oracle/product/11.2.0.3/db_1/dbsのパスを確認して、そのファイルがここにいないことと示している。

解决

まずはそのファイルがこのテーブルスペースにある唯一なデータファイルか確認してください：
SQL> select ts# from v$datafile where file# = 76;
TS#
———-
33
SQL> select file# from v$datafile where ts# = 33;
FILE#
———-
76
So only datafile 76 exists in tablespace 33

SQL> select name from v$tablespace where ts# = 33;
NAME
——————————
GLACLOSEINDEX

そのテーブルスペースを削除してみる:
SQL> drop tablespace glacloseindex;
drop tablespace glacloseindex
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 76 – see DBWR trace file
ORA-01110: data file 76:
‘/u01/app/oracle/product/11.2.0.3/db_1/dbs/glacloseindexdata’

SQL> select * from v$recover_file;
no rows selected
So the datafile must still be online.

SQL> alter database datafile 76 offline drop;
Database altered.
SQL>
SQL>
SQL> drop tablespace glacloseindex;
Tablespace dropped.

ORACLEデータベース によくあるエラ の解決策

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

適用範囲

Oracleデータベース – エンタプライズバーション – 9.2.0.2 から 11.1.0.7まで [Release 9.2 to 11.1]
どんなプラットフォームにも適用できる。

症状

11.1.0.7 バーションのデータベース
あるデータファイルを削除するときに、以下のようなエラになった

ERROR
———————–
ORA-00604: error occurred at recursive SQL level 1
ORA-01426: numeric overflow

原因

そのファイルは空か確認する
select FILE#, BYTES, BLOCKS from v$datafile where NAME=’/u09/flash1/ipv_pound_t_index_6.dbf’;
take FILE#

select * DBA_EXTENTS where FILE_ID=’SUBSTITUTE BY FILE#’
文件不为空.

解决策

テーブルスペースからデータファイルを削除すれば、一部の制約がある：

• ファイルを空のままに保持してください。
• テーブルに初めて作成されたファイルじゃできない。（この場合に、データファイルを代わるために。テーブルスペースを直に削除する。）
• 同じreadonlyのテーブルスペースにあってはいけない
• もし、テーブルスペースに一つのデータファイルしか存在していない場合に、そのデータファイルも削除できなくなる。

ORACLEデータベース によくあるエラ の解決策

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

1.適用範囲

バーション8.1.7.4から10.2.3[release 8.1.7 to 10.2]

2.目标

このファイルはリカバリ策を提供している。SYSTEM ロールバックセグメントがORA-600[4139]/ORA-600[4194]になると、データベースが起動できなくなる。

システムがロールバックセグメントから影響を受ける前に、リカバリの時点をエラが起こる前にしてください。

ORA-600[4193]とORA-[4104はundoのセグメントヘッダと（TRN CTL / FREE BLOCK POOL的信息）undo セグメントブロックに起こった。もし非SYSTEMのundoセグメントに起こる場合に関連するロールバックセグメントを削除すればいい。

3.リカバリ

オペレーションを実行する前に、バックアップしてください

SYSTEM ロールバックセグメントにBBED でktuxc.ktuxcnfb と ktuxc.ktuxcfbp[0..x].ktufbuba を0に設定した。こうすれば、Oraclが新たなトランザクションに空なブロックを使うようになる。

例えば：

以下はロールバックセグメントヘッダのダンプである

1. bbedに対してふさわしい偏差値を設定する。 ktuxc.ktuxcnfbを0X0000に変更する。この例では：0X0001
2. 偏差値を設定する。すべての非0ktuxcfbp[0..x].ktufbubaを0X00000000に設定する。この例でktuxc.ktuxcfbp[0].ktufbubaは0X00400006

3.ブロックは既にリカバリできて、ブロックのチェックサムを新たな数値に設定する。あるいは、ブロックのchecksumを禁止する。

一部のブロックが修正したダンプは以下の通り：

nfb=ktuxc.ktuxcnfb –空のブロック、プールに空じゃないスロットの数

ktuxc.ktuxcfbp=空のブロック・プール

4.データベースを起動して、system ロールバックセグメント：

alter rollback segment SYSTEM shrink;

ORACLEデータベース によくあるエラ の解決策

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

適用範囲

Oracleデータベース –エンタプライズバーション – 9.2.0.5 バーションあるいはより高いバーション
このファイルはどのプラットフォームにも適用できる

症状

データベースをバックアップモードに設置して、すべてのデータファイルと再構造制御ファイルをコピする。そして、いくつのアーカイブログファイルで、データベースをう将数据库设置成备份模式，复制所有数据文件和重建控制文件，并应用几个アップグレードする。alter database open resetlogsでデータベースを起動するときに、以下のようなエラになる：

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: ‘/oracle/PRDDAT/DATA1/tables/PRDDAT.SYSTEM.data1.dbf’

以下はクエリと結果:

select distinct(fhscn) from x$kcvfh;
just one value

select distinct(fhsta) from x$kcvfh;
only the value of 0

select distinct status from v$backup;
not active

制御ファイルスクリプトにもresetlogs.を設置した。

リカバリコマンドは以下の通り：

recover database using backup controlfile;

いくつのログが利用され、ログを削除して、resetlogsに指定し、データベースを起動する。

原因

リカバリコマンドが誤った

解决策

以下のようなコマンドでデータベースを起動する：

recover database using backup controlfile until cancel;

これはデータベースが使用可能なアーカイブログでデータを不完全にリカバリしていると意味している。

ORACLEデータベース によくあるエラ の解決策

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

適用範囲

Oracleデータベース-エンタプライズバーション- 11.2.0.3バーションあるいはより高いバーション
どんなプラットフォームにも適用できる

目标

テーブルスペースをonlineに設定するときにORA-1578エラになった

再びエラスタックトレースファイルを確認すれば、ktundo(Kernel Transaction UNDO )関数を見つけ出す。

ブロックはどのセグメントにも属していない

解决策

あるinactiveトランザクションを削除する必要がある

これは主な原因

ORA-01578: ORACLE data block corrupted (file # 3241, block # 64066)
ORA-01110: data file 3241: ‘+DATA/trexprod/datafile/users.2148.852306913’

========= Dump for incident 1718151 (ORA 1578) ========

*** 2014-07-23 13:39:56.893
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
—– Current SQL Statement for this session (sql_id=g2sc9yx7t379a) —–
alter tablespace USERS online

—– Call Stack Trace —–
kcbgcur KCB: Get a block in current mode.
ktbgcur Kernel Transaction Block GET
kdoiur declare local objects */
kcoubk kcoubk – Kernel Cache Op Undo callBacK — invoke undo callback routine */
ktundo ktundo – Kernel Transaction UNDO
kttasu kttasu – Kernel Transaction Table Apply Save Undo
kttonl kttonl – Kernel Transaction Table ONLine
atsdrv add file list */
kcbgcur KCB: Get a block in current mode.
ktbgcur Kernel Transaction Block GET
kdoiur declare local objects */
kcoubk kcoubk – Kernel Cache Op Undo callBacK — invoke undo callback routine */
ktundo ktundo – Kernel Transaction UNDO
kttasu kttasu – Kernel Transaction Table Apply Save Undo
kttonl kttonl – Kernel Transaction Table ONLine
atsdrv add file list */

BH (0x8cf9c6188) file#: 3241 rdba: 0x2b00fa42 (172/64066) class: 1 ba: 0x8c54dc000
set: 400 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,25
dbwrid: 15 obj: 41612848 objn: -1 tsn: 7 afn: 3241 hint: f
hash: [0x1766a27d00,0x1766a27d00] lru: [0xcffcdecf0,0xaef6b81c0]
ckptq: [NULL] fileq: [NULL] objq: [0x1620f39a60,0x1620f39a60] objaq: [0x1620f39a50,0x1620f39a50]
use: [0x17771ca878,0x17771ca878] wait: [NULL]
st: XCURRENT md: EXCL fpin: ‘kdowh01: kdoiur’ tch: 0
flags:
LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
buffer tsn: 7 rdba: 0x2b00fa42 (172/64066)
scn: 0x0c17.57840563 seq: 0xff flg: 0x04 tail: 0x056306ff
frmt: 0x02 chkval: 0xcf9c type: 0x06=trans data

オブジェクトはゴミ箱にある

ゴミ箱からオブジェクトを探し出して、トラブルを解決する

ORACLEデータベース によくあるエラ の解決策

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

適用範囲

Oracleデータベース – エンタプライズバーション- 11.1.0.7 バーションあるいはより高いバーション
IBM AIX on POWER Systems (64-bit)

症状

以下のようなクエリを実行するときにエラになる:

SQL> select group#||’,’||members||’ , ‘||status from v$log order by 1;
select group#||’,’||members||’ , ‘||status from v$log order by 1
*
ERROR at line 1:
ORA-00204: error in reading (block 1, # blocks 1) of control file
ORA-00202: control file: ‘/oracle/data02/control_01b.ctl’
ORA-27072: File I/O error
IBM AIX RISC System/6000 Error: 9: Bad file number
Additional information: 7
Additional information: 1
Additional information: -1

制御ファイルを別のノートに移動して、トラブルを解決できず、完全に制御ファイルを削除も再構造もできない。

原因

これはBUG 7519558で引き起こした

解决策

Bug 7519558のバッチをダウンロードして実行する

ORACLEデータベース によくあるエラ の解決策

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

適用範囲

Oracleデータベース –エンタプライズバーション- 10.2.0.1から11.2.0.3まで [Release 10.2 to 11.2]
UNIXシステムにしか使えない

症状

起動が失敗した。アラームログでORA-00202とORA-27086エラが現れた

Mon Jun 24 22:21:45 2013
ORA-00202: control file: ‘/u01/oradata/MCSOJMS/Control/control01.ctl’
ORA-27086: unable to lock file – already in use
SVR4 Error: 11: Resource temporarily unavailable
Additional information: 8
Additional information: 26585
Mon Jun 24 22:21:48 2013
ORA-205 signalled during: alter database mount

Tue Jun 25 03:21:27 2013
Errors in file /app/oracle/admin/MCSOJMS/bdump/mcsojms_dbw0_10983.trc:
ORA-01157: cannot identify/lock data file 204 – see DBWR trace file
ORA-01110: data file 204: ‘/u03/oradata/MCSOJMS/jms_tmp_03.dbf’
ORA-27086: unable to lock file – already in use
SVR4 Error: 11: Resource temporarily unavailable
Additional information: 8
Additional information: 26551

変更

ハードウェアトラブルのせいでサーバがシャットダウンした

原因

ハードウェアトラブルのせいで、サーバがクロスされた。すべてのインスタンスもシャットダウンして、制御ファイルとデータファイルを解放できなくなった。

ファイルシステムは無傷だが、インスタンスが起動できなくなった。

解决策

1.データベースをnomount状態に起動する。Spfileで起動した場合にpfileファイルを作成してください

create pfile='<patch>’ from spfile;

2. 制御ファイルを新たなパスにコピして、データベースをmountする。エラ情報が一致していなければ、ステップ３に実行してください。
3. もし制御ファイルが一致していなければ、制御ファイルのインメージを作成する

4.新たなアーカイブログを作成して、フラッシュバックログをに古いアーカイブログファイルをコピする。

5.初始化バラメタを編集し、init.oraを正確なパス情報を修正してください。

6. データファイル、一時ファイル及び制御ファイルを新たなパスにコピする

7.mountの状態で、ファイルをリネームして（データファイル、一時ファイル、制御ファイル）制御ファイルをアップグレードする

alter database rename file <old file location> to <new location>;