SAP SQL Anywhere 17 – インメモリデータベースのバリデーション

バックアップとリカバリプランの一環として、リカバリプロセスのテストを定期的に行うとともに、バックアップに成功した後にバックアップデータベースをバリデーションするのがベストプラクティスであると考えられています。本番データベースが有効かどうか、バックアップがクリーンか、必要な時にリカバリ可能かどうか確認するにはこれがベストな方法です。

しかし、残念ながら、サーバーのバックアップデータベースを起動するということは、そのバックアップデータベースに関連したログファイルのオフセットの予期したスタートに先行して、（少なくとも）チェックポイントが発生します。

これはつまり、そのバックアップデータベースをリカバリに使用した場合には、本番データベースからログファイルをそれに適用することはできないことを意味します。なぜならば予期したログオフセットはもはやマッチしないからです。

バックアップが有効であり、さらにそれがまだリカバリに使用できることを確認するには、バックアップデータベースを「リードオンリー」モード（サーバー –r オプションまたは START DATABASE 文の FOR READ ONLY 句 ）で起動し、そのデータベース/ログに何の変更もないことを確認する必要があります。

多くの場合はうまく機能しますが、全てうまくいくとは限りません。もしバックアップを開始し、データベース内にオープンなトランザクションがある場合には（よくあることですが）、そのバックアップデータベースはそれが開始される時にリカバリを経る必要があります（これらのトランザクションを完了するか、またはロールバックし、ACID 準拠のデータベースを確認します）。

これはつまり、「リードオンリー」モードをバリデーションには使用できないということを意味します。

この場合には、バックアップデータベースのコピーを作成してスタートし、データベースをリカバリさせ、それからバリデーションを行います。明らかに、これではバックアッププランに対して時間とディスクスペースの両方の面でオーバーヘッドを大幅に増加させてしまいます。

バージョン17では、「in-memory validation」または IMVと呼ぶ新しいインメモリーモードでこれに対応しました。これは、データベースとログファイルのコピーを別に作成しなくともバックアップのバリデーションができるようにするものです。

別途ライセンスが必要な（Editionによっては含まれていない）SQL Anywhere のその他のインメモリーモード (in-memory checkpoint-only モード (-im c) や in-memory never-write モード (-im nw ))とは異なり、この in-memory validation モードは全ての SQL Anywhere のバージョンに含まれています。

続きはこちら：SAP SQL Anywhere 17 – インメモリデータベースのバリデーション

SAPのSAP SQL Anywhere製品ページはこちら