タグ付けされた質問 「disk-space」

金曜日の午後9時に毎週のバックアップジョブを実行しますが、ディスクスペース（時々非常に低くなります）とパフォーマンスに関するいくつかの問題が発生しています。何が起こるかを合理化/最適化することを検討しており、コメントをお待ちしています。 具体的には： バックアッププロセスは、バックアップ中に統計を更新するのに約4時間かかります。このプロセスを安全に無効にして時間を節約できますか？ ディスクスペースが非常に頻繁に不足しているため、プロセスを再調整する必要があるかと考えています。現在、バックアップを作成してから以前のバックアップを削除しますが、これがディスク容量を圧迫しています。最初に以前のものを安全に削除してからバックアップを実行できますか？ その他のコメントや意見は大歓迎です編集：サーバー上のSQLファイルの合計サイズは約35GBです。1つのデータベースのサイズは約25GBで、他の6つの共有は他の10GB程度を占めています。

12 sql-server-2008  backup  maintenance  disk-space 

私はTRUNCATEと呼ばれる巨大な（〜120Gb）テーブルを持っていますfiles： TRUNCATE files; VACUUM FULL files; テーブルサイズは0ですが、ディスク領域は解放されていません。失われたディスク容量を回収する方法はありますか？ 更新： 12時間後にディスク領域が解放されましたが、何も操作しませんでした。Ubuntu 8.04サーバーを使用しています。

12 postgresql  truncate  disk-space 

SQL Serverのいくつかのバージョンをテストに使用し、ラップトップにインストールしています（2012、2014、2016、2017）。先日、更新（SP、CU）間で以前のバージョンのファイルを含むフォルダーがあることに気付きました。すべてのバージョンで、実際にはかなりのスペースが使用されています。 （C：\ Program Files（x86）\ Microsoft SQL Server \にあります） 110\Setup Bootstrap\Log - 91.8 MB (818 files) 110\Setup Bootstrap\Update Cache - 608 MB (2,382 files) （以下のフォルダはすべてC：\ Program Files \ Microsoft SQL Server \にあります） 110\Setup Bootstrap\Log - 1.18 GB (3,715 files) 110\Setup Bootstrap\Update Cache - 9.58 GB (14,766 files) 120\Setup Bootstrap\Log - …

11 sql-server  best-practices  disk-space  management 

シナリオ： ASP.NETアプリケーションにサービスを提供するSQL Server 2005データベース（別のWebサーバー上）。 データベース： DBには、約5GBの「通常の」データと約15GBの「ファイル」があります（例：画像（BLOB）として保存された200k PDFなど）。より多くのファイルがユーザーによってアップロードされており、急速に多くのディスク領域を消費しています（DBは、今後数か月で50GBに増加する可能性があり、ほとんどがファイルです）。 懸念事項： DBに非常に多くのファイルを保存すると、既に問題が発生しています（例：データベースの合計サイズが大きいと、DB全体のバックアップと展開が時々難しくなります。）。 そして、さらに問題が発生するのではないかと心配しています。（例：パフォーマンスの問題-おそらく、DB全体をRAMに保持できないことが原因でしょうか？） 質問： この問題に対してどのような技術的解決策を提案しますか？ファイルをファイルシステムに保存しますか？データベースを2つに分割し、ファイル用に大きくて遅いファイルを持っていますか？ 必要に応じてさらに詳細： これらのファイルはそれほど重要ではなく、非常に高速なアクセス時間を必要としません。現在、数秒で十分ですが、現在1時間あたり数十の選択があります。DBの他の「通常の」データには、毎秒何回も必要な情報が含まれています。

11 sql-server-2005  performance  disk-space 

私の質問はPostgresを対象としていますが、回答はデータベースの背景から得られたもので十分かもしれません。 私の仮定は正しいですか： ディスクのブロックサイズは固定ですか？ RAIDコントローラーは異なるブロックサイズを持つことができますか？1つのRAIDブロックが複数の実ディスクブロックに分割されますか？ ファイルシステムには独立したブロックサイズもあり、RAIDブロックサイズに分割されますか？ Postgresは固定の8kブロックで動作します。ここでファイルシステムのブロックサイズへのマッピングはどのように行われますか？Postgres 8kブロックはファイルシステムによってバッチ処理されていますか？ システムをセットアップするとき、すべてのブロックを8kにするのが最善ですか？または、設定は重要ではありませんか？クラッシュした場合に、いくつかの「間違った」ブロックサイズ設定がデータの整合性を危険にさらす可能性があるかどうかも疑問に思っていましたか？たぶん、Postgres 8kブロックを複数のディスクブロックに分割する必要がある場合はどうでしょうか。 または、何も一緒にバッチ処理されないため、定義されたブロックサイズ間のすべての不一致によってディスク領域が失われますか？

11 disk-space  disk-structures 

私たちの環境では、ネットワークストレージの空き容量が少なくなっています。同時に、トランザクションログのバックアップを、6時間ごとではなく、15分ごとに行うようにしたいと思います。私の質問は、ログのバックアップ間隔を6時間から15分ごとに変更すると、より多くのディスク容量が消費されるのでしょうか。

10 sql-server  backup  transaction-log  disk-space  network 

タイトルはそれをかなり要約します。バックアップディスクのスペースが不足しているため、古いバックアップをセットから削除する必要があります。これに関する情報が見つからないようです。

