Pernahkah Anda secara tidak sengaja mengeksekusi TRUNCATE perintah di meja yang salah? Ini akan menyebabkan semua kehilangan data. Yang terburuk adalah Anda tidak akan memiliki kesempatan untuk mendapatkan kembali data Anda. Dalam artikel ini, kita akan melihat bagaimana menghindari situasi seperti itu dan memiliki kesempatan untuk ROLLBACK TRUNCATE .
Anda tidak dapat ROLLBACK TRUNCATE
Sederhananya, Anda tidak dapat mengembalikan transaksi jika transaksi sudah dilakukan tetapi Anda dapat melakukan hal lain untuk mendapatkan kembali datanya (atau setidaknya sebagian darinya).
Saat Anda menjalankan TRUNCATE pernyataan, data Anda masih dalam file MDF. Namun, itu tidak terlihat karena SQL Server memperlakukan ini sebagai ruang kosong (TRUNCATE memberitahu SQL Server untuk membatalkan alokasi halaman data).
Satu-satunya cara untuk mendapatkan kembali data adalah dengan membaca halaman data yang tidak dialokasikan dan mengubahnya menjadi data yang dapat dibaca.
Anda harus bertindak cepat karena ruang kosong akan ditimpa dengan data baru jika belum. Jika Anda dapat menghentikan instans SQL Server dan membuat salinan file MDF dan LDF yang akan memberi Anda lebih banyak waktu.
Ada beberapa alat yang dapat melakukan pemulihan semacam ini.
Anda dapat ROLLBACK MEMOTONG
POTONGKAH adalah operasi yang dicatat, tetapi SQL Server tidak mencatat setiap baris karena memotong tabel. SQL Server hanya mencatat fakta bahwa TRUNCATE operasi terjadi. Itu juga mencatat informasi tentang halaman dan luasan yang tidak dialokasikan. Namun, ada cukup informasi untuk memutar kembali, hanya dengan mengalokasikan kembali halaman-halaman itu. Cadangan log hanya memerlukan informasi yang TRUNCATE TABLE muncul. Untuk memulihkan TRUNCATE TABLE , operasi baru saja diterapkan kembali. Data yang terlibat tidak diperlukan selama RESTORE (seperti untuk operasi 'minimal login' yang sebenarnya seperti MASUKKAN BULK ).
SQL Server tahu halaman mana yang menjadi milik tabel sejauh mereka dikunci dengan kunci eksklusif, dan seperti semua kunci X, mereka ditahan hingga akhir transaksi. Itulah sebabnya halaman atau ekstensi tidak dapat dibatalkan alokasinya, dan tentu saja, tidak dapat digunakan kembali.
Ini contohnya:
Kami mendapat hitungan 504 baris dan sejumlah halaman. Sekarang kita akan melihat jumlah baris, dan halaman yang termasuk dalam tabel.
BEGIN TRAN
TRUNCATE TABLE dbo.Products;
SELECT COUNT(*) FROM dbo.Products;
DBCC IND('AdventureWorks', 'Products', -1);
DBCC EXTENTINFO('AdventureWorks', 'Products', -1);
SELECT resource_type, resource_description,
request_mode FROM sys.dm_tran_locks
WHERE resource_type IN ('EXTENT', 'PAGE')
AND resource_database_id = DB_ID('AdventureWorks');
Anda tidak akan melihat baris dari DBCC IND , dan 0 baris dari count(*). Info kunci mengembalikan berikut ini:
resource_type resource_description request_mode
————- ——————– ————
EXTENT 1:33352 X
HALAMAN 1:42486 X
EXTENT 1:42488 X
HALAMAN 1:42487 X
HALAMAN 1:42488 X
HALAMAN 1:42489 X
HALAMAN 1:23027 X
HALAMAN 1:23030 X
HALAMAN 1:23029 X
HALAMAN 1:26992 X
HALAMAN 1:26993 X
Luas dan penguncian laman mencakup semua laman yang kami lihat di DBCC IND keluaran. Hanya setelah Anda ROLLBACK transaksi akan kuncinya dilepaskan, dan Anda akan melihat semua baris dan halaman kembali di atas meja lagi.
ROLLBACK TRAN;
GO
SELECT COUNT(*) FROM dbo.Products;
DBCC IND('AdventureWorks', 'Products', -1);
GO
Hati-hati dan selalu bungkus pernyataan tabel TRUNCATE dalam transaksi.
