問題タブ [vacuum]

たとえば、SQLite データベースに定期的にデータを挿入し、データの最初の 50% を消去するとしますが、バキュームは行いません。

今、ファイルの最初の 50% をゼロにしたページのようなものはありますか? データの別のバッチを追加すると、それらのゼロ化されたページに入力されますか?

マニュアルでは、データの断片化について言及しています。

挿入、更新、および削除を頻繁に行うと、データベース ファイルが断片化する可能性があります。つまり、単一のテーブルまたはインデックスのデータがデータベース ファイルに散らばっています。

VACUUM は、各テーブルとインデックスの大部分がデータベース ファイル内に連続して格納されるようにします。場合によっては、VACUUM はデータベース内の部分的に埋められたページの数を減らし、データベース ファイルのサイズをさらに減らすこともあります。

ただし、これによって必ずしもパフォーマンスが低下することを示すわけではありません。それは主に、掃除機をかけることで節約できる無駄なスペースをほのめかしています。

厳密に連続したページのデータで顕著なパフォーマンスの向上はありますか? 断片化されたデータがたくさんあるデータベースに「ひどい」パフォーマンスを期待できますか?

私は当初、PostgreSQLで同じカウントを与えると考えn_dead_tupていました。dead_tuple_countしかし、そうではないようです。私は違いが正確に何であるかをよく理解していません。

以下は私の観察です：

1. 10k 行のテーブルを作成しました。
2. 10k 行すべてを更新しました。今、私は10kの死んだタプルを持っています。

3. テーブルの上を掃除機でいっぱいにしました。予想どおり、dead_tuple_count は 0 です。

しかしn_dead_tup、pg_stat_all_tablesieからpg_stat_get_dead_tuples('18466')はまだ 10002 です:

このプロセスを数回繰り返したところ、更新のn_dead_tupたびに更新されたタプルの数が統計に追加されていることがわかりました。

では、ここで正確に何が行われているのVACUUMでしょうか? n_dead_tupとはどう違いdead_tuple_countますか？

いくつかの行を削除した後、ROWID を順番に並べ替える必要があります。テーブルのバキュームは状況に適しているようですが、何らかの理由で行 ID を並べ替えません。

どうしたの ？

実稼働 PostgreSQL で 1 つの問題に直面しています。これは、基本的に XID 範囲の制限を超えるラップアラウンドの問題に関連しています。

この PostgreSQL プロダクションは、大量のトランザクションと一括挿入で 1 年以上実行されています。

私はグーグルでたくさん検索しましたが、この重大なエラーについて混乱し、非常に恐れています。現在、バキュームまたは自動バキューム中にこのエラーが発生しています。約 250 GB の Postgres 運用データベースがあり、すべてのテーブルに自動バキュームも設定しています。

現在開いているトランザクションも確認しましたが、Postgres セッションで実行時間の長いトランザクションはありません。

上記の結果は、以下のクエリを使用して取得しました:

すぐに本番データベースに問題が発生するため、できるだけ早く入力を提供してください。

sqlite3 データベースに裏打ちされたキャッシュを構築しています。使用するディスク容量を制限するために、db ファイルのサイズを定期的にチェックしています。最大制限を超えている場合は、最も古いアイテムを一括削除してバキュームし、サイズが最大の 80% を下回るまで繰り返します。

ただし、バキューム直後はファイル サイズが変化していないため、通常、サイズが小さくなる前にテーブル全体を削除することになります。すべての呼び出しはSQLITE_OK、どこにも見られるエラーなしで返されます。

次のようなものを生成します。

バキュームが終了したことを確認するにはどうすればよいですか?また、ファイル サイズを再度確認するにはどうすればよいですか?

sqlite は教えてくれたり、ブロックさせたりできますか? 何かを使用する必要がありますinotifyか？

これら2つのことについての私の理解が正しいことを確認したいだけです。関連する場合は、Postgres 9.4 を使用しています。

テーブルや多数の行を削除した後など、定期的にファイルシステムからスペースを再利用しようとするときは、データベースをバキュームする必要があると思います。

新しいインデックスを作成した後、または (定期的に) テーブルに大量の行を追加または削除した後にデータベースを分析して、クエリ プランナーが適切な呼び出しを行えるようにする必要があると私は考えています。

そうですか？

最近、エンターテインメントとして、ライブラリSystem.Data.SQLiteによって提供される EntityFramework を使用して SQlite の利点をテストする小さなプロジェクトを開発することにしました。

アプリケーションにはデータ同期プロセスがあり、時間の経過とともに古くなるため、データベースから削除することにしました。予想通り、テーブルの行を削除してもデータベースのサイズは縮小されないので、そこで VACUUM コマンドを実行することにしました。

この優れたブログSQLite、VACUUM、および auto_vacuum を読んだ後、すべてがより明確になりました。特に、トランザクション内でコマンドを実行できないという事実です。

Code First がまだ利用できないように、スクリプトを使用してデータベースにテーブルを作成する必要があるため、同じ場所でコマンドを実行します。

次の例外を受け取って驚きました。

追加情報: SQL 論理エラーまたはデータベースがありません。トランザクション内から VACUUM できません。

メソッド ExecuteSqlCommand によって実行されるすべてのコマンドは、トランザクション内で処理されると思います。.NET Framework 4.5 でEntityFramework 6.1.3 とSystem.Data.Sqlite 1.0.97.0 を使用しています。

質問

私はそれについて間違っていますか？もしそうなら、コマンドを実行する方法はありますか?

「vacuum reindex」操作がスタックしており、これほど長い時間がかかる原因は何なのか疑問に思っています。

最近、Redshift テーブルの 1 つのスキーマを変更しました。変更したスキーマで新しいテーブルを作成し、「select into」を使用してデータをディープ コピーしました (「ディープ コピーの実行」を参照)。私の基本的な理解は、テーブルをディープコピーした後、テーブルのソートキーに従ってデータをソートする必要があるということでした。テーブルには、インターリーブされた 4 列のソート キーがあります。念のため、ディープ コピーを行った後、「インターリーブ スキュー」クエリを実行しました ( Decision When to Reindex を参照)。結果はすべての列で 1.0 であり、スキューがないことを意味します。

次に、テーブルで 'vacuum reindex' を実行しました。データは既にソートされているため、非常に高速です。ただし、掃除機は 30 時間後も稼働しています。バキューム中、定期的に svv_vacuum_progress を調べてバキューム操作の状態を確認しました。「並べ替え」フェーズは約 6 時間後に終了しましたが、現在、「マージ」フェーズは「増分 23」で 12 時間以上スタックしています。

ディープ コピー操作によってデータが既に並べ替えられているはずの場合、長いバキューム操作の原因は何でしょうか? 将来のバキューム操作についても、これらの時間を期待できますか? テーブルには最大 35 億行が含まれており、その合計サイズは最大 200 GB です。