タグ付けされた質問 「database-size」

4
空きディスク容量なしでVACUUM FULLを実行する必要があります
サーバー上のhdスペースの90%近くを占めるテーブルが1つあります。スペースを空けるために、いくつかの列をドロップすることにしました。しかし、スペースをOSに戻す必要があります。ただし、問題は、VACUUM FULLを実行し、テーブルのコピーを作成するための十分な空き領域がない場合にどうなるかわからないことです。 VACUUM FULLは使用すべきではないことを理解していますが、このシナリオでは最良の選択肢であると考えました。 任意のアイデアをいただければ幸いです。 PostgreSQL 9.0.6を使用しています


6
ログファイルを圧縮してもサイズは小さくなりません
350 MBのデータファイル(.mdf)と4.9 GBのログファイル(.ldf)を持つデータベースがあります。復旧モデルはに設定されFULLます。 ログファイルを圧縮しようとしても、圧縮されません。 データベースの縮小は良くないことを知っています。しかし、私はまだログファイルを縮小するためにそれをやろうとしています。 走ったとき DBCC SQLPerf(logspace) ログサイズは4932 MBで、使用されるログ領域は98.76%であることがわかりました。 それから私はこのコマンドを試しました USE <databasename>; DBCC loginfo; 現在、ほとんどすべてのVLFは「ステータス2」であり、すべてが使用中であることを意味します。 ログのバックアップを取り、ログファイルを圧縮しようとしました。縮小してもサイズは小さくなりませんでした。 復旧モデルをに変更し、SIMPLE再度縮小しようとしましたが、これも役に立ちませんでした。 未処理のトランザクションを確認しました DBCC opentran (database); 現在開いているトランザクションがないことがわかりました。 ログファイルの縮小を妨げているのは何ですか?どうすれば解決できますか?

2
DELETE + REORGがディスクスペース(DB2)を解放しないのはなぜですか?
DB2には、大きなバイナリデータを含むテーブルがあります。今、テーブル全体をパージし、runstats、reorg、runstatsを実行しましたが、使用されたディスク容量は変わりません。ここで何が間違っているのでしょうか? テーブルは、次のように作成した独自のテーブルスペースにあります。 CREATE BUFFERPOOL "MY_BP" SIZE 250 AUTOMATIC PAGESIZE 4096; CREATE LARGE TABLESPACE MY_TBS IN DATABASE PARTITION GROUP IBMDEFAULTGROUP PAGESIZE 4096 MANAGED BY AUTOMATIC STORAGE EXTENTSIZE 64 PREFETCHSIZE 64 BUFFERPOOL MY_BP OVERHEAD 10.500000 TRANSFERRATE 0.140000 FILE SYSTEM CACHING; 私は次のように削除/再編成しました: DELETE FROM MY_TBL RUNSTATS ON TABLE MY_TBL WITH DISTRIBUTION AND DETAILED …

1
Postgres:マテリアライズドビューが使用するディスク容量を確認しますか?
Postgresでインデックスとテーブルのサイズを確認する方法を知っています(バージョン9.4を使用しています)。 SELECT relname AS objectname, relkind AS objecttype, reltuples AS "#entries", pg_size_pretty(relpages::bigint*8*1024) AS size FROM pg_class WHERE relpages >= 8 ORDER BY relpages DESC; しかし、これには具体化されたビューは表示されません。使用しているディスク容量を確認するにはどうすればよいですか?

