Menghapus file data sekunder. DBCC SHRINKFILE: Halaman tidak dapat dipindahkan karena ini adalah halaman tabel kerja

Saya memiliki terlalu banyak file data sekunder (.ndf) yang dibuat untuk tempdb. Untuk menghapus file berlebih, saya perlu mengosongkan file (konten akan dipindahkan ke file lain):

DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);

lalu hapus file:

ALTER DATABASE tempdb REMOVE FILE tempdbfile8;

Tetapi EMPTYFILEperintah mengembalikan kesalahan:

DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page.
Msg 2555, Level 16, State 1, Line 2
Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation.

Jangan khawatir, saya hanya perlu mencari objek yang menggunakan halaman ini untuk melakukan sesuatu tentang hal itu:

DBCC TRACEON (3604)
DBCC PAGE(2,8,41920) --dbid=2, fileid=8, pageid=41920

Perintah mengembalikan banyak informasi, object_id di antara mereka. Tapi:

Metadata: ObjectId = 0

Saya tidak tahu harus bagaimana. Kucing apa yang mencegah halaman ini dipindahkan? Bagaimana cara menemukan objek, proses, sesi atau apa pun itu? Bantuan apa pun akan dihargai, tetapi harap dicatat bahwa membiarkan semuanya apa adanya atau menghapus file lain bukan merupakan solusi yang valid untuk masalah ini;).

EDIT:

Saya menghapus file, karena kami biasa mengikuti "praktik terbaik" membuat satu file per inti prosesor (ukuran awal yang sama, tingkat pertumbuhan yang sama). Tapi sejauh yang saya tahu, sampai Anda mengalami masalah pertikaian, tidak ada gunanya membuat file tempdb tambahan pada perangkat yang sama. Dalam kasus kami masuk akal, karena kami telah mengaktifkan MPIO , dan perangkat penyimpanan dapat menangani 4 jalur. Tetapi ada kesalahan, dan kami berakhir dengan total 5 file dengan cpu 6-core. Ini lebih dari jalur MPIO, kurang dari inti CPU, dan itu bukan bilangan genap. Ini mungkin tidak menyebabkan masalah, tetapi sepertinya tidak tepat :).

Saya akhirnya dapat mengosongkan dan menghapus file tanpa me-restart server dengan mengatur salah satu database (yang saya duga menyebabkan masalah) ke mode pengguna tunggal (rollback langsung). Itu berhasil, tapi saya beruntung. Yang benar-benar saya inginkan, adalah untuk selalu dapat melacak halaman :).

— Adam Luniewski
sumber

Perintah DBCC PAGE tidak benar, harus seperti halaman dbcc (2,41920,1). 1,2,3 tergantung pada apa yang Anda inginkan dalam output.

— Shanky

Jika di atas tidak berfungsi Anda mungkin harus melakukannya di perangkat keras dengan menghapus file dan kemudian me-restart server sql sehingga hanya akan menggunakan file yang tidak dihapus. Bisakah Anda merujuk tautan ini daveturpin.com/2011/07/how-to-drop-a-tempdb-database-file

— Shanky

@Shanky Perintahnya benar. 0..3 dapat dilewatkan sebagai parameter ke-4: dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])Tentang solusi Anda: itu akan berhasil, tetapi saya benar-benar ingin melakukan ini tanpa menurunkan instance.

— Adam Luniewski

Oke..aku sudah memberitahumu bentuk halaman dbcc yang lebih sederhana. Harap dicatat adalah perintah tidak berdokumen. Apakah Anda memeriksa tautan yang saya posting

— Shanky

Saya tidak berpikir itu layak untuk menyelesaikan masalah ini tanpa memulai kembali instance. Jelas Anda sudah mencoba melacak apa meja kerja ini (yang akan membantu menentukan siapa pemiliknya), dan itu telah gagal. Ambil hit, atau hidup dengan file tambahan sampai Anda dapat me-restart.

— Aaron Bertrand

Jawaban:

