Tugas SQL panjang: biarkan ia berjalan apabila VPN terputus

VPN terputus dua puluh minit selepas pembinaan semula indeks bermula, klien SQL anda menunjukkan sambungan terputus, dan soalan yang jelas tiada jawapan dalam ralat itu. Adakah pernyataan itu selesai, digulung semula, atau terus berjalan tanpa anda? Menyambung semula dan menghantar semula ialah pilihan paling buruk antara ketiga-tiganya, kerana ia mengubah satu hasil tidak pasti menjadi dua kemungkinan. Pindahkan kerja itu kepada sesuatu yang mempunyai pemilik tahan lama sebelum tetingkap seterusnya.

Apa yang ralat sambungan tidak beritahu anda

Ralat di sebelah klien menerangkan klien. Ia melaporkan bahawa soket ditutup, bukan apa yang pelayan lakukan dengan transaksi itu. Pernyataan itu mungkin masih dilaksanakan, mungkin telah dikomit sejurus sebelum pautan mati, atau mungkin telah digulung semula apabila sesinya dibersihkan. Ketiga-tiganya menghasilkan mesej yang sama pada komputer riba anda.

Hanya keadaan pelayan boleh menyelesaikannya. Lihat di sana sebelum membuat apa-apa keputusan.

Serahkan kerja kepada pemilik di sebelah pelayan

Untuk kerja yang tidak memerlukan manusia mengawasi, biarkan hos pangkalan data memiliki pelaksanaannya. SQL Server Agent menjalankan tugas atas permintaan atau mengikut jadual dan merekodkan setiap larian, jadi kitaran hayat tugas itu bebas daripada sesi VPN anda. Identiti tugas memerlukan tepat kebenaran yang dituntut oleh tugasan itu, bukan konteks interaktif penuh seorang pentadbir. Kemudian komputer riba memulakan kerja dan membaca hasil, bukannya menjadi proses yang memastikannya terus hidup.

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

Ketersediaan Agent bergantung pada edisi dan perkhidmatan yang anda gunakan. Gunakan mekanisme yang benar-benar disediakan oleh platform anda dan bukannya menganggap yang ini ada di mana-mana.

Hos lompat berhampiran pangkalan data memendekkan laluan dan wajar dimiliki, tetapi ia tidak mengubah persoalan pemilikan. Sesi tetap berakhir apabila rangkaian berakhir. Gunakannya untuk memerhati, bukan untuk menjadi perkara yang memastikan kerja terus hidup.

Tinggalkan rekod yang boleh dibaca oleh sesi seterusnya

Catatkan nama tugas atau pengenal, pangkalan data sasaran dan hasil yang anda jangkakan. Rekod itulah yang membolehkan sesi lain, atau orang lain, menjawab soalan yang tidak dapat dijawab oleh ralat itu. Tanpanya anda hanya mempunyai ingatan kabur tentang kemas kini dan tiada cara untuk menyemaknya.

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

Sejarah menunjukkan hasil dan masa bagi setiap langkah, yang lebih berguna daripada satu bendera kejayaan. Untuk tugasan yang mengubah data, tambahkan juga pengesahan aplikasi itu sendiri: kiraan baris, checksum atau baris status yang ditulis oleh tugas itu. Dua rekod bebas inilah yang menjadikan percubaan semula selamat, dan sejarah tugas yang direkodkan ialah yang pertama.

Selaraskan sebelum menghantar semula

Apabila sambungan pemerhatian hilang, cari larian sedia ada sebelum memulakan yang lain. Baca hasil langkahnya dan tentukan sama ada kerja itu telah dikomit, sebahagiannya selesai atau tidak pernah bermula. Hanya selepas itu gunakan peraturan percubaan semula yang ditakrifkan oleh aliran kerja, kerana penghantaran semula secara buta boleh menduplikasi pemuatan atau gagal di pertengahan jalan untuk kali kedua.

Kekalkan pemilik tahan lama dan hasil yang boleh diperiksa, dan kegagalan akses yang singkat menjadi kesulitan dan bukannya tekaan. Itulah keseluruhan matlamat reka bentuk: kerja sepatutnya hidup lebih lama daripada sambungan yang memintanya.