İkincil veri dosyalarını kaldırma. DBCC SHRINKFILE: Sayfa, çalışma tablosu sayfası olduğu için taşınamadı

İçin oluşturulmuş çok fazla ikincil veri dosyam (.ndf) var tempdb. Fazla dosyaları kaldırmak için dosyayı boşaltmam gerekiyor (içerik diğer dosyalara taşınacak):

DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);

ve sonra dosyayı silin:

ALTER DATABASE tempdb REMOVE FILE tempdbfile8;

Ancak EMPTYFILEkomut hatayı döndürür:

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.

Endişelenmeyin, sadece bu sayfayı kullanan bir nesneyi bulmam gerekiyor:

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

Komut, aralarında object_id olan birçok bilgi döndürür. Fakat:

Metadata: ObjectId = 0

Bu konuda ne yapacağım hakkında hiçbir fikrim yok. Hangi kedi bu sayfanın taşınmasını engelliyor? Bu nesne, süreç, oturum ya da her neyse nasıl bulunur? Herhangi bir yardım takdir edilecektir, ancak her şeyi olduğu gibi bırakmanın veya başka bir dosyayı kaldırmanın bu soruna geçerli bir çözüm olmadığını lütfen unutmayın.).

DÜZENLE:

Dosyaları kaldırıyorum, çünkü işlemci çekirdeği başına (aynı başlangıç boyutu, aynı büyüme hızı) bir dosya oluşturmanın "en iyi uygulamasını" takip ediyorduk. Ancak bildiğim kadarıyla, çekişme sorunlarıyla karşılaşana kadar, aynı cihazda ek tempdb dosyaları oluşturmanın bir anlamı yok. Bizim durumumuzda mantıklı, çünkü MPIO açık ve depolama cihazı 4 yolu işleyebilir. Ancak bir hata oluştu ve 6 çekirdekli işlemci ile toplam 5 dosya ile sonuçlandık. MPIO yollarından daha fazla, CPU çekirdeklerinden daha az ve çift bir sayı değil. Herhangi bir soruna neden olmayabilir, ancak doğru görünmüyor :).

Sonunda tek bir kullanıcı moduna (geri alma anında) veri veritabanlarından birini (soruna neden olduğundan şüphelendiğim) ayarlayarak sunucuyu yeniden başlatmadan dosyayı boşaltmayı ve kaldırmayı başardım. İşe yaradı, ama şanslıydım. Gerçekten istediğim, sayfayı her zaman takip edebilmektir :).

— Adam Luniewski
kaynak

DBCC PAGE komutu doğru değil, dbcc sayfası (2,41920,1) gibi olmalıdır. 1,2,3, çıktıda ne istediğinize bağlıdır.

— Shanky

Yukarıdaki işe yaramazsa, dosyaları silerek ve ardından silinmemiş dosyaları kullanması için sql sunucusunu yeniden başlatarak donanımda yapmanız gerekebilir. Bu bağlantıya başvurabilir misiniz daveturpin.com/2011/07/how-to-drop-a-tempdb-database-file

— Shanky

@Shanky Komut doğru. 0..3 4. parametre olarak geçebilir: dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])Çözümünüz hakkında: işe yarayacaktı, ancak bunu örneği indirmeden gerçekten yapmak istiyorum.

— Adam Luniewski

Tamam .. Sana dbcc sayfasının daha basit bir biçimini söylüyordum. Lütfen not belgesiz komuttur.

— Yayınladığım

Örneği yeniden başlatmadan bu sorunu çözmenin mümkün olduğunu düşünmüyorum. Açıkçası, bu çalışma masasının ne olduğunu izlemeye çalıştınız (ki buna kimin sahip olduğunu belirlemeye yardımcı olacak) ve bu başarısız oldu. Yeniden başlayıncaya kadar isabet alın veya fazladan dosyalarla yaşayın.

— Aaron Bertrand

Yanıtlar:

