Oracle 最後の侍 行き詰まりのデータリカバリ

2014/02/01 by Leave a Comment

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

  • 人工的にredoログを削除する

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

  • Resetlogsの方法で起動する

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

使用説明：

  1. お客様がバックアップを持っていない；
  2. なくなるかもしれないデータがとっても大事で、別の方法で作成できない；
  3. お客様がデータベースごとにエクスポートして、データベースを再構造することを用意した。；
  4. その隠しバラメタがデータベースを100％でリカバリすることを保障できない；
  5. 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.

強制的に起動 &データを救う

ある簡単な例

  1. データベースが shutdown abortを実行したあとすべてのredoログを削除して、起動できなくなった；
  2. すべてのロールバックセグメントを探し出す

-bash-3.2$ strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort –

_SYSSMU10_1221199237

_SYSSMU10_1221203537

……

  1. Pfileファイルを以下のように修正する

#*.undo_tablespace=’UNDOTBS1′

_allow_resetlogs_corruption = true  undo_management = MANUAL

_CORRUPTED_ROLLBACK_SEGMENTS = (_SYSSMU10_1221199237,…）

18.

強制的に起動 &データを救う

  1. データベースをクロスして、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を知ったから

  1. 予想したSCN数値は

1826.1818507298 =

(1826* 4294967296) + 1818507298 =

7844428789794

  1. 予想したSCNをgiga値に変更する = 7844428789794/1024/1024/1024= 7305.XXXX

それで、_MINIMUM_GIGA_SCN=7306 を既存するSCNをブロックのSCNより大きいするように調整してください。

22.

強制的に起動 &データを救う

ある簡単な例

  1. Pfileでバラメタ _minimum_giga_scn=7306を追加する
  2. データベースを再起動する

startup mount  recover database  alter database open;

  1. 成功に起動したら、そのバラメタを削除し、再起動してください

DELETE parameter _minimum_giga_scn from the init.ora file  SHUTDOWN THE DATABASE

STARTUP

 

Filed Under: Oracle, Oracle数据恢复、数据库恢复、灾难恢复

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号