ORACLEデータベース によくあるエラ の解決策
プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：service@parnassusdata.com
3.
よくあるデータをなくした状況
コントロールファイルがなくした
データファイルがなくした
Redoログがなくした
4.
よくあるデータをなくした状況
コントロールファイルがなくした
A：コントロールファイル一部がなくした
- 使えるcontrol fileをコピするあるいはspfile/pfile修正して、再起動する。
B：コントロールファイルが全部なくした
- 物理的なバックアップをリカバリする
- バックアップのスクリプト shutdown startup nomount
CREATE CONTROLFILE...
recover database
alter database openを再構造する
- バックアップもtraceスクリプトもなければ、人工的にスクリプトを編集して再構造してみる
5.
よくあるデータをなくした状況
Redoログがなくした
A：非current redo logをなくした
ORA-00313: open failed for members of log group 1 of thread 1 ORA-00312: online log 1 thread 1: ‘/add/test1/test1/redo01.log’
select a.group#,b.member,a.status from v$log a,v$logfile b where a.group#=b.group#;
GROUP# MEMBER STATUS
---------- ---------------------------------------- ----------------
1 /add/test1/test1/redo01.log INACTIVE
3 /add/test1/test1/redo03.log CURRENT
2 /add/test1/test1/redo02.log INACTIVE
alter database clear logfile /xx/redo01.log
6.
よくあるデータをなくした状況
Redoログがなくした
B：current redo logをなくしたが、データベースが正常にクロスされた。
select a.group#,b.member,a.status from v$log a,v$logfile b where
a.group#=b.group#;
GROUP# MEMBER STATUS
---------- ---------------------------------------- ----------------
1 /add/test1/test1/redo01.log INACTIVE
3 /add/test1/test1/redo03.log CURRENT
2 /add/test1/test1/redo02.log INACTIVE
SQL>
recover database until cancel;
Media recovery complete.
SQL>
alter database open resetlogs;
Database altered.
7.
よくあるデータをなくした状況
Redoログがなくした
C：current/active redo logをなくした上に、データベースが非正常にクロスされた
fake recoverをしてみた後でresetlogs方法でデータベースを起動したが、エラになった ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '/add/test1/test1/system01.dbf’
SQL> select file#,status,checkpoint_change#,checkpoint_time,fuzzy
from v$datafile_header order by 1;
FILE# STATUS CHECKPOINT_CHANGE# CHECKPOIN FUZZY
---------- ------- -------------------------- --------- ---
- ONLINE
- ONLINE
- ONLINE
- ONLINE
4565550461182 26-MAY-13 YES
4565550461182 26-MAY-13 YES
4565550461182 26-MAY-13 YES
4565550461182 26-MAY-13 YES
8.
よくあるデータをなくした状況
Redoログがなくした
C：current/active redo logをなくした上に、データベースが非正常にクロスされた。
restore old backup
SQL> startup mount
SQL> recover database until cancel using backup controlfile; SQL> alter database open resetlogs;
- 何のバックアップもない場合に、うまく起動できない。データベースが一致していないままに、強制的に起動する。ユーザーデータをエクスポートして、データベースを再構造するしかない。
9.
よくあるデータをなくした状況
データファイルをなくした
A：非システムデータファイル喪失
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file ORA-01110: data file 5: '/add/test1/test1/test1.dbf'
- バックアップデータでデータファイルをリカバリする
- この部分のデータを無視して、そのデータファイルをoffline dropしたらデータフベースを起動する
B：システムデータファイル喪失
- バックアップデータでデータファイルをリカバリしてください
- バックアップがなければ、データベースが起動できなくなる（正常or強制的）、データがリカバリできなくなる；
データががとっても大切であれば、DULでリカバリしてみてください
10.
強制的に起動 &データを救う
SCN
No
Fuzzy
一致性起動
11.
強制的に起動 &データを救う
SCN
System Checkpoint SCN - V$Database:checkpoint_change#
Datafile Checkpoint SCN - V$Datafile:checkpoint_change#
Datafile Start SCN - V$Datafile_header:checkpoint_change#
Datafile Stop SCN - V$Datafile:last_change#
12.
強制的に起動 &データを救う
No Fuzzy
Media-Recovery-Fuzzy
Datafileでblockを含むSCNがdatafile headerのSCNより前にあるなら、そのデータファイルにダーティブロックを含んでいると意味している。 Fuzzy状態である。一致性を保つために、より多くのrecoveryとしている。
13.
強制的に起動 &データを救う
No SQL>
shutdown abort
ORACLE instance shut down.
Fuzzy SQL>
startup mount
Database mounted.
SQL>
select file#,status,checkpoint_change#,
checkpoint_time,fuzzy from v$datafile_header order by 1;
FILE# STATUS CHECKPOINT_CHANGE# CHECKPOIN FUZ
---------- ------- ------------------ --------- ---
- ONLINE 4565550830945 17-JUN-13 YES
- ONLINE 4565550830945 17-JUN-13 YES
- ONLINE 4565550830945 17-JUN-13 YES
- ONLINE 4565550830945 17-JUN-13 YES
$
dbv file=system01.dbf blocksize=8192
........
Highest block SCN : 595433 (1063.595433)
SCN_WRAP.SCN_BASE
SCN= (SCN_WRAP*4294967296)+SCN_BASE =>4565550831081
14.
強制的に起動 &データを救う
_allow_resetlogs_corruption
Database open段階で一致性テストを強制的にスキップした。データベースがクロスされる前にそのファイルは何か、それになぜクロスされたかを確認しなくなる。
ORA-01190: control file or data file %s is from before the last RESETLOGS
ORA-01194: file %s needs more recovery to be consistent
ORA-01113: file '%s' needs media recovery starting at log sequence # %s
ORA-01195: on-line backup of file %s needs more recovery to be consistent" ORA-01196: file %s is inconsistent due to a failed media recovery session ORA-01152: file '%s' was not restored from a sufficientluy old backup"
15.
強制的に起動 &データを救う
_allow_resetlogs_corruption
使用説明：
- お客様がバックアップを持っていない；
- なくなるかもしれないデータがとっても大事で、別の方法で作成できない；
- お客様がデータベースごとにエクスポートして、データベースを再構造することを用意した。；
- その隠しバラメタがデータベースを100％でリカバリすることを保障できない；
- ORACLEはその隠しバラメタを利用したデータベースに対して、技術supportを提供しなくなる；
16.
強制的に起動 &データを救う
_corrupted_rollback_segments
インスタンス起動段階ですべてのロールバックセグメントへのアクセスを阻止して、ロールバックに含むアクチブトランザクションが提出したと見なされている。
使い方：
- undo_management = MANUALを修正する
- _CORRUPTED_ROLLBACK_SEGMENTS = (_SYSSMU1$, …) all
rollback segments
----
strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort –uを追加する
- UNDO_TABLESPACE と UNDO_RETENTIONの意味を説明する.
17.
強制的に起動 &データを救う
ある簡単な例
- データベースが shutdown abortを実行したあとすべてのredoログを削除して、起動できなくなった；
- すべてのロールバックセグメントを探し出す
-bash-3.2$ strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort –
_SYSSMU10_1221199237
_SYSSMU10_1221203537
……
- Pfileファイルを以下のように修正する
#*.undo_tablespace='UNDOTBS1'
_allow_resetlogs_corruption = true undo_management = MANUAL
_CORRUPTED_ROLLBACK_SEGMENTS = (_SYSSMU10_1221199237,…）
18.
強制的に起動 &データを救う
- データベースをクロスして、mount状態に戻る。Resetlogsで強制的にデータベースを起動する
SQL>
startup mount
Database mounted.
SQL>
recover database until cancel;
ORA-00279: change 4565550830945 generated at 06/17/2013
00:02:46 needed for thread 1
ORA-00289: suggestion :
………..
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS
would get error below
ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: '/add/test1/test1/system01.dbf' ORA-01112: media recovery not started
SQL>
alter database open resetlogs;
Database altered.る
19.
強制的に起動 &データを救う
SCN バラメタ：_minimum_giga_scn (event ADJUST_SCN/10015)
_allow_resetlogs_corruption バラメタと_CORRUPTED_ROLLBACK_SEGMENTS を設定したあと、ORA-600 [2662]エラがよく現れる；
ORA-00600: [2662]
A data block SCN is ahead of the current SCN.
- _minimum_giga_scn
- Event ADJUST_SCN
- Event 10015
20.
強制的に起動 &データを救う
ある簡単な例
allow_resetlogs_corruption と_CORRUPTED_ROLLBACK_SEGMENTS 設定したあと、resetlogsモードでデータベースを起動してみたがエラになった：
ORA-00600: internal error code, arguments: [
2662], [1826], [1818451944],
[1826], [1818507298], [322961417], [], []
ORA-600 [2662] [a] [b] [c] [d] [e]：
Arg [a] Current SCN WRAP：今（コントロールファイル）のSCN WRAP
Arg [b] Current SCN BASE：今（コントロールファイル）のSCN BASE
Arg [c] dependent SCN WRAP：目標SCN WRAP
Arg [d] dependent SCN BASE：目標SCN BASE
21.
強制的に起動 &データを救う
ある簡単な例
ORA-00600: internal error code, arguments: [
2662], [1826], [1818451944],
[1826], [1818507298], [322961417], [], []
SCN= (SCN_WRAP * 4294967296)+SCN_BASEを知ったから
- 予想したSCN数値は
1826.1818507298 =
(1826* 4294967296) + 1818507298 =
7844428789794
- 予想したSCNをgiga値に変更する = 7844428789794/1024/1024/1024= 7305.XXXX
それで、_MINIMUM_GIGA_SCN=7306 を既存するSCNをブロックのSCNより大きいするように調整してください。
22.
強制的に起動 &データを救う
ある簡単な例
- Pfileでバラメタ _minimum_giga_scn=7306を追加する
- データベースを再起動する
startup mount recover database alter database open;
- 成功に起動したら、そのバラメタを削除し、再起動してください
DELETE parameter _minimum_giga_scn from the init.ora file SHUTDOWN THE DATABASE
STARTUP