SQLiteのアトミックコミットメカニズム

この記事は、SQLiteでのトランザクションの実装を詳しく説明したsqlite.orgの興味深い記事の一部を翻訳したものです。 実際、私はSQLiteで作業することはめったにありませんが、それでもこの読書は本当に気に入りました。 したがって、視野を広げたいだけなら、読むのは面白いでしょう。 最初の2つのセクションは、翻訳には含まれていません。そこには何も興味深いものがなく、私はそれらを埋めるのが面倒です（投稿はすでに巨大です）。

3.0単一ファイルのコミット

1つのデータベースファイルのみが関与するアトミックトランザクションをコミットするためにSQLiteが実行する手順を確認することから始めます。 データベースの破損から保護するために使用されるファイル形式の詳細と、複数のデータベースにコミットするために使用される手法を以下に示します。

3.1初期状態

データベースへの接続が発生した直後のシステムの状態は、右の図に表面的に示されています。 右側に表示される情報は、エネルギーに依存しないメディアに保存されます。 各長方形はセクターです。 青色は、このセクターに元のデータが含まれていることを示します。 中央には、オペレーティングシステムのディスクキャッシュがあります。 この例の最初の段階では、キャッシュは冷たく、白で表示されています。 図の左側には、SQLiteを使用するプロセスのRAMコンテンツがあります。 データベース接続が開かれたばかりで、情報が読み取られていません。

3.2読み取りロックの取得

SQLiteが記録を開始する前に、まず、すでに存在するものを見つける必要があります。 これが新しいデータを挿入するだけの場合でも、彼はsqlite_masterテーブルからスキーマを読み取る必要があるため 、INSERTクエリの解析方法とデータの具体的な書き込み場所を理解する必要があります。
最初のステップは、データベースファイルの共有ロックを取得することです。 共有ロックを使用すると、2つ以上の接続が同時にファイルから読み取ることができます。 ただし、このタイプのブロックは、削除されるまで他の接続が記録されないようにします。 これは、別の接続が同時に書き込みを行っている場合、変更されていないデータの一部と変更後のデータの別の部分を読み取ることができるためです。 その場合、レコードは非アトミックと見なされます。
ロックは、ディスク自体ではなく、OSのディスクキャッシュにインストールされていることに注意してください。 ファイルロックは通常、システムのカーネルによって制御される単なるフラグです。 システムクラッシュまたは電源障害が発生した場合、それらはリセットされます。 また、ロックを受け取るプロセスが停止すると、通常リセットされます。

3.3データベースからの情報の読み取り

ロックを取得したら、データベースファイルから読み取りを開始できます。 このシナリオでは、キャッシュがまだウォームアップされていないことを意味するため、まずデータストレージデバイスからオペレーティングシステムのキャッシュに情報を読み込む必要があります。その後、OSキャッシュからユーザースペースに移動できます。 後続の読み取りでは、すべてまたは一部の情報が既にキャッシュにあるため、ユーザー空間に送信するだけで済みます。
通常、ページのごく一部のみがデータベースファイルから読み取られます。 この例では、8ページのうち3ページしか読み取られていません。 典型的なアプリケーションでは、データベースには数千のページが含まれ、クエリが影響を与えるページはごくわずかです。

3.4「バックアップ」ロックの取得

データベースに変更を加える前に、SQLiteは最初にデータベースファイルの「予約済み」ロックを取得します（およそ。これは私にとって最も許容できる翻訳です）。 このようなロックは、他のプロセスがデータベースファイルから読み取ることを許可するという点で、共同ロックに似ています。 1つのバックアップロックが複数の共有ロックと共存できます。 ただし、一度に存在できるバックアップロックは1ファイルにつき1つだけです。 したがって、一度に1つのプロセスのみがデータベースに書き込むことができます。
バックアップロックのアイデアは、近い将来ファイルへの書き込みを開始するプロセスの意図について話すことですが、これまでのところ、これをまだ開始していません。 また、変更の書き込みがまだ開始されていないため、他のプロセスがデータベースからの読み取りを続行する場合があります。 ただし、ロックが生きている間は、どのプロセスも記録を開始できません。

3.5ロールバックログの作成

データベースファイルへの書き込みを開始する前に、SQLiteは最初に別のログを作成して変更をロールバックし、変更される元のデータベースページに書き込みます。 ロールバックログには、トランザクション前のデータベースを元の状態にロールバックするために必要なすべての情報が含まれています。
ロールバックログには、元の状態のデータベースファイルのサイズを含む小さなヘッダー（図に緑色で表示）が含まれています。 そのため、変更後にデータベースファイルのサイズが大きくなった場合でも、元のサイズがわかります。 ページ番号は、ログの各ページの横に保存されます。
新しいファイルが作成されると、ほとんどのオペレーティングシステム（Windows、Linux、Mac OS X）は実際にはディスクに何も書き込みません。 新しいファイルは、オペレーティングシステムのキャッシュにのみ作成されます。 オペレーティングシステムが適切なタイミングを見つけるまで、ファイルはドライブ上に作成されません。 これにより、ドライブの入力/出力操作が可能な場合よりもはるかに高速であるというユーザーの外観が作成されます。 このプロセスを右側の図に示しました。ロールバックログはディスクキャッシュにのみ表示され、ディスク自体には表示されないことを示しています。

