Sql Server Maintenance Plan - Praktik Terbaik tentang Tugas dan Penjadwalan

Saya ditugasi menyusun rencana pemeliharaan untuk basis data Sql Server 2005 kami. Saya tahu untuk backup Saya ingin melakukan backup database harian penuh dan backup log transaksional setiap 15 menit. Masalah saya adalah mencari tahu tugas-tugas lain yang ingin saya lakukan dan seberapa sering saya harus melakukannya.

Sejauh ini saya masih memikirkan hal ini. Perbaiki saya jika ada kesalahan dalam pemikiran saya atau cara yang lebih baik untuk melakukan ini.

1. Cadangan - Semua Tabel, Cadangan Penuh (setiap hari)
2. Cadangan - Tabel yang Dipilih, Cadangan Penuh (setiap jam)
3. Cadangkan - Log Transaksi (setiap 15 menit)
4. Periksa integritas basis data (setiap hari)
5. Atur ulang indeks (setiap hari)
6. Perbarui statistik (setiap hari)
7. Kecilkan basis data (mingguan)
8. Buat kembali indeks (mingguan)
9. Pembersihan pemeliharaan (setiap hari)

Saya ingat membaca beberapa waktu yang lalu (ketika saya membuat rencana serupa di pekerjaan lain) bahwa beberapa tugas ini tidak perlu dijalankan setiap hari atau tidak boleh dijalankan setiap hari. Yang mana, itu luput dari saya. Saya bisa menggunakan sedikit panduan tentang membuat rencana perawatan yang lebih baik yang akan mengurangi kehilangan data dalam suatu bencana, tetapi tidak akan membebani sistem saat dijalankan selama jam sibuk (dan juga meningkatkan kinerja).

Josh,

Ini adalah tugas yang sangat umum untuk semua DBA dan jawaban yang tepat TIDAK sama untuk setiap orang dan untuk setiap server. Seperti banyak hal lain, itu tergantung pada apa yang Anda butuhkan.

Tentunya Anda tidak ingin menjalankan "Shrink Database" seperti yang sudah disarankan. EVIL untuk kinerja dan ref di bawah ini akan menunjukkan kepada Anda mengapa Ini menyebabkan disk dan juga fragmentasi indeks dan ini dapat menyebabkan masalah kinerja. Anda lebih baik dengan pra-alokasi ukuran besar untuk data dan file log sehingga autogrowth TIDAK akan kick-in.

Saya tidak mengerti # 2 Anda. tabel yang dipilih cadangan penuh. Bisakah Anda menguraikan lebih lanjut tentang ini?

Datang ke Index mengatur ulang, memperbarui statistik dan membangun kembali indeks, Anda harus berhati-hati tentang bagaimana Anda melakukan ini jika tidak Anda akan berakhir menggunakan lebih banyak sumber daya dan juga berakhir dengan masalah kinerja.

Ketika Anda membangun kembali indeks statistik indeks diperbarui dengan fullscan tetapi jika Anda memperbarui statistik setelah itu, maka mereka akan diperbarui lagi dengan sampel default (yang tergantung pada beberapa faktor, biasanya 5% dari tabel ketika ukuran tabel> 8 MB) yang dapat menyebabkan masalah kinerja. Tergantung pada edisi yang Anda miliki, Anda mungkin dapat melakukan pembangunan kembali indeks online. Cara yang tepat untuk melakukan aktivitas ini adalah memeriksa jumlah fragmentasi dan bergantung pada apakah indeks tersebut dibangun kembali atau indeks disusun ulang + perbarui statistik. Dan Anda juga mungkin ingin mengidentifikasi tabel mana yang perlu memperbarui statistik lebih sering dan mencoba memperbarui statistik lebih sering.

Rencana Perawatan OK tetapi sulit untuk mendapatkan yang terbaik dari mereka melakukan penyesuaian ini kecuali Anda dapat login ke SSIS dan men-tweak MP. itu sebabnya saya lebih suka TIDAK menggunakannya dan menggunakan skrip gratis Ola Hallengren yang lebih kuat daripada MP. Juga, saya akan merekomendasikan untuk mengejar artikel yang direferensikan oleh Paul Randal tentang topik ini.

Ref: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

