Không thể xóa filegroup không có tệp liên quan

Tôi đang gặp một số thông báo lỗi kỳ lạ trên SQL Server 2017 CU3. Tôi đang di chuyển cơ sở dữ liệu và sắp xếp lại các nhóm fileg. Bằng cách "sắp xếp lại" Tôi có nghĩa là tôi sử dụng một thủ tục được lưu trữ để tạo ra một chức năng phân vùng và sơ đồ phân vùng trên filegroup mới cho một đối tượng, xây dựng lại các chỉ mục trong khi phân vùng và sau đó loại bỏ phân vùng.

Cuối cùng, tôi đã có một số nhóm trống. Các tập tin của họ được gỡ bỏ . Ngoài ra, chính các tập đoàn được loại bỏ. Điều này hoạt động tốt trong hầu hết các trường hợp. Tuy nhiên, đối với hai cơ sở dữ liệu, tôi đã xóa các tệp ... có một tệp fileg còn lại không có tệp nào được liên kết nhưng

ALTER DATABASE REMOVE FILEGROUP

ném lỗi 5042:

Không thể xóa tên tập tin 'xyz' vì nó không trống.

Câu hỏi

Làm thế nào tôi có thể thoát khỏi tập đoàn trống đó ... vấn đề có thể là gì?

Tôi đã đọc một số vấn đề phổ biến tuy nhiên chúng không có trong hệ thống của tôi:

• Đã kiểm tra:

  SELECT * FROM sys.partition_schemes;
  SELECT * FROM sys.partition_functions;

  0 hàng ... không có đối tượng phân vùng còn lại trong cơ sở dữ liệu

• UPDATE STATISTICS cho tất cả các đối tượng trong cơ sở dữ liệu

  không có tác dụng

• Kiểm tra các chỉ mục trên filegroup:

  SELECT * FROM  sys.data_spaces ds
  INNER JOIN sys.indexes i
  ON ds.data_space_id = i.data_space_id
  WHERE ds.name = 'xyz'

  0 hàng

• Kiểm tra các đối tượng trong filegroup:

  SELECT
      au.*,
      ds.name AS [data_space_name],
      ds.type AS [data_space_type],
      p.rows,
      o.name AS [object_name]
  FROM sys.allocation_units au
      INNER JOIN sys.data_spaces ds
          ON au.data_space_id = ds.data_space_id
      INNER JOIN sys.partitions p
          ON au.container_id = p.partition_id
      INNER JOIN sys.objects o
          ON p.object_id = o.object_id
  WHERE au.type_desc = 'LOB_DATA'
  AND ds.name ='xyz'

  0 hàng

Tôi cũng đã thử DBCC SHRINKFILEtham số EMPTYFILEtrước khi xóa tệp khỏi filegroup. Nó không thực sự có ý nghĩa với tôi tuy nhiên tôi đọc các giải pháp để mô tả điều đó như là một sửa chữa. Dù sao cũng không có tác dụng.

Tôi có một số hy vọng đọc câu hỏi này về lỗi máy chủ và đã thử như sau:

• Cập nhật tất cả các số liệu thống kê
• Bỏ tất cả các số liệu thống kê không liên quan đến chỉ mục

Tuy nhiên điều này không có tác dụng. Tôi vẫn có một filegroup không có tệp nào được liên kết và filegroup không thể bị xóa. Tôi hoàn toàn bối rối vì điều này xảy ra trong một số cơ sở dữ liệu chứ không phải trong các cơ sở dữ liệu khác (có cùng cấu trúc). Khi tôi thực hiện DBCC CHECK FILEGROUPtrên tập tin trống này, tôi nhận được một loạt các thông báo lỗi như sau:

Không thể xử lý hàng ID ID 72057594712162304 của đối tượng "STORY_TRANSLATIONSCCC" (ID 120387498), chỉ mục "Ref90159CCC" (ID 2), vì nó không nằm trong filegroup "CCC_APPLICATION_new" (ID 8).