3.6ユーザー空間のデータベースページの変更

元のコンテンツがロールバックログに保存された後、ユーザーメモリ内のページを変更できます。 データベースへの各接続には、ユーザー空間の独自のプライベートコピーがあるため、ユーザー空間に加えられた変更はこの接続のみに表示されます。 他の接続では、まだ変更されていないディスクキャッシュ情報が引き続き表示されます。 そのため、データベース内のデータの変更に1つのプロセスが関与していても、他のプロセスは元のコンテンツの独自のコピーを読み続けることができます。

3.7ドライブへのロールバックログのリセット

次のステップでは、ロールバックジャーナルをキャッシュからエネルギーに依存しないメモリにリセットします。 後で見るように、これは非常に重要なステップであり、停電の場合にデータの安全性を保証します。 また、エネルギーに依存しないメモリへの書き込みは通常、遅い操作であるため、このステップには多くの時間が必要です。
通常、このステップは、単にログをディスクにダンプするよりも複雑です。 ほとんどのプラットフォームでは、2回のフラッシュ（またはfsync）を行う必要があります。 最初のフラッシュは、ログの主な内容を書き込みます。 次に、ログのヘッダーが変更され、ログのページ数が反映されます。 その後、ヘッダーはディスクにフラッシュされます。 これが必要な理由の説明を以下に示します。

3.8排他ロックの取得

データベースファイル自体に変更を加える前に、まず排他的にロックを取得する必要があります。 このようなロックを取得するには、2つの手順が必要です。 最初に、SQLiteは保留中のロックを受け取ります。 次に、このロックは排他的に転送されます。
「保留ロック」を使用すると、ファイルに既に共有ロックが設定されている他のプロセスが、ファイルからの読み取りを継続できます。 ただし、他のプロセスが新しい共有ロックを取得することは禁止されています。 これは、大量の読み取り要求が常に到着するために、記録が完全にならないときに状況が解決しないようにするために必要です。 各プロセスは、読み取り前にまず共有ロックを取得し、その後ロックを読み取り、リセットします。 常に読み取る必要のあるプロセスが多数ある場合、既存のプロセスがロックを解除する前に新しいプロセスがロックを取得するという状況が発生する場合があります。 したがって、ファイルに単一の共有ロックが存在しない場合は決してありません。したがって、排他ロックを取得する方法はありません。 「保留」ロックは、同様の状況が発生する可能性を防ぎ、ファイルの新しいジョイントロックの受信を防ぎ、既存のロックの存続を許可するために必要です。 すべての共有ロックが解放されると、保留中のロックを排他ロック状態に移行できます。

3.9データベースファイルへのデータの書き込み

排他ロックが受信されると、このファイルにこれ以上プロセスが書き込まれることはなく、ファイル内で変更が行われることを確認できます。 通常、これらの変更はOSのディスクキャッシュにのみ到達し、ディスク自体にはフラッシュされません。

3.10ドライブへのデータのリセット

次に、フラッシュを呼び出して、データベースへのすべての変更がエネルギーに依存しないメモリに書き込まれるようにする必要があります。 これは、データがさらに潜在的な停電から生き残るための重要なステップです。 ディスクとフラッシュメモリの速度が遅いため、このステップは、ロールバックログ（セクション3.7）の記録とともに、SQLiteでトランザクションのコミットに費やされる時間の大部分を占めます。

3.11ロールバックログの削除

変更をディスクに保存した後、ロールバックログを削除する必要があります。 これはまさに、コミットが正常に完了したと言える瞬間です。 削除前に電源障害または何らかのシステム障害が発生した場合、データベースはコミット前の以前の状態に復元されます。 ロールバックログを削除した後に電源障害が発生した場合、コミットがコミットされます。 したがって、SQLiteでのコミットの成功は、ログファイルがロールバックのために削除されたかどうかに最終的に依存します。
ファイルの削除は本当にアトミックな操作ではありませんが、ユーザープロセスの観点からはこのように見えます。 プロセスは常にオペレーティングシステムに「このファイルは存在しますか？」と尋ねることができます。また、応答として「yes」または「no」を受け取ります。 トランザクションのコミット中に電源障害が発生した後、SQLiteはトランザクションロールバックログファイルが存在するかどうかをオペレーティングシステムに問い合わせます。 その場合、トランザクションは完了しておらず、ロールバックされます。 答えがいいえの場合、トランザクションは正常に完了しました。
不完全なトランザクションの存在は、ロールバックログファイルが存在するかどうかに依存し、その削除はエンドユーザーの観点からはアトミック操作のように見えます。 したがって、トランザクションはアトミック操作のように見えます。
ファイルの削除は、多くのシステムで高価な操作です。 最適化として、SQLiteは長さ0バイトにトリミングするか、ヘッダーをゼロで埋めることができます。 いずれの場合でも、結果として、ログファイルはロールバックのために読み取ることができなくなり、トランザクションはコミットされます。 ファイルの長さをゼロにトリミングし、削除することは、ユーザープロセスの観点からはアトミック操作であると想定されます。 ログヘッダーをゼロで上書きすることはアトミックではありませんが、ヘッダーの一部が破損した場合、ログはロールバックに使用されません。 したがって、ロールバックログのヘッダーが無効になったときにコミットが発生したと言えます。 通常、これはヘッダーの最初のバイトのみがリセットされるときに発生します。

