Archives for 十一月 2014

PRM DUL ORACLE FAQ よくある質問

データベースの文字セットが分からなかったらどうすればいい?

 

 

Oracleアラームロゴalert.logを確認することによって、データベースの文字セットが確認できる。例えば:

 

[oracle@mlab2 trace]$ grep  -i character alert_Parnassus.logDatabase Characterset is US7ASCII

Database Characterset is US7ASCII

alter database character set INTERNAL_CONVERT AL32UTF8

Updating character set in controlfile to AL32UTF8

Synchronizing connection with database character set information

Refreshing type attributes with new character set information

Completed: alter database character set INTERNAL_CONVERT AL32UTF8

alter database national character set INTERNAL_CONVERT UTF8

Completed: alter database national character set INTERNAL_CONVERT UTF8

Database Characterset is AL32UTF8

Database Characterset is AL32UTF8

Database Characterset is AL32UTF8

 

 

 

なぜPRMいつもシャットダウンするあるいはgc warning: うおeated allocation of very large block (appr.size 512000)”などのエラになるでしょう?

 

それは恐らく推薦していないJAVA環境を使ったせいと思う。とくに、Linuxプラッドフォームでredhat gcj javaを運用したら、よくこのようになる。ParnassusDataはJDK1.6以上の環境でPRMを運用することを勧めている。$JAVA_HOME/bin/java –jar prm.jarによって、PRMを起動できる。

 

JDK 1.6のダウンロードリンクは以下の通り:

http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-arhive-downloads-javase6-419409.html#jdk-6u45-oth-JPR

 

PRMのbugを見つけ出したら、どうやってParnassusDataにreport bugすればいいでしょう?

 

ParnassusDataはあらゆるのreport bugを歓迎する。report_bugs@parnassusdata.comにメールすればいい。メールにbugが出た運用環境、オペレーションシステム、Java運用環境とORACLEデータベースバーション情報を一緒に送信してください。

 

RPMを起動するときにこのようなエラになったら、どうすればいいでしょう?

Error: no `server’ JVM at `D:\Program Files (x86)\Java\jre1.5.0_22\bin\server\jvm.dll’.

 

これはユーザーがJAVA Runtime Environment JREをインストールしているが、JDKをインストールしていないからである。PRMの起動スクリプトに-severオプションが追加したから、このオプションはJRE 1.5前のバーションにないので、エラになる。

 

ParnassusDataはJDK1.6以上の環境でPRMを運用することを勧めている。

 

JDK 1.6のダウンロードリンクは以下の通り

http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html#jdk-6u45-oth-JPR

 

なぜPRMを使うとき、漢字が文字化けになるでしょう?

 

今我々知っている文字化けに導く原因は以下のふたつがある:

オペレーションシステムに中国語言語パックをインストールしていないので、まともに漢字を映せない。

言語バックをインストールしたが、JAVAの運用環境はJDK 1.4なので、文字化けが出る可能性がある、JDK 1.6以上のバーションを使ってください。

 

 

 

PRMはLOBラージオブジェクトフィールドを支持していないでしょうか?

 

いまPRMはCLOB、NCLOB、BLOBなどのLOBラージオブジェクトフィールドを支持している。Disable/Enable Storage in ROWなどの場合はLOBへデータバイパスモードも支持している。

 

LOBラージオブジェクトフィールドには通常のUNLOAD抽出を支持していない。この抽出方法を使ったら、データを導入する場合にものすごくめんどくさいなので、DataBridgeデータバイパスモードを使ってください。

 

PRM DUL ORACLE 誤操作でDROPしたテーブルのリカバリ

D社のアプリ開發者がASMの環境で、なんのバックアップもないのに、システムの肝心なアプリテーブルをDROPした。そのときに、PRMですぐに大部分のデータをリカバリできる。10gのあと、recyclebinゴミ箱を追加した。まずはDBA_RECYCLEBINSビューを確認して、DROPしたテーブルがそこにあるか否かをたしかめる。もしそこにもなかったら、PRMでリカバリしてください。

 

 

リカバリの流れは以下の通り:

 

まずはDROPされたデータテーブルを含むテーブルスペースを見つけ出す。