3
PostgreSQL初期データベースサイズ
私の質問には2つの部分があります。 PostgreSQLのデータベースの初期サイズを指定する方法はありますか? 存在しない場合、データベースが時間の経過とともに大きくなった場合の断片化にどのように対処しますか? 最近、MSSQLからPostgresに移行しました。データベースを作成するときにMSSQLの世界で行ったことの1つは、データベースとトランザクションログの初期サイズを指定することでした。これにより、特にデータベースの「通常の」サイズが事前にわかっている場合、断片化が減少し、パフォーマンスが向上します。 サイズが大きくなると、データベースのパフォーマンスが低下します。たとえば、私がそれを実行しているワークロードは通常10分かかります。データベースが大きくなると、この時間が長くなります。VACUUM、VACUUM FULL、およびVACUUM FULL ANALYZEを実行しても問題は解決しないようです。パフォーマンスの問題を解決するのは、データベースを停止し、ドライブの断片化を解消してから、VACUUM FULL ANALYZEを実行すると、テストのパフォーマンスが元の10分に戻ります。これは、断片化が痛みの原因であると疑うことにつながります。 Postgresでテーブルスペース/データベーススペースを予約するための参照を見つけることができませんでした。間違った用語を使用しているため何も見つからないか、Postgresでファイルシステムの断片化を緩和する別の方法があります。 ポインタはありますか? ソリューション 提供された回答は、私が疑い始めたことを確認するのに役立ちました。PostgreSQLはデータベースを複数のファイルに保存します。これにより、断片化の心配なしにデータベースを拡張できます。デフォルトの動作では、これらのファイルをテーブルデータでいっぱいにパックします。これは、ほとんど変更されないテーブルには適していますが、頻繁に更新されるテーブルには適していません。 PostgreSQLはMVCCを使用して、テーブルデータへの同時アクセスを提供します。このスキームでは、更新ごとに更新された行の新しいバージョンが作成されます(これはタイムスタンプまたはバージョン番号を使用している可能性があります)。古いデータはすぐには削除されませんが、削除のマークが付けられます。実際の削除は、VACUUM操作が実行されるときに発生します。 これは曲線因子とどのように関係しますか?テーブルのデフォルトのフィルファクター100はテーブルページを完全にパックします。つまり、テーブルページ内に更新された行を保持するスペースがないことを意味します。つまり、更新された行は元の行とは異なるテーブルページに配置されます。私の経験が示すように、これはパフォーマンスに悪いです。サマリーテーブルは非常に頻繁に更新されるため(最大1500行/秒)、20のFILL FACTORを設定することを選択しました。つまり、テーブルの20%が挿入行データ用で、80%が更新データ用です。これは過度に思えるかもしれませんが、更新された行のために予約された大量のスペースは、更新された行が元のページと同じページ内に留まり、autovacuumデーモンが古い行を削除するまでにテーブルページがいっぱいにならないことを意味します。 データベースを「修正」するために、次のことを行いました。 サマリーテーブルのFILL FACTORを20に設定します。作成時にこれを行うには、パラメーターをCREATE TABLEに渡すか、ALTER TABLEを介してファクトの後に渡します。次のplpgsqlコマンドを発行しました。ALTER TABLE "my_summary_table" SET (fillfactor = 20); VACUUM FULLを発行しました。これにより、完全に新しいバージョンのテーブルファイルが書き込まれ、含意により新しいフィルファクターで新しいテーブルファイルが書き込まれます。 テストを再実行すると、数百万行のデータベースが必要な大きさであっても、パフォーマンスの低下は見られません。 TL; DR-ファイルの断片化は原因ではなく、表スペースの断片化でした。これは、特定のユースケースに合わせてテーブルのFILL FACTORを調整することで軽減されます。

1
MySQL Workbenchのデータベースサイズ
すべてのMySQL Workbenchデータベースが使用しているハードディスク上の合計サイズを見つけようとしています。 誰もこれを理解する簡単な方法を知っていますか? それ以外の場合、mysql / workbenchがWindowsマシンに生データを保存するために使用するデフォルトの場所は? 前もって感謝します!クインティス

4
テーブルごとにデータとディスク使用の内訳を表示
SQL Server 2008 R2データベースをいくつかの展開されたプログラムで使用しています。 質問:データベース内のすべてのテーブルについて、各テーブルが消費する領域を表示し、論理領域とディスク領域を区別する簡単な方法はありますか? SSMS(Management Studio)を使用している場合、データベースに表示されるストレージプロパティは167 MBであり、3 MBが「利用可能」です(約適切なサイズですが、3 MBが利用可能かどうか心配です-これは心配する限界です) 、十分なディスク容量があることを知っているとしたら?) 各テーブルにドリルダウンできますが、それを行うには永遠にかかります。 独自のクエリを記述してテストできることはわかっていますが、これを行う簡単な(組み込み?)方法が既にあるかどうかを知りたいです。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.