3.12ロック解除

コミットの最後のステップは、排他ロックを解除して、残りのプロセスが再びデータベースにアクセスできるようにすることです。
右の図では、ユーザーのメモリにあった情報がロック解除後にクリアされることを示しました。 これは実際、SQLiteの古いバージョンの場合でした。 しかし、SQLiteの新しいバージョンでは、情報は次のトランザクションに必要な場合に備えてユーザースペースに保存されます。 ディスクキャッシュからデータを取得したり、ディスク自体から読み取ったりするのではなく、既にメモリにあるデータを使用する方が安価です。 このデータを使用する前に、共有ロックを再度取得する必要があります。また、ロックを取得するまでプロセスがデータベースの状態を変更していないことを確認する必要があります。 データベースファイルの最初のページには、変更のたびに増加するカウンターがあります。 このカウンタをチェックすることにより、データベースの状態が変化したかどうかを確認できます。 データベースに変更が加えられた場合、ユーザーキャッシュをクリアして過熱する必要があります。 しかし、多くの場合、変更が行われず、ユーザーキャッシュをさらに使用できるため、パフォーマンスが大幅に向上します。

4.0ロールバック

アトミックコミットは瞬時に行われます。 ただし、上記のすべてのアクションは、明らかに完了するまでにある程度の時間がかかります。 上記のコミットプロセスの途中でコンピューターの電源が切れたと仮定します。 即時の変更の錯覚を維持するために、行われたすべての部分的な変更をロールバックし、データベースを元の状態に復元する必要があります。

4.1何かがうまくいかないとき

変更がディスクに書き込まれたときに、ステップ3.10で電源障害が発生したと想定します。 電源が回復すると、状況は図の右側に示されている状況と多少似たものになります。 データベースファイル内の3つのページを変更しようとしましたが、そのうち1つだけがディスク上で正常に上書きされました。 他のページは部分的に記録され、3番目のページは完全に元の状態のままでした。
電源が復旧すると、ロールバックログはディスク上に完全に記録されます。 これが重要なポイントです。 手順3.7でフラッシュが必要な理由は、データベースファイルに変更を加える前に、ロールバックログ全体がエネルギーに依存しないメモリに完全に保存されることを確実にするためです。

4.2ホットロールバックログ

SQLiteプロセスが最初にデータベースファイルにアクセスしようとすると、セクション3.2で説明されているように、最初に共有ロックが取得されます。 しかし、彼はロールバックログがあることを発見します。 次に、SQLiteは、このログが「ホットロールバックログ」であるかどうかを確認します。 ホットログは、データベースを元の状態に復元するためにデータベースに適用する必要があるロールバックログです。 ホットログが存在するのは、前のプロセスがトランザクションコミットのあるステップにあり、何らかの理由でその瞬間に落ちたときだけです。
すべての条件に該当する場合、ロールバックログは「ホット」です。

• ロールバックログが存在する
• ロールバックログ-空のファイルではありません
• データベースファイルに「予約済み」ロックはありません
• ログファイルのヘッダーは有効であり、破損していません。
• ロールバックログにロールバックマスターログファイルの名前が含まれていない（5.5を参照）、または含まれている場合、このファイルが存在する

ホットログの存在は、前のプロセスがトランザクションをコミットしようとしたが、何らかの理由で失敗したことを示すシグナルです。 ホットログとは、データベースファイルが一貫性のない状態にあり、使用する前に復元する必要があることを意味します。

4.3データベースファイルの排他ロックの取得

ホットログを使用する前の最初のステップは、データベースファイルの排他ロックを取得することです。 これにより、2つ以上のプロセスが同じホットログを一度に適用しようとする状況を防ぐことができます。

4.4不完全な変更のロールバック

プロセスが排他ロックを受け取るとすぐに、データベースファイルへの書き込みが許可されます。 次に、ページの元のコンテンツをロールバックログから読み取って、データベースに書き戻そうとします。 ログのヘッダーには、元の状態のデータベースファイルのサイズが含まれていることに注意してください。 SQLiteは、この情報を使用して、不完全なトランザクションがこのファイルの成長を引き起こした場合に、データベースファイルを元のサイズにトリミングします。 このステップの後、データベースは同じサイズになり、不完全なトランザクションの前とまったく同じデータを含む必要があります。

4.5ホットログの削除

ログ全体がデータベースファイルに適用された後（また、別の停電が発生した場合はディスクにフラッシュされます）、そのログ（ログ）は削除できます。
セクション3.11のように、ログファイルの長さをゼロバイトに切り詰めたり、ヘッダーをゼロで上書きしたりできます。 いずれの場合でも、このステップの後、ログは「ホット」ではなくなります。

