Author: mac

Block Corruption 造成的影响 对商业运行造成的直接影响 数据损坏导致业务停止 数据恢复时间变长 修复工作发生错误，造成二次灾害 寻找原因的时间变长 数据损坏的主要原因 复杂并且有可能被分割的Layer的风险 系统中数据保护的机制 § 单个系统中，考虑到了一些无法防御的的风险的机制。 –    例：因为人为错误删除数据时，在RAID结构中无法防御。 § 复制数据中保护一致性与确实性的机制。 –    例：部分备份导致的数据完整性的欠缺。 § 考虑到迅速切换以及确实的修复的机制。 –    例：由于灾害恢复训练不足，实际上无法切换，无法返回的备份。 为了确实地能提高工作的可持续性需要什么？ Oracle Maximum Availability Architecture § Maximum Availability Architecture (MAA) 是基于oracle验证完成的高可用性的数码与成功事例的最佳实践。 § MAA的目的 –    为了修复、查出、规避所有的停止的情况提供最优实践。 –    在样本中构成最优的高可用性的架构。 § 不受硬件以及OS影响（不需要特定的高价的产品以及技术） § 马上就可以提供高可用性的解决策略（Oracle事先完成验证） 高可用性的数码的最佳实践。 Oracle MAA 的整体映像 Low-Cost, Integrated, Fully Active, High ROI Oracle…

Data Pump(数据泵)是什么   与到10g以前的exp/imp（原始的导入/导出）相同的功能+有更多的附加功能与新功能 数据以及源数据的高速加载、卸载 比Exp/imp速度高几倍 与Exp/imp 相同的功能，进一步的附加功能 并行处理、外部表 exp/imp的互换性 exp/imp 与Data Pump中，转储文件没有互换性 10g中也可以使用exp/imp功能   使用方法 expdp/impdp命令 Enterprise Manager DBMS_DATAPUMP PL/SQL package 其他，外部表等作为引擎来内部使用 相关资料 Oracle Database Utility 　11g 发行版本1（11.1） http://otndnld.oracle.co.jp/document/products/oracle11g/111/doc_dvd/server.111/E05768-02/toc.htm   Data Pump 概要图   expdp/impdp与exp/imp比较     Data Pump的导出工具(expdp) Expdp中可以使用的模式   — full 全库导出 示例， 一般不推荐全库导出！因为一般你都是导出你的应用程序用户数据啊！！你要SYS/SYSTEM的数据干什么呢？对不对啊！ $ expdp scott/tiger full=y — 表模式例 $ expdp…

ORACLEデータベース によくあるエラ の解決策 プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]   前週で、お客様からOracle Bugによって、テーブルデータブロックロジックエラでORA-00600:[13013], [5001]を引き起こした例をもらった。ここで、よりうまく説明できるように、人工的にそのエラをシミュレーションする発想が生み出した。 基礎的な知識 Oracleにテーブルのデータブロックはブロックへっだ、トランザクションスロット、行ディクショナリー、及び行データなどいろんな構造で組み立てた。行データは行数据(rowdata)いろんなrow piece によって組み立てる。各row pieceのヘッダにflag、locks、cols(cc)三つのマーク位置がある。 そのflagはrow pieceのタイプをマークした。そのflag位置は一つのバイトを占めて、違ったbit位置が違った意味を意味している。以下の通り：     ROW_CLUSTER_KEY = 0x80; KDRHFK ROW_CTABLE_NUMBER = 0x40; KDRHFC ROW_HEAD_PIECE = 0x20; KDRHFH ROW_DELETED_ROW = 0x10; KDRHFD ROW_FIRST_PIECE = 0x08; KDRHFF ROW_LAST_PIECE = 0x04; KDRHFL ROW_FROM_PREVIOUS = 0x02; KDRHFP ROW_CONTINUE_NEXT = 0x01; KDRHFN 一般的に、もっとも普通なrow…