Sunucuyu yeniden başlatmak yeterli olmalıdır - bu çalışma masaları temizlenmelidir. Ancak, bu dosyaları başarıyla kaldırmadan önce diğer işlemlerin çalışma masası oluşturmasını önlemek için muhtemelen tek kullanıcı modunda (-m) başlatırım . Sonra için gerekli dosyaları yeniden tanımlayın tempdb; gereksiz dosyaları silme, boyutları değiştirme, vb. Ayrıca, eşit sayıda dosyaya sahip olduğunuzdan, hepsinin aynı boyuta ayarlandığından ve hepsinin aynı otomatik büyüme ayarlarına sahip olduklarından (% değil MB olarak) emin olmalısınız. TF 1117 ve TF 1118'i de dikkate almak iyi bir zaman olabilir ( başlangıç noktası ).

SQL Server'ı yeniden başlatmadan önce sadece dosyaları dosya sisteminden silmek için öneri konusunda çok dikkatli olurum - hiç başlamayabilir.

(Yine de asıl sorunun ne olduğunu merak ediyorum. Çok fazla dosyaya sahip olmak sana zarar vermez.)

— Aaron Bertrand
kaynak

Tabii ki Aaron'un kaldırılması konusunda dikkatli olmanız gerekir, ancak boş olmalıdır, ancak burada belgelenmiştir msdn.microsoft.com/en-gb/library/ms175574.aspx . Denedim ve SQl Server tempdb çevrimiçi geliyor.

— Shanky

@Shanky Saatte 138 mil sürmeye çalıştım ve çekilmedim. Bu, yapmaya devam etmem gerektiği ve yarın ele geçirilme şansım olmadığı anlamına mı geliyor? Daha riskli bir yol önermeden önce ilk önce doğru yolu denemek çok daha güvenli . BENİM NACİZANE FİKRİME GÖRE. Özellikle dosyayı şimdi boşaltamadığından - hata mesajının şikayet ettiği çalışma masasının yanında başka bir şey olabileceğini düşünüyor musunuz? Hata, tüm nesnelerin kapsamlı bir listesini oluşturmaz, yalnızca ilk nesneyi çıktılar .

— Aaron Bertrand

Aslında tempdb kullanan bir şey var, bu yüzden tahmin etmek zor dosyayı boşuna izin vermiyor. Sıralama işleci hala tempdb ihtiyacı olan bazı sorgu olduğunu kullandı. DMV, sys.dm_db_task_space_usage bulmasında yardımcı olabilir sys.dm_db_session_space_usage sys.dm_db_file_space_usage

— Shanky

Yeniden başlatma seçeneği buradadır, ancak dosyayı boşaltmaz ve tempdb dosyasını bırakmayı denemese bile tempdb dosyası bırakılamaz, ancak aynı zamanda sistem kataloğu güncellenir ve yeniden başlatıldıktan sonra dosya gider. Ben tempdb ile varsayılan davranış sanırım bu yüzden önerdi ve hala kullanılsa bile veri dosyasını kaldırma işe yarayacağını düşünüyorum. Aynı şey benim ikinci yorumda gönderdiğim bağlantıda da var.

— Shanky

@ Bu DMV'lerin söz konusu dosyayla hiçbir ilgisi olmayan her türlü şey için binlerce satır döndürebildiğinden, onu nasıl daraltmayı planlıyorsunuz? Ayrıca yönteminizle de yeniden başlatmanız gerektiğinden, neden sadece daha basit olanı denemiyorsunuz? Sadece "zor yolun" ilk öneri olması gerektiğine katılıyorum, üzgünüm.

— Aaron Bertrand

https://social.msdn.microsoft.com/Forums/en-US/2a00c314-f35e-4900-babb-f42dcde1944b/dbcc-shrinkfile-page-411283400-could-not-be-moved-because-it-is- a-iş-masa sayfalık? forumu = sqldatabaseengine

Mike'ın msdn forumunda önerdiği gibi, çalışma tabloları çoğunlukla plan önbelleği ile ilişkilidir. Onları temizlemek çalışma masasını da kaldırır ve Tempdb'yi küçültebilirsiniz. Bu benim için çalıştı. Bu da sunucunun yeniden başlatılmasını sağlar. SQL Server yürütme planlarını yeniden oluşturmak zorunda kalacağından bazı ek yükler olacaktır.

— sajeesh
kaynak