私は Firebird を使用していますが、最近データベースが非常に大きくなっています。更新/挿入だけでなく、実際には多くの削除ステートメントが実行されており、データベースファイルのサイズは非常に急速に大きくなります。大量のレコードを削除した後、データベースのサイズは減少せず、さらに悪いことに、実際にはクエリが少し遅くなったような気がします。これを修正するために、毎日のバックアップ/復元プロセスが必要でしたが、完了する時間があるため、Firebird を使用するのは本当にイライラしていると言えます。
これに関する回避策や解決策に関するアイデアは大歓迎です。
また、友人からこの問題が発生していないと聞いたので、Interbase に切り替えることを検討しています。
本番環境の Firebird には巨大なデータベースが多数ありますが、データベースの増大に関する問題は一度もありませんでした。はい、レコードが削除または更新されるたびに、その古いバージョンがファイルに保持されます。しかし、遅かれ早かれガベージコレクターがそれを一掃します。両方のプロセスのバランスがとれると、データベース ファイルは新しいデータとインデックスのサイズだけ大きくなります。
データベースの膨大な増加を防ぐための一般的な予防措置として、トランザクションをできるだけ短くするようにしてください。私たちのアプリケーションでは、すべてのデータを読み取るために 1 つの READ ONLY トランザクションを使用します。このトランザクションは、アプリケーションの存続期間全体を通じて開かれています。挿入/更新/削除ステートメントのバッチごとに、短い個別のトランザクションを使用します。
古いインデックス統計が原因で、データベース操作が遅くなる可能性があります。ここでは、すべてのインデックスの統計を再計算する方法の例を見つけることができます: http://www.firebirdfaq.org/faq167/
アプリケーションに未完了のトランザクションがあるかどうかを確認してください。トランザクションが開始されたが、コミットもロールバックもされていない場合、データベースには、最も古いアクティブなトランザクションの後に、トランザクションごとに独自のリビジョンがあります。
データベース統計 (gstat または外部ツール) を確認できます。最も古いトランザクションと次のトランザクションがあります。これらの数値の差が大きくなり続ける場合は、スタック トランザクションの問題があります。
状況をチェックする監視ツールもあります。私が使用したツールの 1 つは、Sinatica Monitor for Firebird です。
編集:また、データベース ファイルが自動的に縮小されることはありません。その一部は (スイープ操作後) 未使用としてマークされ、再利用されます。http://www.firebirdfaq.org/faq41/
削除されたレコードが占めるスペースは、Firebird によってガベージ コレクションが行われるとすぐに再利用されます。GC が発生していない場合 (トランザクションの問題?)、DB は GC が機能するまで成長し続けます。
また、テーブル (例: 数百万のレコード) で大量の削除を行うと問題が発生し、そのテーブルの次の選択でガベージ コレクションが「トリガー」され、GC が終了するまでパフォーマンスが低下します。これを回避する唯一の方法は、サーバーがあまり使用されていないときに大量の削除を行い、その後スイープを実行して、スタックしたトランザクションがないことを確認することです。
また、一時データを保持するために「標準」テーブルを使用している場合 (つまり、情報の挿入と削除を数回繰り返す場合)、状況によってはデータベースが破損する可能性があることに注意してください。グローバル一時テーブル機能の使用を開始することを強くお勧めします。