概要

サーバとは別マシン上にあるデータベース・ファイルを使用して、SQL Anywhere サーバにアクセスすることは可能ですが、すべての状況で可能ではありません。以下に、SQL Anywhere データベースの用途に検討する可能性があるアーキテクチャーのいくつかを記載します。

 

 

インターネットSCSI(iSCSI)/ストレージ・エリア・ネットワーク(SAN)/ネットワーク・アタッチド・ストレージ(NAS)

iSCSI、SAN 及び NAS のハードウェア・ソフトウェアのベンダーについて、SQL Anywhere が正常に機能するかどうかを決定する2つの主要な要件があります:

  1. ファイル書き込みの順番が保障されていること。 これは、もしサーバが A の書き込みをリクエストし、その後に B の書き込みをリクエストした場合、B が書き込まれる前に A が物理メディアに書き込まれることを SAN 及び NAS が保証していることを意味します。 さらに Windows では、FlushFileBuffers() の後のSetEndOfFile() コールが、ファイルのメタデータを物理メディアに書き込むのに余裕があることをマイクロソフトが保証することも意味します。 我々は、それらと同じ動作が iSCSI、 SAN 及び NAS により考慮されていることを要求します。
  2. この環境で書き込みの要求が発行された際、iSCSI、 SAN 及び NAS が書き込みコールから復帰する時に(オペレーティング・システム、もしくはドライブの内部キャッシュによりバッファリングされているのではなく) 物理メディアへ書き込みが完了されていること。 これは、上記の 1.のポイントが実施されるならば、一般的に該当します。

iSCSI、 SAN 及び NAS がバッファリングを行う場合、実際の物理ドライブへの書き込み順は重要ではありません。電源切断後、常にそれに依頼した書き込みがすべて成功して完了したようにファイルが見えることが完全に保証されます。通常、「保証」はキャッシュに対するバッテリー・バックアップによって提供されます。

 

標準ネットワーク共有を経由したデータベース・ファイルへのアクセス

いくつかの理由により、標準ネットワーク共有を経由したデータベース・ファイルへのアクセスはサポートされません。

  1. ネットワーク・ファイル・リンクが、十分強固な I/O 順の動作を提供しないため、データベースのリカバリ性は保証されません。
  2. データベース・サーバが任意のI/O 操作を行なおうとしている間に発生するいかなるネットワーク・エラーも、エンジンに致命的なエラーによる停止を引き起こします。
  3. もし、パフォーマンスが考慮すべき事柄であれば、ローカル・ドライブのI/O に対し、ネットワークI/O は大きなパフォーマンス・ペナルティがあることに注意する必要があります。

 

 

 

このページは、以下の英語ページの抄訳です。
Running a SQL Anywhere Database File that is Stored Remotely from the Server Machine

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply