DBCCSHRINKFILEコマンドの概要

DBCC Shrinkコマンドの実行は、SQLServerコミュニティ全体で非常に物議を醸す問題です。この記事では、このコマンドの詳細を確認し、その使用法の概要を説明し、このコマンドを実行するリスクについて警告します。 DBAとして、他のチームやベンダーから多くのデータベースが引き渡されましたが、作成したデータベースを常に管理できるとは限りません。 DBAとして、移行や新しいプロジェクトに関与するときはいつでも、データベースの本番環境へのスムーズな移行と通常の使用を慎重に計画する必要があります。この段階で、データベースのサイズを考慮する必要があります。想像できますか？最初の1年ほどの成長予測を考慮せずにデータベースアプリケーションをセットアップしました。サイズが非常に小さいSQLServerデータベースを作成して、1日おきに拡張する必要があるため、深夜に容量ディスクアラートを発生させるのはどうでしょうか。ばかげているように聞こえるかもしれませんが、実際には、これが発生し、これが制御できない場合があります。

プロアクティブDBAについて考慮すべきいくつかのポイント

本番データベースのサポートを引き継ぐ前に、データベースの成長に関する予測がどのようなものであるかを前任者に確認してください。管理するデータベースの初期サイズは適切なサイズですか？データベースの現在のサイズが現在のデータよりもはるかに大きい場合でも、あまり心配する必要はありません。正しいサイズのデータベースを使用することで完全に回避できた午前3時に、これらのディスク容量の呼び出しを望まないことを忘れないでください。業界全体のデータベース管理者は、そもそも発生しなかったはずのありふれた問題で深夜に命を犠牲にするのが一般的な傾向です。また、データベースのサイズとともに、サーバーのディスク容量に注意してください。ディスクサイズをデータベースが収容できるサイズよりも小さくしすぎないようにする必要があります。これらはすべて、計画時に役立つ単純なものです。ただし、ご存知のように、最初にデータベースをインストールまたは構成するのは、常にデータベースの専門家であるとは限りません。注意すべき重要な点は、サイズ設定の観点からデータベースの基本を正しく理解することであり、このコマンドを実行する必要がない場合があります。ただし、いつものように、DBAとして、物事が制御できない場合があります。その間、DBCCShrinkファイルコマンドを使用して効率的に使用できます。

DBCC ShrinkFileはいつ使用できますか？

睡眠の最中にディスクスペースアラートを受信したばかりで、厳格なSLAを満たす必要があります。優先度レベルはP2であり、SLAはすぐに違反する可能性があります。そして、ディスクの拡張がすぐには行われないことに気づきました。その場合は、DBCC ShrinkFileコマンドを手元に置いて、スペースを再利用できるようにしてください。名前が示すように、データのファイルまたはデータベースのログファイルを縮小します。ただし、DBCC ShrinkFileコマンドの実行を開始する前に、データベースファイルが最初に大きくなっている理由を確認してください。

長時間実行されているトランザクションが原因でファイルが大きくなりましたか？
サーバーに何らかのブロッキングはありますか？
通知されていないメジャーアプリケーションリリースが発生していますか？（これはほとんどの場合に発生します）
データベースの拡張を引き起こすデータベースレプリケーションまたはミラーリングの問題はありますか？

これらの質問に対する回答をできるだけ早く得ることが重要です。一般に、これらすべての質問に対する答えは1つであり、sp_whoisactiveと呼ばれる優れた無料ツールです。このツールの膨大な使用法を説明する言葉はありません。私はこれを何度も使用して、生産に関連する多数の問題を修正しました。次のリンクから最新のコードをダウンロードできます：http：//whoisactive.com/。使い方は簡単でシンプルで、すぐに出力を返します。 DBAの経験が豊富な場合は、すでにこれを自由に使用できます。

DBCCShrinkFileと例

DBCC ShrinkFileの構文は単純でわかりやすいので、以下の例を参照してください。

use YOURDATABASE
go
DBCC Shrinkfile(FileName,1024)

上記の例では、YOURDATABASEに属するFileNameを1024MBに縮小しています。 SQL Server Management Studio（SSMS）を使用して同じ操作を実行できます。データベースを右クリックして、タスクに移動します、縮小を選択します、次にファイル 。

ファイルをクリックすると、このウィンドウが表示されます。

ここでは、ファイルタイプ（データ、ログ、またはファイルストリームデータ）を選択し、必要に応じて「縮小アクション」を実行するオプションがあります。縮小する目的でDBCCコマンド自体を使用する方が簡単です。