Restart server sudah cukup - meja kerja itu harus dibersihkan. Tapi saya mungkin akan memulainya dalam mode pengguna tunggal (-m) untuk mencegah proses lain dari membuat meja kerja sebelum Anda berhasil menghapus file-file itu. Kemudian definisikan ulang file yang diperlukan untuk tempdb; mungkin menghapus file yang tidak perlu, mengubah ukuran, dll. Anda juga harus memastikan Anda memiliki jumlah file yang genap, bahwa mereka semua diatur ke ukuran yang sama, dan bahwa mereka semua memiliki pengaturan autogrowth yang sama (dalam MB, bukan%). Dan mungkin ini saat yang tepat untuk mempertimbangkan TF 1117 dan TF 1118 juga ( titik awal ).

Saya akan sangat waspada dengan saran untuk hanya menghapus file dari sistem file sebelum memulai SQL Server lagi - mungkin tidak memulai sama sekali.

(Tapi saya juga ingin tahu tentang apa masalah sebenarnya. Memiliki terlalu banyak file tidak menyakiti Anda, sungguh.)

— Aaron Bertrand
sumber

@@ Aaron ofcourse Anda harus berhati-hati menghapusnya harus kosong, tetapi yang didokumentasikan di sini msdn.microsoft.com/en-gb/library/ms175574.aspx . Sudah mencobanya dan SQl Server tempdb sudah online.

— Shanky

@Shanky saya mencoba mengemudi 138 mil per jam sekali, dan saya tidak menepi. Apakah itu berarti saya harus terus melakukannya, dan bahwa tidak ada kesempatan saya akan ditarik besok? Jauh lebih aman untuk mencoba cara yang benar terlebih dahulu, sebelum menyarankan cara yang lebih berisiko. MENURUT OPINI SAYA. Terutama karena dia tidak bisa mengosongkan file sekarang - apakah Anda pikir mungkin ada hal lain di dalamnya selain meja kerja yang dikeluhkan oleh pesan kesalahan? Kesalahan tidak menghasilkan daftar lengkap dari semua objek, itu hanya menampilkan objek pertama .

— Aaron Bertrand

Ada sesuatu yang sebenarnya menggunakan tempdb sehingga tidak memungkinkan untuk mengosongkan file-nya sulit ditebak. Mungkin dia menggunakan operator semacam ini adalah beberapa permintaan yang masih membutuhkan tempdb. DMV dapat membantu dalam menemukan sys.dm_db_task_space_usage sys.dm_db_session_space_usage sys.dm_db_file_spile_usage

— Shanky

Restart adalah pilihan di sini tetapi bahkan jika dia tidak mengosongkan file dan mencoba menjatuhkan file tempdb itu akan mengatakan file tempdb tidak dapat dijatuhkan tetapi pada saat yang sama sistem katalog diperbarui dan setelah restart file akan hilang. Ini saya kira perilaku default dengan tempdb jadi saya menyarankan dan masih berpikir menghapus file data akan berfungsi bahkan jika digunakan. Hal yang sama ada di tautan yang saya posting di komentar kedua saya.

— Shanky

@Shanky DMV tersebut dapat mengembalikan ribuan baris untuk semua hal yang tidak ada hubungannya dengan file yang dimaksud - jadi bagaimana Anda berencana mempersempitnya? Juga karena dengan metode Anda, Anda harus memulai ulang juga, mengapa tidak mencoba cara yang lebih sederhana dulu? Saya hanya tidak setuju dengan Anda bahwa "jalan yang sulit" harus menjadi saran pertama, maaf.

— Aaron Bertrand

https://social.msdn.microsoft.com/Forums/en-US/2a00c314-f35e-4900-babb-f42dcde1944b/dbcc-shrinkfile-page-41128343400-bisa- tidak- dipindahkan-karena-akan-adalah- a-work-table-page? forum = sqldatabaseengine

Seperti yang diusulkan oleh Mike di forum msdn, tabel kerja sebagian besar terkait dengan cache paket. Menghapusnya akan menghapus meja kerja juga dan kemudian Anda dapat menyusutkan Tempdb. Ini berhasil untuk saya. Dan ini menghemat server Anda restart juga. Akan ada beberapa overhead karena SQL server harus membuat ulang rencana eksekusi lagi.

— sajeesh
sumber