Mengapa sangat penting untuk membuat cadangan log transaksi Anda?

Kami saat ini menerapkan solusi cadangan untuk klien dan solusi ERP mereka menggunakan SQL Server.

Solusi ERP dibuat oleh perusahaan yang berbeda. Dan mereka mengatakan kepada saya bahwa sangat penting untuk membuat cadangan dan memotong log transaksi.

Saya sudah membaca sedikit pada log transaksi ini dan saya tidak mengerti mengapa ini sangat penting ketika saya sudah membuat cadangan seluruh mesin (Kami menggunakan ArcServe UDP, yang mengetahui SQL Server dan menggunakan VSS). Ini adalah pemahaman saya bahwa tugas pembersihan pada SQL Server VM sudah menangani pemotongan log, namun, UDP juga memungkinkan pemotongan log SQL Server.

Saya memahami bahwa log transaksi dapat digunakan untuk memulihkan database yang rusak, karena, well, ini adalah log dari semua transaksi. Tapi saya sudah punya cadangan per jam dari seluruh database, jadi, mengapa saya peduli?

Anda hanya perlu melakukan ini jika Mode Pemulihan DB Anda diatur ke "penuh". Jika disetel ke "sederhana" Anda tidak perlu membuat cadangan log transaksi. Tapi hati-hati terhadap perbedaan antara dua opsi ini!

Pertama-tama: Jika Anda ingin dapat mengembalikan DB ke titik waktu tertentu Anda harus menggunakan mode "penuh". (Saya pikir Anda dapat menyesuaikan waktunya begitu akurat sehingga Anda bahkan dapat menentukan milidetik untuk titik pemulihan) Dalam mode "sederhana" Anda hanya dapat kembali ke cadangan penuh terakhir .

Jika Anda tidak membuat cadangan / memotong log transaksi Anda, itu akan tumbuh sepanjang waktu (dalam mode penuh). Saya melihat database di mana file .trn lebih dari dua kali lebih besar dari database itu sendiri. Ini tergantung pada seberapa sering perubahan dilakukan pada DB.

Poin lain adalah bahwa cadangan log biasanya lebih cepat daripada cadangan penuh.

Jadi saya pikir rencana cadangan Anda untuk membuat cadangan penuh setiap jam tidak optimal. Tetapi itu tergantung pada situasi Anda:

Jika Anda berkata: Oke jika saya bisa mengembalikan DB ke jam penuh terakhir, semuanya baik-baik saja. -> Anda juga dapat berpikir tentang mengatur mode pemulihan ke "sederhana" jika Anda ingin menyimpan cadangan penuh setiap jam.

Menurut pendapat saya, ide yang lebih baik adalah membuat backup penuh di pagi hari dan kemudian melakukan backup log transaksi setiap jam. Seharusnya lebih cepat, dan Anda dapat mengembalikan ke titik waktu yang Anda inginkan. Dan juga file .trn Anda tidak akan tumbuh terlalu banyak ...

Semoga ini membantu.

Baik. Anda peduli karena jika model pemulihan Anda disetel penuh dan Anda tidak mencadangkan Log Transaksi menggunakan cadangan SQL (dan bukan cadangan server), log transaksi terus bertambah hingga menghabiskan semua ruang disk yang tersedia. (Saya pernah melihat seorang rekan yang lebih rendah menginstal SQL Server pada drive sistem dan tidak pernah membuat cadangan log transaksi. Ini memakan Windows .)

Ya, itu juga akan kembali ke titik waktu tertentu juga. Turun ke menit. Seperti yang dikatakan Twinkles, ya, orang-orang menjatuhkan meja dan sejenisnya.

Saya tidak tahu apa yang Anda gunakan untuk cadangan per jam Anda dari seluruh database, dan apakah itu produk yang sama dengan apa yang Anda gunakan untuk seluruh mesin. Jika demikian, solusi cadangan non-SQL-aware tidak didukung untuk pemulihan. Jumlah waktu yang dibutuhkan VSS untuk menyalin file MDF dan LDF dapat menyebabkan ketidakcocokan stempel waktu internal, misalnya.

Kami juga mengelola beberapa sistem ERP. Dan masalahnya sering bahwa pada malam hari sering ada pekerjaan batch berjalan lama yang menyinkronkan data dengan sistem lain. Dan mereka kadang-kadang memakan waktu satu jam atau lebih. Jadi yang ingin Anda lakukan jika terjadi crash adalah melompat ke titik di mana Anda memiliki data yang konsisten. (Yang berarti tepat di antara dua pekerjaan batch.) Jika Anda hanya melihat waktu, Anda mungkin tidak selalu tahu persis apa status dari basis data saat ini.

Tapi tentu saja itu tergantung situasi. Jika Anda tidak memiliki pekerjaan otomatis dll. Anda dapat benar-benar baik-baik saja dengan cadangan per jam.

Ada beberapa alasan mengapa Anda ingin melakukan itu:

1. Sistem basis data biasanya sibuk, mungkin melakukan ribuan transaksi per detik. Data dapat tersebar di beberapa file pada sistem file yang berbeda. Ini tidak sepele untuk memastikan bahwa database dalam keadaan konsisten (alias dapat digunakan) setelah memulihkan. Jika solusi cadangan Anda sesuai dengan tugas, bagus, tetapi Anda sebaiknya yakin tentang hal ini sebelum mempertaruhkan pekerjaan Anda.
2. Contoh: Seseorang menjatuhkan tabel dengan data penting secara tidak sengaja. Jika Anda memiliki cadangan database dengan kemampuan pemulihan point-in-time, Anda dapat memulihkan data dengan cepat, tanpa harus mengembalikan seluruh sistem.
3. Jika database dalam mode pemulihan penuh, log transaksi SQL Server akan tumbuh. Ruang penyimpanan dalam log transaksi hanya digunakan kembali jika log transaksi telah dicadangkan. Jika Anda tidak mencadangkan log transaksi secara teratur, sistem file Anda akan terisi hingga tidak ada ruang yang tersisa. Pada titik mana semuanya akan segera berhenti , karena tidak ada transaksi baru yang dapat dimulai.

Ketika basis data Anda tumbuh melampaui apa yang dapat Anda backup dalam satu jam, Anda membutuhkan model yang berbeda.

Cadangan penuh dari basis data Anda akan memotong log Anda, tetapi harus "SQL aware", karena dalam skenario itu, perangkat lunak cadangan yang memberi tahu SQL server tentang apa yang telah didukung, dan apa yang harus dipotong.

Seperti yang disebutkan orang lain, jika Anda memiliki basis data dalam model pemulihan "Penuh", log transaksinya akan tumbuh tanpa batas waktu, hingga Anda membuat cadangan Full-SQL-aware.

Pemulihan benar-benar masalah di sini, bukan Cadangan. Dan itu bukan keputusan teknis, ini keputusan bisnis!

Jika pemilik bisnis Anda OK dengan kehilangan satu jam atau lebih dari transaksi basis data mereka (yang mungkin SANGAT sulit atau tidak mungkin untuk diulang!) Maka model Anda berfungsi. Jika mereka baik-baik saja dengan sistem mati selama berjam-jam saat Anda mengembalikan seluruh database dari cadangan, maka model Anda berfungsi.

Namun, jika bisnis Anda menganggap sistem ERP mereka sebagai aset penting untuk operasi mereka (bukankah semuanya?), Maka menetapkan waktu pemulihan maksimum yang dapat diterima (alias RTO, Tujuan Waktu Pemulihan) untuk layanan penting Anda akan menjadi keputusan bisnis.

Juga, pemilik bisnis atau pemangku kepentingan sistem perlu mendefinisikan berapa banyak data yang mereka rela kehilangan risiko dalam suatu kejadian, alias RPO (Recovery Point Objective).

Jawabannya jika Anda bertanya kepada mereka mungkin "TIDAK ada data yang bisa hilang! Sistem ERP harus tersedia 24/7/365!" ... yang kita semua tahu sangat tidak mungkin efektif biaya. Jika Anda memberi mereka biaya yang terkait dengan membangun sistem yang sepenuhnya mubazir, tanpa henti, mereka akan menghasilkan angka yang lebih masuk akal ..;)

Intinya adalah, jika Anda dapat menghindari kehilangan transaksi, Anda menabung bisnis Anda berpotensi ratusan atau ribuan jam kerja yang hilang. Itu berarti penghematan besar di perusahaan mana pun, dan tumbuh dengan ukuran perusahaan Anda ...

Semua orang mendapat respons yang bagus untuk ini, tetapi saya ingin menambahkan catatan penting lainnya ... atau dua.

Mengetahui rincian model pemulihan SQL Server dan persyaratan bisnis Anda untuk kehilangan data keduanya sangat penting; namun, dalam hal ini sangat penting bagi Anda untuk memahami bagaimana produk cadangan Anda bekerja dengan SQL Server. (Berdasarkan komentar di atas, sepertinya Anda membuat cadangan volume disk melalui salinan VSS, yang berarti cadangan SQL Server mungkin atau mungkin tidak diperlukan sebagai tambahan.)

Setelah baru-baru ini mengevaluasi produk serupa, beberapa poin penting yang mungkin perlu Anda tanyakan adalah:

• Bagaimana mengembalikan dilakukan ke titik waktu untuk database dalam pemulihan penuh?
• Bagaimana cadangan awal ditangani untuk database baru dalam pemulihan penuh?
• Apakah produk cadangan memerlukan cadangan log SQL Server untuk mengembalikan ke titik waktu? (Dalam kasus saya, jawabannya adalah ya.)
• Dapatkah infrastruktur penyimpanan Anda menangani volume data untuk salinan / diferensial VSS (pada interval tertentu) di samping beban SQL normal?

Semoga ini bermanfaat.

Pengalaman tim saya dengan evaluasi kami baru-baru ini memberikan beberapa jawaban yang sangat menarik untuk pertanyaan di atas. Satu hal yang pasti, backup lebih kompleks bagi kita dengan produk cadangan VSS.

