Perilaku aneh DBCC Shrinkfile


9

Saya mencoba menjalankan shrinkfile dbcc dalam potongan 1GB terhadap database di mana 95% dari data telah diarsipkan dan dihapus. Saya leaft dengan file 235GB di mana 9GB adalah data / indeks. Saya ingin mengecilkan ini hingga 50GB. Saya tahu bahwa menyusutkan file basis data buruk, menyebabkan fragmentasi dll. Sebagai bagian dari pembersihan data / penyusutan, kami juga memiliki skrip idnex yang dibangun kembali.

Ketika saya menjalankan skrip shrinkfile dbcc saya terhadap database di workstation saya sendiri (quad core, 12GB RAM, 2 x SATA drive), psikiater itu memakan waktu sekitar 8-10 menit.

Saat menjalankan kode yang identik terhadap salinan identik dari pembersihan data pos basis data, dalam lingkungan pengujian kami, (80+ core, 128GB RAM, SSD SAN), dibutuhkan 70 menit. Untuk diketahui, ada sedikit aktivitas pada server ini pada saat file menyusut berjalan. Telah dijalankan 4 kali dengan hasil yang identik.

Saya kemudian mengambil pendekatan yang berbeda, yaitu memindahkan 9GB yang tersisa ke filegroup dan file fisik yang berbeda. Menjalankan dbcc shrinkfile pada file 230GB yang kosong untuk mengecilkannya menjadi 50GB, di stasiun kerja saya sendiri membutuhkan waktu <1 menit.

Dengan pendekatan yang sama ini, pada lingkungan pengujian, sekali lagi diperlukan waktu lebih dari 70 menit.

Saya telah mengambil snapshot dari waitstats sebelum dan sesudah skrip Brent Ozar selama 70 menit berjalan di lingkungan pengujian, dan waittypes kembali menunjukkan tidak ada yang perlu dikhawatirkan. 3 baris teratas di bawah ini:

Waktu Sampel Kedua Durasi Sampel dalam Detik wait_type Waktu Tunggu (Detik) Jumlah Waktu Tunggu Rata-rata ms Per Tunggu
2013-05-28 11: 24: 22.893 3600 WRITELOG 160.8 143066 1.1
2013-05-28 11: 24: 22.893 3600 CXPACKET 20.9 13915 1.5
2013-05-28 11: 24: 22.893 3600 PAGELATCH_EX 11.1 443038 0.0

Log peristiwa Windows tidak menunjukkan apa pun yang tidak biasa. Saya sedang menuju menggaruk pada titik ini, mengapa butuh waktu lama pada perangkat keras ninja, dibandingkan dengan workstation mandiri saya.


Periksa database dan kemudian coba.
Kin Shah

bersihkan statistik kait sebelum menyusut dan tangkap mereka setelah shrnik, pada kedua mesin. sys.dm_os_latch_stats
Remus Rusanu

Juga, @@versionpada keduanya
Remus Rusanu

Apakah data yang dihapus data gumpalan atau data normal? Salinan di workstation Anda dihapus di sana atau apakah Anda membuat cadangan sistem QA setelah dihapus lalu mengembalikannya ke mesin Anda?
mrdenny

Jawaban:


4

Shrinkfile pada datafile adalah operasi single-threaded, menggunakan kembali buffer memori kecil.

Jadi perangkat keras Ninja tidak memiliki keunggulan dengan memori tambahan dan 80 core.

Namun PC lokal Anda memiliki manfaat latensi I / O lokal (disk lokal, yaitu tidak harus melakukan beberapa perjalanan ke SAN).

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.