Kết quả DBCC cho 'STORY_TRANSLATIONSCCC'. Có 0 hàng trong 0 trang cho đối tượng "STORY_TRANSLATIONSCCC".

Điều này là bình thường hay nó chỉ ra điều gì đó bất thường?

Câu hỏi này có thể là một bản sao, tuy nhiên tôi không thể tìm ra cách khắc phục hiệu quả cho mình trong các câu hỏi khác trên dba.stackexchange. Xin vui lòng xem danh sách những gì tôi đã thử. Điều này giống hệt với các giải pháp được mô tả trong Không thể xóa các nhóm không sử dụng .

Thêm chi tiết

Có lẽ nó giúp hiểu những gì tôi làm trước khi xảy ra lỗi. Tôi đang lên kế hoạch di chuyển đến một máy chủ mới. Tôi hiện đang thử nghiệm điều này trên một ví dụ thử nghiệm. Cơ sở dữ liệu được khôi phục từ máy chủ prod và mô hình khôi phục được chuyển sang đơn giản. Mục tiêu của tôi là tái cấu trúc các nhóm fileg và chuyển từ một mô hình với một tệp cho mỗi filegroup sang một mô hình với hai tệp cho mỗi nhóm tệp. Để đạt được điều đó, tôi tạo các nhóm fileg trống mới với hai tệp mỗi tệp và di chuyển dữ liệu qua. Thật không may, hầu hết các đối tượng đều có Dữ liệu LOB (XML và nhị phân) ... vì vậy tôi tận dụng phân vùng như một người trợ giúp để di chuyển dữ liệu lob. Cuối cùng, tất cả các dữ liệu nằm trong các nhóm mới và các nhóm cũ đều trống. Sau đó, tôi loại bỏ tất cả các tập tin và loại bỏ filegroup tương ứng là tốt. Nhóm chính vẫn còn và chỉ cần thêm một tệp khác.câu hỏi của tôi . Quá trình này hoạt động tốt nhưng trong hai cơ sở dữ liệu các tệp có thể bị xóa nhưng filegroup thì không. Đáng ngạc nhiên là cấu trúc của các cơ sở dữ liệu này phải giống như cấu trúc của các cơ sở dữ liệu khác không gặp phải vấn đề gì trong quá trình di chuyển dữ liệu và loại bỏ các tập tin cũ.

Vì vậy, đây là danh sách các tập tin và tệp của hai cơ sở dữ liệu nơi xảy ra sự cố:

1. CCC_GENTE

trước

+-----------------+------------+
| Filegroup       | Filename   |
+-----------------+------------+
| CCC_APPLICATION | CCC_APP    |
+-----------------+------------+
| CCC_ARCHIVE     | CCC_ARCHIV |
+-----------------+------------+
| CCC_AXN         | CCC_AXN    |
+-----------------+------------+
| CCC_GDV         | CCC_GDV    |
+-----------------+------------+
| PRIMARY         | CCC        |
+-----------------+------------+

sau

    +-----------------+--------------------------+--------------------+----------------------------------------------------+
| Filegroup name  | Filegroup temporary name | Filename (logical) | Status                                             |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_APPLICATION | -                        | CCC_APP            | file removed, filegroup  cannot be removed (error) |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_ARCHIVE     | -                        | CCC_ARCHIV         | file and filegroup removed                         |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_AXN         | -                        | CCC_AXN            | file and filegroup removed                         |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_GDV         | -                        | CCC_GDV            | file and filegroup removed                         |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| PRIMARY         | -                        | CCC                | file renamed to PRIMARY_1                          |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| PRIMARY         | -                        | PRIMARY_2          | new file added                                     |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_APPLICATION | CCC_APPLICATION_new      | CCC_APPLICATION_1  | new filegroup renamed at the end                   |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_APPLICATION | CCC_APPLICATION_new      | CCC_APPLICATION_2  | new filegroup renamed at the end                   |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_ARCHIVE     | CCC_ARCHIVE_new          | CCC_ARCHIVE_1      | new filegroup renamed at the end                   |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_ARCHIVE     | CCC_ARCHIVE_new          | CCC_ARCHIVE_2      | new filegroup renamed at the end                   |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_AXN         | CCC_AXN_new              | CCC_AXN_1          | new filegroup renamed at the end                   |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_AXN         | CCC_AXN_new              | CCC_AXN_2          | new filegroup renamed at the end                   |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_GDV         | CCC_GDV_new              | CCC_GDV_1          | new filegroup renamed at the end                   |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_GDV         | CCC_GDV_new              | CCC_GDV_2          | new filegroup renamed at the end                   |
+-----------------+--------------------------+--------------------+----------------------------------------------------+