DBCCShrinkFileと追加オプションの使用

DBCC ShrinkFileコマンドは、空のファイル、notruncate、またはtruncateonlyなどの追加オプションを使用して実行できます。

空のファイル

以下のようにemptyfileコマンドを使用できます。

use YOURDATABASE
go
dbcc shrinkfile(FileName,emptyfile)

これは、同じファイルグループ内の他のファイルにデータを移動するのに役立ちます。完了すると、データベースファイルが不要になった場合に削除できるようになります。ただし、このemptyfileオプションでは、ファイルID 1のプライマリデータファイルの内容を空にすることはほとんどできないため、注意すべき点がいくつかあります。ファイルID番号を取得するには、このスクリプトを実行します。

select file_id, name,physical_name from sys.database_files

ここで、この例では、ファイル名は「mo」で、file_idは1です。file_id1を持つファイルmoを空にしようとすると、このエラーメッセージが表示されます。

これは、元のファイル内にシステム情報があり、空にできないためです。ただし、他のデータファイル「mo2data」で同じコマンドを実行すると、空のファイルコマンドは成功します。

切り捨てない

名前が示すように、OSに解放されるスペースはありません。これは、データベースファイルの全体的なサイズを変更せずに、ファイル自体の中でページが再配布されるファイル内の内部操作に似ています。このため、断片化が導入される可能性が非常に高くなります。以下の例を参照してください。

-- Example only  
Use YourDatabase		
go
DBCC SHRINKFILE (filename,notruncate);  
GO

切り捨てのみ

名前が示すように、空き領域はファイルの最後からOSに解放されます。これは、DBCCShrinkFileを使用して実行できる最も安全な操作です。以下の例を参照してください。

-- Example only  
Use YourDatabase		
go
DBCC SHRINKFILE (filename,truncateonly);  
GO

トランザクションログのDBCCShrinkFileが期待どおりに機能しない場合はどうすればよいですか？この安全な方法を参照して問題を修正してください

このコマンドが期待どおりに機能しない場合があります。データベースのログファイルを縮小しようとしていて、機能していないように見える状況があると仮定します。以下は、縮小が期待どおりに機能しない理由を理解するために実行できるいくつかの手順です。縮小ファイルは成功したものとして表示されますが、ログファイルのサイズは縮小されません。その場合は、このコマンドを実行して、ログファイルの使用状況に関するいくつかのことを確認してください。

select name,log_reuse_wait_desc,* from sys.databases

スクリーンショットから、log_reuse_wait_desc列がログのバックアップを待機していることがわかります。

ここでは、ログファイルを実際に縮小する前に、データベースのログバックアップを実行する必要があることがわかります。これが実稼働データベースにある場合は、使用可能なスペースがある別のドライブでログのバックアップを実行してみてください。ログバックアップを実行するには、以下のサンプルコマンドを使用します。

backup log DBName to disk='C:\Program Files\Microsoft SQL Server\MSSQL15.A1\MSSQL\Backup\DBName.trn'
with init,stats,compression

バックアップコマンドを実行した後、以下のコマンドを再度実行して、log_reuse_wait_desc列のステータスを確認します。

select name,log_reuse_wait_desc,* from sys.databases

スクリーンショットから、log_reuse_wait_desc列のステータスが「Nothing」に変更されたことがわかります。

ここでは、「log_reuse_wait_desc」列のステータスが「Nothing」に変更されていることがわかります。あなたの場合、それはまだ「LOG_BACKUP」として表示されるかもしれません。ステータスが「なし」に変わるまで、データベースのログバックアップを実行し続けます。トランザクションログのバックアップを実行した後も「LOG_BACKUP」ステータスが表示される場合があるのは、トランザクションログのバックアップを実行した後にVLFがクリアされていない可能性があるためです。 VLFは仮想ログファイルの略で、トランザクションログの内部アーキテクチャの一部です。トランザクションログファイルは、これらのVLFで構成されています。このコマンドを実行すると、VLFに関する情報を取得できます。

select * from sys.dm_db_log_info(5)

ここで、5はdatabase_idを表します。出力のスクリーンショットが表示されます。返される行数は、データベース内の仮想ログファイル（VLF）の実際の数を表します。「vlf_status」列をチェックして、仮想ログファイルのステータスをチェックできます。値2は、アクティブであることを意味します。このコマンドを使用すると、トランザクションログファイル内の内部フラグをチェックして、ログバックアップを実行した後でもトランザクションログが解放されない理由を理解できます。