4.6進行中のトランザクションがないかのように続行します

最後の回復手順は、排他ロックを共同ロックに変更することです。 これが発生すると、データベースはトランザクションがロールバックされていないかのような状態になります。 この回復プロセス全体がユーザーに対して自動的かつ透過的に行われるため、回復が発生していないように見えます。

5.0複数のファイルへのコミット

SQLiteでは、 ATTACH DATABASEを使用して、同じ接続から同時に複数のデータベースと通信できます。 1つのトランザクションで複数のデータベースファイルが変更されると、すべてのファイルがアトミックに更新されます。 言い換えると、それらのすべてが更新されたか、いずれも更新されません。 複数のファイルのアトミックな更新を実現することは、1つのファイルよりもやや困難です。 このセクションでは、その背後にあるすべての魔法について説明します。

5.1各データベースの個別のロールバックログ

トランザクションが複数のデータベースファイルに影響する場合、これらの各ファイルには独自のロールバックログがあり、各ファイルに対してロックが個別に取得されます。 右の図は、3つの異なるデータベースファイルが同じトランザクション内で変更されたときの状況を示しています。 このステップの状況は、セクション3.6の単一ファイルに対する通常のトランザクションに似ています。 各データベースファイルでバックアップロックがハングします。 各データベースについて、現在変更されるページの元のコンテンツは適切なロールバックログに書き込まれていますが、これらのログはまだディスクにフラッシュされていません。 データベースファイルはまだ変更されていませんが、変更は既にプロセスのユーザーメモリにあります。
簡潔にするために、このセクションの図面は、他のセクションの図面に比べて簡略化されています。 青色は依然として元の情報を意味し、ピンクは新しい情報を意味します。 ただし、データベースファイルのロールバックログの個々のページは表示されません。また、ディスクに既にある情報とシステムキャッシュにある他の情報は表示しません。 それでも、これらの要因はすべてマルチファイルトランザクションに存在しますが、ダイアグラム上の多くのスペースを占有し、有用な情報を提供しないため、ここでは省略します。

5.2マスターログファイル

マルチファイルトランザクションの次のステップは、マスターログを作成することです。 マスターログの名前は、元のデータベースファイル（接続が開かれた）の名前と同じで、「-mjHHHHHHHHH」（「マスタージャーナル」の「mj」）という形式の行が追加されています。HHHHHHHHHは、それぞれの新しいマスターログ。
（マスターログファイルの名前を生成するためのこのアルゴリズムは、SQLite 3.5.0の実装の詳細にすぎません。仕様では指定されておらず、新しいバージョンでは変更できます）
ロールバックログとは異なり、マスターログにはデータベースのページの元のコンテンツは含まれません。 代わりに、トランザクションに参加している各データベースのロールバックログファイルへのフルパスが含まれています。
マスターログがコンパイルされた後、その内容はディスクにフラッシュされます。 Unixシステムでは、停電後にマスターログがこのディレクトリに表示されるように、マスターログディレクトリもリセットされます。

5.3ロールバックログヘッダーの更新

次の手順は、各ロールバックログのヘッダーにマスターログファイルへのフルパスを書き込むことです。 ロールバックログファイル内のマスターログファイルの名前の下の場所は、作成時に事前に割り当てられています。
各ロールバックログの内容は、マスターログの名前をヘッダーに書き込む前後にディスクにフラッシュされます。 データダンプを2回だけ行うことが重要です。 幸いなことに、通常はログファイルの1ページのみが変更されるため、2回目のフラッシュは通常安価です。

5.4データベースファイルの更新

ロールバックログファイルがディスクにフラッシュされたので、データベースファイルの更新に進むことができます。 変更を書き込むすべてのファイルで排他ロックを取得する必要があります。 変更が記録されたら、それらをディスクにフラッシュする必要があります。
この手順は、単一ファイルコミットのセクション3.8、3.9、および3.10を反映しています。

5.5マスターログの削除

次のステップは、マスターログファイルを削除することです。 この時点で、トランザクションは完了したと見なすことができます。 このステップは、ロールバックログが削除される単一ファイルコミットのセクション3.11を反映しています。
この時点で電源障害または何らかのシステム障害が発生した場合、ロールバックログがまだ生きていても、システム回復後にトランザクションは拒否されません。 それらのヘッダーには、マスターログファイルの名前が含まれています。つまり、マスターログ自体が存在しなくなった場合、ヘッダーは適用されません。

5.6ロールバックログの消去

最後の手順では、各ロールバックログを削除し、データベースファイルへの排他ロックをリセットして、他のプロセスが行った変更を確認できるようにします。
この時点で、トランザクションはすでに完了したと見なされているため、ログの削除にかかる時間はそれほど重要ではありません。 現在の実装では、すべてのログは対応するデータベースファイルからのロックの削除とともに1つずつ削除されます-最初のログが削除され、対応するロックが解放され、次に2番目のログとロックなどが続きます。 ただし、将来的には、この動作を最初にすべてのログが削除され、次にすべてのロックが削除される動作に変更する可能性があります。 主なことは、ログの削除はロックのリリース前ではなく、ロックのリリース前に発生することです。