Ini BUKAN jawaban komprehensif untuk pertanyaan Anda tetapi titik awal yang baik. HTH dan beri tahu kami jika Anda memiliki pertanyaan / komentar tambahan.

Saya akan membagikan pengalaman saya, bahkan jika Anda sudah menerima jawaban. Mungkin ini akan sangat membantu :-).

1. Cadangan harian lengkap (harian) - hebat, tetapi jangan lupa untuk memeriksa ruang dan menghapus file lama setelah beberapa waktu yang telah ditentukan.
2. Cadangkan tabel yang dipilih (setiap jam) - tidak mengerti mengapa Anda membutuhkan ini, sebaiknya gunakan cadangan diferensial. Bagaimana Anda mencadangkan hanya tabel tertentu: SSIS, skrip, bcp? Mengenai cadangan berbeda, jangan jadwalkan terlalu sering, karena Anda akan mencuri peran cadangan log.
3. Pencadangan log transaksi (setiap 15 menit) - bagus, apakah Anda yakin Anda membutuhkan semua basis data? Apakah semua database menggunakan model pemulihan penuh atau tidak?
4. Periksa integritas db - ya, tetapi Anda perlu memastikan bahwa Anda tidak membunuh lingkungan Anda. Pernyataan pemeriksaan DBCC cukup egois pada sumber daya dan memindai dbs lengkap, sehingga harus dijadwalkan pada jam-jam libur.
5. Atur kembali indeks (setiap hari) - jangan memaksanya, lakukan hanya jika diperlukan. Periksa indeks DMV tentang fragmentasi dan reorganisasi hanya berdasarkan kebutuhan. Saya akan memindahkan semua operasi indeks dan statistik dalam satu tugas mingguan.
6. Perbarui statistik (setiap hari) - Silakan lihat jawaban saya untuk pertanyaan sebelumnya. Daripada hanya memaksa pembaruan semua statistik, setiap hari, Anda sebaiknya memeriksa kapan statistik terakhir diperbarui dan hanya dalam beberapa kasus memperbaruinya.
7. Kecilkan basis data (mingguan) - Oh, tidak. Silakan baca artikel Paul Randal tentang penyusutan file.
8. Buat kembali indeks (mingguan) - lihat 5.

9. Pembersihan pemeliharaan (setiap hari) - ok dengan itu.

10. Anda sebaiknya menambahkan tugas untuk memverifikasi cadangan Anda - ada versi perintah RESTORE (verifikasi saja .. jika saya ingat dengan benar) - katakanlah setiap minggu, meskipun saya lebih suka setiap hari.

Anda menyebutkan Anda ingin dilindungi jika terjadi kehilangan data, jadi saya katakan Anda perlu menambahkan basis data sistem dalam prosedur perawatan ini. Dan juga berhati-hati untuk membuat cadangan file pada mesin yang berbeda dari server itu sendiri. Simpan di suatu tempat file dengan apa yang harus dilakukan jika Anda perlu membangun kembali master db, msdb..etc. Semoga berhasil dengan tugas Anda!

Jawaban terlambat tetapi bisa berguna bagi pembaca lain.

Tolong, ingatlah bahwa ada banyak tugas pemeliharaan atau pelaporan, yang dapat Anda buat, yang membawa risiko tak terlihat yang terkait dengannya.

Apa yang akan terjadi ketika drive terisi selama cadangan diferensial dilakukan setiap hari? Dan bagaimana jika indeks membangun kembali pekerjaan berjalan sangat lama? Bagaimana jika suatu proses pemuatan data menyebabkan pertentangan sumber daya yang luas, membuat operasi normal menjadi berlutut? Semua ini adalah acara yang direncanakan, namun dapat menyebabkan gangguan besar pada proses yang kami coba lindungi.

Selalu pertimbangkan bagaimana berbagai pekerjaan berinteraksi dan mengatur waktu sedemikian rupa sehingga tidak ada tumpang tindih dalam tugas yang sensitif atau sumber daya yang intensif.

Saya sarankan membaca artikel ini terlebih dahulu: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

