Log transaksi adalah komponen penting dan vital dari arsitektur database. Dalam artikel ini, kita akan membahas log transaksi SQL Server, kepentingannya, dan perannya dalam migrasi database.
Pengantar
Mari kita bicara tentang berbagai opsi untuk mengambil cadangan SQL Server. SQL Server mendukung tiga jenis Cadangan yang berbeda.
1. Penuh
2. Diferensial
3. Log transaksi
Sebelum masuk ke konsep log transaksi, mari kita bahas jenis pencadangan dasar lainnya di SQL Server.
Cadangan lengkap adalah salinan dari segalanya. Seperti namanya, itu akan mencadangkan semuanya. Ini akan mencadangkan semua data, setiap objek basis data seperti file, grup file, tabel, dll:– Cadangan lengkap adalah dasar untuk jenis pencadangan lainnya.
Pencadangan diferensial akan mencadangkan data yang telah diubah sejak pencadangan penuh terakhir.
Opsi ketiga adalah Backup Log Transaksi, yang akan mencatat semua pernyataan yang kita keluarkan ke database di log transaksi. Log transaksi adalah mekanisme yang dikenal sebagai “WAL” (Write-Ahead-Logging). Itu menulis setiap informasi ke log transaksi terlebih dahulu dan kemudian ke database. Dengan kata lain, proses biasanya tidak memperbarui database secara langsung. Ini adalah satu-satunya opsi lengkap yang tersedia dengan model pemulihan penuh database. Dalam model pemulihan lainnya, data sebagian atau tidak ada cukup data di log. Misalnya, catatan log saat merekam awal transaksi baru (catatan log LOP_BEGIN_XACT) akan berisi waktu transaksi dimulai, dan catatan log LOP_COMMIT_XACT (atau LOP_ABORT_XACT) akan mencatat waktu transaksi dilakukan (atau dibatalkan).
Untuk menemukan internal Log Transaksi online, Anda dapat menanyakan fungsi sys.fn_dblog.
Fungsi sistem sys.fn_dblog menerima dua parameter, pertama, mulai LSN dan akhiri LSN transaksi. Secara default, ini diatur ke NULL. Jika disetel ke NULL, itu akan mengembalikan semua catatan log dari file log transaksi.
USE WideWorldImporters GO SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], [Log Record Fixed Length], [Log Record Length] [Transaction SID], [SPID], [Begin Time], * FROM fn_dblog(null,null)
Seperti yang kita semua tahu, transaksi disimpan dalam format biner dan tidak dalam format yang dapat dibaca. Untuk membaca file log transaksi offline, Anda dapat menggunakan fn_dump_dblog.
Mari kita kueri file log transaksi untuk melihat siapa yang telah menjatuhkan objek menggunakan fn_dump_dblog.
SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], SUSER_SNAME ([Transaction SID]) AS DBUser
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
Context IN ('LCX_NULL') AND Operation IN ('LOP_BEGIN_XACT')
AND [Transaction Name] LIKE '%DROP%'
Kami akan menggunakan fungsi fn_dblog() untuk membaca bagian aktif dari log transaksi untuk menemukan aktivitas yang dilakukan pada data . Setelah log transaksi dihapus, Anda harus menanyakan data dari file log menggunakan fn_dump_dblog().
Fungsi ini menyediakan rowset yang sama dengan fn_dblog(), tetapi memiliki beberapa fungsi menarik yang membuatnya berguna adalah beberapa skenario pemecahan masalah dan pemulihan. Secara khusus, ia tidak hanya dapat membaca log transaksi dari database saat ini, tetapi juga cadangan log transaksi pada disk atau tape.
Untuk mendapatkan daftar objek yang dijatuhkan menggunakan file transaksi, jalankan kueri berikut. Awalnya, data dibuang ke tabel temp. Dalam beberapa kasus, eksekusi fun_dump_dblog() membutuhkan waktu lebih lama untuk dieksekusi. Jadi, lebih baik untuk menangkap data di tabel temp.
Untuk mendapatkan ID objek dari kolom Informasi Kunci, jalankan kueri berikut.
SELECT * INTO TEMP FROM fn_dump_dblog ( NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn', DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) WHERE [Transaction ID] in( SELECT DISTINCT [Transaction ID] FROM fn_dump_dblog ( NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn', DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) WHERE [Transaction Name] LIKE '%DROP%') and [Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%'
Untuk mendapatkan ID objek dari kolom Informasi Kunci, jalankan kueri berikut.
SELECT DISTINCT [Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4,
Substring([Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4) objectid
from temp
Object_id dapat ditemukan dengan memanipulasi nilai kolom Informasi Kunci. Untuk menemukan nama objek untuk id objek yang sesuai, pulihkan database dari cadangan tepat sebelum tabel dijatuhkan. Setelah pemulihan, Anda dapat menanyakan tampilan sistem untuk mendapatkan nama objek.
USE AdventureWorks2016; GO SELECT name, object_id from sys.objects WHERE object_id = '1815677516';
Sekarang, mari kita lihat berbagai bentuk detail transaksi yang sama menggunakan sys.dn_dblog, sys.fn_full_dblog. Fungsi sistem fn_full_dblog hanya berfungsi dengan SQL Server 2017.
Kueri untuk mengambil 10 transaksi teratas menggunakan fn_dblog.
SELECT TOP 10 * FROM sys.fn_dblog(null,null)
Dari SQL Server 2017 dan seterusnya, Anda dapat menggunakan fn_full dblog.
SELECT TOP 10 * FROM sys.fn_full_dblog(null,null,DB_ID(),null,null,null,null,NULL)
Anda dapat mempelajari lebih lanjut fungsi sistem menggunakan sp_helptext fn_full_dblog.
Selanjutnya, kueri file cadangan menggunakan fungsi sistem menggunakan fn_full_dblog. Sekali lagi, ini hanya berlaku dari SQL Server 2017 dan seterusnya.
Pemulihan tepat waktu
Mari kita asumsikan bahwa Anda memiliki daftar seluruh cadangan log, dan kemudian ketika Anda berniat untuk memulihkan log, Anda memiliki kemungkinan untuk melakukan pemulihan data secara tepat waktu. Jadi, dalam proses pemulihan log, Anda tidak perlu memulihkan semua data, Anda dapat memulihkannya hingga, sebelum atau setelah transaksi individual. Jadi, jika database mogok pada waktu tertentu, dan kami memiliki cadangan lengkap dan cadangan log, kami harus dapat memulihkan cadangan lengkap terlebih dahulu dan kemudian memulihkan cadangan log, dan dalam prosesnya, memulihkan log terakhir hingga waktu tertentu , dan itu akan membuat database tetap dalam keadaan sebelum masalah ini terjadi.
Cadangan log adalah VLDB (Basis Data Sangat Besar) yang cukup umum dan basis data paling penting. Itu selalu disarankan untuk menguji proses pemulihan. Setiap kali Anda melakukan backup database, disarankan untuk memikirkan proses restore dengan baik, dan Anda harus selalu menguji proses restore lebih sering.
Itu selalu baik untuk meringankan pengujian proses pemulihan dari waktu ke waktu, jadi pastikan proses berjalan melalui backup secara normal.
Skenario
Mari kita bicara tentang sebuah skenario, ketika Anda perlu memulihkan database yang sangat besar dan kita semua tahu itu biasanya bisa memakan waktu beberapa jam, dan itu adalah sesuatu yang harus diperhatikan semua orang. Jika Anda berencana untuk migrasi database tanpa kehilangan data dan jendela pemadaman yang lebih kecil, itu masih bisa menjadi masalah yang cukup besar. Jadi, pastikan Anda mengandalkan pencadangan log Transaksi untuk mempercepat proses.
Mari kita pertimbangkan skenario lain di mana Anda melakukan migrasi database berdampingan antara dua versi SQL Server yang berbeda; Anda terlibat dalam migrasi database ke versi perangkat lunak yang sama pada target dan itu termasuk transfer sistem operasi, database, aplikasi, dan jaringan dll:-; migrasi database dari satu perangkat keras ke perangkat keras lainnya; mengubah perangkat lunak dan perangkat keras. Proses migrasi database selalu menjadi tantangan di mana kehilangan data selalu mungkin terjadi dan tunduk pada lingkungan.
Praktik terbaik migrasi Database
Mari kita bahas praktik standar manajemen migrasi database.
Migrasi harus dilakukan secara transaksional untuk menghindari inkonsistensi data. Langkah-langkah biasa dari proses migrasi secara konvensional adalah sebagai berikut:
- Hentikan layanan aplikasi—di sinilah waktu henti dimulai
- Memulai pencadangan log, tergantung kebutuhan Anda
- Letakkan database dalam mode pemulihan sehingga tidak ada perubahan lebih lanjut pada database
- Pindahkan file log
- Pulihkan database File log transaksi—asalkan, Anda telah memulihkan database cadangan penuh sesuai target dan membiarkan database dalam kondisi pemulihan.
- Klon login dan perbaiki pengguna yatim piatu
- Buat Pekerjaan
- Instal aplikasi
- Konfigurasi jaringan – Ubah entri DNS
- Konfigurasi ulang setelan aplikasi
- Mulai layanan aplikasi
- Uji aplikasi
Memulai
Pada artikel ini, kita akan membahas cara menangani migrasi database OLTP yang sangat besar. Kami akan membahas strategi untuk menggunakan teknik SQL server dan alat pihak ke-3 untuk keamanan data bersama dengan nol atau gangguan minimal pada ketersediaan sistem produksi. Selama proses tersebut, selalu ada peluang untuk kehilangan data. Apakah Anda pikir penanganan transaksi yang mulus adalah strategi yang baik? Jika “ya”, apa pilihan favorit Anda?
Mari kita mendalami opsi yang tersedia:
- Cadangkan dan Pulihkan
- Log pengiriman
- Pencerminan basis data
- Alat pihak ketiga
Cadangkan dan Pulihkan
Teknik database Backup-and-Restore adalah opsi yang paling layak untuk migrasi database apa pun. Jika direncanakan dan diuji dengan benar, kami akan menghindari banyak kesalahan migrasi yang tidak terduga. Kita semua tahu bahwa pencadangan adalah proses online, mudah untuk memulai pencadangan log Transaksi pada waktu yang tepat untuk mempersempit jumlah transaksi yang akan dipasok ke database baru. Selama jendela migrasi, kami dapat membatasi pengguna untuk mengakses database dan memulai satu pencadangan log terakhir dan mentransfernya ke tujuan. Dengan cara ini, waktu henti dapat dipersingkat secara signifikan.
Pengiriman log
Kita semua memahami pentingnya file log di dunia database. Teknik pengiriman log menawarkan solusi pemulihan bencana yang baik dan mendukung akses baca-saja terbatas ke database sekunder, selama interval antara pekerjaan pemulihan. Ini pada dasarnya adalah konsep mencadangkan log transaksi dan diputar ulang pada cadangan penuh pada satu basis data sekunder lagi. Basis data sekunder ini adalah salinan duplikat dari basis data utama dan terus-menerus memulihkan cadangan log transaksi ke salinannya sendiri, agar tetap sinkron dengan basis data utama. Karena database sekunder berada pada perangkat keras yang terpisah, jika terjadi kegagalan primer karena alasan apa pun, salinan sistem yang dicadangkan sepenuhnya segera tersedia untuk digunakan dan lalu lintas jaringan dapat dengan mudah dialihkan ke server sekunder, tanpa ada pengguna yang mengetahui bahwa kesalahan telah terjadi. Pengiriman log menyediakan cara yang mudah dan efektif untuk mengelola migrasi ke tingkat yang lebih tinggi di sebagian besar kasus.
Pencerminan
Pencerminan Basis Data juga merupakan opsi untuk migrasi basis data asalkan sumber dan target memiliki versi dan edisi yang sama. Pada dasarnya, mirroring membuat dua salinan duplikat database pada dua instance perangkat keras. Transaksi akan terjadi pada kedua database secara bersamaan. Anda memiliki kemampuan untuk membuat database produksi offline, beralih ke versi cermin dari database tersebut, dan memungkinkan pengguna untuk terus mengakses data seolah-olah tidak ada yang terjadi. Dalam penerapannya, kami berurusan dengan server utama, server cermin, dan saksi. Tapi itu akan menjadi fitur yang tidak digunakan lagi dan akan dihapus dari versi SQL Server yang akan datang.
Ringkasan
Dalam artikel ini, kami membahas jenis pencadangan, pencadangan log transaksi secara detail, standar migrasi data, proses, dan strategi, mempelajari teknik SQL untuk penanganan langkah migrasi data yang efektif.
Mekanisme penulisan log transaksi WAL memastikan bahwa transaksi selalu ditulis ke file log terlebih dahulu. Dengan cara ini, SQL Server menjamin efek dari semua transaksi yang dilakukan pada akhirnya akan ditulis dalam file data (ke disk), dan bahwa setiap modifikasi data pada disk yang berasal dari transaksi yang tidak lengkap akan ROLLBACK dan tidak tercermin dalam file data.
Dalam sebagian besar kasus, penundaan sinkronisasi data tidak terduga dan kehilangan data bersifat permanen. Lebih sering daripada tidak, semuanya tergantung pada ukuran database dan infrastruktur yang tersedia. Sebagai praktik yang direkomendasikan, lebih baik menjalankan migrasi secara manual daripada sebagai bagian dari penerapan untuk menjaga hal-hal terpisah sehingga keluaran dapat lebih dapat diprediksi.
Secara pribadi, saya lebih suka pengiriman Log karena berbagai alasan:Anda dapat mengambil cadangan penuh data dari server lama jauh sebelumnya, memindahkannya ke server baru, memulihkannya, dan kemudian menerapkan sisa transaksi (cadangan t-log ) dari titik sampai dengan saat pemotongan. Prosesnya sebenarnya cukup sederhana.
Migrasi database tidak sulit jika dilakukan dengan cara yang benar. Saya harap postingan ini membantu Anda menjalankan migrasi database dengan lebih lancar.