Tôi hy vọng việc đó sẽ có ích một chút. Ngoài ra còn có một cơ sở dữ liệu thứ hai trong đó các tên filegroup khác nhau nhưng tôi để nó ra cho ngắn gọn.

Kiểm tra hai nhóm trong cơ sở dữ liệu

Xác minh rằng filegroup không có bất kỳ tệp nào được đính kèm bằng cách ban hành lệnh sau:

use [DB]
go
sp_helpfilegroup 

Điều này sẽ tạo ra một danh sách các nhóm fileg:

 groupname | groupid | filecount
-----------+---------+-----------
 PRIMARY   | 1       | 1
 xyz       | 2       | 1

... và sau đó cho mỗi nhóm được liệt kê thực thi

use [DB]
go
sp_helpfilegroup @filegroupname='PRIMARY'
go
sp_helpfilegroup @filegroupname='xyz'

Đầu ra có thể trông như thế này:

 groupname | groupid | filecount
-----------+---------+------------
 xyz       | 2       | 1

.... và đầu ra thứ hai có thể là:

  file_in_group    | fileid | filename                          | size    | maxsize   | growth  
 ------------------+--------+-----------------------------------+---------+-----------+---------
  xyz_logical_name | 3      | X:\SQL\SQL_DATA\xyz_filegroup.ndf | 5120 KB | Unlimited | 1024 KB  

Xóa tập đoàn

Nếu bạn vẫn có một tệp được liên kết với một trong các nhóm fileg của bạn, thì lệnh hoàn chỉnh để xóa tệp logic của filegroup và chính filegroup sẽ là:

USE [DB]
GO
ALTER DATABASE [DB] REMOVE FILE [xyz_logical_name]
GO
ALTER DATABASE [DB] REMOVE FILEGROUP [xyz]
GO

Filegroup 'xyz' là mặc định

Nếu bạn nhận được thông báo lỗi khi cố xóa tệp logic của filegroup trông như thế này:

Msg 5031, Level 16, State 1, Line 88
Cannot remove the file 'xyz_logical_name' because it is the only file in the DEFAULT filegroup.

... Sau đó, bạn sẽ phải đặt PRIMARYfilegroup thành DEFAULTfilegroup:

ALTER DATABASE [DB] MODIFY FILEGROUP [PRIMARY] DEFAULT

Filegroup 'xyz' được đọc một lần

Tuy nhiên, nếu thông báo lỗi là như sau:

Msg 5055, Level 16, State 2, Line 88 
Cannot add, remove, or modify file 'xyz_logical_name'. The file is read-only.

... sau đó bạn sẽ phải xóa thuộc tính READ_ONLY trên xyzfilegroup:

ALTER DATABASE [DB] MODIFY FILEGROUP [xyz] READWRITE

Bây giờ bạn có thể loại bỏ tệp logic của filegroup và chính filegroup.

Giao dịch mở

Nếu bạn thực sự không có tệp (logic_name / pyhsical_file_name) được liên kết với nhóm fileg xyzmà bạn đang cố xóa, thì việc thực hiện sao lưu nhật ký giao dịch có thể giải phóng bất kỳ giao dịch nào cản trở việc xóa thêm filegroup.

Quay số 911

Nếu vẫn thất bại, bạn có thể muốn xem xét mở một cuộc gọi với Microsoft.

