SHRINKFILEの失敗-ファイルサイズを大きくすると解決するのはなぜですか？

SHRINKFILEファイルグループ内の小さな不要なファイルをクリーンアップするために、いくつかの操作を実行しています。縮小の1つについて、以下のコマンドはエラーになります。

DBCC SHRINKFILE (N'myfile' , EMPTYFILE)'

データベースID xのファイルID xは、別のプロセスによって縮小されているか、空であるため縮小できません

空ではなく、縮んでもいない。現在私以外の誰も使用していないデータベースで実行されています。自動縮小は有効になっておらず、一度も有効になりませんでした。ただし、それが問題になる場合は、私が手に入れる前に、このデータベースで定期的に手動で縮小が行われていました。

でSQLServerCentral、十年前からのスレッドがあることがあるため、ファイルに数MBを追加提案し、「それは今シュリンクの途中ではありません、それを伝える内部カウンタまたはスイッチをリセットします。」

これはうまくいった-素晴らしい。しかし、SQL Serverの内部に関してこれがどのように/なぜ機能するのか、誰でも詳細に説明できますか？

— LowlyDBA
ソース

答えは言えませんが、将来この状況に遭遇したかどうかを知るのに便利なトリックなので、賛成票を投じます。

— John Eisbrener、

縮小中に設定されるファイルヘッダーページのフラグを再現できるか？

— マーティン・スミス

ええ、私はテストインスタンスでそのショットを与えるかもしれませんが、これは本物だったので、そこで再現しようとする贅沢はありません。

— LowlyDBA

Martin Smithのコメントで示唆されているように、ファイルヘッダーページをあちこち見回しました。これは答えの一部だと思いますが、それは主に、縮小の実行と他の操作の間のファイルヘッダーページフラグ値の変化の観察に基づく推測です。

最初に、セカンダリファイルグループを含め、テストするデータベースを作成しました。

CREATE DATABASE [Shrinkfile_Test]
ON PRIMARY
(
    NAME = N'Shrinkfile_Test',
    FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\Shrinkfile_Test.mdf',
    SIZE = 8192KB,
    FILEGROWTH = 65536KB
),
FILEGROUP [SECONDARY]
(
    NAME = N'ShrinkFile_Test_Secondary',
    FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\ShrinkFile_Test_Secondary.ndf',
    SIZE = 1024KB,
    FILEGROWTH = 65536KB
)
LOG ON
(
    NAME = N'Shrinkfile_Test_log',
    FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL13.SQL2016\MSSQL\DATA\Shrinkfile_Test_log.ldf',
    SIZE = 73728KB,
    FILEGROWTH = 65536KB 
)
GO

USE Shrinkfile_Test;
GO

私は、ファイル_id 3であるセカンダリファイルの「ページ0」を調べました。

DBCC TRACEON (3604);
GO
DBCC PAGE (N'Shrinkfile_Test', 3, 0, 3);

m_flagBitsという値を持つと呼ばれるフィールドがあります0x208。

このファイルを空にした場合：

DBCC SHRINKFILE (N'ShrinkFile_Test_Secondary' , EMPTYFILE);

そのm_flagbitsフィールドは同じまま0x208です（）。それほど興味深いことではありませんが、今あなたが報告した状況にあります。もう一度ファイルを空にしようとすると、次のエラーが発生します。

データベースID 19のファイルID 3は、別のプロセスによって縮小されているか空であるため、縮小できません。

私はファイルを拡張してみます（あなたのために働いた解決策）：

ALTER DATABASE ShrinkFile_Test
MODIFY FILE
(
    NAME = ShrinkFile_Test_Secondary,
    SIZE = 1025KB
);
GO

今m_flagbitsです0x8！

この時点で、ファイルを再度空にすると、0x208期待どおりに値が返されます。

私が面白いと思うのは、ファイルを元に戻した後でこれを行うと（aka flagbits値は0x8）、

USE [master]
GO
ALTER DATABASE [Shrinkfile_Test] MODIFY FILEGROUP [SECONDARY] READONLY
GO

ファイルは表のようis_read_onlyにマークされ、に戻されます。 そのため、ファイルを圧縮するときと読み取り専用に設定するときに、同様のファイルレベルのフラグが設定されているようです。sys.databasesm_flagbits0x208

私の推測では、この値は他の（内部）フラグと一緒に使用され、ファイルが圧縮可能であることを示します。ファイルを拡張すると、そのフラグ（少なくともで表示されるフラグ）が設定解除されたように見えますm_flagbits。

— ジョシュ・ダーネル
ソース