アサーションが表示されましたが、どうしたらよいですか？

この資料では、アサーション失敗のエラーが発生した場合の対策について説明します。

データベース・サーバまたはエンジンが”フリーズ”して、サーバ・ウィンドウまたは出力ログに「***ERROR*** Assertion failed (***エラー***アサーションに失敗しました）」というメッセージとそのエラー番号や詳細情報が表示されることがあります。アサーションは最終チェックに失敗した結果です。その後、不良なデータよりも状態が良いデータは存在しないという原則に従い、サーバはフリーズします。この防御メカニズムによって、データベースが使用できなくなることがあります。

対策

1. 可能な場合は、破壊されたデータベースに新しいデータを追加するのを中止します。どのような問題が発生していても、自体の悪化を招く可能性があるからです。

2. すぐにデータベースとログ・ファイルのコピーを作成します。既存のバックアップを上書きしてコピーを作成しないでください。Dbbackupは破壊されたデータベースに対しては機能しなくなる可能性があるため、サーバを停止してファイルをコピーします。

3. 修復作業中に、データベースを読み込んだまま使用し続ける必要がある場合は、既存のログ・ファイルの名前を変更して、新しいログ・ファイルを作成できるようにします。データベースを起動できず、SQL Remote、Rep Agent、またはMobile Linkを使用してレプリケーションを行っていない場合は、”dbeng?? -f dbfile.db”というコマンドを発行し、ログを使用せずにデータベースを1回だけ強制的に起動して停止する必要があります。??には、実行中のエンジンのバージョン(50、6、または7)を指定します。dbfile.dbは、使用するデータベース・ファイルの名前に置き換えます。

アサーションを回避するには?

アサーション・エラーを防ぐには、適切なバックアップと検証が大切です。
dbvalidユーティリティでは、データベースの潜在的な破壊をすべて検出するのは困難ですが、多くの場合、シンプルな解決策でありながら問題を検出することができます。運用時間外に検証を行うようにスケジュールを組むか、またはこの目的に特化したコンピュータを使用してオフラインで検証を行うとよいでしょう。ユーザ・マニュアルでは、dbvalidの使い方やオプションが詳しく説明されていて、バックアップを実行する前に健勝を行うように推奨されています。これは、簡単で便利な作業ですが、次に示す手順よりも完璧ではありません。

1. ハード・ディスクへのバックアップを実行します。

2. バックアップしたファイルをテープにコピーします。

3. ハード・ディスク上のコピーに対してdbvalidを実行します。この操作は、検証プロセスでネットワーク・サーバのリソースが消費されないように、独立したコンピュータ上で行ってもよいでしょう。

4. ***このデータベースのコピーを廃棄します***。dbvalidを実行するためであっても、すでにオープンされているバックアップは、バックアップではなくなります。運用データベースによって生成される以降のログ・ファイルは、このコピーには適用されません。バックアップをテープまたは他の安全な場所にコピーする前に検証しないでください。

5. ASA6 または7を実行している場合は、ルール4の代わりに-rスイッチを使用してエンジンを読み込み専用モードで起動することも可能です。この方法でオープンしたデータベースにはチェックポイントは書き込まれないため、エンジンを安全に起動して、アーカイブする前に検証することができます。データベースが大きい場合は、この方法で時間やリソースを大幅に節約できます。

dbbackupコマンドはマニュアルでも説明されています。プロセスの一部には、ログ・ファイルの管理（削除して再開、または名前を変更して再開）を含めることができます。データベースのバックアップ・コピーを現時点で運用できる状態にするには、そのバックアップ以降のすべてのログ・ファイルを適用する必要があります。そのため、バックアップのアクティブなログ・ファイルを削除する場合は、必ずそのログを安全な場所にコピーしておいてください。バックアップ・ディレクトリ内のファイルを上書きする場合は、そのファイルをテープにバックアップする前に上書きしないでください。プロセスの設計が不十分な場合は、バックアップを行い過ぎるのも、バックアップを怠るおと同じくらい良くありません。
リカバリ・ポイントは必ず複数設定してください。１日単位のバックアップを１週間保存する場合は、１ヶ月前と6ヶ月前のバックアップとともに、最近６ヶ月以内の全てのログ・ファイルも保存してください。破壊の形態によってはバックアップ・プロセスでリカバリできない場合もあるため、破壊されていないバックアップを見つけられるようにすることが必要です。

レプリケーションを行っていますが、何か特別な作業が必要ですか？

レプリケーションはログとオフセットに基づいて行われ、再構築されたデータベースのオフセットと元のデータベースのオフセットには違いが生じます。そのため、データベースをトランザクション・ログなしで起動することは避け、データベースはできるだけ再構築しないようにしてください。バージョン6にはデータベースのオフセットを解消してレプリケーションを続行できる機能が追加されています。バージョン6.0.3以降には、データベースの再構築およびログの処理を１つの手順で行えるオプションがあります。ただし、これらの手順を試すには、データベースを破棄する必要がある場合に備えて、必ずデータベースのコピーを作成しておいてください。

統合データベースを再構築したりログ・ファイルから作成しなおす際に、オフセットを解消できない場合は、すべてのリモート・ユーザを再抽出する必要があります。
リモート・データベースが破壊され、他の方法ではリストアできない場合は、そのリモート・データベースを再抽出する必要があります。再抽出の時点で移動中のデータは、SQL Remoteによって拒否されます。再抽出を実行する前に、リモート・データベースからできるだけ多くの情報を統合データベースに引き出しておいてください。

有効なバックアップがありますが、どのようにしてログ・ファイルを適用すればよいですか？

破壊されたデータベースに対しては、バックアップとそれ以降のログを適用することが最適な解決策です。バックアップのコピーを十分にテストして、その有効性を確かめます。dbvalidを実行すると、ほとんどの問題を検出できます。最も完璧なテスト方法は、dbunloadユーティリティを使用してデータベースをアンロードすることです。これによって、データベースにアのすべてのレコードにアクセスできます。アンロードの際にエラーが発生しなければ、そのバッカップは良好である可能性が高いと言えます。データベースのアンロードを実行するには、そのデータベースの2倍のサイズが必要になります。この条件にパスして、ログ・ファイルの適用に成功したら、アンロードによって作成されたファイルを削除できます。詳細はマニュアルを参照するか、またはコマンド・ラインから”dbunload/?”と入力して、dbunloadコマンドの構文を参照してください。バックアップの有効性を確認したら、テスト済みのコピーを廃棄します。新しいコピーをリストアしてログを適用します。データベース・ファイルのバックアップ以降に、ログ・ファイルがトランケートされていない場合は、現在のログを適用するだけですみます。構文は次のとおりです。

dbeng?? dbfile.db -a dbfile.log

ここで、??は使用しているソフトウエァのバージョンに対応し、dbfile.dbはバックアップ済みのデータベース・ファイル、dbfile.logはアクティブなログ・ファイルです。これらのファイルが現在のディレクトリに格納されていない場合は、そのパスを指定します。

ログ・ファイルをトランケートしている場合は、データベースとともにバックアップされたログから順番に、それぞれのログ・ファイルを適用する必要があります。なぜなら、データベース・ファイルをバックアップする際にログ・ファイルがアクティブな状態で、トランザクションやチェックポイントが発生する可能性があるからです。名前の重複を避けるため、データベース・ファイルは専用のディレクトリに配置し、各・ログ・ファイルは、上記の構文を使用して順番に適用します。新しいログ・ファイルは、データベースと同じディレクトリに作成されるか、またはログ・ファイルが通常格納されるディレクトリに作成されます。
このプロセスによってレプリケーションが壊れることはありません。

バックアップがないか、または壊れていますが、ログ・ファイルは１日目からトランケートされていません。

全ての内容が含まれたログ・ファイルを１つ使用して、データベース全ｔ内を作成しなおすことができます。新しいデータベースを使用すると、オフセットを解消できない場合は、レプリケーションが壊れます。このプロセスでは、新しいデータベースを作成して、ログ・ファイルを変換してSQLコマンド・ラインを作成し、ISQL/DBISQLを使用してSQLファイルを読み込みます。このプロセスの詳細は、次のURLに掲載されている技術資料#1010802で説明しています。

http://my.sybase.com/detail/1,3693,1010802,00.html

有効なバックアップがなく、ログ・ファイルがいくつかのポイントで再開されています。自分のデータベースをロードできません。

“File is shorter than expected (ファイルは予想よりも短いです）”というアサーションが表示された場合は、データベースやログ・ファイルが格納されているボリュームか、またはテンポラリ・ファイルが書き込まれるボリュームのハード・ディスク容量が不足している可能性があります。この動作はバージョン5.5.05以降では改善されているため、ソフトウェアをアップグレードして、今後この問題が起こらないようにしてください。

この種のアサーションは、弊社の”DELSIZE.EXE”というユーティリティを使用して簡単に解決できる場合があります。この問題は技術サポートの事例を参照して解決することができます。一方、予想よりも短かったのがログ・ファイルで、レプリケーションを行っていない場合は、ログ・ファイルを移動/削除/アーカイブしてから、エンジンを-fスイッチ付きで起動し、強制的にログ・ファイルなしでエンジンを実行するだけで問題を解決できます。
その問題でエンジンを起動できない場合は、-hoスイッチ付きでエンジンを起動すれば処理を開始することができます。この方法では、データベースはロールバック・ログなしで開始されます。この場合、データベースを使用し続けるにはデータベースを再構築する必要があります。データベースをロールバック・ログなしで開始すると、参照整合性のエラーが発生したり、インデックス・エントリが失われたり重複したり、外部キーの違反が発生します。データベースを再構築すれば、これらの問題が解消されます。
繰り返しますが、これらのスイッチを適用する前に、破壊されたデータベースのコピーを作成してください。データベースを弊社に送ってパッチを当てる場合は、これらの操作が適用されていないコピーが必要です。

有効なバックアップがなく、ログ・ファイルがいくつかのポイントで再開されています。エンジンはデータベースをロードしますが、頻繁にアサーションが発生したりクラッシュします。

データベースをロードできる場合は、そのデータベースを再構築することができます。データベースを再構築するには、Sybase Centralを使用するか、バッチ・ファイルの「rebuild.bat」を使用するか、またはdbunloadユーティリティを使用します。最初の2つのオプションは、デフォルト・スイッチを前提にしています。これらのオプションが機能しない場合は、dbunloadを-uスイッチ付きで実行してみてください。
Dbunload -uコマンドは、順不同のアンロードを実行します。つまり、ASCIIファイルに書き込まれるデータの順番を決めるためにインデックスは使用されません。これらのインデックスはデータベースを再構築する際に作成し直されますが、インデックスが破壊されている場合は、これによって問題が解決される可能性があります。

有効なバックアップがなく、ログ・ファイルがいくつかのポイントで再開されています。エンジンはデータベースをロードしますが、頻繁にアサーションが発生したりクラッシュします。１つまたは複数のテーブルで、Dbunloadがアサーション・エラーを起こして失敗します。

アサーション・エラーを起こすテーブルの数が比較的少ない場合は、次のURLに掲載されている資料#1010806「Assertion Error – 50213/200601 dbunload Fix Procedure」で説明されている手順で、ほとんどのデータを救出することができます。

http://my.sybase.com/detail/1,3693,1010806,00.html

上記のいずれの方法でも問題が解決しません。

メンテナンス・パッチやEBF (Emergency Bug Fix)を調べてください。長年にわたって、アサーション・エラーを起こす多くの問題が発見され、解決されています。http://www.ianywhere.jp/sup/saillogin.htmlにアクセスして[Downloads]を選択すると、メンテナンス・パッチやEBFなどのダウンロード・アイテムが表示されます。パッチまたはEBFの修正リストを読めば、バグの影響を受けているのか、またはテスト目的で開発用にマシンにアップグレードを適用できるのかを判断できます。アップグレードはできるだけテストしてから適用してください。影響を受けるバグによっては、データベースを再構築しなければ修正効果が現れない場合があります。

全般的な所見として、バージョン6.0以降を運用しているユーザではデータベースの破壊が極めて少ないことが判明しています。

データベースを修復する必要がある場合は、バグ・レポートを提出しないでください。アサーション自体はバグを意味しているわけではなく、バグ・レポートの事例は早期の回答や解決を約束するものではありません。データベースを弊社に送って修復する場合は、以下の質問に対してできるだけ多くの回答をお寄せください。
これらの情報は、データベースをより効率的に修復したり、潜在的な破壊の原因を追跡するのに役立ちます。