6.0コミットプロセスの追加詳細

セクション3.0では、SQLiteでアトミックコミットがどのように発生するかの概要を示しますが、いくつかの重要な詳細は省略します。 次のセクションでは、これらのギャップを埋めようとします。

6.1。ディスクセクター全体が常にログに記録されます。

元のデータがロールバックログに書き込まれると、ページサイズがセクターサイズよりも小さい場合でも、SQLiteは常に完全なセクターを書き込みます。 セクターサイズがSQLiteコードで512バイトとしてハードコーディングされたことがたまたまありました。最小ページサイズも512バイトであるため、これは問題になりませんでした。 ただし、SQLiteバージョン3.3.14以降では、より大きなセクターで動作します。 したがって、このバージョンから開始して、ページがロールバックログに書き込まれると、ディスク上の同じセクターに分類される別のページを一緒に書き込むことができます。
セクターの記録中にエネルギーが突然失われるシナリオを防ぐために、正しいセクターのすべてのページを誓約することが重要です。 ページ1、2、3、および4がすべてセクター1に格納され、そのページ2が変更されたとします。 変更をページ2に書き込むには、ファイルシステムはセクター全体で動作するため、ページ1、3、4の内容も書き換える必要があります。 この記録操作がエネルギーの損失によって中断された場合、ページ1、3、または4のいずれかが誤ったデータのままになることがあります。 したがって、このシナリオを回避するには、これらすべてのページをロールバックログに保存する必要があります。

6.2ログ内の不良データをどうするか

データがロールバックログファイルに書き込まれると、SQLiteはファイルが最初に「ランダム」データ（ファイルサイズが増加し、ディスクのこの部分がキャプチャされるまでこの場所にあったデータ）で満たされていると想定し、それから正しいデータのみがそれを置き換えます。 言い換えると、SQLiteはファイルサイズが最初に増加し（その下のスペースが割り当てられ（申し訳ありませんが、割り当てられます））、その後データのみが書き込まれると想定します。 ファイルサイズを変更した後で、データを書き込む前に電源障害が発生した場合、ロールバックログには不正なデータが含まれます。 電源が復元された後、別のSQLiteプロセスは、ガベージデータを含むロールバックログファイルを確認し、それに基づいてロールバックを試みるため、データベースが破損します。
SQLiteは、この問題に対処するために2つの手法を使用します。 最初に、SQLiteはロールバックログのヘッダーにページ数を書き込みます。 この番号は最初にゼロとして書き込まれます。 そのため、不完全なログをロールバックしようとすると、プロセスにはログに単一のページが含まれておらず、ロールバックが発生しないことがわかります。 コミットの前に、ロールバックログはディスクにフラッシュされ、その後のみ、目的の数だけページ数を修正します。 ログヘッダーは常にディスクの別のセクターに書き込まれ、電源障害が発生してもこれらのページが上書きされないようにします。 ログは2回ディスクにフラッシュされることに注意してください。最初にページのコンテンツを書き込み、次にヘッダーにページ数を追加します。
前の段落では、フラグPRAGMA synchronous=FULL;したSQLiteの動作について説明しPRAGMA synchronous=FULL;
デフォルトでは、このフラグはFULL設定されていますNORMALに設定されている場合、SQLiteはページ数を記録した後、ログを1回だけリセットします。 これは、データベースページの前にページ数が書き込まれる可能性があるため、データ破損のリスクを伴います。 ページデータは最初に書き込み用に送信されましたが、SQLiteはファイルシステムが書き込みジョブの順序を並べ替え、それに応じて最初にページ数を記録できると想定しています。 これに対する別の防御策として、SQLiteはロールバックログの各ページに32ビットの署名（ハッシュ）を使用します。 ログ内の一部のページがその署名と一致しないことが判明した場合、ロールバックはキャンセルされます。
synchronousフラグがFULL設定されている場合、ログの署名はオプションです。 このフラグがNORMAL場合にのみ必要です。 ただし、それらは決して損傷しないため、すべてのモードでログに含めます。

6.3コミット中のキャッシュオーバーフロー

セクション3.0のコミットプロセスでは、コミットする前にすべての変更がメモリに収まると想定しています。 これが最も可能性の高いケースです。 ただし、ユーザープロセスに割り当てられたメモリが一連の変更によってオーバーフローすることがあります。 このような場合、トランザクションが完了する前にキャッシュをデータベースに送信する必要があります。
送信の最初の段階では、データベースはセクション3.6に示す状態にあります。 元のデータはロールバックログに保存され、ユーザーメモリに変更があります。 キャッシュを送信するために、SQLiteはステップ3.7、3.8、および3.9を実行します。 ログがディスクにフラッシュされ、データベースファイルで排他ロックが受信され、すべての変更が記録されました。 その後、最後に別のヘッダーがログに追加され、ステップ3.6に戻ります。 トランザクションが完了するか、書き込むデータがさらにある場合は、ステップ3.7に戻り、次に3.9に戻ります。 （ステップ3.8、手放しなかったので、今は必要ありません）（約.per：この章ではnifigがわかりません。非常に奇妙に書かれています。アイデアがあれば書いてください）

