タグ付けされた質問 「shrink」

SQL Serverデータベースに対して行うことができる最悪の事態。つまり、スペースを確保するためにパフォーマンスが犠牲になります。

4
トランザクションログが増え続ける、またはスペースが不足するのはなぜですか?
これは、ほとんどのフォーラムやWeb全体でよくある質問のようです。ここでは、一般的に次のような多くの形式で質問します。 SQL Serverで- トランザクションログが非常に大きくなる理由は何ですか? ログファイルが非常に大きいのはなぜですか? この問題の発生を防ぐ方法は何ですか? 根本的な原因を追跡し、トランザクションログファイルを正常なサイズにしたい場合はどうすればよいですか?

8
すべてのデータベースのすべてのファイルをすばやく圧縮するにはどうすればよいですか?
SQL Server(この場合は2008)では、インスタンス上のすべてのデータベースのすべてのファイル(ログとデータの両方)をどのようにすばやく縮小できますか?SSMSを実行し、それぞれを右クリックして[タスク]-> [縮小]を選択できますが、もっと速いものを探しています。 私はいくつかの「データベースの作成」スクリプトのスクリプトを作成しましたが、デフォルトのバルーンサイズがあったことを忘れており、このプロジェクトでこれらのファイル用に予約されたスペースをそれほど必要としません。

5
データベースを縮小しても大丈夫ですか?
シュリンクは悪魔です。ページの順序を逆にし、皮膚がん、データの断片化、地球温暖化の原因となります。リストは続きます...つまり、100 GBのデータベースがあり、50 GBのデータを削除するとします。1つのテーブルではなく、データベース全体のレベルで古いデータを削除し、90%をカバーします。テーブル-これはデータベースを縮小するための適切なユースケースを構成しますか? そうでない場合、データベースからこのような高い割合のデータを削除した後に家をきれいにするために取る適切な手順は何ですか?インデックスの再構築と統計の更新の2つを考えることができます。ほかに何か?

4
データベースを縮小する必要があります-多くのスペースを解放しました
この質問はさまざまな形式でここに尋ねられますが、質問は次のように要約されます。 データベースの縮小は危険を伴うことを知っています。この場合、大量のデータを削除したため、二度と使用しません。 データベースを縮小するにはどうすればよいですか?どのファイルを縮小しますか? これを行う際の考慮事項は何ですか? 後は何をすべきですか? 大規模なデータベースの場合はどうなりますか?少しずつ縮小できますか?


1
運用環境でTempdbを圧縮するベストプラクティス
この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 5年前に移行され ました。 SQL Server 2008で一時データベースを縮小するときに使用するベストプラクティスは何ですか? 以下を使用するのは危険ですか? use tempdb GO DBCC FREEPROCCACHE -- clean cache DBCC DROPCLEANBUFFERS -- clean buffers DBCC FREESYSTEMCACHE ('ALL') -- clean system cache DBCC FREESESSIONCACHE -- clean session cache DBCC SHRINKDATABASE(tempdb, 10); -- shrink tempdb dbcc shrinkfile ('tempdev') -- shrink db file dbcc shrinkfile …

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
AlwaysOn可用性グループの使用中にトランザクションログを圧縮する
私たちは、使用しているAlwaysOn Availability Group2012年の正規完全データベースバックアップとトランザクションログのバックアップがセカンダリデータベース上で毎日行われているSQL Serverの機能を。 私は読んだことが、ここでのプライマリレプリカまたはセカンダリレプリカのいずれかにトランザクションログのバックアップを行うことは、再利用可能なよう両方のレプリカトランザクション・ログをマークします。とにかく、トランザクションログのバックアップサイズは大きく、縮小ファイルを使用して縮小できます。 データベースをローカルに復元し、縮小操作を実行しました。ログファイルのサイズは160 MBに縮小されました。 私の質問は、どのデータベースでトランザクションログファイル(プライマリ、セカンダリ、またはその両方)の縮小操作を実行する必要があるかということです。 過去数年間、ログファイルのバックアップは作成されていなかったため、非常に大きくなりました。実行するDBCC SQLPERF (LOGSPACE)と0.06%、ファイルのみが使用されていることがわかります。このような巨大なサイズのログファイルを保持する意味はありません。で[sys].[database_files]、私はそのことを確認してくださいがmax_sizeに設定されている-1とgrowthする65536ことは、それが得るより多くのスペースを必要とするとき、私は推測するようにします。とにかく、将来の成長を防ぐために、たとえば5%に縮小できます。私はそうすることは悪い考えではないという確認を見つけようとしています。 実際、(データベースとログファイルの)バックアップはセカンダリデータベースでのみ実行されるため、それらのデータベースでシュリンクファイルを実行する方が簡単ですが、プライマリログファイルのサイズも小さくなりますか?

4
テーブルフィールドを削除した後のディスク領域の要求
私はSQL 2008 r2を実​​行していますが、非常にアクティブで使用されているテーブルにntextフィールドを追加するまで、データベースは過去3年間正常かつ高速に動作していました。このテーブルのサイズが非常に大きくなっているため、サーバースペースを使い始めています。 何年も高速に動作していたため、dbのインデックス付けを失いたくはありませんし、断片化の支出も受けたくないのです。 そのフィールドとそのすべての値を削除することにしました: ntextフィールドとそのすべての値を削除し、インデックスを削除せず、縮小せずに、dbのパフォーマンスを失うことなくスペースを解放する方法はありますか? 過去5か月のサイズ拡張を示すために、dbサイズクエリ出力を添付します。