ディクショナリーをけんさくして、あるいはLOGMINERでDROPされたデータテーブルのDATA_OBJECT_IDを見つけ出す。DATA_OBJECT_IDを得られない場合にはNON-DICTモードでPRMを起動する。DROPされたデータテーブルを含むテーブルスペースにすべてのフィルタを追加したら、SCAN DATABASE+SCAN TABLE from Extent MAP。

DATA_OBJECT_IDによって、データテーブルを見つけて、DataBridgeモードでもとのデータベースに伝送する。

 

SQL> select count(*) from “MACLEAN”.”TORDERDETAIL_HIS”; 

COUNT(*)

———-

984359

 

SQL>

SQL> create table maclean.TORDERDETAIL_HIS1 as select * from  maclean.TORDERDETAIL_HIS;

 

Table created.

 

SQL> drop table maclean.TORDERDETAIL_HIS;

 

Table dropped.

 

 

 

 

Logminerに通って、あるいはリカバリシーン9の方法で大抵なDATA_OBJECT_IDを得られる、LOGMINERを利用するスクリプトは以下の通り:

 

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => ‘/oracle/logs/log1.f’, OPTIONS => DBMS_LOGMNR.NEW); 

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => ‘/oracle/logs/log2.f’, OPTIONS => DBMS_LOGMNR.ADDFILE);

 

Execute DBMS_LOGMNR.START_LOGMNR(DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG+DBMS_LOGMNR.COMMITTED_DATA_ONLY);

 

SELECT * FROM V$LOGMNR_CONTENTS ;

 

EXECUTE DBMS_LOGMNR.END_LOGMNR;

 

たとえここでDATA_OBJECT_ID得られなくとも、データテーブルが多くない場合に人工的にリカバリしたいデータテーブルを見つけ出すことができる。

 

 

まずはDROPされたデータテーブルを含むテーブルスペースをOFFLINEする。

 

SQL> select tablespace_name from dba_segments where segment_name=’TPAYMENT’; 

TABLESPACE_NAME

——————————

USERS

 

SQL> select file_name from dba_data_files where tablespace_name=’USERS’;

 

FILE_NAME

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

+DATA1/parnassus/datafile/users.263.843694795

 

SQL> alter tablespace users offline;

 

Tablespace altered.

 

PRMを起動して、NON-DICTモードに入って、該当するデータフィルタを追加し、SCAN DATABASE+SCAN TABLE From Extentsを選んでください。

 

PRM-DUL-DUL73

 

PRM-DUL-DUL74

 

ASM DiskgroupにあるすべてのASM Disks追加したら、ASM analyzeをクリックしてください。

 

PRM-DUL-DUL75

 

非ディクショナリーモードなので、必要な文字セットを入力してください。

PRM-DUL-DUL76

 

DROPされたデータテーブルを含むテーブルフィルタをクリックすればいい、ほかのフィルタはどうでもいい。そしてSCANをクリックする。

 

PRM-DUL-DUL77

 

PRM-DUL-DUL78

 

生成したデータベースの名前をクリックし、右ボタンでscan tables from extentsを選んでください。

 

PRM-DUL-DUL79

 

PRM-DUL-DUL80

 

人工的にDATA_OBJECT_ID=82641のデータはDROPされたTORDERDETAIL_HISテーブルに該当し、DataBridge技術でモートのリポジトリに伝送する。

 

PRM-DUL-DUL81

 

PRM-DUL-DUL82

 

PRM-DUL-DUL83

 

PRM DUL ORACLE 誤操作でDROP TABLESPACEしたデータをリカバリする

D社の職員があるいらないテーブルスペースを削除したいだが、つまりDROP TABLESPACE INCLUDING CONTENTS操作で、DROP TABLESPACEを実行したら、開發者がDROPされたTABLESPACEにSCHEMAという重要なデータがあるが、テーブルスペースがDROPされて、バックアップもないので、まさに万策尽きという状態である。

 

 

こういう時にやくに立てるのはPRMのNo-Dictモードで、DROP TABLESPACEされたすべてのフィルタを抽出してください。多くのデータがこの方法でリカバリできると思うが、非ディクショナリーモードなので、もう一度リカバリしてきたデータとアプリデータテーブルを対応する必要がある。この時に、アプリ開發者の協力が必要で、データはどこのテーブルに属しているのか人工的に判明する必要がある。DROP TABLESPACE操作がデータディクショナリーを変更した上で、OBJ$で該当するテーブルスペースの目標を削除したから、OBJ$からDATA_OBJECT_IDとOBJECT_NAMEの間の関係を得られない。この時に、以下の方法を活かし、DATA_OBJECT_IDとOBJECT_NAMEの関係をより多く手に入ることができる。

 

 

