データベースの管理 (SQL Server Compact)
Microsoft SQL Server Compact 3.5 データベースの内部構造は、時間と共に断片化し、無駄なディスク領域が作成されることになります。断片化が過剰になると、パフォーマンスが低下します。断片化を回避するには、以下の機能を使用して SQL Server Compact 3.5 データベースを保守します。
このトピックで説明するメソッドとプロパティの使用の詳細については、「System.Data.SqlServerCe」を参照してください。
最適化
Compact メソッド (ネイティブのプログラミングでは CompactDatabase メソッド) を使用して、データベース ファイル内の領域を再利用します。また、このメソッドを使用してパスワードやロケール ID (LCID) などのデータベース設定を変更することもできます。
SQL Server Compact 3.5 データベース ファイルは、ページと呼ばれる 4 KB の論理ユニットに分割されます。データベースが継続的に変更されるにつれて、ページに未使用の領域が含まれたり、ページ自体が未使用になることがあります。未使用のページは、AutoShrink メカニズムにより最終的に再利用されます。詳細については、このトピックの後半の「自動圧縮」を参照してください。
ページの空き領域は、Compact メソッドをすることによってのみ再利用できます。Compact メソッドでは、最適化前のデータベースから行が読み取られ、最適化後のデータベースにそれらの行が書き込まれます。その際、最適化後のデータベースの無駄な領域は最小限に抑えられます。
注意
最適化後のデータベースの Data Source プロパティが指定されていない場合、Compact メソッドでは、最適化前のデータベースが、同一の名前を持つ最適化された新しいデータベースで上書きされます。
データベースの最適化時には、次の処理が行われます。
新しいデータベースが再作成され、新しいインデックスが作成されます。
テーブルのページが再構成され、隣接するデータベース ページ内に格納されます。これによりデータベース内のテーブルの断片化が少なくなるため、領域の割り当てが改善されます。
オブジェクトとレコードを削除することで作成された未使用の領域は、データベース内のすべてのデータを新しいデータ ページに再書き込みすることにより再利用されます。オブジェクトやレコードがデータベースから削除されると、割り当てられていた領域は、データベースへの新しい追加データ用に利用可能としてマークされます。ページ全体のデータが削除されない限り、そのページは部分的に使用されたままの状態になります。データベースは、最後のデータがページから削除されるか、データベースが最適化されない限り圧縮されません。データベースでオブジェクトとレコードの追加、削除、および更新を頻繁に行う場合は、最適化を頻繁に行うことをお勧めします。
次に割り当てられる値が残りのレコード内の最大値よりも 1 ステップ値分大きくなるように、ID 列の増分がリセットされます。たとえば、データベースのすべてのレコードが削除された場合、データベースの最適化により、次のレコードの ID 列の値がシード値に設定されます。データベース内に残っている最大 ID 値が 50 で、ステップ値が 5 の場合は、データベースの最適化により、次のレコードの値が 55 に設定されます。50 を超える値が含まれたレコードが以前に追加されたとしても、最適化前に削除されればこの値は 55 になります。ステップ値は負の数にすることもできます。たとえば、ステップ値が -5 で、最小値が 15 の場合、データベースを最適化すると、次のレコードの値は 10 に設定されます。
注意
元のリリース バージョンの Visual Studio 2008 を使用している場合に、この動作が行われます。データベースを最適化しても、Visual Studio 2008 SP1. の ID 情報は変更されません。
最適化後のデータベースの接続文字列のロケール ID またはパスワードの値が指定された場合、これらの値は最適化後のデータベースの作成時に使用されます。
データベースを最適化する前に、以下の条件が満たされていることを確認してください。
データベースを閉じる必要があります。
Compact メソッドを使用するときに、最適化後のデータベースがあらかじめ存在しないようにする必要があります。DestConnection に指定したデータベースが既に存在する場合、または同じ名前のファイルが既に存在する場合は、エラーが発生します。
キャッシュされたデータや一時データベースに格納されたデータ以外に、最適化前のデータベースと最適化後のデータベースの両方を格納するための十分な記憶域用メモリが必要です。
重要
Compact メソッドを使用するには、最適化前のデータベースのサイズの少なくとも 2 倍の空き領域がデバイスに存在する必要があります。
自動圧縮
データベースを最適化するには、新しいデータベースを作成し、最適化前のデータベースから新しいデータベースにすべてのオブジェクトをコピーします。通常、最適化は自動的には開始されません。自動的にデータベース ファイルのサイズを調整することを、自動圧縮 (AutoShrink) と呼びます。この技法は、プロセッサの時間とメモリをほとんど使用しないので、特にハンドヘルド デバイスとモバイル データベース製品に適しています。Autoshrink 技法では、空のページや未割り当てのページがファイルの末尾に連続して配置されるように、ファイル内のページが移動されます。空のページは、その後切り捨てられます。切り捨てられたページは、後でデータベース ファイル システムで使用できます。切り捨てられたページがデータベース ファイル システムに戻されることにより、ファイル システムの領域が増加します。
マネージ コードで Autoshrink を設定するには、AutoShrink Threshold 接続文字列プロパティを使用します。ネイティブ コードの場合は、DBPROP_SSCE_AUTO_SHRINK_THRESHOLD プロパティを使用します。このプロパティで、ファイル内の空き領域の割合を指定してから、Autoshrink を開始します。
注意
Shrink メソッドを呼び出してデータベースを圧縮することもできます。詳細については、「System.Data.SqlServerCe」を参照してください。
検証
SQL Server Compact 3.5 データベース ファイルは、ページと呼ばれる 4 KB の論理ユニットに分割されます。各ページがデータベース ファイルに書き込まれると、SQL Server Compact 3.5 によってそのページのチェックサムが計算され、保存されます。ファイルに書き込まれた後でページが変更されたり破損した場合、そのページのチェックサムは予想されたものと一致しなくなります。SQL Server Compact 3.5 によりこのページが読み取られると、ネイティブ エラー SSCE_M_DATABASECORRUPTED (25017) が返されます。
SqlCeEngine クラスの Verify メソッドを呼び出すと、データベース ファイル内のすべてのページのチェックサムが再計算され、それらのチェックサムが予想された値と一致するかどうかが検証されます。このメソッドで true が返された場合、データベース ファイルは破損していません。false が返された場合、データベース ファイルが破損しているので、アプリケーションで Repair メソッドが呼び出されます。
修復
データベース ファイルが破損した場合、SqlCeEngine オブジェクトの Repair(System.String,System.Data.SqlServerCe.RepairOption) メソッドまたはネイティブの Engine オブジェクトのプログラミング (SQL Server Compact) の Repair メソッドを使用して、データベース ファイルの修復を試行できます。Repair メソッドを使用すると、データベースがスキャンされ、ページ チェックサムが計算されます。このチェックサムが、ページがデータベースに書き込まれたときに計算されたチェックサムに一致しない場合、ページは破損していると見なされます。Repair メソッドが RepairOption.DeleteCorruptedRows の値と共に呼び出された場合、破損したページはすべて破棄されます。この場合、破損ページにデータベース スキーマが含まれていると、重要なデータの損失が発生する可能性があります。しかし、Repair メソッドを使って修復したデータには破損が含まれません。Repair メソッドが RepairOption.RecoverCorruptedRows の値と共に呼び出された場合、データベースでは、破損したページからのデータの読み取りが試行されます。これが、より多くのデータを修復することになります。ただし、このオプションを使用しても、修復したデータが論理的に破損していないことは保証されません。
注意
Repair メソッドは、SQL Server Compact 3.5 からネイティブ エラー SSCE_M_DATABASECORRUPTED (25017) が返された場合、または SqlCeEngine オブジェクトの Verify メソッドを呼び出して false が返された場合にのみ役立ちます。
自動フラッシュ
トランザクションの結果、データベースで変更が発生すると、これらの変更はトランザクションでコミットまたはアボートされるまでバッファ プールで保持されます。アボートされた場合、データベースへの変更は破棄されます。コミットされた場合、データベースへの変更は他のユーザーとトランザクションから参照できるようになりますが、すぐにはデータベースに書き込まれないことがあります。デバイスのリセットなどによりプログラムが異常終了した場合、コミットされたがデータベースに変更が書き込まれていないトランザクションは破棄されます。
トランザクションは、常にコミットされた順序でデータベースに書き込まれることに注意してください。これは、トランザクションが損失することはあっても、データベースの一貫性は常に保たれることを意味します。たとえば、アプリケーションでトランザクション A がコミットされ、次にトランザクション B がコミットされたとします。アプリケーションがクラッシュしたりデバイスがリセットされた場合、データベースの状態は以下の 3 つのうちのいずれかになります。
変更されない
トランザクション A により変更される
A と B の両方により変更される
トランザクションがコミットされた順序でデータベースに書き込まれることにより、データベース ファイルの書き込み回数が減少し、パフォーマンスが向上します。パフォーマンスの向上は、短時間でコミットされた小さなトランザクションが多数存在する場合に、特に顕著になります。この場合、トランザクションごとに別々のデータベース書き込み操作が発生するのではなく、すべてのトランザクションが同時にデータベース ファイルに書き込まれます。
保留されているバッファ プール内の変更は、ADO .NET の Flush Interval 接続文字列プロパティ (OLE DB では DPROP_SSCE_FLUSH_INTERVAL プロパティ) により、指定された間隔で書き込まれたりフラッシュされたりします。これらのプロパティにより、コミットされたトランザクションがディスクにフラッシュされるまでの最大秒数が設定されます。
注意
コミット時にデータベースに保存されるトランザクションの場合、アプリケーションで CommitMode 列挙 (OLE DB では DBPROP_SSCE_TRANSACTION_COMMIT_MODE プロパティ) を使用して、コミット時の既定のフラッシュ動作を上書きできます。これらのプロパティをアプリケーションで使用することにより、データベース内で発生したすべてのトランザクションが正常に保存されることを保証できます。
バックアップ、復元、削除
SQL Server Compact 3.5 はファイル ベースのデータベース システムなので、ファイル システム API を使用して、バックアップ、復元、削除など、繰り返し使用する多くのデータベース作業を実行できます。
データベースをバックアップするには、データベースへのすべての接続を閉じてから、.sdf ファイルをコピーします。
データベースを復元するには、.sdf ファイルを通常の作業場所にコピーします。これらの操作は、データベースがレプリケーション用に設定されている場合でも機能します。
データベースを削除するには、.sdf データベース ファイルを削除します。