PRM DUL ORACLE 誤削除とSYSTEMテーブルスペースがなくした。

D社のSAシステム管理員があるデータベースのSYSTEMテーブルスーペスのフィルタを削除したことによって、データベースがうまく起動せず、データを取り出せない。でも、たとえバックアップがなくても、PRMで100%に近いデータをリカバリできる。

 

此场景中启动PRM后,进入Recovery Wizard后 选择《Non-Dictionary mode》非字典模式:このシーンでPRMを起動したら、Recovery Wizardに入ったら、Non-Dictionary modeを選んでください:

 

PRM-DUL-DUL37

 

PRM-DUL-DUL38

 

No-dictionaryモードでユーザーが文字セットと各国語キャラクタ・セットを指定する必要がある。システムテーブルスペースをなくした後、データベース情報の文字セットが正確に獲得できないから、ユーザーの入力が必要になる。正確に文字セットを設置したことと必要な言語パックをインストールしたことはNo-Dictionaryモードで、順調に多国語を抽出する保障である。

 

シーン1と同じように、いまユーザーが獲得可能なすべてのフィルタを入力し(一時的なフィルタを含まない)、正確にBlock SizeとOFFSETを設置してください:

 

PRM-DUL-DUL39

 

そして、SCANをクリックしてください。SCANの役目はすべてのフィルタのSegment Headerをスキャンし、SEG$.DATとXT$.DATに記録する。Oracleの中で、一つの非パーティション表とパーティション表はテーブルデータセグメントのEXTENT MAP情報に該当する、EXTENT MAPによって、そのテーブルにすべての記録を手に入れる。

 

また、一つの非パーティション表をある二つのフィルタによって構造したテーブルスペースに格納し、そのSEGMENT HEADERと半分のデータがAフィルタに格納し、その

ほかの半分がBフィルタに格納する。だが、ある事情によってSYSTEMテーブルスペースもSEGMENT HEADERを格納したAフィルタもなくし、Bフィルタしか残っていない場合に、ただBフィルタのデータをリカバリしたいとすれば、SEGMENT HEADERに頼らず、BフィルタのEXTENT MAPの情報に頼るしかない。

 

 

SEGMENT HEADERに基づく和EXTENT MAPデータのNO-Dictionaryモードのリカバリ需要を同時に満たすために、SCAN操作はここでSEG$.DATとEXT$.DATに書き込み、(テキストフィルタは診断しやすくなるため、すべてのプログラムはPRM自身が持ち込むDERBYに頼っている。)そしてDERBYデータベースに記録する。

 

PRM-DUL-DUL40

 

PRM-DUL-DUL41

 

SCANを完成したら、インタフェースの左側にデータベースアイコンが現れる。

 

この時、二つのバッタンを選べる。:

 

  1. Scan Tables From Segments、このバッタンは:

システムテーブルスペースをなくしたが、すべての応用データテーブルスペースが存在している場合に適応している。

  1. Scan Tables From Extents

DictionaryモードのTruncateテーブルデータリカバリに適応していない。

システムテーブルスペースをなくしたにかかわらず、SEGMENT HEADERを格納したフィルタもなくした場合に適応している。

 

簡単にいうと、シーン2の方法でTRUNCATEされたデータをリカバリできないに限って、それ以外の場合はScan Tables From Segmentsを使ってください。Scan Tables From Segmentsを使っても、必要とするデータも見つからないときにScan Tables From Extentsを使うことに考えてください。

 

 

 

私たちはScan Tables From Segmentsモードを優先的に利用することを勧めている。

PRM-DUL-DUL42

 

Scan Tables From Segments完成したら、インタフェース左側の樹形図を起動できる。

 

PRM-DUL-DUL43

 

Scan Tables操作はSEG$の中のSEGMENT HEADER情報でデータテーブルの情報を構造する、樹形図の中に一つのノードが一つのデータテーブルセグメントを意味する。、その名はobj+データセグメントが記録したDATA OBJECT ID。

 

一つのノードをクリックして、インタフェース右側のコラムを見てください。

