SQL Serverデータベースを縮小するにはどうすればよいですか？
データベースのサイズは約1.9Gbで、MSDE2000では2.0Gbを超えるDBは許可されません
このDBを縮小する必要があります（また、さまざまなクライアントの場所でこのような多くのデータベースを縮小します）。
私は、不要と考えられる何千ものレコードを見つけて削除しました。これらのレコードは、データベース内のいくつかのメイン（最大）テーブルの大部分を占めています。したがって、多くのスペースが取得可能になっていると仮定するのは合理的です。
そのため、不足しているレコードを考慮してDBを縮小する必要があります。
DBCC ShrinkDatabase('MyDB')......を実行しますが、効果はありません。- MSSMSで提供されているさまざまなシュリンク機能を試しました。..それでも効果はありません。
- データベースをバックアップして復元しました...それでも効果はありません。
まだ1.9Gb
どうして？
私が最終的に見つけたどのような手順でも、OSqlなどにアクセスできるクライアントマシンで再生可能である必要があります。
ALTER DATABASE MyDatabase SET RECOVERY SIMPLE
GO
DBCC SHRINKFILE (MyDatabase_Log, 5)
GO
ALTER DATABASE MyDatabase SET RECOVERY FULL
GO
これは奇妙に思えるかもしれませんが、私にとってはうまく機能しており、これを自動化するC＃プログラムを作成しました。
手順1：トランザクションログを切り捨てます（トランザクションログのみをバックアップし、非アクティブなトランザクションを削除するオプションをオンにします）
ステップ2：データベースの縮小を実行し、すべてのページをファイルの先頭に移動します
手順3：手順2でログエントリが追加されるため、トランザクションログを再度切り捨てます
ステップ4：データベースの縮小を再度実行します。
SQL DMOライブラリを使用する私のコードは次のとおりです。
SQLDatabase.TransactionLog.Truncate();
SQLDatabase.Shrink(5, SQLDMO.SQLDMO_SHRINK_TYPE.SQLDMOShrink_NoTruncate);
SQLDatabase.TransactionLog.Truncate();
SQLDatabase.Shrink(5, SQLDMO.SQLDMO_SHRINK_TYPE.SQLDMOShrink_Default);
これは古い質問ですが、たまたま思いついたばかりです。
本当に短くて正しい答えはすでに与えられており、最も票を得ています。つまり、howトランザクションログを縮小します。これはおそらくOPの問題でした。また、トランザクションログが制御不能になった場合、多くの場合縮小する必要がありますが、ログが制御不能になる将来の状況を防ぐように注意する必要があります。 dba.se に関するこの質問はそれを説明しています。 基本的に-最初は適切な復旧モデル、トランザクションログのメンテナンス、トランザクション管理などによってそのサイズを大きくしないでください
しかし、データファイル（またはログファイル）の圧縮に関するこの質問を読むときの私の頭の中の大きな質問は、why？and試してみるとどんな悪いことが起こりますか？縮小操作が行われたように見えます。この場合、MSDE/Expressエディションは最大DBサイズで制限されているため、ある意味で意味があります。しかし、正しい答えは、あなたのニーズに合った適切なバージョンを見ることです。そして、本番データベースを縮小しようとしてこの質問に出くわし、これが理由でない場合は、why？の質問を自問する必要があります。
「データベースを縮小する方法」を求めてWebを検索し、それがクールまたは容認できることだと思う人はいません。
データファイルの縮小は、特別な機会のために予約する必要がある特別なタスクです。データベースを縮小すると、インデックスが効果的に断片化されることを考慮してください。データベースを縮小すると、データベースがいつかは再び成長する可能性のある空きスペースを取り去ることを考慮してください。時間を効果的に無駄にし、DBが再び成長することを確認するためだけに縮小操作のパフォーマンスヒットが発生します。
この概念については、データベースの縮小に関するいくつかのブログ投稿で書きました。 「 その縮小ボタンに触れないでください 」という名前が最初に思い浮かびます。ここで概説したこれらの概念について説明しますが、データベースの「適切なサイズ設定」の概念についても説明します。データベースのサイズを決定し、将来の成長を計画し、その量に割り当てることをお勧めします。 SQL Server 2005以降のデータファイルでインスタントファイルの初期化を使用できるため、成長のコストは低くなりますが、適切な初期アプリケーションを使用することを好みます。また、データベース内のホワイトスペースは私よりもはるかに少ないです。最初は何も考えずに一般的に縮小します。 :)
DBCC SHRINKDATABASEは私のために動作しますが、これはその完全な構文です：
DBCC SHRINKDATABASE ( database_name, [target_percent], [truncate] )
どこ target_percentは、データベースが縮小された後にデータベースファイルに残される空き領域の望ましい割合です。
truncateパラメータには次のものがあります。
NOTRUNCATE
解放されたファイルスペースがデータベースファイルに保持されます。指定しない場合、解放されたファイル領域はオペレーティングシステムに解放されます。
TRUNCATEONLY
データファイル内の未使用スペースをオペレーティングシステムに解放し、ファイルを最後に割り当てられたエクステントまで縮小し、データを移動せずにファイルサイズを縮小します。行を未割り当てページに再配置する試みは行われません。 TRUNCATEONLYが使用されている場合、target_percentは無視されます。
...そして、はいno_oneは正しいです、例えば、datbaseを縮小することはあまり良い習慣ではありません：
データファイルの縮小は、データベースファイルの割り当てられた範囲の最後からファイルの先頭のどこかにページを移動するため、重要な論理的な断片化を引き起こす優れた方法です。
データベースの縮小は、データベース、サーバーに大きな影響を与える可能性があります。実行する前に十分に検討してください。
ウェブ上には、それに関する多くのブログと記事があります。
遅い回答ですが、他の人にとっては役に立つかもしれません
DBCC ShrinkDatabase/ShrinkFileもSSMS（Tasks/Shrink/Database）も役に立たない場合は、QuestとApexSQLからジョブを実行できるツールがあり、必要に応じて定期的な縮小をスケジュールすることもできます。
この記事の最後にある短い説明に従って、私は後者を無料トライアルで使用してこれを少し前に行いました。
必要なことは、ApexSQL Backupをインストールし、メインリボンの[データベースの圧縮]ボタンをクリックして、ポップアップウィンドウでデータベースを選択し、[完了]をクリックすることだけです。
また、個々のデータファイルを圧縮する必要があります。
ただし、データベースを縮小することはお勧めできません。たとえば、 here を参照してください
以下を使用する必要があります。
dbcc shrinkdatabase (MyDB)
ログファイルを圧縮します（Windowsエクスプローラーを開いたままにしておきます）。
別のソリューションを次に示します。 データベース公開ウィザード を使用して、スキーマ、セキュリティ、およびデータをSQLスクリプトにエクスポートします。その後、現在のDBをオフラインにして、スクリプトを使用して再作成できます。
馬鹿げているように聞こえますが、いくつかの利点があります。まず、データを失う可能性はありません。元のデータベース（DBを削除するときにデータベースを削除しない限り）は安全で、新しいDBはできる限り小さくなり、現在のデータベースの2つの異なるスナップショットが作成されます。ロールするために、1つを縮小します-バックアップするために選択できます。
「したがって、多くのスペースを取得できると仮定するのは合理的です。」
質問を誤解した場合は申し訳ありませんが、スペースを使い果たしているのはログファイルではなくデータベースであると確信していますか？データベースがどの復旧モデルにあるかを確認してください。可能性がフルになっている可能性があります。つまり、ログファイルが切り捨てられることはありません。すべてのトランザクションの完全な記録が必要ない場合は、ログを切り捨てるSimpleに変更できるはずです。プロセス中にデータベースを縮小できます。うまくいくと仮定すると、プロセスは次のようになります。
- データベースをバックアップしてください！
- シンプルリカバリへの変更
- データベースの縮小（データベースを右クリックして、すべてのタスクを選択>データベースの縮小-> 10％の空き容量に設定）
- スペースが回収されていることを確認します。回収されていない場合は、完全バックアップを行う必要があります。
うまくいかない場合（または、リカバリモードを切り替えようとすると「ログファイルがいっぱいです」というメッセージが表示される場合）、これを試してください：
- バックアップ
- データベースへのすべての接続を強制終了します
- Dbをデタッチします（右クリック>デタッチまたは右クリック>すべてのタスク>デタッチ）
- ログ（ldf）ファイルを削除する
- データベースを再接続します
- 回復モードを変更する
等.
2000年または2005年のバージョンから少し複雑になったMSSQL 2012バージョンでファイルを圧縮する必要があるにもかかわらず、この投稿に出会いました。この問題に関連するすべてのリスクと問題を読んだ後、テストをしました。要するに、私が得た最良の結果は、MS SQL Server Management Studioを使用したことです。
Right-Click the DB -> TASKS -> SHRINK -> FILES -> select the LOG file
これがどれほど実用的かはわかりません。また、データベースのサイズ、テーブルの数、その他の複雑さにもよりますが、私は：
- 物理ドライブをデフラグします
- 要件、スペース、増加率などに従って新しいデータベースを作成します
- シンプルなssmsタスクを使用して、古いデータベースから新しいデータベースにすべてのテーブルをインポートします
- 古いデータベースのすべてのテーブルのインデックスをスクリプト化してから、新しいデータベースにインデックスを再作成します。外部キーなどの必要に応じて拡張します。
- 必要に応じてデータベースの名前を変更し、成功したことを確認し、古いものを削除します
また、データファイルとログファイルの最小サイズを変更する必要があります。 DBCC SHRINKDATABASEは、データを縮小しますinside既に割り当てたファイル。ファイルを最小サイズよりも小さいサイズに縮小するには、DBCC SHRINKFILEを使用して新しいサイズを指定します。
最近これをやった。路上でのテスト用にデータベースのコンパクトバージョンを作成しようとしていましたが、削除した行数に関係なく、データベースを縮小できませんでした。最終的に、このスレッドで他の多くのコマンドを実行した後、クラスター化インデックスが行の削除後に再構築されないことがわかりました。インデックスを再構築すると、適切に縮小できるようになりました。
データを削除し、復旧モデルが単純であることを確認してから、縮小します（データベースの縮小またはファイルの縮小のいずれかが機能します）。データファイルがまだ大きすぎる場合、およびヒープを使用してデータを保存する（つまり、大きなテーブルにクラスター化インデックスがない）場合、ヒープからのデータの削除に関してこの問題が発生する可能性があります。 http：// support .Microsoft.com/kb/913399
完全復旧から単純復旧に切り替えると、すべてのログを削除できると思います。データベースを右クリックしてPropertiesを選択し、Optionsを選択して変更します
Recovery modeからSimpleContainment typeからNone
