Início / dba / Perguntas / 227391
Accepted
LowlyDBA - John M
Asked: 2019-01-18 07:26:33 +0800 CST

Falha no SHRINKFILE - Por que aumentar o tamanho do arquivo resolve isso?

  • 772

Estou executando algumas SHRINKFILEoperações para limpar um monte de arquivos minúsculos e desnecessários em um grupo de arquivos. Para um dos encolhimentos, o comando abaixo resulta em um erro:

DBCC SHRINKFILE (N'myfile' , EMPTYFILE)'

O ID do arquivo x do ID do banco de dados x não pode ser reduzido, pois está sendo reduzido por outro processo ou está vazio

Não está vazio nem sendo encolhido. Ele está sendo executado em um banco de dados que não está em uso por ninguém, exceto por mim. A redução automática não está habilitada e nunca esteve. No entanto, houve encolhimentos manuais realizados neste banco de dados regularmente antes de eu colocar minhas mãos nele, se isso importa.

No SQLServerCentral , um thread de uma década atrás sugere adicionar alguns MB ao arquivo porque isso "reinicia um contador ou switch interno que informa que não está no meio de uma redução agora".

Isso funcionou - incrível. Mas alguém pode explicar com mais detalhes como/por que isso funciona em relação aos internos do SQL Server?

sql-server sql-server-2016

1 respostas

  1. Best Answer

    Dei uma olhada na página de cabeçalho do arquivo, como sugerido por Martin Smith nos comentários. Eu acho que isso é parte da resposta, mas é principalmente especulação baseada na observação de alterações nos valores do sinalizador da página de cabeçalho do arquivo entre a execução de reduções e outras operações.

    Primeiro, criei um banco de dados para testar, incluindo um grupo de arquivos secundário:

    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

    Eu olhei para a "página 0" para o arquivo secundário, que é file_id 3:

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

    Há um campo chamado m_flagBitsque tem um valor de 0x208.

    Se eu esvaziar este arquivo:

    DBCC SHRINKFILE (N'ShrinkFile_Test_Secondary' , EMPTYFILE);

    Esse m_flagbitscampo permanece o mesmo ( 0x208). Não é tão interessante, mas agora estou na situação que você relatou: se eu tentar esvaziar o arquivo novamente, recebo este erro:

    A ID de arquivo 3 da ID de banco de dados 19 não pode ser reduzida porque está sendo reduzida por outro processo ou está vazia.

    Vou tentar aumentar o arquivo (a solução que funcionou para você):

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

    Agora m_flagbitsé 0x8!

    Neste ponto, o esvaziamento do arquivo novamente é bem-sucedido e retorna o valor 0x208conforme o esperado.

    O que acho interessante é que, se eu fizer isso depois de aumentar o arquivo de volta (o valor de flagbits AKA é 0x8):

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

    O arquivo é marcado como is_read_onlyna sys.databasestabela e m_flagbitsé definido como 0x208. Portanto, parece que há algum sinalizador de nível de arquivo semelhante definido ao reduzir um arquivo e ao configurá-lo para somente leitura.

    Meu melhor palpite é que esse valor é usado junto com algum outro sinalizador (interno) para indicar que um arquivo é elegível para ser reduzido. Aumentar o arquivo parece desmarcar esse sinalizador (pelo menos o visível em m_flagbits).

    • 5

relate perguntas