7.0最適化

テストによると、ほとんどの場合、SQLiteはほとんどの時間をディスクへの書き込みの待機に費やしています。 したがって、最初に記録を最適化し、ディスクを操作する必要があります。 このセクションでは、コミットの整合性を維持しながら、I / O操作の数を最小限に抑えるためにSQLiteが使用する手法のいくつかについて説明します。

7.1トランザクション間でキャッシュを保存する

手順3.12では、ジョイントロックが解除されると、ユーザーキャッシュ全体がクリアされることがわかります。 これは、共有ロックがない場合、他のプロセスがデータベースファイルを変更し、ユーザーキャッシュを廃止する可能性があるためです。 したがって、新しいトランザクションはそれぞれ、データベースからデータを読み取ることから始まります。 このデータはオペレーティングシステムのディスクキャッシュにある可能性が高いため、これは見かけほど悪くありません。したがって、OSメモリからのデータのコピーにすぎません。 それでも、時間がかかります。
バージョン3.3.14から、データを再度読み取る必要が生じる可能性を減らすメカニズムが追加されました。 ユーザーキャッシュ内のデータは、トランザクションの後、次のトランザクションの前に残り、SQLiteはデータベースファイルが何らかの形で変更されたかどうかを確認します。 その場合、ユーザーキャッシュはフラッシュされます。 しかし、多くの場合、この時点でファイルは同じ状態になるため、不必要な読み取り操作を回避できます。
データベースファイルが変更されたかどうかを判断するために、SQLiteはデータベースヘッダー内のカウンター（24〜27バイト）を使用します。このカウンターは、各ファイル変更操作の後にインクリメントされます。 カスタムSQLiteプロセスは、トランザクションを完了する前にカウンターの状態を保持します。 次に、データベースのロックを受け取った後、最初のトランザクションの前とカウンタを比較し、値が異なる場合はキャッシュをフラッシュします。

7.2排他的アクセスモード

SQLite 3.3.14は、「排他的アクセスモード」と呼ばれる新機能を受け取りました。 このモードでは、SQLiteはトランザクション後に排他ロックをデータベースファイルに保存します。 これにより、データベースが他のプロセスからアクセスされることを防ぎますが、SQLiteを使用するほとんどの場合、ある時点では1つのプロセスのみがデータベースを使用するため、これは問題ではありません。 したがって、ディスク操作の数は次の理由で削減できます。

1. 最初のトランザクションの後にカウンターをインクリメントする必要はありません。 これにより、多くの場合、最初のページをロールバックログとデータベースファイル自体に書き込む操作が節約されます。
2. 他のプロセスではデータベースを変更できないため、毎回上記のカウンターを確認する必要はなく、ユーザーキャッシュをクリアする必要はありません。
3. 各トランザクションは、ファイルを削除する代わりに、ヘッダーがゼロで埋められた以前のログを上書きできます。 このため、ログが保存されているディスクセクターを展開するだけでなく、ディレクトリにログファイル自体を追加する必要もありません。 したがって、ほとんどのシステムでは書き換えがはるかに安価であるため、新しいトランザクションを作成してデータを書き込むのではなく、次のトランザクションは前のトランザクションのログを単純に上書きします。

3番目の最適化の一部である、ファイルを削除する代わりにログヘッダーを記録するには、実際には排他アクセスモードが必要です。以下のセクション7.6で説明するように、 journal_mode_pragmaディレクティブを使用して有効にできます。

7.3ページのフリーリストを記録しない

SQLiteデータベースから情報が削除されると、削除された情報を含むページが空きリストに追加されます。 後続の挿入では、ファイル拡張子のサイズを必要とせずに、データベースファイル内のこれらのページが単に上書きされます。
一部のフリーリストページには、より正確には、他のフリーリストページの場所などの重要な情報が含まれています。 しかし、それらのほとんどには重要なものは含まれていません。 重要ではないページは「リーフ」ページと呼ばれます。 データベースの状態は変わりませんが、コンテンツを自由に変更できます。
リーフページの内容はあまり重要ではないため、SQLiteはコミットプロセスのステップ3.5でロールバックログに保存することを避けます。 シートページが変更され、この変更がリカバリ中にロールバックされない場合、データベースはこれから何らかの方法で損傷することはありません。

7.4 1ページの変更とセクターの原子記録

