Saya mengalami beberapa pesan kesalahan aneh pada SQL Server 2017 CU3. Saya memigrasikan basis data dan mengatur ulang grup-grup film. Dengan "mengatur ulang" maksud saya bahwa saya menggunakan prosedur tersimpan yang membuat fungsi partisi dan skema partisi pada filegroup baru untuk objek, membangun kembali indeks saat mempartisi dan kemudian menghapus partisi.
Pada akhirnya saya mendapatkan beberapa filegroup kosong. File - file mereka dihapus . Juga filegroup itu sendiri dihapus. Ini bekerja dengan baik dalam banyak kasus. Namun untuk dua database saya dihapus file ... memiliki filegroup dibiarkan tanpa file terkait tapi
ALTER DATABASE REMOVE FILEGROUP
melempar kesalahan 5042:
Filegroup 'xyz' tidak dapat dihapus karena tidak kosong.
Pertanyaan
Bagaimana saya bisa menyingkirkan filegroup kosong itu ... apa masalahnya?
Saya sudah membaca beberapa masalah umum namun tidak ada dalam sistem saya:
Diperiksa:
SELECT * FROM sys.partition_schemes; SELECT * FROM sys.partition_functions;
0 rows ... tidak ada objek partisi yang tersisa di database
UPDATE STATISTICS
untuk semua objek dalam databasetidak berpengaruh
Cek indeks pada 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 baris
Memeriksa objek di 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 baris
Saya juga memberi DBCC SHRINKFILE
parameter EMPTYFILE
mencoba sebelum menghapus file dari filegroup. Itu tidak benar-benar masuk akal bagi saya namun saya membaca solusi untuk menggambarkan itu sebagai perbaikan. Lagi pula tidak berpengaruh.
Saya mendapat harapan membaca pertanyaan ini tentang kesalahan server dan mencoba yang berikut:
- Perbarui semua statistik
- Hapus semua statistik yang tidak terkait dengan indeks
Namun ini tidak berpengaruh. Saya masih memiliki filegroup tanpa file yang terkait dan filegroup tidak dapat dihapus. Saya benar-benar bingung karena ini terjadi di beberapa database dan tidak di yang lain (dengan struktur yang sama). Ketika saya tampil DBCC CHECK FILEGROUP
di filegroup kosong ini saya mendapatkan banyak pesan kesalahan seperti berikut:
Tidak dapat memproses rowset ID 72057594712162304 objek "STORY_TRANSLATIONSCCC" (ID 120387498), indeks "Ref90159CCC" (ID 2), karena ia berada di filegroup "CCC_APPLICATION_new" (ID 8), yang tidak dicentang.
Hasil DBCC untuk 'STORY_TRANSLATIONSCCC'. Ada 0 baris dalam 0 halaman untuk objek "STORY_TRANSLATIONSCCC".
Apakah ini normal atau apakah ini menunjuk ke sesuatu yang tidak biasa?
Pertanyaan ini mungkin merupakan duplikat, namun saya tidak dapat menemukan perbaikan yang berfungsi untuk saya dalam pertanyaan lain di dba.stackexchange. Silakan lihat daftar apa yang sudah saya coba. Ini identik dengan solusi yang dijelaskan dalam Tidak dapat menghapus filegroup yang tidak digunakan .
Keterangan lebih lanjut
Mungkin membantu memahami apa yang saya lakukan sebelum kesalahan terjadi. Saya merencanakan migrasi ke server baru. Saat ini saya sedang menguji ini pada contoh uji. Database dipulihkan dari server prod dan model pemulihan dialihkan ke yang sederhana. Tujuan saya adalah merestrukturisasi filegroup dan pindah dari model dengan satu file per filegroup ke model dengan dua file per grup file. Untuk mencapai itu saya membuat filegroup kosong baru dengan masing-masing dua file dan memindahkan data. Sayangnya sebagian besar objek memiliki Data LOB (XML dan biner) ... jadi saya memanfaatkan partisi sebagai penolong untuk memindahkan data-lob juga. Pada akhirnya semua data berada di filegroup baru dan filegroup lama kosong. Lalu saya menghapus semua file dan menghapus filegroup masing-masing juga. Filegroup utama tetap dan hanya mendapatkan file lain ditambahkan.pertanyaan saya . Proses ini berfungsi dengan baik tetapi dalam dua basis data file dapat dihapus tetapi grupfile tidak. Anehnya struktur basis data ini harus sama dengan struktur basis data lain jika tidak ada masalah yang dihadapi dalam proses pemindahan data dan menghapus filegroup lama.
Jadi, inilah daftar filegroup dan file dari dua database di mana masalah terjadi:
- CCC_GENTE
sebelum
+-----------------+------------+
| Filegroup | Filename |
+-----------------+------------+
| CCC_APPLICATION | CCC_APP |
+-----------------+------------+
| CCC_ARCHIVE | CCC_ARCHIV |
+-----------------+------------+
| CCC_AXN | CCC_AXN |
+-----------------+------------+
| CCC_GDV | CCC_GDV |
+-----------------+------------+
| PRIMARY | CCC |
+-----------------+------------+
setelah
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| 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 |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
Saya harap itu sedikit membantu. Ada juga database kedua di mana nama filegroup berbeda tetapi saya biarkan itu untuk singkatnya.