ORACLEデータベース によくあるエラ の解決策 プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]   今のORACLE PRM-DUL はORACLE ASMのファイルコピ機能を無料で使える。詳しい内容はhttp://www.parnassusdata.com/に参考してください   AMDUはORACLEがASM開發に対するソースデータダンプツールで、その名前はASM Metadata Dump Utility(AMDU)である。 AMDUに以下のような三つの機能がある： より簡単に分析できるように、ASM DISKのソースデータをファイルシステムに移す。 2. ASMファイルの内容を抽出してOSファイルシステムに書き込む。 3. ブロックのソースデータを印刷して、ブロックのｃ言語構造あるいは16進数の形式を利用する。 ここで、AMDUでASM DISKGROUPからデータファイルを抽出する。ASMは最近流行っているストレージ解決策として、みんながASMのメリットもデメリットもよく知っている。DISKGROUPがMOUNTできなくなった場合に、伝統的なやり方で、何のデータもエクスポートできなくなる。 AMDUはこのトラブルを解決した。ここで、ASM DISKGROUP がMOUNTできなくなる場合を検討して、RDBMSデータファイルにASMエラが現れたことについて検討しない。 注意：AMDUが11gでリリースしたばかりのツールだが、実際には10gのASMに対しても有効である。 よくある場合は以下の通り： ORACLE DATABASEのSPFILE、CONTROLFILE、DATAFILEがASM DISKGROUPに格納していて、ASM ORA-600エラでDISKGROUPをMOUNTできなくなった。ここで、AMDUでファイルをASM DISKからダンプしてください。 シーン 1 　SPFILE、CONTROLFILE、DATAFILEをなくした リカバリステップ： バックアップからSPFILEをリカバリして、SPFILEがなければ、PFILEでもいい。とにかく、バラメタファイルからcontrol_filesの情報が欲しい・ SQL> show parameter control_files NAME TYPE VALUE ———————————— ———– —————————— control_files string…

ORACLEデータベース によくあるエラ の解決策 プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]   AMDUはORACLEに対するASM開發のソースデータダンプツールで、その名前はASM Metadata Dump Utility(AMDU)，、《AMDUツールでMOUNTできなくなったDISKGROUPからデータファイルを抽出する》でAMDUデータベースファイルの抽出方法を紹介した、 今日はAMDUにDUMPダンプモードで作成されたMAPファイルの意味を紹介する。 DUMPモードで、AMDUはDISKGROUPのIMAGEファイルを作成して、MAPファイルも作成する:     [oracle@lab1 oracle.SupportTools]$ ./amdu -diskstring ‘/dev/asm*’ -dump DATA amdu_2012_09_24_02_14_12/ AMDU-00204: Disk N0002 is in currently mounted diskgroup DATA AMDU-00201: Disk N0002: ‘/dev/asm-diskb’ [oracle@lab1 oracle.SupportTools]$ cd amdu_2012_09_24_02_14_12/ [oracle@lab1 amdu_2012_09_24_02_14_12]$ head -10 DATA.map N0002 D0000 R00 A00000000 F00000000 I0 E00000000…

ORACLEデータベース によくあるエラ の解決策 プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]   以下のスクリプトはASMでdisk headerをリカバリするときに使える：     Ddに有効なmetadata block :   #! /bin/sh rm /tmp/kfed_DH.out /tmp/kfed_FS.out /tmp/kfed_BK.out /tmp/kfed_FD.out /tmp/kfed_DD.out /tmp/kfed_PST.out for i in `ls /dev/asm-disk*` do echo $i >> /tmp/kfed_DH.out kfed read $i >> /tmp/kfed_DH.out echo $i >> /tmp/kfed_FS.out kfed read $i blkn=1 >> /tmp/kfed_FS.out echo $i >>…