select tablespace_name,segment_type,count(*) from dba_segments where owner=’PARNASSUSDATA’  group by tablespace_name,segment_type; 

 

TABLESPACE SEGMENT_TYPE      COUNT(*)

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

USERS      TABLE                  126

USERS      INDEX                  136

 

SQL> select count(*) from obj$;

 

COUNT(*)

———-

75698

 

 

SQL> select current_scn, systimestamp from v$database;

 

CURRENT_SCN

———–

SYSTIMESTAMP

—————————————————————————

1895940

25-4月 -14 09.18.00.628000 下午 +08:00

 

 

 

SQL> select file_name from dba_data_files where tablespace_name=’USERS’;

 

FILE_NAME

——————————————————————————–

H:\PP\MACLEAN\ORADATA\PARNASSUS\DATAFILE\O1_MF_USERS_9MNBMJYJ_.DBF

 

 

SQL> drop tablespace users including contents;

 

テーブルスペースもう削除した

 

C:\Users\maclean>dir H:\APP\MACLEAN\ORADATA\PARNASSUS\DATAFILE\O1_MF_USERS_9MNBMJYJ_.DBF

 

ドライブの巻はentertainment

巻のシリアルナンバーはentertainment

 

 

フィルタが見つからない

 

drop tablespaceした後、TABLESPACEに該当するフィルタがOSで削除されたから。

 

 

 

 

この時に、フィルタリカバリツールでリカバリできる。

 

PRM-DUL-DUL65

 

PRMを起動する=> recovery Wizard =>非ディクショナリーモード

 

PRM-DUL-DUL66

 

PRM-DUL-DUL67

 

非ディクショナリーモードなので、自分からふさわしい文字セットを選ぶ必要がある。

 

PRM-DUL-DUL68

 

先リカバリしてきたフィルタをクリックしてスキャンする。

 

PRM-DUL-DUL69

PRM-DUL-DUL70

そしてセグメントヘッダあるいはディスク領域スキャンテーブルを選んでください。セグメントヘッダーがすべてのテーブルをひとつも漏れずに探し出すことができない場合に、ディスク領域でもう一度スキャンしてください。

 

PRM-DUL-DUL71

 

そして、インタフェースの樹形図にものすごく大量なOBJXXXXXのようなテーブルが現れる。ここのOBJXXXXXはテーブルのDATA_OBJECT_IDであって、そのシステムの開發応用モードに詳しい技術者がサンプルデータ分析を参照して、テーブルとアプリテーブルをつながる。

 

PRM-DUL-DUL72

 

 

もし、協力する技術者がいないなら、以下の方法を考えてください。

 

この例で使っているのはDROPしたTABLESPACEテーブルのスペースであって、データベース自身はなんの問題もないので、FLASHBACK QUERYを活かし、DATA_OBJECT_IDとテーブル名前のつながりを獲得できる。

 

SQL>  select count(*) from sys.obj$; 

COUNT(*)

———-

75436

 

 

 

 

 

 

 

SQL> select count(*) from sys.obj$ as of scn 1895940;

select count(*) from sys.obj$ as of scn 1895940

*

第一行がエラになり

 

ORA-01555:スナップショットが古すぎて、ロールバックセグメント番号(名は”SYSTEM”)が小さすぎる。

 

初めてはFLASHBACK QUERYでOBJ$の記録を見つけ出したいが、SYSTEM ROLLBACK SEGMENTを使ったことによって、ORA-01555になる。

 

この時にAWRビューDBA_HIST_SQL_PLANを使ってください。七天以内でそのテーブルにアクセスしたら実行計画からOBJECT#とOBJECT_NAMEのつながりが得られる。

 

SQL> desc DBA_HIST_SQL_PLAN

名称                                      是否为空? 类型

名前                  ブランクかいなか  タイプ

—————————————– ——– ———————–

DBID                                      NOT NULL NUMBER

SQL_ID                                    NOT NULL VARCHAR2(13)

PLAN_HASH_VALUE                           NOT NULL NUMBER

ID                                        NOT NULL NUMBER

OPERATION                                          VARCHAR2(30)

OPTIONS                                            VARCHAR2(30)

