Често виждам „проблеми“, които включват изисквания към SQL Server за извършване на „мръсна работа“ като:
- В моя тригер трябва да копирам файл към/от мрежата
- Моята съхранена процедура трябва да FTP файл
- След приключване на архивирането ми трябва SQL Server, за да го архивирам, да направя копие и след това да го архивирам.
- Когато се добави клиент, искам да създам нова база данни и да направя куп неща в Active Directory
- Моята задача на SQL Server Agent трябва да сканира директория за файлове и да извършва групови вмъквания, когато намери нови.
Това не е изчерпателен списък; Вероятно бих могъл да запълня страница. Въпросът е, че изпълнението на тези задачи от SQL Server представлява значителни пречки:
Сигурност
Обикновено за всичко, за което смятате, че SQL Server се нуждае от файлова система или друг достъп на ниво операционна система, вие или (а) ще дадете изрични права на карт бланш на акаунта за услуги на SQL Server (и/или акаунтите на SQL агент/прокси), или (б) просто настройте акаунтите за услуги на SQL Server да работят като съществуващ акаунт в домейн, който вече има всички тези права. Това е „лесното“ решение – сега, вместо индивидуално да предоставяте достъп до тази папка и този споделен ресурс и този друг ресурс, просто избършете ръцете си, защото те вече са администратори на домейна. След това активирате настройките на ниво сървър, които са деактивирани по подразбиране, но ви пречат да изпълните една или повече от горните задачи (напр. xp_cmdshell ).
Не мисля, че трябва да обяснявам нивото на експозиция, което тези действия могат да представляват. Или какви проблеми могат да се случат, ако това е действителен акаунт на служител и този служител си отиде – или определи, че е недоволен, преди да си отиде. Мда. Виждал съм няколко случая, когато се използва общ акаунт за всички SQL сървъри. Познайте какво се случва, ако/когато трябва да промените паролата за акаунт на домейн, който се използва активно от десетки или стотици екземпляри на SQL Server? Няма значение колко често ще се случва, ако не изключите този потребител от правилата за нулиране на парола?
Ефективност
В допълнение към проблемите със сигурността, излизането извън сървъра на базата данни може да доведе до забавяне, докато SQL Server разчита на някакъв външен процес, върху който няма контрол. Наистина ли транзакцията на базата данни трябва да изчака компресирането и копирането на файл или завършването на FTP трансфера, или вашият резервен домейн контролер да отговори? Как се комбинира това, когато няколко потребители изпълняват подобни задачи, като всички се конкурират за една и съща честотна лента и/или дискови глави? Също така трябва да имате предвид, че след като SQL Server е казал на някакъв пакетен файл да направи нещо, тогава съдържащата се транзакция се връща назад, не можете да отмените външното действие.
Отговорът
Е, обикновено – и винаги има изключения – отговорът е да се използват външни процеси за тези задачи, които наистина са външни за SQL Server. Използвайте PowerShell, използвайте C#, използвайте пакетни файлове; по дяволите, използвайте VBScript. Помислете кои от тези задачи наистина трябва да бъдат решени *незабавно* и докато транзакцията все още е активна – подозирам, че не са много. Създайте таблица на опашката за тях и запишете в таблицата на опашката вътре в транзакцията (която ще бъде върната назад, ако транзакцията не е успешна). След това имайте фонова задача или скрипт, който консумира редове от таблицата на опашката, изпълнява асоциираната(ите) задача(и) и изтрива или маркира всеки ред като завършен. Допълнителен бонус:SQL Server Agent не се изисква тук, така че можете да използвате всеки корпоративен планировчик, а методологията все още работи със SQL Server Express.
