主页 / dba / 问题 / 273667
Accepted
HandyD
Asked: 2020-08-13 17:06:14 +0800 CST

在文件/文件组中查找数据

  • 772

我在尝试将数据迁移出文件组以清空并删除文件组时遇到问题。我已将使用文件组的所有索引/表和所有分区方案移动到新文件组，但我无法从旧文件组中删除最后一个文件。我得到的错误是文件不为空。

我尝试了 EMPTYFILE 技巧，但这不起作用，因为它说文件中仍有数据，这似乎是真的，因为查询 sys.allocation_units 显示文件中仍有大约 30 MB 的数据。查询索引、分区、对象和其他 DMV 不会报告任何仍在使用此文件组作为数据空间的内容。

还有哪些其他 DMV/DMF 可以向我展示文件中留下的数据实际上是什么？

SQL Server 2016 企业版

sql-server

1 个回答

  1. Best Answer

    所以我永远无法确定为什么分配的页面无法使用 sys.allocation_units 链接到底层对象，但是，我最终能够使用来自 Paul Randal和 DBCC PAGE 的脚本的修改版本来识别对象。

    首先，运行这个脚本（它基于 Paul Randal 的 sp_AllocationMetadata 但修改为基于文件组名称而不是对象名称进行过滤）：

    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>'

    输出给了我一个分配单元列表和相关的页面标识符：

    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)

    然后可以对照DBCC PAGE检查这些结果以识别底层对象：

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

    这会输出一些元数据，特别是表示Metadata: ObjectId = <object id>. 此对象 ID 引用与此数据页相关的对象。

    就我而言，我有大约 300 个分配单元需要处理。相关部分是所识别的对象是建立在分区方案上的，这些分区方案从未将相关文件组引用为目标数据空间，但不知何故，数据最终分配到了这些文件中。在任何情况下，重建索引都会从相关文件组中释放页面，并且可以删除文件和文件组。

    • 0

相关问题