OBJECT_NODE                                        VARCHAR2(128)

OBJECT#                                            NUMBER

OBJECT_OWNER                                       VARCHAR2(30)

OBJECT_NAME                                        VARCHAR2(31)

OBJECT_ALIAS                                       VARCHAR2(65)

OBJECT_TYPE                                        VARCHAR2(20)

OPTIMIZER                                          VARCHAR2(20)

PARENT_ID                                          NUMBER

DEPTH                                              NUMBER

POSITION                                           NUMBER

SEARCH_COLUMNS                                     NUMBER

COST                                               NUMBER

CARDINALITY                                        NUMBER

BYTES                                              NUMBER

OTHER_TAG                                          VARCHAR2(35)

PARTITION_START                                    VARCHAR2(64)

PARTITION_STOP                                     VARCHAR2(64)

PARTITION_ID                                       NUMBER

OTHER                                              VARCHAR2(4000)

DISTRIBUTION                                       VARCHAR2(20)

CPU_COST                                           NUMBER

IO_COST                                            NUMBER

TEMP_SPACE                                         NUMBER

ACCESS_PREDICATES                                  VARCHAR2(4000)

FILTER_PREDICATES                                  VARCHAR2(4000)

PROJECTION                                         VARCHAR2(4000)

TIME                                               NUMBER

QBLOCK_NAME                                        VARCHAR2(31)

REMARKS                                            VARCHAR2(4000)

TIMESTAMP                                          DATE

OTHER_XML                                          CLOB

 

 

例えば

select object_owner,object_name,object# from DBA_HIST_SQL_PLAN where sql_id=’avwjc02vb10j4′

 

OBJECT_OWNER         OBJECT_NAME                                 OBJECT#

——————– —————————————- ———-

 

PARNASSUSDATA        TORDERDETAIL_HIS                              78688

 

 

 

 

Select * from

