Vendor Ingin Menjalankan pekerjaan MSDB setiap 5 menit untuk Aplikasi Bisnis


15

Kami memiliki vendor pihak ke-3 yang mencoba mengintegrasikan 2 aplikasi berbeda di mana kedua DB berada di instance SQL Server kami dengan 150+ DB lain, dan mereka ingin membuat pekerjaan MSDB untuk "menyinkronkan" dua aplikasi yang berbeda setiap 5 menit (pada awalnya mereka ingin menjalankannya setiap menit).

Firasat awal saya adalah bahwa mereka seharusnya melakukan ini entah bagaimana dalam tingkat Aplikasi dengan pekerjaan yang dijadwalkan Windows, atau bahkan mungkin pemicu yang ditakuti (yang biasanya kita gunakan dalam situasi seperti ini).

Saya lebih suka untuk menjaga pekerjaan MSDB dicadangkan untuk tugas-tugas DBA sebanyak mungkin untuk mengurangi kekacauan di sana, dan juga mengalami kesulitan dalam menanyakan MSDB saat melihat riwayat pekerjaan dengan pekerjaan super aktif seperti ini (yang juga menenggelamkan dan mengeluarkan riwayat pekerjaan penting dari hal yang lebih penting seperti riwayat cadangan). Tapi sekali lagi, mungkin preferensi saya salah dan saya perlu membuat beberapa ruang untuk tingkat Aplikasi di MSDB dan menyingsingkan lengan baju saya dan memperbaiki masalah riwayat pekerjaan yang membutuhkan waktu lama untuk memuat ketika saya perlu mempertahankan lebih banyak entri riwayat untuk menangkap hal-hal penting seperti cadangan (atau menghapus entri pekerjaan yang hiper aktif).

Masalah lain yang saya miliki adalah bahwa sekarang saya harus memberikan hak "sysadmin" vendor ini dan bukan hanya hak "dbo" hanya pada DB mereka ketika mereka melakukan peningkatan melalui GUI mereka dan berharap mereka tidak meledakkan contoh di mana misi saya kritis DBs adalah (salah satu kelemahan konsolidasi).

Saya kira saya bisa menempatkan mereka pada contoh "terisolasi" lain di mana kita menempatkan semua vendor yang tidak bermain bagus, tapi kemudian kita perlu mengkonfigurasi ulang Aplikasi untuk menunjuk ke contoh SQL baru ( sayangnya mendesah tidak sepele dalam hal ini).

Vendor telah mendorong kembali kekhawatiran saya berbicara tentang seberapa buruk pemicunya. Jadi, saya "googled" tentang ini sedikit dan muncul kosong. Adakah yang melihat ada tautan di luar sana yang “berwibawa” bahwa ini adalah ide yang buruk dan saya dapat merujuknya? Atau haruskah saya merangkul pendekatan mereka?

Saya tidak percaya saya pernah diposting di forum sql sebelum meminta bantuan, jadi semoga pertanyaan saya dibingkai dengan benar.

EDIT: Kami sedang menjalankan SQL Server 2008 Enterprise R2 x64 SP1 (Terima kasih telah menunjukkan bahwa saya lupa menyebutkan versi!). Hmmm, semoga mereka tidak perlu mengubah skrip pemutakhiran MSDB ketika kami membuka versi yang lebih baru.

Terima kasih atas waktunya! Kaya


Kata-kata yang bagus. Mungkin Anda dapat menambahkan tag dengan versi spesifik yang Anda gunakan (dan juga menyebutkan dalam pertanyaan edisi). Tidak yakin apakah ada perbedaan antara Standar dan Perusahaan tetapi mungkin relevan.
ypercubeᵀᴹ

Anda selalu dapat memberi tahu pekerjaan untuk membersihkan riwayatnya sendiri (Anda dapat menghapus dari tabel MSDB dengan mudah), jadi "lambatnya permintaan tabel sejarah" seharusnya tidak menjadi faktor. Saya akan lebih gugup membiarkan proses eksternal menangani hal ini, justru karena saya kurang memiliki kendali atas sejarah. Juga jika 5 menit adalah "cukup saat ini" mengapa beralih ke pemicu yang akan mempengaruhi setiap operasi DML secara real time?
Aaron Bertrand

PS Saya sangat meragukan skrip penciptaan pekerjaan mereka akan memiliki perubahan antara 2008 R2 dan 2012 kecuali mereka benar-benar mengubah fungsionalitas pekerjaan (yang tidak akan menjadi hal yang spesifik versi kecuali mereka mengambil keuntungan dari beberapa fitur baru). Skrip pekerjaan itu sendiri tidak boleh berubah.
Aaron Bertrand

2
Anda tidak perlu harus memberi mereka sysadminagar mereka memodifikasi pekerjaan agen SQL - lihat msdn.microsoft.com/en-us/library/ms188283(v=sql.105).aspx
SQLFox

Terima kasih atas tanggapan cepat semua orang! Saya akan merangkul pendekatan mereka dan melihat pembersihan bersama dengan tidak memberi mereka sysadmin.
rzuech

Jawaban:


12

IMO vendor Anda sebenarnya ada di jalur yang benar.

