データベースのサイズが 1.9Gb 近くありますが、MSDE2000 では 2.0Gb を超える DB は許可されません。
この DB を縮小する必要があります (およびさまざまなクライアントの場所でこのような他の多くの DB を縮小する必要があります)。
私は、不要と考えられる何百ものレコードを見つけて削除しました。これらのレコードは、データベース内のいくつかのメイン (最大) テーブルの大部分を占めています。したがって、多くのスペースが取得可能であると想定するのは合理的です。
そのため、不足しているレコードを考慮して DB を縮小する必要があります。
DBCC ShrinkDatabase('MyDB')ます……効果なし。それでも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);
DBCC SHRINKDATABASE私にとってはうまくいきますが、これはその完全な構文です：
DBCC SHRINKDATABASE ( database_name, [target_percent], [truncate] )
はtarget_percent、データベースが圧縮された後にデータベース ファイルに残された空き領域の割合です。
パラメータtruncateは次のとおりです。
NOTRUNCATE
解放されたファイル スペースがデータベース ファイルに保持されます。指定しない場合、解放されたファイル スペースはオペレーティング システムに解放されます。
TRUNCATEONLY
データ ファイル内の未使用領域をオペレーティング システムに解放し、最後に割り当てられたエクステントまでファイルを縮小して、データを移動せずにファイル サイズを縮小します。割り当てられていないページへの行の再配置は試行されません。TRUNCATEONLY が使用されている場合、target_percent は無視されます。
...そしてはい、no_oneは正しいです。たとえば、データベースを縮小することはあまり良い習慣ではありません:
データファイルの縮小は、ページをデータベースファイルの割り当てられた範囲の終わりからファイルの先頭のどこかに移動するため、重大な論理的断片化を導入する優れた方法です...
データベースの縮小は、データベース、サーバーに多くの影響を与える可能性があります....実行する前によく考えてください!
ウェブ上には、それに関するブログや記事がたくさんあります。
また、個々のデータファイルを縮小する必要があります。
ただし、データベースを縮小することはお勧めできません。たとえば、ここを参照してください
以下を使用する必要があります。
dbcc shrinkdatabase (MyDB)
ログ ファイルが圧縮されます (Windows エクスプローラーを開いたままにし、それが起こっていることを確認します)。
「したがって、多くのスペースが現在取得可能であると想定するのは合理的です。」
質問を誤解した場合はお詫びしますが、スペースを使い果たしているのはデータベースであり、ログファイルではありませんか？データベースがどのリカバリモデルにあるかを確認します。フルになっている可能性があります。これは、ログファイルが切り捨てられないことを意味します。すべてのトランザクションの完全な記録が必要ない場合は、ログを切り捨てるSimpleに変更できるはずです。プロセス中にデータベースを縮小できます。物事がうまくいくと仮定すると、プロセスは次のようになります。
それが機能しない場合（またはリカバリモードを切り替えようとすると「ログファイルがいっぱいです」というメッセージが表示される場合）は、次のことを試してください。
等
もう 1 つの解決策があります。データベース公開ウィザードを使用して、スキーマ、セキュリティ、およびデータを SQL スクリプトにエクスポートします。その後、現在の DB をオフラインにして、スクリプトを使用して再作成できます。
ちょっとばかげているように聞こえますが、いくつかの利点があります。まず、データを失う可能性はありません。元のデータベースは (DB をドロップするときに削除しない限り!) 安全です。新しい DB は可能な限り小さくなり、現在のデータベースの 2 つの異なるスナップショットが作成されます。転がす、縮小する、バックアップするを選択できます。
MSSQL 2012 バージョンで SHRINKFILE を実行する必要がありましたが、2000 または 2005 バージョン以降は少しトリッキーでしたが、この投稿に出くわしました。この問題に関連するすべてのリスクと問題を読んだ後、テストを終了しました。簡単に言えば、私が得た最良の結果は、MS SQL Server Management Studioを使用した結果でした。
Right-Click the DB -> TASKS -> SHRINK -> FILES -> select the LOG file
また、データファイルとログファイルの最小サイズを変更する必要があります。DBCC SHRINKDATABASEは、すでに割り当てたファイル内のデータを縮小します。ファイルを最小サイズよりも小さいサイズに縮小するには、DBCC SHRINKFILEを使用して、新しいサイズを指定します。
データを削除し、復旧モデルが単純であることを確認してから、圧縮します (データベースの圧縮またはファイルの圧縮のいずれかが機能します)。データ ファイルがまだ大きすぎて、ヒープを使用してデータを格納している場合 (つまり、大きなテーブルにクラスター化インデックスを使用していない場合)、ヒープからのデータの削除に関して次の問題が発生する可能性があります: http://support.microsoft.com /kb/913399
私は最近これをしました。外出先でのテスト用にデータベースのコンパクト バージョンを作成しようとしていましたが、削除した行数に関係なく、データベースを縮小することはできませんでした。最終的に、このスレッドで他の多くのコマンドを実行した後、行を削除した後にクラスター化インデックスが再構築されていないことがわかりました。インデックスを再構築すると、適切に縮小できるようになりました。