120GBのデータベースがあります。役に立たない60GBのデータを持つテーブルがあり、切り捨てました。
現在、データベースのサイズは120GBで、空き容量は60GBです。データベースは少なくとも3か月で60GBまで成長しません。データファイルを縮小できますか?.
断片化の問題を認識しています。私たちのデータベースは24 * 7データベースではないので、インデックスを再構築できます。
MDF
ファイルの圧縮についてアドバイスしてください
データベースを圧縮することで、具体的に何を達成しようとしていますか?データベースの増加を計画し、この増加のためにスペースを予約しておく必要があります。
それでは、DBに送信される新しいデータ用にスペースを割り当てたので、そのままにしないでください。
データベースを縮小したくないほど何度も議論されてきました。これを確認して、縮小する前によく考えてください。
データベースファイルの縮小を中止します。真剣に、今すぐです。 By Brent Ozar
データベースを縮小する方法 に関する私の投稿を読んでください。ここで要約します。
ファイルグループ内のすべてのファイルのサイズを確認します。グループ内のすべてのファイルのサイズを均等にし、拡張やインデックスのメンテナンスなどのためにスペースを確保したい場合。データベースを小さくしすぎると、データベースを小さくしすぎるよりも、少し大きくしすぎる方が賢明です。 。個人的には、目標サイズの少なくとも6か月の成長を説明します。
SELECT
LogicalName = dbf.name
,FileType = dbf.type_desc
,FilegroupName = fg.name
,PhysicalFileLocation = dbf.physical_name
,FileSizeMB = CONVERT(DECIMAL(10,2),dbf.size/128.0)
,UsedSpaceMB = CONVERT(DECIMAL(10,2),dbf.size/128.0 - ((dbf.size/128.0)
- CAST(FILEPROPERTY(dbf.name, 'SPACEUSED') AS INT) /128.0))
,FreeSpaceMB = CONVERT(DECIMAL(10,2),dbf.size/128.0
- CAST(FILEPROPERTY(dbf.name, 'SPACEUSED') AS INT)/128.0)
FROM sys.database_files dbf
LEFT JOIN sys.filegroups fg ON dbf.data_space_id = fg.data_space_id
ORDER BY dbf.type DESC, dbf.name;
すでにこれを行っているようですが、縮小後にインデックスのメンテナンスを実行する必要があります。メンテナンスウィンドウ中にインデックスを縮小して実行するのに十分な時間を計画してください。既存のインデックスを縮小するよりも、メンテナンスウィンドウを使用して新しいデータベースに移行したり、すべてのインデックスを新しいファイルグループに再構築したりする方が速くて簡単です。
常にSHRINKFILE
を使用し、SHRINKDATABASE
は使用しないでください。手順1で決定した情報を使用して、SHRINKFILE
ステートメントを作成します。
USE [DatabaseName];
DBCC SHRINKFILE(LogicalName, TargetSize);
定期的なメンテナンス作業がある場合は、その作業を開始して、魔法のようにしてください。すべてが実際に断片化されるため、通常よりもはるかに長い時間がかかります。通常よりはるかに多くのトランザクションログを生成するため、トランザクションログのバックアップが大きくなり、ログ配布、可用性グループ、ミラーリングなどの影響もわかります。
以下のコードを使用してください。詳細 こちら 。 7はMBです。
USE UserDB;
GO
DBCC SHRINKFILE (DataFile1, 7);
GO