PRM-DUL-DUL44

 

インテリジェントフィールドタイプ分析

 

システムスペースをなくしたゆえに、NO-Dictionaryモードではデータテーブルの構造情報がない。その構造情報にはテーブルのフィールド名とフィールドタイプを含んでいて、そしてOracleでこれらの情報がディクショナリー情報として格納する。ユーザーがテーブルスペースを使うときに、データセグメントのROW行データで一つ一つのフィールドのタイプを当てる必要がある。PRMは最先端のJava予測技術を応用し、10種以上のメインデータ・タイプも含まれている。

 

 

インテリジェント分析の正確度が90%を超え、自動的に多くのシーンを解決できる。

 

右側のコラムのフィールドの意味:

 

  • Col1 noフィールド番号
  • Seen Count: 獲得した行数
  • MAX SIZE:最大の長さ、単位はバイト
  • PCT NULL: 獲得したNULLの比率
  • String Nice: そのフィールドを文字列に解析し、そして成功した例
  • Number Nice:そのフィールドを数字に解析し、そして成功した例
  • Date Nice: そのフィールドをDateに解析し、そして成功した例
  • Timestamp Nice: そのフィールドをTimestampに解析し、そして成功した例
  • Timestamp with timezone Nice: そのフィールドをTimestamp with timezone Niceに解析し、そして成功した例

 

サンプルデータ分析Sample Data Analysis

 

PRM-DUL-DUL45

 

この部分にはインテリジェントフィールドタイプ解析の結果で10個のデータを解析し、そしてその結果を示す。例のデータによって、ユーザーがそのデータセグメントの中のデータを格納する様子を、もっと詳しく理解できる。

 

 

もしデータセグメントにあるデータは10個を足りていないなら、すべての記録が表示される。

 

TRY TO ANALYZE UNKNOWN column type:

 

PRM-DUL-DUL46

 

この部分はインテリジェントフィールド型解析が100%で確認できないフィールドをいろんな手段をつかって解析して、ユーザーは自身の判断でタイプを判明できる。

 

PRM今まだ支持していないタイプは:

XDB.XDB$RAW_LIST_T、XMLTYPE、カスタムタイプなど。

 

Unload Statement:

 

この部分はPRMが生成したUNLOAD文で、システムが内部的に使用する場合とPRM開発チーム及び       ParnassusDataエンジニアがサポートしている場合にしか使えない。

 

PRM-DUL-DUL47

 

ドも使える。ディクショナリーモードと比べれば、主な違いは非ディクショナリーモードでユーザーが自身でフィールドのタイプを実行できる、以下のように、一部のフィールドタイプはUNKNOWNで、これらのフィールドはPRMがまだ支持していないフィールドで、あるいはPRMのインテリジェント解析が順調に解析できなかったから。

 

 

もしユーザーがこのテーブルが設計するときの構造さえ知っていれば(アプリ開發者からのフィルタもいい)、自身で正確なColumn Typeを選べるようになる。これによって、PRMがそのテーブルのデータを順調に目標データベースにデータバイパスできる。

 

PRM-DUL-DUL48

 

 

誤操作でテーブルスペースと一部のアプリテーブルスペースデータフィルタを削除した。

 

D社のSAは誤操作で、オンライン業務データベースのSYSTEMテーブルスペースのフィルタと一部のアプリテーブルスペースフィルタを削除した。

 

 

このシーンで、一部のアプリデータスペースフィルタが削除されたから、その中にデータテーブルのSEGMENT HEADERフィルタを含む可能性があるので、Scan Tables From Segment Headerより、Scan Tables From Extentsを使うほうがいい。

 

 

ステップは以下の通り:

 

 

  1. Recovery Wizardに入って、No-Dictionaryモードを選んで、すべて使用可能なデータフィルタを追加し、Scan Databaseを実行する。

2.データベースを選んで、マウスの右ボタンでScan Tables From Extentsをクリックする

3.PRMインタフェースに生成した対象樹形図のデータを分析して、導出あるいはデータバイパスする。

4.そのほかの操作はシーン4と同じ。

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号