SQLite 3.5.0以降、新しい仮想ファイルシステム（VFS）インターフェイスには、ストレージ（ディスク）のプロパティを返すxDeviceCharacteristicsメソッドが含まれています。 これらのプロパティの中には、原子セクター記録の可能性があります。
SQLiteは、デフォルトでは、ディスクがアトミックではなくリニアに書き込むことを想定しています。 行の記録はセクターの一方の端から始まり、バイトごとにもう一方の端に到達します。 記録中に電源障害が発生した場合、セクターの一部が破損している可能性があります（古いデータが含まれている）。 セクターのアトミック記録では、セクター全体が上書きされるか、セクター全体が同じ状態のままになります。
最新のドライブのほとんどは、アトミックセクター書き込みをサポートしています。 電力損失が発生すると、ディスクはコンデンサに保存されたエネルギーおよび/またはパンケーキ回転エネルギーを使用して、スケジュールされたすべての記録タスクを完了します。 それでも、システム書き込み呼び出しとディスク自体の電子回路の間には非常に多くの層があるため、セクターが線形に書き込まれるという悲観的な仮定を立てるためにすべてのプラットフォームを決定しました。
セクターレコードがアトミックで、データベースのページサイズがセクターサイズと等しい場合、1ページだけを変更する必要がある場合、SQLiteはロギングプロセスを完全にスキップし、代わりに変更をデータベースファイルに直接書き込みます。 また、カウンターの変更前に発生した場合でも、エネルギーをオフにしてもここでは何の害もないため、変更カウンターは個別にインクリメントされます。

7.5安全な追加機能を備えたファイルシステム

バージョン3.5.0で導入された別の最適化では、安全な追加ディスク機能が使用されます。 覚えているように、通常、SQLiteは、新しいデータがファイルに追加されると、そのサイズが最初に増加し、次にデータのみが書き込まれると想定します。 したがって、これらのイベント間でディスクのエネルギーが失われると、ファイルには最終的にデッドデータが含まれます。 xDeviceCharacteristicsのメソッドの1つは、ディスクが安全な追加を実行できるかどうかを示します。 この機能は、反対に、ディスクが最初に「事前に割り当てられた」領域にデータを書き込む方法で実装されます。その後、ファイルサイズが増加し、その領域がこのファイルに与えられます。 したがって、エネルギーの損失は記録中でもひどいものではありません（実際、これはアトミックアペンドです）。
安全な追加を有効にすると、SQLiteはロールバックログのヘッダーのページ数を-1のままにします。 ログに-1が発生すると、プロセスはページ数をログのサイズから計算する必要があることを理解します。 これにより、1回のフラッシュ操作が保存されます。

7.6ログの削除の拒否

多くのシステムでは、ファイルの削除はかなり高価な操作です。 そのため、SQLiteではログの削除を無効にできます。 代わりに、ファイルの長さをゼロにトリミングするか、ヘッダーにゼロを入力することができます。 この場合、ファイル自体はそのままであるため、ファイルが含まれているディレクトリに触れる必要がないため、ファイルのトリミングはより有益です。 一方、ヘッダーを上書きすると、ファイルの長さ（このファイルのiノード）を変更せずに、ディスク上の新しく解放されたセクターの割り当て解除に時間を浪費することがなくなります。 その後、次のトランザクションで、既存のファイルにログが作成され、上書きされます。また、追加するよりも高速になります。
journal_modeオプションをPERSIST設定すると、SQLiteはこの戦略を順守します。 （ PRAGMA journal_mode=PERSIST ）
通常、このモードを使用すると、ほとんどのシステムで顕著なパフォーマンスの向上が得られます。 もちろんマイナスがあります-ログはディスク上に残り、スペースを使い果たします。このようなログを削除する唯一の安全な方法は、ロギングモードでトランザクションをコミットすることですDELETE。

 PRAGMA journal_mode=DELETE BEGIN EXCLUSIVE COMMIT; 

ファイルを手動で削除しようとすると、ログがまだ進行中のトランザクションに属している状態になる可能性があります。
バージョン3.6.4以降、モードもサポートされていTRUNCATEます。

 PRAGMA journal_mode=TRUNCATE 

このモードでは、ログファイルのサイズはゼロバイトに切り捨てられます。ファイルが保存されているディレクトリは影響を受けないため、この戦略も有効です。そのため、多くの場合、ファイルの削除は削除よりも高速です。また、TRUNCATE状態をディスクに同期するためのシステムコール（fsync、flush）も必要ありません。しかし、このような挑戦をするとより安全になります。しかし、ほとんどのファイルシステムでは、TRUNCATEはアトミックな同期操作であるため、エネルギーが失われた場合でも安全である可能性が高くなります。アトミックTRUNCATEがファイルシステムでサポートされているかどうかが不明で、データの整合性が重要な場合は、別のロギング戦略を選択することをお勧めします。
同期ファイルシステムを備えた組み込みシステムでは、通常、TRUNCATEはPERSISTよりも低速です。最初のコミットの速度は同じですが、データの上書きはファイルの最後に追加するよりも速いため、後続のトランザクションは遅くなります。新しいログは常にTRUNCATEの後に追加されますが、永続的な戦略では古いログが上書きされます。

8.0アトミックコミットテスト

SQLite開発者は、このシステムが停電やさまざまなシステム障害に直面しても信頼できると確信しています。自動化されたテスト手順は、シミュレートされた障害から回復する能力についてSQLiteをテストします。クラッシュテストと呼びます。
SQLiteのクラッシュテストでは、独自のVFSを使用します。これにより、通常、停電や何らかのシステム障害の後に発生するさまざまな種類のファイルシステムの損傷をシミュレートできます。未完成のセクター、ランダムな順序での不完全な書き込み操作によるガベージデータで満たされたページをシミュレートします。クラッシュテストはトランザクションを1つずつ実行し、さまざまな変数（損傷が発生した時間、損傷の種類など）を変更します。その後、各テストはデータベースへの新しい接続を開き、トランザクションが完全に完了したか、まったく完了していないこと、およびデータベースを検証します一貫した状態です。

