問題タブ [vacuum]

SAMSUNG Glaxy と Huawei C8812 からそれぞれ 2 つの mmssms.db ファイルを取得しました。「PRAGMA auto_vacuum;」の実行 これらのファイルでは、結果は両方とも「1」になります。しかし、16 進エディタを使用してこれらのファイルを開くと、これらのファイルの ptrmap ページにフリーリスト ページ レコードがあることがわかりました。次に、いくつかのSMS削除操作の後、これらのファイルをデバイスから再度プルしました。まだ ptrmap ページで freelist ページ レコードを見つけることができました。自動バキューム モードが 1 または「フル」の場合、フリーリスト ページはデータベース ファイルの末尾に移動され、トランザクション コミットごとにフリーリスト ページを削除するためにデータベース ファイルが切り捨てられます。これらのフリーリスト ページ レコードとフリーリスト ページはどのように残っていますか?

アプリケーション データベースの作業を最適化してみてください。

データベースの同期中に、アプリケーションは 1 つのトランザクション内で「削除」コマンドと「挿入」コマンドの大きなパッケージを実行します。トランザクション「COMMIT」アプリケーションの後、「VACUUM」コマンドを実行します。VACUUM は正常に動作しますが、時間がかかる場合があります。そこで、「VACUUM」の実行を並列スレッドに移動することにしました。そして、ここで何かがうまくいかない。他のスレッドでは、「データベースがロックされています」と表示されます。

私がやること：

1.「COMMIT」が成功した後、データベースを閉じます。

2.「VACUUM」でデータベースを再度開いて閉じる別のメソッドを開始します。

「COMMIT」の同じスレッドでは「VACUUM」は正常に動作しますが、別のスレッドでは同じメソッドが「データベースがロックされています」というエラーを取得します。データベースの同期は論理的に別のアプリケーション プロセスであるため、クローズド データベースで動作するプロセスは他にないと断言できます。

私は何を間違っていますか？

クエリの作成/削除/更新時にエラーが発生しました:

エラー: データベースは、データベース "mydb" でラップアラウンド データ損失を回避するコマンドを受け付けていません。 ヒント: ポストマスターを停止し、スタンドアロン バックエンドを使用してそのデータベースをバキュームします。古い準備済みトランザクションをコミットまたはロールバックする必要がある場合もあります。

そのため、データベースはブロックされ、SELECT クエリしか実行できません。

データベースのサイズ 350 GB。1 つのテーブル ( my_table ) には最大 10 億行あります。

システム: 「x86_64-unknown-linux-gnu 上の PostgreSQL 9.3.4、gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)、64 ビットでコンパイル」

postgresq.conf いくつかの設定:

準備済みトランザクションは使用しません。しかし、基本的なストアド プロシージャ (つまり、自動トランザクションですよね?) は 1 日に 5000 万回も使用されます。

現在、「autovacuum: VACUUM ANALYZE public. my_table (ラップアラウンドを防ぐため)」が実行されており、そのクエリ アクティビティはほぼ 12 時間です。

私が理解している限り、バキュームされていない死んだタプルの問題ですよね？

この問題を解決し、将来これを防ぐにはどうすればよいですか? 助けてください ：）

話の終わり (~1 か月後) 今、私の大きなテーブルは数千のテーブルで分割されています。各小さなテーブルは、はるかに高速にバキュームされます。自動バキューム構成がデフォルトにより近く設定されました。必要に応じて、さらに積極的に設定することもできますが、これまでのところ、数十億行のデータベースがうまく機能しています。

したがって、トピックの問題は再び表示されないはずです。

ps 現在、データのスケーラビリティの次のステップとして Postgres-XL を検討しています。

バキュームが実行されたときに表示するクエリを見つけましたが、現在実行されているクエリは見つかりませんでした。( http://heatware.net/databases/postgres-tables-auto-vacuum-analyze/ )

これを達成するためのクエリはありますか? pg_stat_activity をヒットできることはわかっていますが、一部のバキュームにはテーブル名がなく、pg_toast.pg_toast_3621837 が含まれているため、これは 100% の時間は機能しません。

Amazon Redshift のドキュメントを読んで、クエリのパフォーマンスを向上させるために、これまでバキュームされたことのない特定の 400GB テーブルで VACUUM を実行しました。残念ながら、VACUUM によってテーブルが 1.7 TB (!!) に増大し、Redshift のディスク使用率が 100% になりました。次に、スーパー ユーザー キューで CANCEL クエリを実行して VACUUM を停止しようとしましたが (「set query_group='superuser';」を実行して入力します)、クエリでエラーは発生しませんでしたが、実行し続けるvaccumクエリ。

私に何ができる？

私は MySQL よりも PostgreSQL に精通しています。PostgreSQL db でラップアラウンド Id 障害に一度遭遇し、db でのバキュームの重要性を理解しました。実際、これは対処するのに非常に大きなオーバーヘッド作業でした (そして、自動バキュームを持つように数か月前に更新された古いバージョン 7.4.3 での作業でした)。MySQL と PostgreSQL を比較する場合、MySQL は PostgreSQL のバキュームのようなオーバーヘッドに対処する必要がないと仮定してください。この仮定は正しいですか？

また、PostgreSQL と比較して、MySQL Dbs ではバキュームが必要ないのはなぜですか? MySQL データベースに存在するバキュームに似た他の最適化の代替手段はありますか?

postgresql-9.2を使用して、現時点では、次のクエリを使用しているテーブルを見つけています。dead_tuples

これはテーブル名を返し、次に実行します：

それは良い方法ですか、それとも変更する必要がありますか?もしそうなら、いくつかの方法を提案してください

ありがとう