技術ブログ
引き続き、来週の特濃JPOUG | Japan Oracle User Groupの準備をしつつ、いろいろ検証しております。物理破損関連で、面白い機能を見つけたので紹介します。
データへのアクセス時に物理破損を検知すると、ORA-1578が発生します。このとき、シングル環境の場合は一般に以下の方法で破損を修復します。
しかし、11.2以降のData Guardのフィジカルスタンバイ環境で、リアルタイム問い合わせを有効にしている場合は、これらの方法を使用する必要がありません。破損が発生していないスタンバイデータベースのブロックが自動的にプライマリデータベースに転送され、このブロックのデータをもとにブロックリカバリが実行されます。これを Automatic Block Media Recovery(Auto BMR) と呼びます。
なお、破損データにアクセスするSQLを実行したアプリケーションにはORA-1578が返されず、リカバリされた正常なデータが返されます。アプリケーションには、物理破損があったことすらわからない形になります。
Auto BMRを使用するには、スタンバイデータベースをリアルタイム問い合わせモードにする必要があります。すなわち、スタンバイデータベースを読み取り専用でオープンしているし、この状態で管理リカバリモードを有効にしている必要があります。また、リアルタイム問い合わせモードを使用するためには、Active Data Guard オプションのライセンスが必要ですので、必然的にAuto BMRもActive Data Guard オプションのライセンスが必要になります。
以下に、Auto BMRが実行されたときのプライマリデータベースのアラートログを抜粋します。ABMRというバックグラウンドプロセスが、Auto BMR処理を実行していることがわかります。
Sat Nov 09 05:33:20 2013 Hex dump of (file 5, block 134) in trace file /u01/app/oracle/diag/rdbms/c101p/c101p/trace/c101p_ora_3658.trc Corrupt block relative dba: 0x01400086 (file 5, block 134) Bad check value found during multiblock buffer read Data in bad block: type: 6 format: 2 rdba: 0x01400086 last change scn: 0x0000.0008a633 seq: 0x1 flg: 0x06 spare1: 0x0 spare2: 0x0 spare3: 0x0 consistency value in tail: 0xa6330601 check value in block header: 0xddb4 computed block checksum: 0x1a05 Reading datafile '/u01/app/oracle/oradata/c101p/tbs1.dbf' for corruption at rdba: 0x01400086 (file 5, block 134) Reread (file 5, block 134) found same corrupt data (no logical check) Starting background process ABMR Sat Nov 09 05:33:20 2013 ABMR started with pid=35, OS id=3710 Sat Nov 09 05:33:20 2013 Automatic block media recovery service is active. Sat Nov 09 05:33:20 2013 Automatic block media recovery requested for (file# 5, block# 134) Sat Nov 09 05:33:21 2013 Automatic block media recovery successful for (file# 5, block# 134) Sat Nov 09 05:33:21 2013 Automatic block media recovery successful for (file# 5, block# 134)