Không phù hợp siêu dữ liệu

Đã thêm sau khi nghiên cứu thêm

Rõ ràng có những trường hợp khi siêu dữ liệu trong cơ sở dữ liệu không phản ánh vị trí thực tế của các đối tượng.

Tham khảo:
- CỐ ĐỊNH: Lỗi không thống nhất siêu dữ liệu sau khi bạn chuyển phân vùng bảng và thả các tệp và nhóm tệp tương ứng (Hỗ trợ của Microsoft)
- Lỗi: Xảy ra lỗi khi bạn cố gắng thả hoặc xóa các tệp fileg hoặc các lược đồ và chức năng phân vùng trong SQL Server (Hỗ trợ của Microsoft)

Hai trường hợp này dường như đã được giải quyết với Cập nhật tích lũy 3 cho SQL Server 2014 SP1 và Cập nhật tích lũy 1 cho SQL Server 2016 tương ứng. Chúng không áp dụng cho tình huống của bạn, nhưng chúng cho thấy rằng đôi khi siêu dữ liệu có thể sai.

Mục dường như đang chặn việc xóa nhóm của bạn là chỉ mục, có thể được lưu trữ với dữ liệu meta sai.

Giải pháp có thể

Xem xét xây dựng lại chỉ mục Ref90159CCCđược tham chiếu trong thông báo lỗi.

Cannot process rowset ID 72057594712162304 of object 
"STORY_TRANSLATIONSCCC" (ID 120387498), index "Ref90159CCC" (ID 2), 
because it resides on filegroup "CCC_APPLICATION_new" (ID 8), 
which was not checked.

Bài viết sau đây mô tả một tình huống tương tự và chỉ ra cách tác giả phát hiện ra thủ phạm và giải quyết tình huống.

Tham khảo: SQL Server: vấn đề không nhất quán phân vùng và siêu dữ liệu (Blog dbi-service.com)

Tìm các đối tượng liên quan đến Filegroup đã lỗi thời

Tôi đã dựng lên kịch bản này để kiểm tra càng nhiều nơi ẩn càng tốt cho các bảng / chỉ mục / phân vùng / v.v. điều đó vẫn có thể liên quan đến tệp filegroup bị bỏ:

_{Vui lòng thay thế DEFAULTRObằng tên của filegroup lỗi thời của bạn (ví dụ CCC_APPLICATION)}

 /* ==================================================================
  Author......: hot2use
  Date........: 16.02.2018
  Version.....: 0.1
  Server......: LOCALHOST (first created for)
  Database....: StackExchange
  Owner.......: -
  Table.......: -
  Type........: Script
  Name........: ADMIN_Filegroup_Statement_All_Objects.sql
  Description.: Checks all objects related to filegroups based on the 
  ............  relationship between the data_space_id ID.
  ............      
  History.....:  0.1    h2u First created
  ............      
  ............      
 ================================================================== */
DECLARE @nvObsoleteFG AS NVARCHAR(50)
SET @nvObsoleteFG = N'DEFAULTRO'

SELECT -- DISTINCT use in conjunction with sys.allocation_units table and objects
       '-->'                            AS DataSpaceNfo
      ,ds.name                          AS DataSpaceName
      ,ds.data_space_id                 AS DatSpacID_DataSpace
      ,'-->'                            AS FileGroupNfo
      ,f.name                           AS FileGrpName
      ,f.data_space_id                  AS DatSpacID_FileGrp
      ,f.[type]                         AS FileGrpType
      ,'-->'                            AS DataBaseFilesNfo
      ,df.data_space_id                 AS DatSpacID_DBFiles
      ,df.[type]                        AS DBFilesType
      ,df.name                          AS DBFilesName
      ,'-->'                            AS ObjectNfo
      ,o.[object_id]                    AS OjbID
      ,o.name                           AS ObjName4HeapsClusters
      ,o.type_desc                      AS ObjTypeDesc
      ,'-->'                            AS IndexNfo
      ,i.name                           AS ObjName4Indexes
      ,i.type_desc                      AS IndTypeDesc
      ,i.[object_id]                    AS IndObjID
      ,i.index_id                       AS IndIndID
      ,'-->'                            AS PartSchemaNfo
      ,ps.name                          AS PartSchemaName
      ,ps.data_space_id                 AS DatSpacID_PartSchema
       -- ,au.type_desc                     AS AllocUnitTypeDesc
       -- ,au.data_space_id                 AS DatSpacID_AllocUnit