Ini menjelaskan cara melakukan tugas-tugas pemeliharaan penting dalam SQL Server - bebas risiko. Misalnya - Anda dapat membuat pemeriksaan sederhana ke dalam pekerjaan pemeliharaan Anda yang memverifikasi sumber daya yang tersedia serta apa yang diperlukan operasi sebelum eksekusi. Ini memungkinkan Anda untuk memastikan bahwa lingkungan Anda dapat menangani apa yang akan Anda lakukan, dan membatalkan dengan kesalahan yang berarti jika sumber daya tidak memadai.

1. Sepertinya baik-baik saja

2. Anda mungkin mendapat manfaat dari melakukan Diferensial Cadangan di sini. Lihatlah ke dalamnya pasti

3. Sepertinya baik-baik saja

4. Sepertinya baik-baik saja

5. Seperti yang dinyatakan sebelumnya, penyusutan database buruk karena mereka membuat fragmentasi fisik data dan file log Anda, sehingga menyebabkan lebih banyak pembacaan IO acak.

5, 6, dan 8: Lihat berikut.

Ini benar-benar berjalan seiring, karena indeks mengandalkan statistik terkini, dan urutan operasi ini cukup penting. Metode dasar yang saya terapkan, yang diakui mungkin tidak bekerja untuk semua orang, adalah saya melakukan dua putaran pemeliharaan indeks. Pertama, saya melakukan indeks berkerumun dan kemudian indeks nonclustered. Metode yang saya terapkan untuk keduanya adalah sebagai berikut. Jika indeks cukup besar dan cukup terfragmentasi (sys.dm_db_index_physical_stats), saya akan membangun kembali indeks (yang mencakup pembaruan statistik dengan pemindaian penuh). Jika indeks terlalu kecil untuk membangun kembali atau tidak cukup terfragmentasi untuk membangun kembali (kurang dari 100 halaman dan antara 5% dan 15% fragmentasi), saya pertama-tama akan melakukan pengorganisasian indeks. Saya kemudian akan melakukan pembaruan statistik dengan pemindaian penuh.

Sekarang, ini mencakup statistik indeks, tetapi lalai untuk melakukan apa pun untuk statistik kolom. Setiap minggu, saya akan memperbarui statistik kolom.

Saya harap ini membantu!

Saya memiringkan pada komentar "kehilangan data Anda dapat memiliki konsekuensi hukum di sini".

Kemudian, Anda pasti ingin mendapatkan alat pihak ke-3 yang kuat (seperti DPM) yang dapat menangani backup (dan pulih dari peristiwa bencana dalam sekejap dan sedikit rewel) banyak lebih cepat dan jauh lebih baik daripada skrip apa pun yang dapat Anda lakukan dari Internet.

Memiliki cadangan adalah satu hal. Mengetahui cara menggunakannya dalam keadaan darurat adalah hal lain.

Jangan lupa bahwa jika Anda ingin mengembalikan cadangan setelah kegagalan besar, Anda mungkin sudah berada di bawah tekanan dan tekanan. Anda tidak perlu beban tambahan untuk menggali dan menulis dengan sempurna pernyataan RESTORE DATABASE dengan 12 file log transaksi ... Dan berdoa itu tidak mengecewakan Anda ...

Di tempat kerja saya, saya dapat memulihkan / mengembalikan database 350Gb ke titik mana pun dalam jangka waktu 5 menit selama seminggu terakhir menggunakan DPM. Dengan antarmuka GUI. Layak, dalam buku saya.

Untuk selebihnya, pastikan untuk melihat skrip indeks Ola Hallengren, dan sesuaikan parameternya dengan kebutuhan Anda. Secara pribadi, saya ditambah dengan tugas terjadwal yang membuatnya berjalan selama satu jam setiap malam tanpa pemindaian ulang, sehingga menangani indeks terburuk setiap saat, dan memaksa pemindaian ulang penuh fragmentasi setiap hari Sabtu, atau ketika semua indeks dalam daftar telah didefragmentasi.

Terakhir, saya menambahkan suara saya ke grup "jangan menyusutkan file Anda secara otomatis, pernah". Penyusutan File hanya alat untuk digunakan secara sporadis ketika terjadi peristiwa tidak teratur yang memutakhirkan log atau file DB Anda (infinite loop atau semacamnya). Itu tidak seharusnya menjadi alat pemeliharaan. Jika Anda memiliki tekanan ruang disk, menyusut hanya akan menunda yang tidak terhindarkan lagi pula.