以前は、使用されたコマンドは同様の情報を提供するDBCCLOGINFOでした。

トランザクションログのDBCCShrinkFileが期待どおりに機能しない場合はどうすればよいですか？非本番環境で実行できること。ただし、本番環境ではお勧めしません

リカバリモデルを単純なものに変更してから、OSにスペースを解放するためにシュリンクファイルを実行することを推奨している複数のWebサイトに出くわしたことでしょう。リカバリモデルを単純なモデルに変更すると、特定の時点にリカバリできないため、データベースのリカバリに影響することに注意してください。これもビジネスのSLAによって異なります。リカバリモデルは、T-SQL（下記）またはGUIを使用して変更できます。

alter database DB_NAME set recovery simple

GUIを使用して、図のようにリカバリモデルを変更します。データベースを右クリックし、[プロパティ]に移動して、[オプション]をクリックします。「オプション」で「リカバリモデル」を選択します。

リカバリモデルをSimpleに変更しただけでは、スペースがOSに戻されないことに気付くでしょう。 DBCC ShrinkFileコマンドを明示的に実行して、ファイルを縮小し、スペースを再利用する必要があります。以下のサンプルスクリプトを参照してください。このコマンドは、FileNameを1024MBに縮小します。

use YOURDATABASE
go
DBCC Shrinkfile(FileName,1024)

データベースの自動縮小オプション

データベースのプロパティ内に「自動縮小」と呼ばれるオプションがあることに気付くでしょう。データベースを右クリックするだけで、データベースのプロパティが表示されます。オプションセクションの下に、次のようにこのオプションが表示されます。モデルデータベースの設定から、「自動縮小」オプションがデフォルトで無効になっていることがわかります。したがって、新しいデータベースが作成されるたびに、このオプションも無効な状態になります。データベースの専門家が、このオプションをオンのままにしておくことの悪影響を認識せずに、このオプションを無意識のうちに有効のままにしておく場合があります。

このコマンドを実行して、サーバー上のデータベースのこのオプションのステータスを確認します。

select name,is_auto_shrink_on,* from sys.databases

この出力が表示されます。

偶然に有効になっていることがわかった場合は、GUIを使用して無効にするか、データベースに対して以下のコマンドを実行できます。

ALTER DATABASE YOUR_DATABASE set AUTO_SHRINK OFF

その他のメンテナンスの提案

DBCC ShrinkFileコマンドを実行する必要があるため、データベースの増大の問題を回避するために、これらのいくつかの追加のヒントを参照してください。

データベースのリカバリモデルがビジネスSLAと整合していることを確認します。ビジネスでテストデータベースのポイントインタイムリカバリが必要ない場合は、単純リカバリモデルのままにしておきます。最新の完全バックアップを使用したリカバリで問題がない場合に、データベースのリカバリモデルが完成することが何度もありました。
特にデータベースの拡張に伴い、適切な監視を確実に実施します。ログファイルの使用率が85％に達すると、アラートが表示されます。これにより、スペースの問題を解決するための時間が与えられます
データベースが完全復旧モデルの場合は定期的なログバックアップが作成されていることを確認し、ログバックアップのいずれかが失敗した場合はアラートを受け取る必要があります
スペース不足の問題を回避するために、データベースドライブに十分なスペースがあることを確認してください
アーカイブ可能なデータベースの場合、古いデータを別のデータベースに移動してレポートを作成し、そのデータベースを読み取り専用にすることができるように、いくつかのアーカイブ戦略を開発します。これにより、データベースのサイズ設定をより細かく制御できるようになります
DBCC CheckDBを使用して、データベースの整合性チェックを定期的に実行するようにしてください。詳細については、次の記事を参照してください：https://codingsight.com/dbcc-checkdb-overview/

結論

この記事から、DBCCShrinkFileコマンドの使用について十分に理解できました
DBCCShrinkFileコマンドを実行することのリスクについて学びました
DBCCShrinkFileコマンドを使用して提供できるさまざまなオプションを学びました
DBCCShrinkFileコマンドを使用してトランザクションログが縮小されていない場合に試すことができるオプションを確認しました
データベースプロパティ内のデフォルトの自動縮小設定について学習しました
データベースを正常に保つために、他のデータベース保守の提案も学びました
最後に、あなたのコントロールの及ばないかもしれないそれらのオフの日のためにどんな場合でも準備ができていることを確認してください