Tugas SQL panjang: tetap berjalan saat VPN putus

VPN putus dua puluh menit setelah rebuild indeks dimulai, klien SQL Anda menampilkan koneksi terputus, dan pertanyaan yang jelas tidak punya jawaban dalam galat itu. Apakah pernyataan selesai, di-rollback, atau terus berjalan tanpa Anda? Menyambung ulang dan mengirim ulang adalah pilihan terburuk dari ketiganya, karena mengubah satu hasil tak pasti menjadi dua kemungkinan. Pindahkan pekerjaan ke sesuatu yang punya pemilik tahan lama sebelum jendela berikutnya.

Apa yang tidak diberitahukan galat koneksi

Galat di sisi klien menjelaskan klien. Galat itu melaporkan bahwa soket ditutup, bukan apa yang dilakukan server terhadap transaksi. Pernyataan itu mungkin masih dieksekusi, mungkin sudah di-commit tepat sebelum tautan mati, atau mungkin di-rollback saat sesinya dibersihkan. Ketiganya menghasilkan pesan yang sama di laptop Anda.

Hanya status server yang bisa memutuskannya. Lihat ke sana sebelum memutuskan apa pun.

Serahkan pekerjaan ke pemilik di sisi server

Untuk pekerjaan yang tidak perlu diawasi manusia, biarkan host basis data memiliki eksekusinya. SQL Server Agent menjalankan tugas sesuai permintaan atau menurut jadwal dan mencatat setiap eksekusi, sehingga siklus hidup tugas tidak bergantung pada sesi VPN Anda. Identitas tugas membutuhkan tepat izin yang dituntut tugas itu, bukan konteks interaktif penuh seorang administrator. Lalu laptop memulai pekerjaan dan membaca hasil, bukan menjadi proses yang menjaganya tetap hidup.

EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';

Ketersediaan Agent bergantung pada edisi dan layanan yang Anda terapkan. Gunakan mekanisme yang benar-benar disediakan platform Anda, bukan menganggap yang ini ada di mana-mana.

Host lompat dekat basis data memperpendek jalur dan layak dimiliki, tetapi tidak mengubah soal kepemilikan. Sesi tetap berakhir saat jaringan berakhir. Gunakan untuk mengamati, bukan untuk menjadi hal yang menjaga pekerjaan tetap hidup.

Tinggalkan catatan yang bisa dibaca sesi berikutnya

Catat nama tugas atau pengenal, basis data target, dan hasil yang Anda harapkan. Catatan itulah yang memungkinkan sesi lain, atau orang lain, menjawab pertanyaan yang tidak bisa dijawab galat tadi. Tanpanya Anda hanya punya ingatan samar tentang pembaruan dan tidak punya cara memeriksanya.

EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';

Riwayat menampilkan hasil dan waktu per langkah, yang lebih berguna daripada satu bendera sukses. Untuk tugas yang mengubah data, tambahkan juga verifikasi milik aplikasi: jumlah baris, checksum, atau baris status yang ditulis tugas itu. Dua catatan independen itulah yang membuat percobaan ulang aman, dan riwayat tugas yang tercatat adalah yang pertama.

Rekonsiliasi sebelum mengirim ulang

Saat koneksi pengamat hilang, temukan eksekusi yang sudah ada sebelum memulai yang lain. Baca hasil langkah-langkahnya dan putuskan apakah pekerjaan sudah di-commit, selesai sebagian, atau tidak pernah dimulai. Baru setelah itu terapkan aturan percobaan ulang yang didefinisikan alur kerja, karena pengiriman ulang secara membabi buta bisa menggandakan pemuatan atau gagal di tengah jalan untuk kedua kalinya.

Pertahankan pemilik tahan lama dan hasil yang dapat diperiksa, dan kegagalan akses singkat menjadi ketidaknyamanan alih-alih dugaan. Itulah seluruh tujuan desain: pekerjaan seharusnya hidup lebih lama daripada koneksi yang memintanya.