ORACLEデータベース によくあるエラ の解決策 プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]     春節前に、友のために、電源が切れた後、起動できなくなった10.2.0.1データベースを起動できた。そのデータベースはアーカイブモードではない上に、何のバックアップもない。 電源が切れたあと、データベースインスタンスを再起動してみたが、ORA-00600:[kccpb_sanity_check_2内部エラが現れた:   SQL> select status from v$instance; STATUS ———— STARTED SQL> SQL> shutdown immediate; ORA-01507: database not mounted ORACLE instance shut down. SQL> startup mount; ORACLE instance started. Total System Global Area 2147483648 bytes Fixed Size 1220432 bytes Variable Size 486539440 bytes Database…

ORACLEデータベース によくあるエラ の解決策 プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]     “BBED(Oracle Block Brower and EDitor Tool)はデータファイルを確認や修正するツールで、Oracleの内部ツールである。Oracleデータファイルブロックの内容を直に修正できる。簡単に言えば、Oracleバイナリ編集ツールである。このツールはOracleに支持されていない。ディフォルトに実行できるファイルがないから、使う前に、再編集する必要がある。”   10gでそのツールを編集するのが難しくない:   [maclean@rh2 ~]$ cd $ORACLE_HOME/rdbms/lib [maclean@rh2 lib]$ make -f ins_rdbms.mk $ORACLE_HOME/rdbms/lib/bbed make: `/s01/10gdb/rdbms/lib/bbed’ is up to date. [maclean@rh2 lib]$ rm bbed [maclean@rh2 lib]$ make -f ins_rdbms.mk $ORACLE_HOME/rdbms/lib/bbed Linking BBED utility (bbed) rm -f /s01/10gdb/rdbms/lib/bbed gcc -o…

ORACLEデータベース によくあるエラ の解決策 プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]     _OFFLINE_ROLLBACK_SEGMENTS(offline undo segment list)隠しバラメタ(hidden parameter)の特別使い道： インスタンスstartupを起動して、データベースを起動する場合にも_OFFLINE_ROLLBACK_SEGMENTSに挙げたUndo segments(削除セグメント/ロールバックセグメント)を読み取れる。もしこれらのundo segmentsにトラブルがあれば、ほかのlogと別のTRACEに現れるが、実際のstartupプロセスに影響を与えない。 もしデータブロックにアクチブなトランザクションがあって、ITLも該当するundo segmentsに指せば： もしundo segmentsの.transaction tableトランザクションテーブルを読み取れば、トランザクションが既に挙げられたことを気づき、データブロックをクリンアップすることを実行する。 もしトランザクションがアクチブだが、コミットされていないことを気づいたら、CRブロックコピが作成される そのundo segmentsにトラブルがあれば、(corruptedエラかもしれない、あるいはmissedがなくした)エラをlogにエクスポートして、クエリが中止される。 もしDMLが関するデータブロックをアップグレードすれば、サビースプロセスがアクチブトランザクションをリカバリするために、デッドロップに落ちて、大量なCPUを使う。解決策はクエリで関するテーブルを再構造する。   _offline_rollback_segments も _corrupted_rollback_segments もインスタンスを変化させる： 以上二つのバラメタに挙げたUndo Segments(削除セグメント/ロールバックセグメント)はオンラインで使われない UNDO$データディクショナリーベーステーブルで、OFFLINEと示した記録 インスタンスで新たなトランザクションに使われない バラメタに挙げたUndo Segmentsリストのアクチブトランザクションactive transactionはロールバックされない。それに、デッドとマークされない。 (みんなも知らないSMON機能(五):Recover Dead transaction)      

ORACLEデータベース によくあるエラ の解決策 プロのOracle Databaseの復旧サービスを提供 携帯番号： +86 13764045638 メール：[email protected]   _CORRUPTED_ROLLBACK_SEGMENTS(corrupted undo segment list)隠しバラメタしか持っていない機能: インスタンスにstartupを起動して、データベースを起動する段階：_CORRUPTED_ROLLBACK_SEGMENTSにあげたundo segments(削除セグメント/ロールバックセグメント)が読み取らない これらの_CORRUPTED_ROLLBACK_SEGMENTSによって挙げられたundo segmentsのトランザクションもコミットされたと認められて、今のundo segmentsはドロップの時に似ている： これはかなりひどいロジックエラに導く もしデータディクショナリーにアクチブトランザクションがあれば、より深刻な状況になる。データディクショナリーロジックエラはデータベース管理トラブルに導く。 もしbootstrapコアオブジェクトにアクチブトランザクションがあれば、ORA-00704: bootstrap process failureエラが無視できなくなって、データベースを強制的に起動できなくなる。（Oracleデータリカバリ:ORA-00600:[4000] ORA-00704: bootstrap process failureの解決例に参考してください) _CORRUPTED_ROLLBACK_SEGMENTSというバラメタでデータをエクスポートして、データベースを再構造する。けど、このバラメタを使うと、後始末がかなりめんどくさくなる。 Oracle社内でTXCheckerというツールでトラブルトランザクションを検知できる     _offline_rollback_segments も_corrupted_rollback_segments もインスタンスを変化させる： 以上の二つのバラメタに挙げられたUndo Segments(削除セグメント/ロールバックセグメント)はオンラインで使わないようにされる UNDO$データディクショナリーベーステーブルにOFFLINEと示した記録 インスタンスは新たなトランザクションに使われない バラメタに挙げられたUndo Segmentsリストにアクチブトランザクションactive transactionはロールバックされない、deadとマックされない。(みんなも知らないSMON起動(五):Recover Dead transaction)