dbvalid を統合データベースのバックアップに対して実行できない理由 - SQL Anywhere 技術情報（TechDoc）- アイエニウェア・ソリューションズ株式会社 -

dbvalid を統合データベースのバックアップに対して実行できない理由

概要：この文書では、SQL Anywhere のバックアップとリカバリで、正常なファイルを破損したファイルで上書きすることを防止する方法について説明します。

バックアップ対象のデータベースを検証してから、データ保護用のバックアップとリカバリを実行する必要があります。検証していない場合は、破損ファイルを正常なファイルに上書きしてしまい、リカバリできなくなることがあります。このマニュアルでは、これを防止する方法について説明します。

データを保護する際には、データベース・ファイルをバックアップする前、特にバックアップを既存のデータベース・ファイルに上書きする前に、データベース・ファイルを検証することが重要です。

dbvalid コマンド・ライン・ユーティリティまたは SQL コマンドの VALIDATE INDEX と VALIDATE TABLE を使用して、データベースが破損していないかどうかを検証できます。

検証ユーティリティは、データベース内の一部またはすべてのテーブルでインデックスとキーを検証します。このユーティリティは、テーブル全体をスキャンし、テーブル内の各行が正しいインデックス内にあるかどうかを確認します。

dbvalid をバックアップ・データベース・ファイルに対して実行すると、終了時にログ・ファイルでチェックポイントが設定されるときに、統合ログ・ファイルの終了ログ・オフセットが大きくなります。このログ・ファイルの終了オフセットは、次のログ・ファイル (多くの場合は現在のログ・ファイル) の開始ログ・オフセットよりも大きくなるため、重複部分が発生します。この重複部分が原因で、レプリケーションが中断することがあります。

レプリケーション環境でのログ・オフセット保持の詳細については、 http://www.sybase.com/detail?id=1017970にある別ドキュメントの「The Importance of Log Offsets in a Replicating System」を参照してください。

多くのユーザは、パフォーマンス上の理由で、運用マシン上のデータベースに対して検証ユーティリティを実行していません。しかし、破損を検出し、それが原因でシステムがダウンすることを防止するため、頻繁に検証を実行することが非常に重要です。

レプリケートするデータベースの検証については、次の 2 つの推奨事項があります。

1. 検証プロセス全体を複数のサブプロセスに分割し、サーバの負荷が低いときに実行することで、負荷を分散してください。たとえば、夜間の数時間は運用マシンの負荷が低いが、検証プロセス全体を実行するには短すぎる場合は、検証プロセスをサブプロセスに分割します。キー・テーブルまたはインデックスに対して VALIDATE TABLE コマンドまたは VALIDATE INDEX コマンドを毎日夜に実行し、1 週間ですべてのテーブルが検証されるように、検証プロセスを分割します。

2. 検証ユーティリティをバックアップ対象のデータベース・ファイルのコピーに対して実行します。検証プロセスが終了し、エラーが発生しなかった場合にだけ、元のバックアップ対象のデータベース・ファイルを既存のファイルに上書きします。

BACK : 技術情報（TechDoc）のトップページ