9.0何がおかしいのか

SQLiteのアトミックコミットメカニズムは非常に信頼性が高くなりますが、基になるレイヤーが間違った動作を行うと破損する可能性があります。このセクションでは、システム障害または電源障害が原因でデータベースが破損する可能性のあるいくつかのシナリオについて説明します。

9.1重要なロックの実装

SQLiteはファイルロックを使用して、一度に1つのプロセスのみがデータベースを変更できるようにします。ロックメカニズムはVFSレベルで実装され、オペレーティングシステムによって異なります。SQLiteはこれらの実装に依存しています。レベルで何か問題が発生し、2つ以上のプロセスがデータベースファイルに書き込むことができる場合、データベースが破損する可能性があります。
WindowsネットワークファイルシステムとNFSでバグが報告されましたが、ロックは期待どおりに機能しませんでした。これらのレポートを確認することはできませんが、ロックをネットワークファイルシステムに実装するのは非常に難しいため、これらのバグが実際に存在することを疑う理由はありません。パフォーマンスの大幅な低下のためだけに、ネットワークファイルシステム上でSQLiteを使用しないことをお勧めします。
Max OS XにプリロードされたバージョンのSQLiteには、AppleがサポートするすべてのネットワークFSで機能するロックの代替戦略を使用する機能が既にあります。データベースファイルを使用するすべてのプロセスが同じ戦略を使用している場合、これらの戦略は正常に機能します。残念ながら、ロックメカニズム（実装）は相互に排他的ではないため、あるプロセスがドットファイルロック（aha、トートロジー）を使用するのと同じファイルでAFPロックを使用する場合、同時に1つのファイルに書き込むことができます、これらの戦略は相互に排他的ではありません。

9.2不完全なディスクフラッシュ

SQLiteは、fsyncUnixシステムおよびFlushFileBufferswin32でシステムコールを使用して、ファイルをディスクにフラッシュします。残念ながら、これらのインターフェイスはどれも多くのシステムで適切に動作しないという事実に関連する多くのレポートを受け取ります。FlushFileBuffersWindowsの一部のバージョンでは、レジストリで完全に無効にすることができます。 Linuxの一部のバージョンにfsyncは、基本的に一部のファイルシステムのスタブである実装も含まれています。 OSレベルですべてが正常に機能する場合でも、実際にはまだディスクキャッシュにあるデータが磁気ドライブに到達したと言って、ドライブが嘘をつくことがよくあります。
Macでは、設定できますPRAGMA fillfsync=ON;、ディスクキャッシュだけでなくディスク上のパンケーキへのデータの完全なリセットを保証します。しかし、fullfsyncの実装はかなり遅く、ディスクに関連する他の操作を遅くします。

9.3不完全なファイル削除

SQLiteは、ファイルの削除はユーザープロセスの観点からはアトミックな操作であると想定しています。ファイルの削除中にエネルギー損失が発生した場合、SQLiteはファイルが完全に保存または削除されることを期待しています。トランザクションは、動作が異なるシステムではアトミックとは見なされません。

9.4外部からのデータベースファイルの変更

SQLiteデータベースは、他のプロセスで開いて変更できるディスク上の通常のファイルにあります。どのプロセスでもデータベースファイルを開き、「不良」データを入力できます。SQLiteは、このような干渉から自身を保護するために何もできません。

9.5ホットログの削除または名前変更

トランザクション中に障害が発生し、ホットログがディスクに保存された場合、トランザクションがロールバックされるまで、データベースファイルとログが元の名前でディスクに残っていることが重要です。復旧プロセス中に、SQLiteはデータベースファイル自体の名前を使用して、データベースファイルがあるディレクトリでログファイルを検索します。データベースファイルまたはログファイルが移動または名前変更された場合、プロセスはログを表示せず、データベースはロールバックされません。
ユーザーは、電源が復元された後にホットログファイルを削除できます。その後、データベースは復元されず、破損した状態になります。
データベースファイルにシンボリック（またはハード）リンクが作成される場合、ログはデータベースが開かれたリンクの名前に基づいて名前が付けられます。クラッシュが発生し、データベースが別のリンク（または元のファイル）を介して開かれた場合、ホットログは取得されず、破損したデータベースを操作します。
停電により、新しく変更されたファイルが消えてしまい、/lost+found。これが発生すると、ホットログを見つけることも不可能になり、ロールバックを行うことはできません。SQLiteは、ログ自体が同期するのと同時にログを含むディレクトリを同期（fsync）することにより、これを防止しようとします。ただし、この現象は、データベースファイルと同じディレクトリで作成または変更された完全に無関係なファイルによっても発生する可能性があります。また、SQLiteの制御下にないため、それを防ぐことはできません。このような脆弱性の影響を受けやすいシステムを使用している場合（最新のジャーナリングFSはほとんど影響を受けません）、各SQLiteデータベースを個別のディレクトリに配置する必要があります。