ユーザデータベースのリカバリ時に発生したトラブルの事例、およびその対処方法について説明します。
DSIを再作成後にrdbrcvコマンドでDSIをリカバリしようとすると、メッセージ qdg02668u が出力される
DSIを再作成したあとで、rdbrcvコマンドでDSIをリカバリしようとすると次のメッセージが出力されます。
qdg02668u: 指定した“資源名”が退避データの内容と違います
バックアップデータとDSIの整合性はDSI名以外の情報でも管理しているため、DSIを再作成すると、それ以前に取得したバックアップデータは使用できなくなります。
なお、DSIの再作成以外に、以下のような場合にバックアップデータが使用できなくなります。
ディクショナリを再作成した場合
“qdg12284u RDBIIディクショナリの再作成以前に取得された退避データが指定されました”というメッセージが表示されます。
容量変更を伴うrdbgcdsiコマンドを実行した場合
容量変更を伴うrdbfmtコマンドを実行した場合
分割値を変更するALTER DSI文を実行した場合
“qdg02202u 退避データはDSIの容量変更もしくは DSI分割値変更以前に取得されたものであるため処理できません”というメッセージが表示されます。
注意
上記のような操作を行った場合は、必ずバックアップデータを再取得してください。
ポイント
rdbdmpコマンド以外に、rdbunlコマンドを利用したデータのバックアップ手段があります。
rdbunlコマンドを利用して取得したバックアップデータは、上記のどの操作を行った場合でも利用できます。バックアップデータとしての違いは以下のとおりですので参考にしてください。
rdbdmpコマンドによるバックアップデータ
アーカイブログ運用を実施していることで、異常発生時に常に最新の状態にリカバリできます。
rdbunlコマンドによるバックアップデータ
対象DSIの状態に関わらず、データをバックアップ時点へリカバリできます。
RDBディクショナリのバックアップデータを取得しておかないと、アクセス禁止状態になった場合にリカバリできない
RDBディクショナリに入出力障害が発生すると、アクセス禁止状態になります。RDBディクショナリがアクセス禁止状態になった場合、リカバリを行うまでSymfoware/RDBの起動ができません。
リカバリを行うためには、あらかじめRDBディクショナリのバックアップデータを取得しておく必要があります。RDBディクショナリがアクセス禁止状態になった場合に、バックアップデータがなければRDBディクショナリはリカバリできないため、rdbcrdicコマンドでRDBディクショナリの再作成からやり直すしかありません。この場合、RDBディクショナリ配下のすべてのデータベース資源を失います。
また、データベース(DSI)のバックアップデータをrdbdmpコマンドで取得している場合、rdbrcvコマンドでのリカバリを行うためには、rdbdmpコマンド実行時のRDBディクショナリが必要となります。RDBディクショナリを再作成した場合、RDBディクショナリの再作成前に取得したrdbdmpコマンドのバックアップデータは使用できません。
データベース(DSI)のバックアップデータを、毎日、取得していても、RDBディクショナリのバックアップデータは取得していないというケースが多くありますが、異常時に備えてRDBディクショナリについてもバックアップデータを取得するようにしてください。
なお、データベースの定義変更やDSIの自動容量拡張が行われると、RDBディクショナリが更新されますが、RDBディクショナリが更新されると、RDBディクショナリのバックアップデータとデータベース(DSI)の間で不整合が発生します。
したがって、定義変更を行った場合は、RDBディクショナリのバックアップデータを再度取得するか、アーカイブログ運用を行ってリカバリ時にバックアップデータ取得時からのアーカイブログを適用する必要があります。DSIの自動容量拡張については、拡張が自動的に行われるので、アーカイブログ運用を行ってリカバリ時にバックアップデータ取得時からのアーカイブログを適用する必要があります。
rdbcrdicコマンドを実行してしまうと、現在使用しているアーカイブログの内容がリセットされてしまいます。rdbcrdicコマンド実行後にRDBディクショナリのバックアップデータからリカバリを行おうとしても、アーカイブログ適用時にエラーとなってリカバリできないので、rdbcrdicコマンドの実行には注意してください。
参照
RDBディクショナリのバックアップ方法については、“RDB運用ガイド”を参照してください。
以下に、RDBディクショナリバックアップ時のチェックポイントを示します。
チェックポイント | 対処 | ||||||
|---|---|---|---|---|---|---|---|
RDBディクショナリのバックアップデータを取得しているか | |||||||
| 取得していない | RDBディクショナリがアクセス禁止になった場合、RDBディクショナリ配下の資源のリカバリは諦めて、RDBディクショナリの再作成を行ってください。 | |||||
取得している | |||||||
| DSIの自動容量拡張を設定しているか、または、表定義時に格納領域指定('ON データベーススペース名'を指定)を行っているものがあるか | ||||||
| 設定している | ||||||
| アーカイブログ運用を行っているか | ||||||
| 行っていない | DSIの自動容量拡張が行われている場合、データベースとRDBディクショナリのバックアップデータの間が不整合な状態です。 | |||||
行っている | RDBディクショナリのリカバリ時にアーカイブログを適用します。 | ||||||
設定していない | 定義変更を行った場合は、RDBディクショナリのバックアップデータを取得し直してください。 | ||||||
ポイント
高信頼性システムにおいては、アーカイブログ運用を行い、バックアップデータも複数世代採取してください。
DSIに対してアクセス禁止状態が設定された場合、メディアリカバリを実施するがバックアップがないためリカバリできない
DSIに対してアクセス禁止状態が設定された場合、メディアリカバリを実施することでデータベースをリカバリできます。しかし、データのバックアップやアーカイブログを取得していない場合にはデータベースをリカバリできません。
このような状況において、コントローラ異常や一時的なOSの資源不足などが原因で、ディスク自体は損傷を受けていない場合は、以下のようにディスク上に残っているデータを強制的に出力することができます。
アクセス禁止状態が設定されているDSIに対してrdbunlコマンドを使用して強制的にデータベースのデータを出力してください。
出力されたデータの内容を確認してください。強制的に出力した場合、レコードが不足したり、不整合なデータが含まれたりする可能性があります。問題がある場合は適宜修正してください。
出力したデータは、rdbsloaderコマンドなどを使用してロードすることが可能です。
注意
上記の操作は救済措置の位置付けであり、必ずしもデータを完全に出力できることを保証するものではありません。緊急時以外には使用しないでください。また、ディスク異常に備えてバックアップを取得するようにしてください。
以下に事例を示します。
事例：
I/Oエラーが発生し、該当データベーススペースに割り付けられているDSIに対してアクセス禁止状態が設定されてしまった。
CE調査の結果、ディスクのコントローラ異常が発生しているが、ディスク自体は損傷を受けておらず交換の必要はない。しかし、アーカイブログが同時にアクセス禁止状態に設定され、また、退避データも過去のものしか残っていないため、メディアリカバリを実施できない。
この場合に、ディスク上に残っている最新データを使用して業務を再開したい。
アクセス禁止状態の表のDSIからデータを強制的に出力します。
例
rdbunl -i データベース名.表のＤＳＩ名 -e /home/rdb2/unl1_e.dat
注意
異常を検知したページは読み飛ばされます。その場合、以下のような詳細情報がRDB構成パラメタファイルのRDBCOREで指定したディレクトリに出力されます。
pagedump_内部時間情報
pageinf_内部時間情報
また、詳細情報の最大出力サイズはDSIのサイズとなります。
なお、I/Oエラーなどの要因により詳細情報の出力が失敗した場合、詳細情報の出力を中止し、データの抽出を続行します。
RDB構成パラメタファイルの詳細については、“セットアップガイド”を参照してください。
出力したデータが正しいか確認してください。不当である場合は適宜修正してください。
注意
データを出力したファイルには、本来存在すべきレコードが欠損していたり、重複キーを持つレコードが存在している可能性があります。そのため、ファイルの内容は必ず確認してください。
なお、出力したデータはrdbsloaderコマンドなどを使用してロードすることが可能です。