Seperti yang banyak orang lain katakan, jika Anda menggunakan alat pihak ketiga untuk mencadangkan / memotret VM atau penyimpanan, Anda masih berisiko tidak memiliki cadangan yang valid. Semua alat pihak ketiga yang mengelola cadangan SQL Server akan menerapkan dan terhubung ke SQL Server menggunakan VSS. Ini melakukan ini untuk meminta SQL Server menghentikan semua I / O ke file data sehingga snapshot yang konsisten dapat diambil. Jika tidak, maka Anda dapat memiliki banyak transaksi di berbagai negara dan pengembalian tidak akan tahu apakah transaksi tersebut dapat digulirkan ke depan atau ke belakang.

Saya belum bekerja dengan setiap alat pihak ketiga VM / Storage snapshot tooling di luar sana, tetapi yang saya telah bekerja dengan tidak pernah dapat snapshot penyimpanan di mana Sistem Database terletak - SQL Server tidak bisa meredakan database tersebut. Mereka SEMUA membuat cadangan basis data tersebut dengan cara yang dialirkan - yaitu ... mengeluarkan perintah CADANGAN DATABASE dan kemudian mengambil file cadangan itu sendiri.

Di atas semua itu, seperti yang juga dikatakan banyak orang, jika Anda berada dalam model pemulihan LENGKAP, dan Anda tidak mengeluarkan laporan LOG CADANGAN secara teratur, log transaksi akan terus bertambah hingga tidak ada ruang tersisa di disk.

Pertanyaan sebenarnya yang perlu Anda tanyakan, dan saya mungkin telah melewatkannya di atas ... apakah Anda berhasil dipulihkan dari cadangan ini beberapa kali, dan apakah Anda senang dengan konsistensi data dalam pemulihan tersebut. Secara pribadi, bahkan itu tidak akan cukup bagi saya, itu masih terasa seperti lemparan dadu, dan itu adalah sesuatu yang tidak pernah dibutuhkan DBA baik dalam hal pencadangan dan pemulihan.

Ketahuilah bahwa log transaksi bukan sekadar mekanisme pemulihan. Pemeliharaan log yang tepat juga dapat memainkan peran penting dalam keseluruhan kinerja basis data (yaitu, throughput transaksi).

Sering membuat cadangan file log Anda melakukan beberapa hal:

1. Ini mengurangi jumlah VLF dalam file log fisik yang baik untuk kinerja.
2. Anda lebih siap menggunakan cadangan log jika Anda perlu memulihkan basis data.
3. Ini sedikit lebih cepat daripada cadangan penuh

Jika Anda dapat melakukan backup penuh setiap jam, maka Anda saya tidak yakin seberapa besar Anda akan mendapat manfaat dari backup log yang lebih sering. Setelah semua seperti yang saya pahami, cadangan lengkap juga akan mencadangkan sebanyak mungkin log yang diperlukan untuk memastikan pemulihan lengkap.

Di sisi lain, jika aplikasi Anda menghasilkan banyak transaksi di antara cadangan penuh per jam Anda, maka itu mungkin menjelaskan mengapa pengembang asli menyarankan pemeliharaan log yang lebih terperinci. Banyak transaksi yang dapat menumbuhkan penghitungan VLF di log Anda yang dapat dikenakan penalti kinerja hingga log tersebut terpotong. Saya telah melihat ini dinyatakan sebagai kesalahan 'batas waktu permintaan kadaluwarsa' dalam suatu aplikasi (sesaat sebelum hang).

Rekomendasi yang berhubungan dengan pemeliharaan log transaksi dijelaskan dengan sangat baik dalam artikel ini 8 Langkah untuk Lebih Baik Transaksi Log throughput . Selain itu, artikel ini Tip Teratas untuk Pemeliharaan Basis Data yang Efektif menyebutkan jumlah VLF yang agak arbitrer bertujuan (<200) yang telah bekerja sangat baik untuk saya.

Orang lain telah memberikan sebagian besar alasan untuk cadangan translog dll. Tampaknya ada beberapa keraguan mengapa ini adalah strategi yang baik ketika Anda sudah membuat cadangan server.

Beberapa alasan bagus muncul untuk saya yang tidak ada di atas. Bagaimana jika Anda aplikasi pihak ke-3 gagal mengambil cadangan yang dapat Anda pulihkan? Sudahkah Anda mencoba mengembalikan cadangan Anda? Bagaimana dengan server baru yang baru Anda bangun dari templat Anda (pikirkan DR)? Bagaimana dengan server lain di domain Anda yang memiliki susunan yang berbeda? atau contoh SQL?

Saya mengambil cadangan yang berlebihan tanpa alasan selain terkadang aplikasi pihak ketiga Anda bukanlah cara tercepat untuk memulihkan. Terkadang penyimpanan yang disimpan oleh aplikasi pihak ketiga juga terpengaruh, atau rusak karena alasannya sendiri.