10 backup  sql-server-2008-r2  disk-space 

Mac（10.10.4）でpostgres（postgis）9.4.2を実行しています。 私はいくつかの大きなテーブル（数TB）を持っています。 そのうちの1つで約1週間かかるインデックス作成中に、停電がバッテリーユニットとシステムよりも長く続いたときにインデックスが終了するポイントに近いと予想されるので、利用可能なHDスペースの低下を観察しました降りた。fillfactor=100静的データソースであるため、私はバッファをオフにしていて、ビルド中にそれを行いました。再起動時に、ドライブに残っている使用可能なスペースは、インデックスビルドのほぼ終了時とまったく同じです。真空分析はスペースを解放しません。 テーブルを落として再度取り込みましたが、スペースは落ちませんでした。現在、インデックスを作成するための十分なスペースがない場所にいます。 インデックスの構築中に生成されたファイルは、停電中にマシンがダウンした方法が原因でシステムによって削除できない場所でスタックしていますか？ テーブルサイズとデータベース内のインデックス（そのドライブ上の唯一のデータ）を見ると、合計で約6TBです。ドライブです8TB未満、そこにある500ギガバイトは、インデックスがあったであろうという大きさです1.5TB失われたどこかに約あるようですので、ドライブに残しました。 何か案は？

9 postgresql  index  postgresql-9.4  disk-space  vacuum 

不十分に管理されたデータベーステーブルは巨大なものに成長しました。孤児のレコードの48+ギグ。私はそれをクリーンアップして、危険なほどにいっぱいになったハードドライブを通常の状態に戻そうとしています。このテーブルから約4億個のレコードを削除します。これは、私が入力しているときに実行されています。ハードドライブ領域の低下は見られませんが、システムテーブルクエリでメモリの低下が見られます。テーブルサイズを取得するために実行しています。データベースは「単純復旧モデル」を使用しています。 これに類似した多くの質問があり、データベースを縮小する必要があると回答しています。しかし、彼らは断片化されたデータなどのためにこれがどのように悪い/怖いのかを説明し続けます データベースはこのサイズであってはならないので。それを縮小するのはまだ悪いですか？ これは本番データベースです。縮小すると、ダウンタイムが発生したり、データベースがロックされたりしますか？ SQL Server Management Studioには、縮小、データベース、またはファイルの2つのオプションがあります。私の状況を考えると、最良の選択肢は何でしょうか？ DBに必要な空き領域の割合に関するルールはありますか？ 縮小のタグの説明を読んでも、私はそれをしたくありません。別の方法はありますか？

9 sql-server  disk-space  shrink 

SQL Serverデータベースでの自動拡張操作を回避するために、mdf / ndfファイルを手動で大きなサイズに変更しました。ファイルの方が大きいので、ディスクパーティションの空き領域はほとんどなく、システム管理者は、領域が不足していることを警告し続けます。 サイズを変更したため、データファイルには多くの空き領域がありますが、ファイルサイズ/ディスクの空き領域を確認しても気付かないでしょう。 データファイルの実際の使用率を監視するにはどうすればよいですか？私は、perfmonカウンタを使用したいと思います。ファイルが実際にスペースを使い果たすと、SQL Serverは十分なスペースを割り当てることができず、クラッシュするだろうと私は確信しています。

9 sql-server  disk-space  monitoring  perfmon 

varbinary（max）型のフィールドに大量のデータが格納されたデータベースがあります。ある時点で、すべての行ではなく、ほとんどの行のデータをパージできます。私たちの計画は、そのフィールドをnull可能にし、不要になったときにデータをnullにすることです。それができたら、DBのサイズを小さくしたいと思います。これを達成するための最良の方法は何ですか？ 現在の設定でスペースを再利用する良い方法がない場合、私が持っているアイデアの1つは、メインテーブルへのキーとデータフィールドの2つの列だけを持つ別のテーブルにデータフィールドを移動することです。次に、不要になった行を削除するだけです。（そして、何らかの縮小を行います。）ただし、これは、既存のフィールドを単にnull可能にするよりも、はるかに難しい変更です。 注：データベースファイルのサイズを小さくすることはあまり気にしていませんが、新しく解放されたスペースが再利用可能になることは気にします。 DBサイズの90％以上がこの1つのフィールドです。私はすでに3TBです。

8 sql-server  sql-server-2014  disk-space  blob  varbinary 

私は、pg_dumpPostgreSQL 8.3サーバーでホストしているJIRAデータベースで実行しました。データベース後のサイズvacuum fullだった217132652（約207メガバイト）。 次に、次のコマンドを使用して、JIRAデータベースをPostgreSQL 9.4サーバーに復元しました。 $ psql -X -v ON_ERROR_STOP=1 -d jira2 -U jira -h localhost < jiradb2017_03_12.sql 私はを使用して以来、エラーが発生すると復元が終了すると思いON_ERROR_STOP=1ますが、SQLスクリプトは正常に終了しました（データの復元に関連しないいくつかの警告にもかかわらず）。 最終的に、サイズが158019348（約151 MB）のデータベースができました。 だから、ここの話は何ですか？データベースが正常に復元され、PostgreSQLがストレージ（バージョン8.3から9.4の間）を最適化し、スペースをより効率的に使用していると仮定できますか？

8 postgresql  restore  disk-space