Apa pro dan kontra dari skrip Ola vs menggunakan rencana pemeliharaan?

9

Maukah Anda membantu saya memahami pro dan kontra menggunakan solusi Ola atas rencana pemeliharaan? Saya telah menyiapkan presentasi berdasarkan SQL Pass ( http://www.pass.org/DownloadFile.aspx?File=ebae1b31 ) yang akan saya presentasikan.

Saya juga menyiapkan beberapa skenario yang tidak ditangani oleh solusi Ola dan solusi rencana perawatan. Bisakah Anda membantu saya menjelaskan hal ini secara lebih teknis?

Omong-omong, kami mengelola hampir 150+ server (campuran 2008/2012/2014/2016) dengan solusi Ola pada setidaknya 75% dari mereka. Saya menyukai artikel ini oleh Brent Ozar. Namun dalam satu komentar, Brent telah merekomendasikan untuk menggunakan solusi berbasis skrip untuk jumlah server yang kami miliki. https://www.brentozar.com/archive/2012/04/maintenance-plans-roombas-suck-good-way/

sql-server ola-hallengren

— Menepuk
sumber

Apakah kita berbicara tentang cadangan, pemeliharaan indeks / stat, pemeriksaan korupsi atau semua hal di atas?

— nkdbajoe

Mereka semua. Seluruh skrip solusi pemeliharaan oleh Ola. Saya telah menyelesaikan masalah pembaruan indeks dan statistik yang tidak perlu dalam rencana pemeliharaan menggunakan skrip Ola. Saya hanya ingin beberapa amunisi teknis dari DBA lain di luar sana. Terima kasih.

— Pat

2

Saya pribadi percaya solusi terbaik adalah solusi yang memenuhi persyaratan bisnis Anda dan kemampuan Anda untuk menyelesaikannya setelah ada kesalahan. Solusi Ola tidak buruk secara umum tetapi saya masih lebih suka solusi khusus saya untuk lingkungan saya. Misalnya, untuk pemeliharaan indeks, saya ingin memiliki eksekusi paralel untuk menghemat waktu. Solusi Ola tidak berfungsi di sini. Saya ingin memiliki pembaruan statistik tambahan, solusi Ola juga tidak bekerja di sini.

— jyao

Apakah Anda memiliki data untuk menunjukkan bahwa mereka lebih baik atau apakah Anda hanya akan merasa lebih baik? Cara terbaik untuk mengatasi masalah ini adalah mendapatkan beberapa data kinerja agar dapat menunjukkan mengapa suatu metode lebih baik

— Joe W

Untuk pemeliharaan indeks, sering kali faktor pembatasnya adalah SAN dan subsistem penyimpanan Anda. Bergantung pada konfigurasi SAN Anda, Anda mungkin tidak melihat peningkatan dalam pembangunan kembali paralel.

— Alen

13

Saya sudah menulis di sini

Rencana perawatan tidak buruk, tetapi ketika lingkungan Anda tumbuh, fleksibilitas dan fungsionalitas terbatas yang disediakan rencana pemeliharaan tidak akan cukup.

Untuk menambahkan lebih banyak,

Solusi pemeliharaan Ola diterima secara luas di masyarakat dan organisasi besar .
Sumbernya terbuka dan masalah dapat diangkat di github / masalah dengan kemungkinan untuk memperbaikinya dengan sangat cepat.
Ini fleksibel dan scalable (bahkan jika Anda ingin menyebarkannya ke 100-an server cukup gunakan Install-DbaMaintenanceSolution dari dbatools.)
Microsoft membutuhkan waktu hampir satu dekade untuk memperbaiki rencana Pemeliharaan GUI yang bermasalah sendiri :-)
memiliki dokumentasi dan FAQ yang luas dan terus diperbarui untuk mengakomodasi versi server sql yang lebih baru.
dalam versi pratinjau , Anda bahkan dapat menjalankan backup secara paralel.
untuk solusi pemeliharaan indeks, Anda bahkan dapat mengatur waktu proses mis. jika berjalan lebih dari jumlah waktu X, batalkan.

— Kin Shah
sumber

5

Salah satu keuntungan utama dari solusi berbasis skrip adalah kemudahan penyebaran - sesuatu yang jelas relevan dalam kasus Anda, karena Anda memiliki 150+ server. Mencoba untuk meluncurkan beberapa rencana perawatan (yaitu minimal 2, satu untuk database sistem dan satu untuk database pengguna) di 150 server akan menjadi mimpi buruk. Menjaga mereka sekali di tempat sama merepotkan.

Solusi berbasis skrip jauh lebih mudah untuk digunakan dan dipelihara dari waktu ke waktu. Skrip Ola cukup komprehensif dan mencakup sebagian besar kebutuhan. Mereka mewakili titik awal yang bagus bagi organisasi mana pun untuk kemudian menyesuaikan agar sesuai dengan persyaratan unik mereka sendiri.

