Ik zie vaak "problemen" die betrekking hebben op vereisten voor SQL Server om "vuil werk" uit te voeren, zoals:
- In mijn trigger moet ik een bestand naar/van het netwerk kopiëren
- Mijn opgeslagen procedure moet een bestand FTP-en
- Nadat de back-up is voltooid, heb ik SQL Server nodig om het te zippen, een kopie te maken en het vervolgens te archiveren
- Als een klant wordt toegevoegd, wil ik een nieuwe database maken en een heleboel dingen doen in Active Directory
- Mijn SQL Server Agent-taak moet een map scannen op bestanden en bulkinvoegingen uitvoeren wanneer er nieuwe worden gevonden
Dit is geen uitputtende lijst; Ik zou waarschijnlijk een pagina kunnen vullen. Het punt is dat het uitvoeren van deze taken vanuit SQL Server aanzienlijke obstakels met zich meebrengt:
Beveiliging
Voor alles waar u van mening bent dat SQL Server toegang tot een bestandssysteem of ander besturingssysteem nodig heeft, gaat u ofwel (a) expliciete carte blanche-rechten geven aan het SQL Server-serviceaccount (en/of de SQL Agent-/proxyaccounts), of (b) stel SQL Server-serviceaccounts zo in dat ze worden uitgevoerd als een bestaand domeinaccount dat al over al deze rechten beschikt. Dit is de "gemakkelijke" oplossing - nu, in plaats van individueel toegang te verlenen tot deze map en die share en deze andere bron, veeg je gewoon je handen af omdat ze al domeinbeheerders zijn. Vervolgens schakelt u instellingen op serverniveau in die standaard zijn uitgeschakeld, maar die u in de weg staan om een of meer van de bovenstaande taken uit te voeren (bijv. xp_cmdshell ).
Ik denk niet dat ik hoef uit te leggen hoeveel blootstelling deze acties kunnen vertegenwoordigen. Of wat voor soort problemen er kunnen gebeuren als dit een echt werknemersaccount is en die werknemer weggaat - of vaststelt dat hij/zij ontevreden is voordat ze weggaan. Jakkes. Ik heb verschillende gevallen gezien waarin een gemeenschappelijk account wordt gebruikt voor alle SQL-servers. Raad eens wat er gebeurt als/wanneer u het wachtwoord moet wijzigen voor een domeinaccount dat actief wordt gebruikt door tientallen of honderden SQL Server-instanties? Maakt niet uit hoe vaak het zal gebeuren als u die gebruiker niet uitsluit van het beleid voor het opnieuw instellen van wachtwoorden?
Prestaties
Naast beveiligingsproblemen kan het buiten de databaseserver gaan vertragingen veroorzaken, terwijl SQL Server afhankelijk is van een extern proces waar het geen controle over heeft. Moet de databasetransactie echt wachten tot een bestand is gecomprimeerd en gekopieerd, of totdat een FTP-overdracht is voltooid, of totdat uw back-updomeincontroller reageert? Hoe werkt dit als meerdere gebruikers vergelijkbare taken uitvoeren, die allemaal strijden om dezelfde bandbreedte en/of schijfkoppen? U moet er ook rekening mee houden dat zodra SQL Server een batchbestand heeft verteld om iets te doen, de bevattende transactie wordt teruggedraaid, u de externe actie niet kunt terugdraaien.
Het antwoord
Welnu, meestal - en er zijn altijd uitzonderingen - is het antwoord om externe processen te gebruiken voor deze taken die echt extern zijn aan SQL Server. Gebruik PowerShell, gebruik C#, gebruik batchbestanden; ach, gebruik VBScript. Bedenk welke van deze taken echt *onmiddellijk* moeten worden afgehandeld en terwijl de transactie nog steeds actief is, vermoed ik niet veel. Bouw hiervoor een wachtrijtabel en schrijf naar de wachtrijtabel binnen de transactie (die wordt teruggedraaid als de transactie niet succesvol is). Zorg vervolgens voor een achtergrondtaak of -script dat rijen uit de wachtrijtabel verbruikt, de bijbehorende taak(en) uitvoert en elke rij verwijdert of markeert als voltooid. Toegevoegde bonus:SQL Server Agent is hier niet vereist, dus u kunt elke bedrijfsplanner gebruiken en de methode werkt nog steeds met SQL Server Express.