Início / dba / Perguntas / 273667
Accepted
HandyD
Asked: 2020-08-13 17:06:14 +0800 CST

Localizando dados no arquivo/grupo de arquivos

  • 772

Estou tendo um problema ao tentar migrar dados de um grupo de arquivos para esvaziar e remover o grupo de arquivos. Movi todos os índices/tabelas e todos os esquemas de partição usando o grupo de arquivos para o novo grupo de arquivos, mas não consigo remover o último arquivo do grupo de arquivos antigo. O erro que recebo é que o arquivo não está vazio.

Eu tentei o truque EMPTYFILE, mas isso não funciona, pois diz que ainda há dados no arquivo, o que parece ser verdade, pois a consulta de sys.allocation_units mostra cerca de 30 MB de dados ainda no arquivo. Consultar índice, partição, objeto e outros DMVs não relata nada que ainda esteja usando esse grupo de arquivos como espaço de dados.

Que outros DMVs/DMFs existem para me mostrar quais são os dados deixados no arquivo?

SQL Server 2016 Enterprise Edition

sql-server

1 respostas

  1. Best Answer

    Portanto, nunca consegui determinar por que as páginas alocadas não puderam ser vinculadas ao objeto subjacente usando sys.allocation_units, mas acabei conseguindo identificar os objetos usando uma versão modificada de um script de Paul Randal e DBCC PAGE.

    Em primeiro lugar, executando este script (que é baseado no sp_AllocationMetadata de Paul Randal, mas modificado para filtrar com base no nome do grupo de arquivos e não no nome do objeto):

    SELECT
    [sa].[allocation_unit_id] AS [Alloc Unit ID],
    [sa].[type_desc] AS [Alloc Unit Type],
    '(' + CONVERT (VARCHAR (6),
        CONVERT (INT,
            SUBSTRING ([sa].[first_page], 6, 1) +
            SUBSTRING ([sa].[first_page], 5, 1))) +
    ':' + CONVERT (VARCHAR (20),
        CONVERT (INT,
            SUBSTRING ([sa].[first_page], 4, 1) +
            SUBSTRING ([sa].[first_page], 3, 1) +
            SUBSTRING ([sa].[first_page], 2, 1) +
            SUBSTRING ([sa].[first_page], 1, 1))) +
    ')' AS [First Page],
    '(' + CONVERT (VARCHAR (6),
        CONVERT (INT,
            SUBSTRING ([sa].[root_page], 6, 1) +
            SUBSTRING ([sa].[root_page], 5, 1))) +
    ':' + CONVERT (VARCHAR (20),
        CONVERT (INT,
            SUBSTRING ([sa].[root_page], 4, 1) +
            SUBSTRING ([sa].[root_page], 3, 1) +
            SUBSTRING ([sa].[root_page], 2, 1) +
            SUBSTRING ([sa].[root_page], 1, 1))) +
    ')' AS [Root Page],
    '(' + CONVERT (VARCHAR (6),
        CONVERT (INT,
            SUBSTRING ([sa].[first_iam_page], 6, 1) +
            SUBSTRING ([sa].[first_iam_page], 5, 1))) +
    ':' + CONVERT (VARCHAR (20),
        CONVERT (INT,
            SUBSTRING ([sa].[first_iam_page], 4, 1) +
            SUBSTRING ([sa].[first_iam_page], 3, 1) +
            SUBSTRING ([sa].[first_iam_page], 2, 1) +
            SUBSTRING ([sa].[first_iam_page], 1, 1))) +
    ')' AS [First IAM Page]
FROM sys.system_internals_allocation_units AS [sa] (NOLOCK)
INNER JOIN sys.allocation_units au (NOLOCK) ON au.allocation_unit_id = sa.allocation_unit_id
INNER JOIN sys.data_spaces ds (NOLOCK) ON ds.data_space_id = au.data_space_id
WHERE ds.[name] = '<filegroup name here>'

    A saída me deu uma lista de unidades de alocação e os identificadores de página associados:

    Alloc Unit ID       Alloc Unit Type First Page      Root Page   First IAM Page
72059231029821440   IN_ROW_DATA     (44:2579440)    (21:2832)   (21:2812)
72059231073271808   IN_ROW_DATA     (25:4532384)    (21:3888)   (21:3883)
72059240244248576   IN_ROW_DATA     (21:656)        (21:656)    (21:1040)
72059240310046720   IN_ROW_DATA     (44:1047088)    (21:2592)   (21:2572)
72059240312340480   IN_ROW_DATA     (25:2516760)    (21:1880)   (21:1859)

    Esses resultados podem ser verificados em relação ao DBCC PAGE para identificar o objeto subjacente:

    DBCC TRACEON (3604);
DBCC PAGE (19, 21, 688, 0);
DBCC TRACEOFF (3604);

    Isso gera alguns metadados, especificamente uma linha que diz Metadata: ObjectId = <object id>. Este ID de objeto faz referência ao objeto ao qual esta página de dados está relacionada.

    No meu caso, eu tinha cerca de 300 unidades de alocação para trabalhar. A parte preocupante é que os objetos identificados foram construídos em esquemas de partição que nunca referenciaram o grupo de arquivos em questão como um espaço de dados de destino, mas de alguma forma os dados acabaram alocados nesses arquivos. De qualquer forma, a reconstrução dos índices desalocou as páginas do grupo de arquivos em questão e os arquivos e o grupo de arquivos podem ser removidos.

    • 0

relate perguntas