FROM   sys.data_spaces                  AS ds
       FULL JOIN sys.filegroups         AS f
            ON  ds.data_space_id = f.data_space_id
       FULL JOIN sys.database_files     AS df
            ON  f.data_space_id = df.data_space_id
       FULL JOIN sys.indexes            AS i
            ON  f.data_space_id = i.data_space_id
       FULL JOIN sys.partition_schemes  AS ps
            ON  f.data_space_id = ps.data_space_id
       FULL JOIN sys.objects            AS o
            ON  i.[object_id] = o.[object_id]         
       -- FULL JOIN sys.allocation_units   AS au
       --      ON  au.data_space_id = f.data_space_id

-- If you omit the whole WHERE clause you get an overview of everything (incl. MS objects)
WHERE  o.is_ms_shipped = 0
       -- if you omit the lower AND you'll get all items related to all filegroups
       AND (
               df.data_space_id=(
                   SELECT data_space_id
                   FROM   sys.filegroups
                   WHERE  NAME = @nvObsoleteFG
               )
               OR f.data_space_id=(
                      SELECT data_space_id
                      FROM   sys.filegroups
                      WHERE  NAME = @nvObsoleteFG
                  ) 
               OR df.data_space_id=(
                      SELECT data_space_id
                      FROM   sys.filegroups
                      WHERE  NAME = @nvObsoleteFG
                  )
               OR ps.data_space_id=(
                      SELECT data_space_id
                      FROM   sys.filegroups
                      WHERE  NAME = @nvObsoleteFG
                  )
           )

Tham khảo: Kịch bản cá nhân của tôi

Chạy nó và xem nếu có bất kỳ đối tượng nào được hiển thị có chứa filegroup lỗi thời của bạn. Đi với data_space_idhơn là với tên. Các tham gia được cố ý FULLđể bắt bất kỳ tài liệu tham khảo "mồ côi".

Hoặc sử dụng tập lệnh nhỏ hơn này để kiểm tra nhanh các mục trong nhóm tệp lỗi thời:

SELECT o.[name]
      ,o.[type]
      ,i.[name]
      ,i.[index_id]
      ,f.[name]
FROM   sys.indexes i
       INNER JOIN sys.filegroups f
            ON  i.data_space_id = f.data_space_id
       INNER JOIN sys.all_objects o
            ON  i.[object_id] = o.[object_id]
WHERE  i.data_space_id = f.data_space_id
       AND o.type = 'U' -- User Created Tables

Tham khảo: SQL SERVER - Liệt kê tất cả các đối tượng được tạo trên tất cả các nhóm trong cơ sở dữ liệu (SQLAuthority.com)

Sau bốn tháng, bộ phận Hỗ trợ của Microsoft đã tìm thấy giải pháp. Thực sự có một bảng đề cập đến tập đoàn có lẽ trống rỗng này.

Bảng được xác định bởi tuyên bố sau:

SELECT t.[name] FROM sys.tables t
   inner join sys.filegroups f
         on t.lob_data_space_id = f.data_space_id
   where f.name = 'xyz'

Sau khi chuyển dữ liệu sang một bảng mới và bỏ bảng có vấn đề, filegroup đã được xóa thành công. Quá trình di chuyển dữ liệu là: tạo một bảng mới có cùng cấu trúc và chỉ mục, sao chép dữ liệu qua SELECT INTO, bỏ bảng cũ, đổi tên bảng mới (và tất nhiên là chăm sóc các khóa ngoại nếu có bất kỳ khóa nào trong toàn bộ quá trình) )