1
SHRINKFILEの失敗-ファイルサイズを大きくすると解決するのはなぜですか?
SHRINKFILEファイルグループ内の小さな不要なファイルをクリーンアップするために、いくつかの操作を実行しています。縮小の1つについて、以下のコマンドはエラーになります。 DBCC SHRINKFILE (N'myfile' , EMPTYFILE)' データベースID xのファイルID xは、別のプロセスによって縮小されているか、空であるため縮小できません 空ではなく、縮んでもいない。現在私以外の誰も使用していないデータベースで実行されています。自動縮小は有効になっておらず、一度も有効になりませんでした。ただし、それが問題になる場合は、私が手に入れる前に、このデータベースで定期的に手動で縮小が行われていました。 でSQLServerCentral、十年前からのスレッドがあることがあるため、ファイルに数MBを追加提案し、「それは今シュリンクの途中ではありません、それを伝える内部カウンタまたはスイッチをリセットします。」 これはうまくいった-素晴らしい。しかし、SQL Serverの内部に関してこれがどのように/なぜ機能するのか、誰でも詳細に説明できますか?

3
データベースサイズ-MDFが大きすぎますか?
約2.9TbのデータをホストするSQL Server 2005データベースを維持しています(2 x 1.45Tb-RAWスキーマとANALYSISスキーマがあるため、基本的にデータの2つのコピーが取り込まれます)。リカバリモデルはシンプルで、6 .ldfGBです。 何らかの理由で、.mdf7.5Tbです。現在、ANALYSISテーブルには2〜3列しか追加されておらずNVARCHAR(MAX)、私が誤って理解している可能性があるため(間違っている場合は修正してください)、追加のスペース割り当てを引き起こしている可能性がある列は多くありません。これは、データベースを圧縮した直後です。その前は、約9 TBでした。何かご意見は? そして、追加の質問がある場合はお知らせください-私はデータベース管理と最適化の取り組みに非常に慣れていません(私は通常、仕事のこの側は行いません:))。 どうもありがとう! アンドリヤ

3
トランザクションログはSQL Serverで自動的に縮小されますか?
SQL ServerデータベースがSIMPLEモードの場合、トランザクションログのバックカップを気にする必要はありません。ただし、SIMPLEモードでは、FULLモードと同様にトランザクションログが大きくなるようです。ある時点で自動的に切り捨てられますか?それとも手動で切り詰める必要がありますか?

10
データベースを初期サイズ以下に縮小する
ライブの30GBコピーであるSQL Server 2005開発データベースを持っています。devで不要なデータをいくつか削除しました。これにより、使用されるデータファイルスペースが20GBに下がります。したがって、約33%が未使用です。 スペースを再利用する必要があります。これにより、サーバーに2番目の開発DBを(カットダウンバージョンに基づいて)配置できます。ただし、スペースを取り戻すことはできません。次のようにしました。 ファイルの初期サイズSMS2_Dataは30GBです。 DBCC SHRINKFILE (N'SMS2_Data' , 0, TRUNCATEONLY) に続く DBCC SHRINKFILE (N'SMS2_Data' , 19500) 喜びがない。バックアップを作成して、初期サイズの小さい新しいDBを作成してから復元しようとしましたが、初期サイズが上書きされて喜びません。また試しました: ALTER DATABASE SMS2HazSub MODIFY FILE (NAME = 'SMS2_Data', SIZE = 20000) これは誤り、言った: MODIFY FILEが失敗しました。指定されたサイズは現在のサイズよりも小さいです。 20800を試してから29000(29GB)まで上がり続けましたが、それでも変更できません。 縮小を行った後、回復モードをからFULLに変更しSIMPLEました。喜びがない。 いくつかのTEXT分野と関係があると思いました。システム全体で約6つあります。テストとして、すべてを削除してからファイルを縮小しましたが、変更はありませんでした。 残っている唯一のオプションは、データを別のDBに再インポートすることです。ライブDBで実行する必要があるため、これは実用的ではなく、リスクが高すぎます。半定期的にライブDBのコピーを取得し、dev / testを上書きします。500テーブルのようなものがあります。新しいDBにデータをエクスポートするリスクのない方法を教えてください。 データを別のファイルに移動しようとすると、データの5%を除くすべてがコピーされました。これが、すべてのテキスト列を削除しようとした理由です。 サーバーは互換モード90ですが、SP2です。これで、すべてのテーブルのインデックスの再作成、データベースのバックアップ、ファイルの圧縮、データベースの圧縮の3回を実行しました。まだ喜びはありません。 EXECUTE sp_spaceused 戻り値: database_name database_size unallocated space SMS2Tests 31453.94 MB …

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

2
TempDBは縮小しません。未処理のトランザクションはありません
SQL 2008でTempDBが非常に大きくなり(> 40GB)、それを縮小したいのですが。私は、Management Studioを介してdbccの縮小データベース、dbccの縮小ファイル、および縮小コマンドを使用しました。 次のエラーが発生します。 ページ1:4573184は作業テーブルページであるため移動できませんでした。 DBCC FREEPROCCACHEを実行し、縮小ルーチンの1つを再実行することで、危険を回避するためにいくつかの領域を再利用できましたが、明らかにこれは理想的ではなく、たぶん少し時間を費やすだけです。 私はDBCC OpenTranを実行しましたが、そこには何もぶらさがっていません。 私がインターネット上で読んだところはどこでもSQL Serverのリサイクルに行き着きます...確かにより良い方法が必要です...誰か? おかげで、 トム

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.