Mengimbangi waktu mulai jadwal pekerjaan Agen Server SQL antar instans

Saya memiliki tugas agen yang ditetapkan untuk menjalankan pencadangan log setiap dua jam mulai pukul 02.00 hingga 23.59 (meninggalkan jendela untuk menjalankan pencadangan penuh atau diferensial). Pekerjaan serupa dilakukan di setiap 50 contoh saya. Saya mungkin menambahkan beberapa ratus contoh dari waktu ke waktu (kami menghosting SQL Server untuk beberapa pelanggan kami). Semuanya dicadangkan ke volume disk SAN yang sama. Hal ini menyebabkan masalah latensi dan berdampak pada kinerja.

Saya ingin mengimbangi waktu pelaksanaan pekerjaan pada setiap instance sebanyak 5 menit, sehingga instance yang satu akan menjalankan pekerjaan pada pukul 2:00, 4:00, dst., instance dua akan menjalankannya pada 2:05, 4:05 , dll., contoh tiga akan menjalankannya pada 2:10, 4:10, dll. dan seterusnya. Jika saya mengimbangi waktu mulai pekerjaan pada setiap instance (2:00 misalnya satu, 2:05 misalnya dua, 2:10 misalnya tiga, dll.), dapatkah saya berharap bahwa saya akan mendapatkan hasil yang saya inginkan? tidakkah semua instance menjalankan pekerjaan secara bersamaan?


sql-server job-scheduling sql-agent-job sql-server-agent
person Mark Freeman    schedule 28.08.2013    source sumber

Jawaban (2)


arrow_upward
2
arrow_downward

Jika ini adalah percakapan yang sama yang baru saja kita lakukan di twitter: ketika Anda memberi tahu Agen SQL Server untuk berjalan setiap n menit atau setiap n jam, proses selanjutnya didasarkan pada waktu mulai, bukan selesai waktu. Jadi, jika Anda menyetel tugas pada instance 1 agar dijalankan pada pukul 2:00 dan dijalankan setiap 2 jam, maka eksekusi kedua akan dijalankan pada pukul 4:00, baik eksekusi pertama membutuhkan waktu 1 menit, 12 menit, 45 menit, dan seterusnya.

Ada beberapa peringatan:

  • mungkin ada sedikit penundaan karena sinkronisasi agen internal, tapi saya belum pernah melihatnya lebih dari beberapa detik
  • jika eksekusi pertama pada pukul 02.00 memakan waktu lebih dari 2 jam (namun kurang dari 4 jam), kali berikutnya tugas dijalankan pada pukul 06.00 (pengoperasian pukul 04.00 dilewati, maka tugas tersebut akan dijalankan pada pukul 06.00. tidak berjalan pada 4:10 atau 4:20 untuk "mengejar ketinggalan")

Ada saran lain untuk menambahkan WAITFOR untuk mengimbangi waktu mulai (dan kita harus membuang WAITFOR acak, karena mungkin bukan itu yang Anda inginkan - acak ‹> unik). Jika Anda ingin melakukan hard-code penundaan yang berbeda pada setiap instance (1 menit, 2 menit, dll.) maka akan jauh lebih mudah untuk melakukannya dengan jadwal daripada menambahkan langkah-langkah ke semua pekerjaan Anda. MENURUT OPINI SAYA.

person Aaron Bertrand    schedule 28.08.2013
comment
Itu sebabnya saya memasukkan URL ke halaman ini di Tweet saya. Pekerjaan biasanya selesai dalam beberapa menit (semua database berukuran di bawah 10 GB). Variasi beberapa detik tidak membuat saya khawatir. Saya hanya tidak ingin 50 cadangan log semuanya mencoba menulis ke tujuan yang sama dan berbagi pada waktu yang sama. Tampaknya Anda sudah menyediakannya. Terima kasih! Saya mencari jaminan bahwa jika saya menetapkan offset waktu mulai tersebut sekarang, saya akan mendapatkan hasil yang diharapkan mulai pukul 02.00 malam ini. - person Mark Freeman; 28.08.2013
comment
@Mark Maaf, saya tidak mengklik tautannya. - person Aaron Bertrand; 28.08.2013

arrow_upward
0
arrow_downward

Mungkin Anda dapat menyiapkan DB terpusat yang mengelola "jadwal" dan meminta pekerjaan menambah/memperbarui satu baris saat dijalankan. Dengan cara ini setiap server berikutnya dapat memulai pekerjaan yang "melakukan jajak pendapat" kapan dapat dimulai. Dengan cara ini, setiap latensi dalam pekerjaan akan menyebabkan pekerjaan lain menunggu sehingga Anda tidak memiliki perbedaan dalam pengaturan waktu ketika salah satu server dimatikan.

Karena sedikit paranoid, saya akan menambahkan skenario umum yang mengatakan setelah "x" menit menunggu, tetap lanjutkan sehingga penundaan tidak terjadi cukup jauh sehingga pekerjaan tidak berjalan.

person Shawn E    schedule 28.08.2013
comment
Sangat rumit. Saya tidak ingin menyiapkan server tertaut di setiap instance sehingga mereka dapat berkomunikasi dengan database pusat dan menulis banyak kode jika hanya dengan mengubah waktu mulai pada jadwal pekerjaan akan menyelesaikan masalah. Bukan masalah besar jika beberapa akhirnya tumpang tindih, tapi semuanya mengenai satu waktu jelas merupakan masalah. - person Mark Freeman; 28.08.2013