SHRINKFILE Errore: perché risolverlo aumenta la dimensione del file?

Sto eseguendo alcune SHRINKFILEoperazioni per ripulire un mucchio di piccoli file non necessari in un filegroup. Per uno dei restringimenti, il comando seguente genera un errore:

DBCC SHRINKFILE (N'myfile' , EMPTYFILE)'

L'ID file x dell'ID database x non può essere ridotto in quanto è ridotto da un altro processo o è vuoto

Non è vuoto né ridotto. Viene eseguito su un database non attualmente utilizzato da nessuno tranne me stesso. La riduzione automatica non è abilitata e non lo è mai stata. Tuttavia, ci sono stati restringimenti manuali eseguiti su questo database su base regolare prima che io ci mettessi le mani sopra, se ciò è importante.

Su SQLServerCentral , un thread di una decina di anni fa suggerisce di aggiungere alcuni MB al file perché "ripristina un contatore interno o un interruttore che gli dice che non è nel mezzo di una riduzione adesso".

Questo ha funzionato - fantastico. Qualcuno può spiegare con maggiore dettaglio come / perché questo funziona in relazione agli interni di SQL Server?

Ho cercato nella pagina di intestazione del file, come suggerito da Martin Smith nei commenti. Penso che questo sia parte della risposta, ma è principalmente una speculazione basata sull'osservazione delle modifiche ai valori dei flag della pagina di intestazione del file tra l'esecuzione di riduzioni e altre operazioni.

Per prima cosa ho creato un database con cui provare, incluso un filegroup secondario:

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

Ho guardato "pagina 0" per il file secondario, che è file_id 3:

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

C'è un campo chiamato m_flagBitsche ha un valore di 0x208.

Se svuoto questo file:

DBCC SHRINKFILE (N'ShrinkFile_Test_Secondary' , EMPTYFILE);

Quel m_flagbitscampo rimane lo stesso ( 0x208). Non molto interessante, ma ora sono nella situazione che hai segnalato: se provo a svuotare di nuovo il file, ottengo questo errore:

L'ID file 3 dell'ID database 19 non può essere ridotto in quanto è ridotto da un altro processo o è vuoto.

Proverò a far crescere il file (la soluzione che ha funzionato per te):

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

Adesso m_flagbitsè 0x8!

A questo punto, svuotare nuovamente il file ha esito positivo restituendo il valore 0x208come previsto.

La cosa che trovo interessante è che se lo faccio dopo aver ridimensionato il file (il valore delle flagbits di AKA è 0x8):

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

Il file è contrassegnato come is_read_onlynella sys.databasestabella ed m_flagbitsè impostato su 0x208. Quindi sembra che ci sia un flag simile a livello di file impostato quando si restringe un file e quando si imposta in sola lettura.

La mia ipotesi migliore è che questo valore viene utilizzato insieme ad altri flag (interni) per indicare che un file è idoneo per essere ridotto. L'espansione del file sembra annullare l'impostazione di tale flag (almeno quello visibile in m_flagbits).