本稿はデータベースソフトウェア「SQL Anywhere」およびデータベース全般に関する英語ドキュメントを翻訳する形で提供しています。図など、部分的に英語のままになっていますが、製品のSQL Anywhere自体は完全に日本語化されていますのでご安心ください。
※編集部注：掲載しているブログ内容は執筆時点での情報のため、現在とは異なる場合があります。
本日、SQL Anywhereエンジニアリング部門が執筆したホワイトペーパー「WindowsおよびLinux向けSQL AnywhereのI/O要件」が公開されました。このホワイトペーパーでは、WindowsおよびLinuxプラットフォームで動作するSQL Anywhereサーバーでメディアまたは電源の障害時に確実なデータベース復旧を行うために満たすべきI/O要件が詳しく説明されています。このホワイトペーパーの要約を次に示します。
コミットされたトランザクションを確実に永続化し、電源喪失時にデータベースを適切に復旧するためには、保存先のストレージへデータが到達したということをデータベースサーバーが正しく把握できなければなりません。オペレーティングシステムとストレージデバイスは、パフォーマンスを向上させるために、書き込み操作のキャッシュや並び替えを行います。正しく設定されていないシステム上でデータベースサーバーを動作させると、データの消失や破損につながる可能性があります。この文書では、耐久性の高いストレージの要件や、SQL AnywhereのI/Oセマンティクスについて理解するために必要な背景を説明します。
また、3.2.1項の内容を一部抜粋して紹介します。
Windowsでは、
FlushFileBuffers()を呼び出すことでOSにディスクフラッシュを要求できます。SQL Anywhereでも、データの信頼性を保証するために適宜この呼び出しを通じてフラッシュを要求しています。しかし残念ながら、一部のI/Oドライバにはバグがあり、FlushFileBuffers()を呼び出してもフラッシュコマンドが常にディスクに渡されるとは限りません。また、SQL Anywhereでは、データベースファイルやトランザクションログファイルを開く際にCreateFile()にFILE_FLAG_WRITE_THROUGHフラグを渡すことで、FUAビット付きのI/Oを要求しています。しかしFUAビットの扱いはディスクメーカーやWindowsのバージョンの間で必ずしも統一されていません。一部のATAベースの実装は、FUAビットを完全に無視しているらしく、SQL Anywhereの信頼性を脅かしています。
Windowsを市販コンピュータ上で使っている方、あるいはLinuxディストリビューション上で使っている方（特に私が以前の記事で紹介したEXT3ファイルシステムを使用している場合）は、このホワイトペーパーをお読みになることをお勧めします。
