Często widzę „problemy”, które wiążą się z wymaganiami SQL Servera do wykonywania „brudnej pracy”, takich jak:
- W moim wyzwalaczu muszę skopiować plik do/z sieci
- Moja procedura składowana wymaga FTP pliku
- Po zakończeniu tworzenia kopii zapasowej potrzebuję programu SQL Server, aby go skompresować, wykonać kopię, a następnie zarchiwizować
- Po dodaniu klienta chcę utworzyć nową bazę danych i zrobić kilka rzeczy w Active Directory
- Moje zadanie agenta SQL Server musi przeskanować katalog w poszukiwaniu plików i wykonać zbiorcze wstawianie, gdy znajdzie nowe
Ta lista nie jest wyczerpująca; Prawdopodobnie mógłbym wypełnić stronę. Chodzi o to, że wykonywanie tych zadań z poziomu SQL Server stwarza poważne przeszkody:
Bezpieczeństwo
Zazwyczaj w przypadku wszystkiego, co uważasz, że SQL Server wymaga dostępu do systemu plików lub innego systemu operacyjnego, będziesz albo (a) przyznać jawne prawa carte blanche kontu usługi SQL Server (i/lub SQL Agent/kont proxy), lub (b) po prostu ustaw konta usługi SQL Server tak, aby działały jako istniejące konto domeny, które ma już wszystkie te prawa. To jest „łatwe” rozwiązanie – teraz zamiast indywidualnie przyznawać dostęp do tego folderu i tego udziału oraz tego innego zasobu, po prostu wycierasz ręce, ponieważ są już administratorami domeny. Następnie włączasz ustawienia na poziomie serwera, które są domyślnie wyłączone, ale przeszkadzają w wykonaniu jednego lub więcej z powyższych zadań (np. xp_cmdshell ).
Myślę, że nie muszę wyjaśniać, jaki poziom ekspozycji mogą reprezentować te działania. Lub jakie problemy mogą się wydarzyć, jeśli jest to rzeczywiste konto pracownika, a pracownik odejdzie – lub stwierdzi, że jest niezadowolony, zanim odejdzie. Ojej. Widziałem kilka przypadków, w których dla wszystkich serwerów SQL używane jest wspólne konto. Zgadnij, co się stanie, jeśli/kiedy trzeba zmienić hasło do konta domeny, które jest aktywnie używane przez dziesiątki lub setki instancji SQL Server? Nieważne, jak często się to stanie, jeśli nie wykluczysz tego użytkownika z zasad resetowania hasła?
Wydajność
Poza kwestiami bezpieczeństwa, wyjście poza serwer bazy danych może powodować opóźnienia, podczas gdy SQL Server opiera się na jakimś zewnętrznym procesie, nad którym nie ma kontroli. Czy transakcja bazy danych naprawdę musi czekać na skompresowanie i skopiowanie pliku, zakończenie transferu FTP lub odpowiedź zapasowego kontrolera domeny? Jak to się składa, gdy kilku użytkowników wykonuje podobne zadania, wszyscy konkurują o tę samą przepustowość i/lub głowice dysków? Należy również wziąć pod uwagę, że gdy SQL Server nakaże jakiemuś plikowi wsadowemu coś zrobić, a następnie zawierająca transakcję zostanie wycofana, nie można wycofać zewnętrznej akcji.
Odpowiedź
Cóż, zwykle – i zawsze są wyjątki – odpowiedzią jest użycie procesów zewnętrznych do tych zadań, które naprawdę są zewnętrzne względem SQL Server. Użyj PowerShell, użyj C#, użyj plików wsadowych; do licha, użyj VBScript. Zastanów się, które z tych zadań naprawdę trzeba wykonać *natychmiast* i póki transakcja jest nadal aktywna – podejrzewam, że niewiele. Zbuduj dla nich tabelę kolejek i zapisz do tabeli kolejek wewnątrz transakcji (która zostanie wycofana, jeśli transakcja się nie powiedzie). Następnie przygotuj zadanie lub skrypt w tle, który zużywa wiersze z tabeli kolejki, wykonuje skojarzone zadania i usuwa lub oznacza każdy wiersz jako zakończony. Dodatkowa premia:agent SQL Server nie jest tutaj wymagany, więc możesz użyć dowolnego harmonogramu korporacyjnego, a metodologia nadal działa z SQL Server Express.