Dalam kasus kami, kami memiliki sekitar 40 instance SQL di lingkungan DEV kami, dan kami menggunakan skrip Ola yang dimodifikasi dengan fitur multi-koneksi SSMS untuk dapat meluncurkan perubahan pada rezim pemeliharaan pada semua 40 instance pada satu klik. Setiap kasus khusus ditangani oleh modifikasi kami.

— Mike
sumber

3

Saya tidak 100% yakin dengan skripnya tetapi skrip khusus jauh lebih baik daripada rencana pemeliharaan. Paket bawaan akan membangun kembali setiap indeks di atas meja tidak peduli seberapa kecil fragmentasi. Jika Anda memiliki Selalu Aktif itu akan membuat badai lalu lintas.

Skrip khusus Anda dapat membangun kembali apa pun lebih dari 20% atau apa pun ambangnya. Lebih sedikit indeks yang dibangun kembali sekaligus. Kurang Selalu Di data untuk dikirim ke sekunder. Pembangunan kembali lebih cepat karena Anda membangun kembali indeks yang lebih sedikit. Diperlukan jendela perawatan yang lebih pendek.

Terakhir kali saya menggunakan rencana perawatan, saya memiliki 300 juta baris tabel dan Selalu Aktif akan menjadi jam di belakang setiap kali indeks membangun kembali dimulai dan masalah dengan log transaksi melimpah. Kembali ke skrip dan semuanya hilang.

— Alen
sumber

1

Saya awalnya menulis sendiri untuk SQL 2005 sekitar tahun 2007. Saya menggunakan buku apa yang dimiliki sebagai basis dan mengubahnya sedikit. Saat itu sepertinya kebanyakan orang menggunakan rencana dan sekarang tampaknya telah terbalik. Dan sebelum saya mulai melakukan hal-hal DBA, DBA sebelumnya sebelum saya memiliki skrip kustom untuk SQL 2000. Satu-satunya hal yang saya berbeda adalah saya membangun kembali semuanya. Lebih cepat untuk membangun kembali apa pun lebih dari 20% atau 30% daripada mengatur ulang juga. Untuk cadangan, kami selalu menggunakan produk pihak ketiga

— Alen

1

Selain alasan di atas, alasan favorit saya adalah untuk dapat mengganti jenis cadangan secara otomatis sehingga basis data baru akan memiliki cadangan lengkap saat pertama kali pekerjaan pencadangan log dijalankan alih-alih menunggu hingga pekerjaan pencadangan penuh berikutnya berjalan.

— SQLDBAWaberhubungan
sumber

0

Rencana pemeliharaan akan baik-baik saja hampir sepanjang waktu. Skrip Ola Hallengren akan baik-baik saja hampir sepanjang waktu.

Dalam kasus yang sangat jarang, Anda mungkin harus tumbuh sendiri.

Seperti yang dikatakan Jyao, Anda merasa paling nyaman bekerja dengannya. Jika rekan kerja Anda merasa paling nyaman dengan rencana perawatan, mengapa celana dalam Anda berputar?

Jika dia sudah melakukan database selama 20+ tahun, dia sudah menulis skrip pemeliharaan sendiri. Tepat saat Anda belajar mengemudi, mungkin ada beberapa punk muda dengan celana pendek kargo dan sandal jepit yang datang dan semuanya seperti "hei, kau pembuat kode lama, rencana pemeliharaan lebih baik - dan tarik celana Anda ke bawah, Anda terlihat konyol! ".

Kemudian mungkin ada pertempuran 4 tahun di mana anak muda yang sombong menyelinap dalam rencana pemeliharaan kapan pun dia bisa. Sekarang ini punk muda lainnya dengan skinny jeans dan dasi kupu-kupu freakin menyuruhnya untuk kembali ke skrip. Cukup untuk mengubah rambut Anda menjadi abu-abu.

Tiga hal yang perlu dipertimbangkan:

Apakah contoh-contoh keunggulan Hallengrenite ini benar-benar berlaku untuk lingkungan Anda?

Apakah itu akan menyebabkan Anda masalah aktual jika dia menggunakan rencana perawatan?

Jika Anda meyakinkan dia untuk menggunakan skrip Hallengren dan ada masalah, apakah dia bisa menyelesaikannya sendiri atau harus memanggil Anda?

— James
sumber

Jawab dua pertanyaan pertama Ya. Kami telah melihat masalah dengan Rencana Perawatan dan saya menyelesaikannya dengan solusi Ola. Ada menyusut log tugas (??) di server produksi juga yang saya nonaktifkan segera. Pertanyaan ketiga, saya tidak tahu. Saya tidak yakin apakah dia akan dapat menyelesaikan masalah yang dibuat oleh Rencana Perawatan itu sendiri. Ketika saya bertanya kepadanya jika kita melihat masalah dengannya, apa yang harus kita lakukan? Jawabannya adalah memanggil dukungan Microsoft. (??)

— Pat

@Pat, ahh, sepertinya dia mencapai batasnya di bawah Prinsip Peter. Berhati-hatilah untuk membuatnya menjadi lebih baik - dia tidak akan menghargai bantuannya.

— James