Ｄ社のＳAシステム管理員があるデータベースのSYSTEMテーブルスーペスのフィルタを削除したことによって、データベースがうまく起動せず、データを取り出せない。でも、たとえバックアップがなくても、ＰＲＭで１００％に近いデータをリカバリできる。
此场景中启动PRM后，进入Recovery Wizard后 选择《Non-Dictionary mode》非字典模式:このシーンでＰＲＭを起動したら、Recovery Wizardに入ったら、Non-Dictionary modeを選んでください：
No-dictionaryモードでユーザーが文字セットと各国語キャラクタ・セットを指定する必要がある。システムテーブルスペースをなくした後、データベース情報の文字セットが正確に獲得できないから、ユーザーの入力が必要になる。正確に文字セットを設置したことと必要な言語パックをインストールしたことはNo-Dictionaryモードで、順調に多国語を抽出する保障である。
シーン１と同じように、いまユーザーが獲得可能なすべてのフィルタを入力し（一時的なフィルタを含まない）、正確にBlock SizeとOFFSETを設置してください：
そして、SCANをクリックしてください。SCANの役目はすべてのフィルタのSegment Headerをスキャンし、SEG$.DATとXT$.DATに記録する。Oracleの中で、一つの非パーティション表とパーティション表はテーブルデータセグメントのEXTENT MAP情報に該当する、EXTENT MAPによって、そのテーブルにすべての記録を手に入れる。
また、一つの非パーティション表をある二つのフィルタによって構造したテーブルスペースに格納し、そのSEGMENT HEADERと半分のデータがAフィルタに格納し、その
ほかの半分がBフィルタに格納する。だが、ある事情によってSYSTEMテーブルスペースもSEGMENT HEADERを格納したAフィルタもなくし、Ｂフィルタしか残っていない場合に、ただＢフィルタのデータをリカバリしたいとすれば、SEGMENT HEADERに頼らず、ＢフィルタのEXTENT MAPの情報に頼るしかない。
SEGMENT HEADERに基づく和EXTENT MAPデータのNO-Dictionaryモードのリカバリ需要を同時に満たすために、SCAN操作はここでSEG$.DATとEXT$.DATに書き込み、（テキストフィルタは診断しやすくなるため、すべてのプログラムはＰＲＭ自身が持ち込むDERBYに頼っている。）そしてDERBYデータベースに記録する。
SCANを完成したら、インタフェースの左側にデータベースアイコンが現れる。
この時、二つのバッタンを選べる。：
- Scan Tables From Segments、このバッタンは：
システムテーブルスペースをなくしたが、すべての応用データテーブルスペースが存在している場合に適応している。
- Scan Tables From Extents
DictionaryモードのTruncateテーブルデータリカバリに適応していない。
システムテーブルスペースをなくしたにかかわらず、SEGMENT HEADERを格納したフィルタもなくした場合に適応している。
簡単にいうと、シーン２の方法でTRUNCATEされたデータをリカバリできないに限って、それ以外の場合はScan Tables From Segmentsを使ってください。Scan Tables From Segmentsを使っても、必要とするデータも見つからないときにScan Tables From Extentsを使うことに考えてください。
私たちはScan Tables From Segmentsモードを優先的に利用することを勧めている。
Scan Tables From Segments完成したら、インタフェース左側の樹形図を起動できる。
Scan Tables操作はSEG$の中のSEGMENT HEADER情報でデータテーブルの情報を構造する、樹形図の中に一つのノードが一つのデータテーブルセグメントを意味する。、その名はobj+データセグメントが記録したDATA OBJECT ID。
一つのノードをクリックして、インタフェース右側のコラムを見てください。
インテリジェントフィールドタイプ分析
システムスペースをなくしたゆえに、NO-Dictionaryモードではデータテーブルの構造情報がない。その構造情報にはテーブルのフィールド名とフィールドタイプを含んでいて、そしてOracleでこれらの情報がディクショナリー情報として格納する。ユーザーがテーブルスペースを使うときに、データセグメントのROW行データで一つ一つのフィールドのタイプを当てる必要がある。ＰＲＭは最先端のＪａｖａ予測技術を応用し、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
この部分にはインテリジェントフィールドタイプ解析の結果で１０個のデータを解析し、そしてその結果を示す。例のデータによって、ユーザーがそのデータセグメントの中のデータを格納する様子を、もっと詳しく理解できる。
もしデータセグメントにあるデータは１０個を足りていないなら、すべての記録が表示される。
TRY TO ANALYZE UNKNOWN column type:
この部分はインテリジェントフィールド型解析が１００％で確認できないフィールドをいろんな手段をつかって解析して、ユーザーは自身の判断でタイプを判明できる。
ＰＲＭ今まだ支持していないタイプは：
XDB.XDB$RAW_LIST_T、XMLTYPE、カスタムタイプなど。
Unload Statement:
この部分はＰＲＭが生成したUNLOAD文で、システムが内部的に使用する場合とＰＲＭ開発チーム及び ParnassusDataエンジニアがサポートしている場合にしか使えない。
ドも使える。ディクショナリーモードと比べれば、主な違いは非ディクショナリーモードでユーザーが自身でフィールドのタイプを実行できる、以下のように、一部のフィールドタイプはUNKNOWNで、これらのフィールドはＰＲＭがまだ支持していないフィールドで、あるいはＰＲＭのインテリジェント解析が順調に解析できなかったから。
もしユーザーがこのテーブルが設計するときの構造さえ知っていれば（アプリ開發者からのフィルタもいい）、自身で正確なColumn Typeを選べるようになる。これによって、ＰＲＭがそのテーブルのデータを順調に目標データベースにデータバイパスできる。
誤操作でテーブルスペースと一部のアプリテーブルスペースデータフィルタを削除した。
Ｄ社のSAは誤操作で、オンライン業務データベースのSYSTEMテーブルスペースのフィルタと一部のアプリテーブルスペースフィルタを削除した。
このシーンで、一部のアプリデータスペースフィルタが削除されたから、その中にデータテーブルのSEGMENT HEADERフィルタを含む可能性があるので、Scan Tables From Segment Headerより、Scan Tables From Extentsを使うほうがいい。
ステップは以下の通り：
- Recovery Wizardに入って、No-Dictionaryモードを選んで、すべて使用可能なデータフィルタを追加し、Scan Databaseを実行する。
2.データベースを選んで、マウスの右ボタンでScan Tables From Extentsをクリックする
3.ＰＲＭインタフェースに生成した対象樹形図のデータを分析して、導出あるいはデータバイパスする。
4.そのほかの操作はシーン４と同じ。