Mempertahankan basis data 24x7 adalah topik yang cukup besar dengan banyak opsi untuk dipertimbangkan. Topik luas ini memiliki banyak hal yang perlu dipertimbangkan, tetapi kita dapat mencoba dan menyentuh berdasarkan beberapa poin tinggi.
Apa yang pertama kali ingin Anda identifikasi adalah, sementara banyak operasi 24x7, biasanya ada saat aktivitas rendah. Anda dapat memanfaatkan waktu ini untuk menjalankan pemeliharaan sehingga Anda mengurangi gangguan yang Anda miliki pada basis data. Yang kedua adalah Anda harus menyediakan waktu untuk pemadaman total (untuk hal-hal seperti paket layanan atau migrasi basis data), jadi Anda perlu menegosiasikan jendela perawatan penuh dengan manajemen Anda. Untuk barang-barang tertentu, Anda perlu mempertimbangkan dan merencanakannya, serta memanfaatkan alat-alat Anda dengan tepat. Yang penting adalah Anda harus RENCANA masing-masing, setiap contoh yang saya berikan sangat banyak "mil Anda dapat bervariasi".
Cadangan
Cadangan biasanya tidak akan berdampak besar pada beban kerja, tetapi harus diperhitungkan karena mereka dapat mengkonsumsi banyak I / O. Anda akan ingin menjadwalkan ini dengan tepat dan memonitor jumlah waktu yang dibutuhkan untuk menyelesaikannya. Rintangan terbesar di sini adalah bahwa dalam operasi 24x7, Anda mungkin tidak akan dapat melakukan backup malam penuh setiap malam dalam seminggu. Anda akan ingin merencanakan kapan Anda dapat mengambil penuh, ketika Anda mengambil diferensial, dan periode retensi untuk keduanya dikombinasikan dengan cadangan log Anda.
Sebagai contoh, saya menjalankan backup penuh dari semua database saya pada Minggu malam (aktivitas terendah), perbedaan pada semua malam lainnya (Senin-Sabtu). Saya menyimpan dua minggu penuh penuh dan berbeda pada disk, log selama dua hari terakhir. Ini memberi saya cukup fleksibilitas untuk pemulihan, tetapi saya mungkin harus memulihkan cadangan dari kaset jika perlu.
Pemeliharaan Indeks / Statistik
Ini adalah jenis perawatan aktif paling umum yang harus Anda tangani. Anda tidak dapat menghindarinya, tetapi Anda dapat mengurangi dampaknya. Aturan awal praktis adalah Anda hanya harus melakukan perawatan pada objek yang membutuhkannya. Pedoman umum hanya untuk membangun kembali indeks yang lebih besar dari 30% terfragmentasi dan lebih dari 1000 halaman . Jika Anda memiliki statistik pembaruan otomatis , ini akan menangani sebagian besar pemeliharaan statistik Anda, tetapi pekerjaan malam hari untuk menjaga semuanya tetap sinkron bukanlah ide yang buruk.
Jika Anda memiliki Edisi Perusahaan, Anda juga memiliki akses ke beberapa opsi lain untuk mengelola pemeliharaan. Yang terpenting adalah Online Index Rebuilds , yang akan memungkinkan Anda untuk membangun kembali indeks saat masih digunakan (pada dasarnya, itu membangun indeks berdampingan, lalu menukarnya). Anda juga dapat memanfaatkan partisi untuk tabel "besar" untuk mengurangi jumlah waktu yang diperlukan untuk membangun kembali.
Taruhan terbaik Anda untuk jenis pemeliharaan ini, jika Anda tidak memiliki skrip khusus yang menangani praktik terbaik ini, adalah dengan menggunakan skrip Pemeliharaan Ola Hallengren . Ini cukup mudah untuk diatur dan dikonfigurasikan dan memiliki banyak panduan ini.
Cek Konsistensi DBCC
Bergantung pada keseluruhan beban kerja Anda, Anda mungkin mendapati bahwa pemeriksaan DBCC akan mengganggu operasi Anda. Ada dua cara umum untuk meminimalkan dampak DBCC Anda untuk database Anda:
PHYSICAL_ONLY- Menjalankan opsi ini akan memeriksa basis data Anda di tingkat halaman fisik dan menghindari pemeriksaan penuh yang lebih invasif. Ini akan mencakup mengidentifikasi jenis-jenis korupsi yang paling mungkin.- Memeriksa salinan yang dipulihkan - Jika Anda memiliki ruang, Anda dapat mengembalikan database ke instance lain dan menjalankan pemeriksaan DBCC terhadap salinan yang dipulihkan. Ini akan menceritakan kisah yang sama tentang database langsung Anda, tetapi Anda jelas tidak akan mengganggu aktivitas. Beberapa alternatif lain di sini menjalankan DBCC terhadap salinan yang dikirimkan log atau db yang dicerminkan.
Posting blog ini memberikan detail lebih lanjut tentang opsi Anda.
Pekerjaan batch / ETL
Ini benar-benar bermuara pada bagaimana Anda merancang proses Anda. ETL Anda selalu dapat mengganggu tabel OLTP langsung (seperti halnya aplikasi lain), jadi beberapa kunci yang perlu diingat:
- Jadwalkan pekerjaan semacam itu di sekitar pemeliharaan Anda yang lain dan dalam periode aktivitas yang rendah.
- Ukuran pekerjaan yang tepat sehingga batch untuk kinerja dan agar batch tidak begitu besar sehingga mengunci meja Anda selama berjam-jam. Contoh dari ujung spektrum: Baris-demi-agonisasi-baris (RBAR) versus satu juta baris dihapus.
- Gunakan tabel panggung dan luring pemrosesan data Anda jika perlu. Hanya menyentuh siaran langsung saat benar-benar diperlukan.
Kesimpulan
Sekali lagi, ada banyak alasan untuk dibahas di sini. Ini bukan panduan yang komprehensif, tetapi gambaran umum tingkat tinggi dari beberapa pendekatan. Saya bahkan belum membahas opsi ketersediaan tinggi (seperti Ketersediaan Groups dan Failover Clustering). Anda perlu meninjau setiap item dan menyusun rencana bagaimana menanganinya. Dalam banyak hal, Anda juga perlu mengulang dan memperbaiki pekerjaan Anda saat Anda bergerak maju.
Sumber daya tambahan:
Praktik terbaik pemeliharaan Keterampilan SQL VLDB