Jag ser ofta "problem" som innebär krav på att SQL Server ska utföra "smutsigt arbete" som:
- I min trigger måste jag kopiera en fil till/från nätverket
- Min lagrade procedur behöver FTP en fil
- När säkerhetskopieringen är klar behöver jag SQL Server för att zippa den, göra en kopia och sedan arkivera den
- När en kund läggs till vill jag skapa en ny databas och göra en massa saker i Active Directory
- Mitt SQL Server Agent-jobb måste skanna en katalog efter filer och utföra massinsättningar när det hittar nya
Detta är inte en uttömmande lista; Jag skulle nog kunna fylla en sida. Poängen är att att utföra dessa uppgifter från SQL Server utgör betydande hinder:
Säkerhet
Vanligtvis, för allt där du anser att SQL Server behöver filsystem eller annan åtkomst på OS-nivå, kommer du att antingen (a) ge explicita carte blanche-rättigheter till SQL Server-tjänstkontot (och/eller SQL Agent/proxy-konton), eller (b) ställ bara in SQL Server-tjänstkonton så att de körs som ett befintligt domänkonto som redan har alla dessa rättigheter. Det här är den "enkla" lösningen – nu, istället för att individuellt ge åtkomst till den här mappen och den resursen och den här andra resursen, torkar du bara dina händer eftersom de redan är domänadministratörer. Därefter aktiverar du inställningar på servernivå som är inaktiverade som standard men som står i vägen för att utföra en eller flera av ovanstående uppgifter (t.ex. xp_cmdshell ).
Jag tror inte att jag behöver förklara graden av exponering som dessa åtgärder kan representera. Eller vilken typ av problem som kan hända om detta är ett verkligt anställdskonto och den anställde försvinner – eller fastställer att han/hon är missnöjd innan de försvinner. Usch. Jag har sett flera fall där ett gemensamt konto används för alla SQL-servrar. Gissa vad som händer om/när du behöver ändra lösenordet för ett domänkonto som aktivt används av dussintals eller hundratals SQL Server-instanser? Strunt i hur ofta det händer om du inte utesluter den användaren från policyerna för lösenordsåterställning?
Prestanda
Förutom säkerhetsproblem kan det att gå utanför databasservern leda till förseningar medan SQL Server förlitar sig på någon extern process som den inte har kontroll över. Behöver databastransaktionen verkligen vänta på att en fil ska komprimeras och kopieras, eller på att en FTP-överföring ska slutföras, eller på att din backupdomänkontrollant ska svara? Hur blir detta när flera användare utför liknande uppgifter, alla konkurrerar om samma bandbredd och/eller diskhuvuden? Du måste också tänka på att när SQL Server har sagt åt någon batchfil att göra något, då den innehållande transaktionen rullas tillbaka, kan du inte återställa den externa åtgärden.
Svaret
Tja, vanligtvis – och det finns alltid undantag – är svaret att använda externa processer för dessa uppgifter som verkligen är externa till SQL Server. Använd PowerShell, använd C#, använd batchfiler; fan, använd VBScript. Tänk på vilka av dessa uppgifter som verkligen behöver hanteras *omedelbart* och medan transaktionen fortfarande är aktiv – jag misstänker att det inte är många. Bygg en kötabell för dessa, och skriv till kötabellen inuti transaktionen (som kommer att rullas tillbaka om transaktionen inte lyckas). Ha sedan en bakgrundsuppgift eller ett skript som förbrukar rader från kötabellen, utför de associerade uppgifterna och tar bort eller markerar varje rad som slutförd. Extra bonus:SQL Server Agent krävs inte här, så du kan använda vilken företagsschema som helst, och metoden fungerar fortfarande med SQL Server Express.