Dostawca chce uruchamiać zadanie MSDB co 5 minut dla aplikacji biznesowej

Mamy zewnętrznego dostawcę, który próbuje zintegrować 2 różne aplikacje, w których obie bazy danych znajdują się w naszym wystąpieniu programu SQL Server z ponad 150 innymi bazami danych, i chcą utworzyć zadanie MSDB w celu „synchronizacji” 2 różnych aplikacji co 5 minut (początkowo chciałem uruchamiać go co minutę).

Moje początkowe przeczucie polega na tym, że zamiast tego powinni to zrobić w warstwie aplikacji za pomocą zaplanowanego zadania systemu Windows, a może nawet przerażającego wyzwalacza (do czego zwykle uciekamy się w takich sytuacjach).

Wolę, aby zadania MSDB były zarezerwowane dla zadań DBA w jak największym stopniu, aby zmniejszyć bałagan, a także natrafiłem na powolne zapytania do MSDB podczas przeglądania historii zadań z bardzo aktywnymi zadaniami takimi jak ta (które również zagłuszają i usuwają ważne historie zadań ważniejsze rzeczy, takie jak historie kopii zapasowych). Ale z drugiej strony, może moje preferencje są błędne i muszę zrobić trochę miejsca dla warstwy aplikacji w MSDB i zakasać rękawy i naprawić problemy związane z wczytywaniem historii zadań, gdy muszę zachować znacznie więcej wpisów historii, aby przechwycić ważne rzeczy, takie jak kopie zapasowe (lub wyczyść hiperaktywne wpisy zadań).

Inną kwestią, którą mam, jest to, że teraz muszę przyznać temu dostawcy uprawnienia „sysadmin” zamiast tylko uprawnienia „dbo” tylko na swoich bazach danych, gdy przeprowadzają aktualizacje za pośrednictwem interfejsu GUI, i mam nadzieję, że nie wysadzą przypadku, w którym moja misja jest krytyczna DB to (jedna z wad konsolidacji).

Wydaje mi się, że mogę umieścić je w innej „izolowanej” instancji, w której umieszczamy wszystkich dostawców, którzy nie grają dobrze, ale wtedy musimy ponownie skonfigurować aplikacje, aby wskazywały na nową instancję SQL ( westchnienie niestety nie jest trywialne w tym przypadku).

Sprzedawca już odpowiedział na moje obawy, mówiąc o tym, jak złe są wyzwalacze. Więc „trochę googlowałem” i wyszedłem pusty. Czy ktoś widział jakikolwiek link „wyglądający autorytatywnie”, że jest to zły pomysł i mogę go do niego skierować? Czy powinienem przyjąć ich podejście?

Nie sądzę, że kiedykolwiek pisałem na forum sql, zanim poprosiłem o pomoc, więc mam nadzieję, że moje zapytanie jest odpowiednio sformułowane.

EDYCJA: Korzystamy z SQL Server 2008 Enterprise R2 x64 SP1 (Dziękujemy za wskazanie, że zapomniałem wspomnieć o wersji!). Hmmm, mam nadzieję, że nie będą musieli zmieniać swoich skryptów aktualizacji MSDB, kiedy przejdziemy do nowszej wersji.

Dziękuję za Twój czas! Bogaty

IMO twój sprzedawca jest właściwie na dobrej drodze.

Zadanie warstwy aplikacji wymagałoby od niego ponownego wykonania wielu gotowych funkcji SQL Agent (np. Logiki, aby nie uruchamiać już uruchomionego zadania, zaproponować rozwiązanie do przechowywania zabezpieczeń i poświadczeń, zintegrować wyniki zadania z raportowanie błędów i śledzenie wyników w SQL itp. itd. itd.). I, co najważniejsze, zapewnij zapasowe / HA / DC rozwiązanie do planowania. Nie chcesz, aby historia odzyskiwania po awarii była następująca: „a po zakończeniu odzyskiwania serwera rezerwowego utwórz 50 zadań harmonogramu NT”. Więc ma rację, odpychając się od korzystania z harmonogramu systemu, nie ma on żadnych funkcji ani możliwości, jakie ma Agent.

Jeszcze bardziej ma rację, odpychając się od wyzwalaczy. Zastąpienie zadania okresowego wyzwalaczem synchronicznym zwiększa opóźnienie żądania, zwiększa spójność i łączenie (pomyśl zmiany schematu ...), zwiększa ryzyko przestoju z powodu problemów z synchronizacją (błąd wyzwalania -> błąd aplikacji vs. błąd zadania -> napraw i spróbuj ponownie później) , dramatycznie zwiększa problemy z impasem (z powodu krzyżowych aktualizacji między śledzonymi / śledzonymi) i ma wiele innych problemów.

Najłatwiejszym rozwiązaniem jest zadanie agenta i msdbw żadnym wypadku nie jest zarezerwowane dla DBA. Bardziej wymyślnym rozwiązaniem byłoby użycie timerów konwersacji i wewnętrznej aktywacji , które miałyby pewne zalety w stosunku do zadań Agenta, głównie ze względu na ograniczenie (wszystko znajduje się w bazie danych aplikacji, pomyśl o dublowaniu scenariuszy przełączania awaryjnego), ale całkowicie rozumiem, czy twój dostawca jest niechętnie wypróbowuje coś, co wymaga bardzo konkretnej wiedzy. BTW Mam nadzieję, że nie masz na myśli jednego zadania co 5 minut na DB .

Jeśli chodzi o uprawnienia sysadmin: nazwa gry to podpisywanie kodu . Możesz wyrazić zgodę na określone procedury, sprawdzone i zatwierdzone przez Ciebie, podpisując je prywatnym certyfikatem.

Osobiście wolę używanie wyzwalaczy do obsługi przynajmniej części synchronizacji. Nie dbam szczególnie o zaplanowaną synchronizację odpytywania, ponieważ musisz poradzić sobie z potencjalnymi konfliktami, nieaktualnymi danymi, wpływem powtarzalnego zadania na wydajność itp. Jeśli chcą to zrobić tak agresywnie, jak 1–5 minut, zgaduję ma to na celu złagodzenie konfliktów i stagnacji, a natychmiastowość wyzwalacza rozwiązałaby ten problem.

Jeśli wszystko dzieje się na tym samym serwerze, prawdopodobnie dobrze jest umieścić kod synchronizacji w wyzwalaczach lub wywołać procedurę wyzwalającą, która synchronizuje każdy rekord, którego dotyczy problem. Jeśli synchronizacja obejmuje serwery lub chcesz się upewnić, że posiadanie jednej bazy danych w trybie offline nie uniemożliwi korzystania z drugiej bazy danych, skorzystaj z usługi Service Broker do obsługi aktualizacji asynchronicznych. Zrobiłem to, aby zsynchronizować dane dotyczące sprzedaży z danymi CRM między dwoma różnymi serwerami, jednocześnie umożliwiając przełączenie jednego z serwerów w tryb offline bez wpływu na drugą aplikację. Po ponownym uruchomieniu Service Broker dostarcza wiadomości i aktualizuje dane na zdalnym serwerze.

I tak naprawdę nie ma nic złego w wyzwalaczach, ale podobnie jak większość aspektów T-SQL, bardzo możliwe jest pisanie kodu, który działa okropnie. Napisałem artykuł o częstych pułapkach wyzwalaczy, jeśli to pomaga.

Pisanie dobrze zachowanych wyzwalaczy