(select object_name,object# from DBA_HIST_SQL_PLAN

UNION select object_name,object# from GV$SQL_PLAN) V1 where V1.OBJECT# IS NOT NULL minus select name,obj# from sys.obj$;

 

select obj#,dataobj#, object_name from WRH$_SEG_STAT_OBJ where object_name not in (select name from sys.obJ$) order by object_name desc;

 

もう一つの例

SELECT tab1.SQL_ID,

current_obj#,

tab2.sql_text

FROM DBA_HIST_ACTIVE_SESS_HISTORY tab1,

dba_hist_sqltext tab2

WHERE tab1.current_obj# NOT IN

(SELECT obj# FROM sys.obj$

)

AND current_obj#!=-1

AND tab1.sql_id  =tab2.sql_id(+);

 

 

 

以上はユーザーがどうしてもリカバリしたいデータテーブルについて、なんの情報も得られない場合にしか使えない。(つまり、このアプリモードについてのひともスクリプトもテキストもない場合)、それにAWRデータに頼っていて、正確性には少し問題がある。

 

 

PRM DUL ORACLE ASMでSYSTEMテーブルスペースのリカバリを削除した(なくした)

D社の技術者は誤操作で一番大事なデータベースのSYSTEMテーブルスペースFILE#=1のフィルタと一部のアプリテーブルスペースを削除したことによって、データベースが順調に起動できない。

 

 

このシーンでPRMの《Non-Dictionary Mode(ASM) 》ASMの非ディクショナリーモードによって、今のデータフィルタに基づき、いちはやくデータをリカバリできる。

 

簡単な流れは以下の通り:

 

 

  1. Recovery Wizard
  2. Dictionary Mode(ASM)
  3. 必要なASM DISKを追加し(リカバリしたいデータベースを含むASM Disk GroupにすべてのASM DISK)
  4. ASM analyze クリックする
  5. あとのフィルタのために、ふさわしいEndianを選ぶ。(非ディクショナリーモードなので、人工で選ぶ必要がある)。
  6. ASM analzeのフィルタリストで必要とするデータフィルタを選んでください。一つのリポジトリしかない場合に、Select allを選んでください。
  7. ロードをクリックして、後のリカバリはシーン3に似ている。

PRM-DUL-DUL61

 

PRM-DUL-DUL62

 

PRM-DUL-DUL63

 

PRM-DUL-DUL64

 

PRM DUL ORACLE ASMの環境でデータベースが起動できない

D社の一番大事なCRMリポジトリがASM Diskgroupに追加したディスクがI/O問題があるから。SYSTEMテーブルスペースのDBFデータフィルタがエラになり、データベースが正常に起動できない。

 

この時はPRMを通って、ASM DiskgroupからDATAFILEを全部フィルタシステムにコーピーして、リカバリシーン6のように、データベースを修復する。

 

PRMのDictionary Mode(ASM)もASMのディクショナリーモードで問題を解決できる。簡単な流れは以下の通り:

 

  1. Recovery Wizard
  2. Dictionary Mode(ASM)
  3. 必要なASM DISKを追加し(リカバリしたいデータベースを含むASM Disk GroupにすべてのASM DISK)
  4. ASM analyze クリックする
  5. あとのフィルタのために、ふさわしいEndianを選ぶ。
  6. ASM analzeのフィルタリストで必要とするデータフィルタを選んでください。一つのリポジトリしかない場合に、Select allを選んでください。
  7. ロードをクリックして、後のリカバリはシーン3に似ている。

 

PRM-DUL-DUL56

 

PRM-DUL-DUL57

 

PRM-DUL-DUL58

 

PRM-DUL-DUL59

 

PRM-DUL-DUL60

RPM DUL ORACLE 壊されたASM Diskgroupからデータベースのデータを抽出する

D社はASM方法でフィルタシステムとRAWデバイスをかわったが、いま運用しているのは11.2.0.1バーションで、bugが多いので、ASM DISKGROUPディスくがMOUNTをロードできなくて、いろんな手を打ったが、なかなか効果が出ない。

 

このシーンで使えるのはPRMのASM Files Cloneフィルタコーピー機能です。この機能はダンメージを受けたASM Diskgroupからデータベースフィルタをコーピーできる。

1.インタフェースをオープンして、ToolsメニューコラムでASM File(s) Cloneを選んでください。:

 

PRM-DUL-DUL49

 

  1. ASM Disksに入って、SELECT…をクリックして、使用可能なASM Disksを追加する。例えば、/dev/asm-disk5(linux)。すべての使用可能なLUNを追加した後、ASM analyzeボタンをクリックしてください。

PRM-DUL-DUL50

 

PRM-DUL-DUL51

 

PRM-DUL-DUL52

 

ASM analyzeがDisk groupの中のフィルタとアドレス(File Extent Map)を見つけ出すために、指定されたASM Diskのディスクヘッダーを分析する。これらのデータは以後も使えるように、Derbyデータベースに記録される。ここで、PRMはASMあらゆるのMetadataを収集して分析して格納する。そして、いろいろな方法でPRMの基本的な機能を改善し、グラフの形式でユーザーに示す。

 

PRM-DUL-DUL53

 

ASM Analyzeが完成したら、PRMは探し出したASMのフィルタをリストにする。どれをコーピーする必要があるか、ユーザーが自分で決めて、コーピー先を指定することもできる。

PRM-DUL-DUL54

 

コーピー段階で、ASM Fileのコーピー進捗状況を示されて、完成したら、OKをクリックしてください。

 

PRM-DUL-DUL55

 

 

 

 

コーピー段階の進捗状況は以下のようにエクスポートする。

 

Preparing selected files… 

Cloning +DATA2/ASMDB1/DATAFILE/TBS2.256.839732369:

……………………..1024MB

………………………………..2048MB

………………………………..3072MB

………………………………….4096MB

………………………………..5120MB

………………………………….6144MB

……………………………….7168MB

…………………………………8192MB

…………………………………9216MB

…………………………………10240MB

…………………………………11264MB

…………………………………..12288MB

…………………………………….13312MB

…………………………….14336MB

……………………………………..15360MB

……………………………….16384MB

…………………………………17408MB

…………………………………18432MB

…………………………………………………………………………………………….19456MB

……………………………………

Cloned size for this file (in byte): 21475885056

 

Cloned successfully!

 

 

Cloning +DATA2/ASMDB1/ARCHIVELOG/2014_02_17/thread_1_seq_47.257.839732751:

……

Cloned size for this file (in byte): 29360128

 

Cloned successfully!

 

 

Cloning +DATA2/ASMDB1/ARCHIVELOG/2014_02_17/thread_1_seq_48.258.839732751:

……

Cloned size for this file (in byte): 1048576

 

Cloned successfully!

 

 

 

 

All selected files were cloned done.

 

 

 

Dbvあるいはrman validateコマンドによって、コーピーされたフィルタを確認できる。例えば:

rman target / 

 

RMAN> catalog datafilecopy ‘/home/oracle/asm_clone/TBS2.256.839732369.dbf’;

 

cataloged datafile copy

datafile copy file name=/home/oracle/asm_clone/TBS2.256.839732369.dbf RECID=2 STAMP=839750901

 

RMAN> validate datafilecopy ‘/home/oracle/asm_clone/TBS2.256.839732369.dbf’;

 

Starting validate at 17-FEB-14

using channel ORA_DISK_1

channel ORA_DISK_1: starting validation of datafile

channel ORA_DISK_1: including datafile copy of datafile 00016 in backup set

input file name=/home/oracle/asm_clone/TBS2.256.839732369.dbf

channel ORA_DISK_1: validation complete, elapsed time: 00:03:35

List of Datafile Copies

=======================

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN

—- —— ————– ———— ————— ———-

16   OK     0              2621313      2621440         1945051

File Name: /home/oracle/asm_clone/TBS2.256.839732369.dbf

Block Type Blocks Failing Blocks Processed

———- ————– —————-

Data       0              0

Index      0              0

Other      0              127

 

Finished validate at 17-FEB-14

 

 

 

では’、 ASMLIBを使っているASM環境はどうやってPRMを使うでしょう。

 

簡単に言うと、asmlibについてのASM DISKはOSでll /dev/oracleasm/disksの形式で保存する、例えば:/dev/oracleasm/disksでのフィルタをPRM ASM DISKに追加してすればいい。

 

$ll /dev/oracleasm/diskstotal 0

brw-rw—-  1 oracle dba 8,  97 Apr 28 15:20 VOL001

brw-rw—-  1 oracle dba 8,  81 Apr 28 15:20 VOL002

brw-rw—-  1 oracle dba 8,  65 Apr 28 15:20 VOL003

brw-rw—-  1 oracle dba 8,  49 Apr 28 15:20 VOL004

brw-rw—-  1 oracle dba 8,  33 Apr 28 15:20 VOL005

brw-rw—-  1 oracle dba 8,  17 Apr 28 15:20 VOL006

brw-rw—-  1 oracle dba 8, 129 Apr 28 15:20 VOL007

brw-rw—-  1 oracle dba 8, 113 Apr 28 15:20 VOL008

 

 

/dev/oracleasm/disksでのフィルタをPRM ASM DISKに追加してください

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と同じ。

PRM DUL ORACLE Oracleデータディクショナリーがダンメージを受け、データベースが起動できない

D社のDBAは誤操作でTS$データディクショナリーを削除したため、データベースが起動できない。

 

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit ProductionWith the Partitioning, Automatic Storage Management, OLAP, Data Mining

and Real Application Testing options

 

 

INSTANCE_NAME

—————-

ASMME

 

SQL>

SQL>

SQL> select count(*) from sys.ts$;

 

COUNT(*)

———-

5

 

SQL> delete ts$;

 

5 rows deleted.

 

SQL> commit;

 

Commit complete.

 

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

 

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-01405: fetched column value is NULL

Process ID: 5270

Session ID: 10 Serial number: 3

 

Undo initialization errored: err:1405 serial:0 start:3126020954 end:3126020954 diff:0 (0 seconds)

Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc:

ORA-01405: fetched column value is NULL

Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc:

ORA-01405: fetched column value is NULL

Error 1405 happened during db open, shutting down database

USER (ospid: 5270): terminating the instance due to error 1405

Instance terminated by USER, pid = 5270

ORA-1092 signalled during: ALTER DATABASE OPEN…

opiodr aborting process unknown ospid (5270) as a result of ORA-1092

 

 

 

このシーンでデータディクショナリーは既に壊されたから、データベースを起動するのは不可能だ。

 

 

このとき、PRMでデータベースのデータを抽出することができる。具体的な操作はシーン1とほぼ同じ、ユーザーがデータベースにあるすべてのデータベースフィルタを入力しただけでいい。

2.ディクショナリーモードを選んでくださいDictionary Mode

3. BigかLittle Endianを選ぶにはよく考えてください

4.データフィルタを追加してロードをクリックしてください。

5.実際に応じて、テーブルのデータをリカバリしてください。

 

PRM-DUL-DUL36

 

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569