Saya tidak bagus dalam SQL, tapi saya punya database untuk dipelihara.
Hampir tidak ada tempat yang tersisa untuk itu, jadi saya telah memutuskan untuk menghapus semua data untuk, katakanlah, tahun 2008. Setelah menjalankan permintaan hapus (telah membersihkan sekitar 10.000 000 baris) dan membersihkan log transaksi, saya menemukan bahwa tindakan tidak berpengaruh pada ukuran basis data. Apakah ada hal lain yang harus saya lakukan?
Jawaban:
Menyusut memang berbahaya karena alasan yang disebutkan di sini. Ada media bahagia antara jawaban Jimbo dan jawaban John ... Anda harus selalu mempertimbangkan dengan serius apakah Anda ingin mengecilkan database Anda atau tidak.
Di dunia yang ideal - Anda akan menciptakan DB dengan banyak ruang bebas untuk berkembang. Saya menyebut ini "Ukuran Benar" database Anda. Anda akan membiarkan ruang kosong ini ada di sana dan tidak berusaha untuk mengembalikannya dan menjaga ukuran total Anda tepat pada ukuran yang Anda gunakan .. Mengapa? Karena database Anda pada akhirnya akan tumbuh lagi .. Kemudian Anda akan menyusut lagi .. Dan Anda akan terjebak dalam pola menyusut tidak berguna yang diikuti oleh pertumbuhan - dan sepanjang waktu, seperti yang telah ditunjukkan beberapa orang, Anda akan meningkatkan fragmentasi indeks Anda.
Saya telah membuat blog tentang hal ini di mana saya menasihati orang-orang untuk " Jangan sentuh tombol menyusut itu! " Tapi kadang-kadang ... Kadang-kadang Anda perlu. Jika Anda memiliki database besar, hanya membebaskan ruang yang signifikan dan jangan berharap untuk tumbuh kembali ke dalamnya - yah, maka boleh saja untuk mempertimbangkan penyusutan sebagai operasi satu kali selama Anda dapat mengurus fragmentasi indeks Anda kemudian melalui pembangunan kembali mereka. Operasi menyusut dapat memakan waktu sehingga Anda ingin merencanakannya untuk waktu di mana Anda dapat membayar harga penyusutan itu. Pendekatan membuat DB kosong dan menyalin data ke dalamnya berfungsi - tetapi itu bisa menjadi sangat sulit dengan database yang lebih besar dan banyak data.
Jika Anda berencana menambahkan ruang itu kembali ke DB melalui penggunaan normal dan pola pertumbuhan ke masa depan, maka Anda mungkin hanya ingin meninggalkan ruang di sana.
Juga
Anda bilang Anda "membersihkan" log transaksi Anda. Saya ingin tahu bagaimana Anda melakukan ini tetapi ketika Anda membaca posting yang saya bagikan dan yang lain dalam seri ini Anda akan melihat beberapa tips tentang manajemen log transaksi. Namun singkatnya - jika Anda berada dalam mode Pemulihan Penuh, Anda harus mengambil cadangan log biasa untuk menjaga agar log tersebut dapat digunakan kembali. Jika tidak - tanpa cadangan log saat dalam Mode Penuh - file log terus tumbuh dan tumbuh dan tumbuh dan selalu menyimpan apa yang telah Anda lakukan karena Anda memberi tahu SQL Anda tidak hanya ingin mempertahankan log itu untuk pemulihan kerusakan tetapi ingin menyimpan cadangan manual untuk memutar ulang transaksi / membatalkan transaksi untuk memulihkan ke titik waktu tertentu untuk tujuan pemulihan ... Jika Anda sederhana dan melihat log tumbuh berlebihan,BEGIN TRAN ... do work.... COMMIT TRANatau apakah Anda baru saja mengeluarkan satu DELETEpernyataan besar dan menghapus seluruh kekacauan data dalam satu transaksi implisit.)
Saya juga berasumsi bahwa Anda mencari ruang kosong ini di sistem file Anda. Jika Anda mencari di dalam SQL dan di dalam file besar yang Anda miliki - bisa jadi Anda sedang menunggu pembersihan hantu untuk menyelesaikan jika mencari segera setelah operasi Anda. Paul Randal menulis blog tentang Pembersihan Hantu .
Menghapus baris dalam basis data tidak akan mengurangi ukuran file basis data yang sebenarnya.
Anda harus memadatkan database setelah penghapusan baris.
SQL Server 2005 DBCC SHRINKDATABASE (Transact-SQL)
Setelah menjalankan ini, Anda ingin membangun kembali indeks. Penyusutan biasanya menyebabkan indeks fragmentasi, dan itu bisa menjadi biaya kinerja yang signifikan.
Saya juga merekomendasikan bahwa setelah Anda mengecilkan, Anda menumbuhkan kembali file sehingga Anda memiliki beberapa ruang kosong. Dengan begitu, ketika baris baru masuk, mereka tidak memicu autogrowth. Autogrowth memiliki biaya kinerja dan merupakan sesuatu yang ingin Anda hindari (melalui ukuran basis data yang tepat) bila memungkinkan.
JANGAN MENGERIKAN DATABASE ANDA!
"Mengapa ini terjadi? Operasi penyusutan file data bekerja pada satu file pada satu waktu, dan menggunakan bitmap GAM (lihat Di dalam Mesin Penyimpanan: GAM, SGAM, PFS dan peta alokasi lainnya) untuk menemukan halaman tertinggi yang dialokasikan dalam Kemudian memindahkannya sejauh mungkin ke arah depan file, dan seterusnya, dan seterusnya. Dalam kasus di atas, itu benar-benar membalik urutan indeks berkerumun, mengambilnya dari defragmentasi sempurna menjadi terfragmentasi sempurna. "
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
"Lihatlah ironi dari database Shrinking. Satu orang menyusutkan database untuk mendapatkan ruang (berpikir itu akan membantu kinerja), yang mengarah pada peningkatan fragmentasi (mengurangi kinerja). Untuk mengurangi fragmentasi, satu indeks membangun kembali, yang mengarah ke ukuran database meningkat jauh lebih besar daripada ukuran asli database (sebelum menyusut). Nah, dengan Shrinking, orang tidak mendapatkan apa yang biasanya ia cari. "
Saat Anda menghapus data, SQL Server menyimpan ruang untuk digunakan nanti untuk memasukkan data baru. Anda perlu mengecilkan basis data. Anda dapat menemukan informasi lebih lanjut di sini .
Saya menemukan ini karena saya baru saja menghapus banyak tabel cadangan karena database saya telah "maxed out". Saya terus melihat properti "Ukuran", berpikir mengapa ini tidak semakin kecil? . Setelah membaca ini, tidak, saya tidak ingin menyusutkan database. Yang ingin saya lakukan adalah "merebut kembali" ruang untuk sampah yang baru saja saya hapus. Yang perlu saya perhatikan adalah "Ruang Yang Tersedia". Saya berpikir mungkin itu yang orang lain mungkin perlu melihat itu juga .?*
Perlu dicatat juga bahwa jika tabel memiliki indeks di atasnya, fragmentasi dapat ada setelah menghapus petak besar data. Saya memiliki meja hari ini yang memiliki ~ 70 juta catatan di dalamnya yang mengambil sekitar 13GB. Saya membersihkannya hingga 1639 catatan (sisanya dihasilkan oleh satu bug) tetapi meja masih memakan sekitar 4,5GB. Setelah saya membangun kembali semua indeks di atas meja, hanya butuh 85 halaman (680kb). Setelah itu, saya menggunakan shrinkfile tambahan untuk merebut kembali ruang (dan memperbaiki bug pada sistem untuk mencegah pengulangan).