Jasa Managed SQL Server untuk Aplikasi Bisnis Anda

Maintenance plan SQL yang benar-benar berjalan

Susunan maintenance plan SQL yang wajar mencakup empat pekerjaan berkala, dan urutannya berpengaruh: pemeriksaan integritas basis data, pembaruan statistik, penataan ulang atau pembangunan ulang indeks, lalu pemangkasan riwayat pekerjaan.

Yang sering kami temukan bukan ketiadaan maintenance plan, melainkan plan yang gagal setiap malam tanpa ada yang tahu. SQL Server Agent mencatat kegagalannya di riwayat pekerjaan, dan riwayat itu tidak pernah dibuka.

Karena itu bagian pertama pekerjaan kami adalah menyambungkan notifikasi kegagalan ke kanal yang memang dibaca — bukan ke alamat email yang sudah tidak dipakai sejak orang yang memasangnya pindah.

Tuning indeks SQL Server berdasarkan data, bukan tebakan

Pekerjaan tuning indeks SQL Server punya keuntungan yang tidak dimiliki basis data lain: SQL Server sendiri mencatat indeks apa yang menurutnya kurang, lewat DMV `sys.dm_db_missing_index_details`.

Catatan itu berguna sebagai petunjuk, bukan perintah. Menerapkan semua saran indeks yang hilang adalah kesalahan umum yang berakhir pada tabel dengan dua puluh indeks, penulisan yang lambat, dan cadangan yang membengkak.

Yang kami lakukan adalah menyilangkan saran itu dengan Query Store — melihat kueri mana yang benar-benar mahal berdasarkan total waktu eksekusi, lalu menyusun indeks gabungan yang melayani beberapa kueri sekaligus. Indeks yang tidak pernah dipakai, terlihat dari `sys.dm_db_index_usage_stats`, ikut dibersihkan.

Fragmentasi ditangani sesuai tingkatnya: di bawah 30 persen cukup ditata ulang, di atasnya dibangun ulang. Membangun ulang semua indeks setiap malam tanpa memeriksa fragmentasinya hanya membuang I/O dan memenuhi log transaksi.

Backup SQL Server otomatis dan model pemulihannya

Penyiapan backup SQL Server otomatis dimulai dari satu keputusan yang sering diambil tanpa disadari: model pemulihannya. Pada mode `SIMPLE`, log transaksi dipangkas otomatis tetapi pemulihan hanya bisa ke cadangan penuh terakhir. Pada mode `FULL`, pemulihan bisa ke titik waktu mana pun — tetapi log transaksi wajib dicadangkan berkala, dan bila tidak, ia tumbuh tanpa batas.

Berkas log yang memenuhi disk sampai basis data berhenti menerima penulisan hampir selalu berasal dari kombinasi ini: mode `FULL` tanpa cadangan log. Kami periksa itu di hari pertama.

Jadwal yang lazim kami pasang: cadangan penuh mingguan, diferensial harian, dan log setiap 15 sampai 30 menit tergantung berapa banyak data yang boleh hilang. Semuanya ditulis ke penyimpanan di luar server, lalu diuji pemulihannya secara berkala.

Always On Availability Group untuk ketersediaan tinggi

Penyiapan Always On Availability Group memberi salinan basis data yang aktif di server lain, dengan peralihan otomatis ketika node utama gagal. Ia juga membuka kemungkinan mengarahkan beban baca — laporan, dasbor — ke replika sekunder.

Yang perlu diperiksa sebelum memutuskan: edisi lisensinya. Availability Group dengan beberapa replika dan pembacaan dari sekunder menuntut Enterprise Edition, dan selisih biaya lisensinya besar. Standard Edition menyediakan Basic Availability Group dengan batasan satu basis data per grup dan tanpa replika yang bisa dibaca.

Untuk banyak perusahaan, kombinasi cadangan yang teruji ditambah waktu pemulihan yang bisa dipertanggungjawabkan lebih ekonomis daripada Enterprise Edition. Kami sampaikan perhitungannya, bukan langsung menyarankan yang paling lengkap.

DBA SQL Server tanpa merekrut penuh waktu

Kebutuhan DBA SQL Server pada perusahaan menengah biasanya nyata tetapi tidak sebesar satu posisi purnawaktu. Yang diperlukan lebih sering berupa perawatan berkala plus kehadiran cepat saat ada masalah performa.

Cakupan yang kami jalankan berisi hal-hal berikut.

• Pemeriksaan harian atas keberhasilan cadangan dan pekerjaan terjadwal.
• Peninjauan bulanan kueri termahal beserta rekomendasi indeks.
• Pemantauan pertumbuhan berkas data dan log, dengan peringatan sebelum disk penuh.
• Penerapan tambalan keamanan SQL Server pada jendela terjadwal.
• Penelusuhan saat aplikasi melambat, termasuk analisis deadlock dan blocking.
• Audit akses: siapa punya hak `sysadmin`, dan apakah masih perlu.

Konfigurasi awal yang paling sering dibiarkan bawaan

Beberapa pengaturan SQL Server dibiarkan pada nilai bawaan padahal hampir selalu perlu diubah, dan efeknya langsung terasa pada performa.

`max server memory` yang tidak dibatasi membuat SQL Server mengambil hampir seluruh RAM, menyisakan terlalu sedikit untuk sistem operasi — gejalanya server yang terasa berat secara menyeluruh, bukan hanya basis datanya. `MAXDOP` bawaan pada server dengan banyak inti sering membuat kueri sederhana diparalelkan secara tidak perlu.

Yang juga sering ditemukan: `tempdb` masih satu berkas di disk yang sama dengan data, padahal memisahkannya dan menambah jumlah berkas sesuai jumlah inti memberi perbaikan yang terukur pada beban kerja dengan banyak operasi sementara.

Semua ini bisa disetel tanpa menyentuh aplikasi, dan biasanya masuk dalam pekerjaan minggu pertama.