Pekerjaan lapisan aplikasi akan mengharuskan dia untuk mengulang banyak fitur SQL Agent out-of-the-box (mis. Logika untuk tidak menjalankan pekerjaan yang sudah berjalan, datang dengan solusi toko keamanan dan kredensial, mengintegrasikan hasil pekerjaan dengan pelaporan kesalahan dan pelacakan hasil dalam SQL dll dll dll). Dan, yang paling penting, menyediakan solusi cadangan / HA / DC untuk penjadwalan. Anda tidak ingin cerita pemulihan bencana Anda menjadi 'dan setelah Anda selesai memulihkan server siaga pergi buat 50 tugas penjadwal NT ini'. Jadi dia benar dalam mendorong kembali menggunakan penjadwal sistem, ia tidak memiliki fitur dan kemampuan yang dimiliki Agen.

Dia bahkan lebih benar dalam mendorong balik terhadap pemicu. Mengganti pekerjaan berkala dengan pemicu sinkron meningkatkan latensi permintaan, meningkatkan kohesi dan penggandengan (pikirkan skema perubahan ...), meningkatkan risiko downtime karena masalah sinkronisasi (kesalahan pemicu-> kesalahan aplikasi vs. kesalahan pekerjaan-> perbaiki dan coba lagi nanti) , secara dramatis meningkatkan masalah kebuntuan (karena pembaruan lintas antara dilacak / dilacak) dan memiliki banyak lebih banyak masalah.

Solusi termudah memang merupakan pekerjaan Agen, dan msdbsama sekali tidak disediakan untuk DBA. Solusi yang lebih mewah adalah dengan menggunakan pengatur waktu percakapan dan aktivasi internal , yang akan memiliki beberapa keunggulan dibandingkan pekerjaan Agen, terutama karena penahanan (semuanya ada di dalam aplikasi DB, pikirkan mirroring failover skenario), tetapi saya benar-benar dapat memahami jika vendor Anda enggan untuk mencoba sesuatu yang membutuhkan pengetahuan yang sangat spesifik. BTW Saya harap Anda tidak bermaksud satu pekerjaan setiap 5 menit per DB .

Adapun izin sysadmin: nama permainan adalah penandatanganan kode . Anda dapat memberikan izin apa pun untuk prosedur khusus, diperiksa dan divalidasi oleh Anda, dengan menandatanganinya dengan sertifikat pribadi Anda.


Berikut ini tautan ke jawaban Anda di Stack Overflow yang menunjukkan contoh pengatur waktu percakapan dan aktivasi internal: stackoverflow.com/a/4079716
Jon Seigel

1
Saya menandai ini sebagai jawaban yang diterima yang tampaknya merupakan konsensus. Hal terbesar yang saya ambil dari semua ini adalah tidak apa-apa bagi Aplikasi untuk sering menggunakan pekerjaan MSDB, dan saya hanya perlu menggunakan tautan di sini yang disediakan untuk melakukannya dengan cara yang tepat untuk keamanan. Semua orang sangat berwawasan, dan terima kasih atas komentar dan waktu Anda!
rzuech

2

Preferensi pribadi saya adalah menggunakan pemicu untuk menangani setidaknya beberapa bagian dari sinkronisasi. Saya tidak terlalu peduli dengan sinkronisasi pemungutan suara yang dijadwalkan, karena Anda harus berurusan dengan potensi konflik, data basi, dampak kinerja dari pekerjaan berulang, dll. Jika mereka ingin melakukannya dengan agresif seperti 1 hingga 5 menit, saya kira itu untuk mengurangi konflik dan kemantapan, dan kedekatan pemicu akan mengatasi itu.

Jika semuanya terjadi dalam server yang sama, Anda mungkin baik-baik saja menempatkan kode sinkronisasi dalam pemicu, atau meminta pemicu memanggil prosedur tersimpan yang menyinkronkan setiap catatan yang terpengaruh. Jika sinkronisasi mencakup server, atau Anda ingin memastikan bahwa satu basis data offline tidak akan mencegah agar basis data lainnya tidak dapat digunakan, lihatlah menggunakan Broker Layanan untuk menangani pembaruan asinkron. Saya telah melakukan ini untuk menyinkronkan angka entri penjualan dengan data CRM antara dua server yang berbeda, sementara memungkinkan server mana pun untuk offline tanpa mempengaruhi aplikasi lain. Setelah muncul kembali, Service Broker mengirimkan pesan dan memperbarui data di server jarak jauh.

Dan sebenarnya tidak ada yang buruk secara inheren tentang pemicu, tetapi seperti kebanyakan aspek T-SQL, sangat mungkin untuk menulis kode yang berkinerja sangat buruk. Saya menulis artikel tentang perangkap umum pemicu, jika itu membantu.

Menulis Pemicu yang Berperilaku Baik


Ya 2 DB berada di server yang sama. Secara pribadi, saya akan melakukan pemicu juga dan Aplikasi mereka adalah kentang yang cukup kecil relatif terhadap beberapa tugas DB yang cukup berat yang kita miliki di sana. Tapi, saya rasa saya tidak bisa benar-benar meyakinkan vendor karena saya tidak bisa benar-benar menunjukkan hal-hal "praktik terbaik" di luar sana mengenai tidak menggunakan pekerjaan MSDB untuk sinkronisasi Aplikasi. Ditambah lagi, saya sangat menghormati pendapat Harun sehingga saya tidak akan mendesak mereka. db2 Saya membaca tautan Anda dan merasa cukup informatif, dan Service Broker adalah pilihan bagus yang bahkan tidak saya pertimbangkan. Terima kasih!
rzuech

Ya, jika Anda pernah khawatir tentang pemicu kegagalan (database offline, perubahan skema, dll), maka Service Broker adalah jalan yang harus diambil, dengan asumsi Anda menginginkan sinkronisasi (dekat) instan.
db2
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.