Jeg ser ofte "problemer", der involverer krav om, at SQL Server udfører "beskidt arbejde" som:
- I min trigger skal jeg kopiere en fil til/fra netværket
- Min lagrede procedure skal FTP en fil
- Når sikkerhedskopieringen er færdig, skal jeg bruge SQL Server til at zippe den, lave en kopi og derefter arkivere den
- Når en kunde tilføjes, vil jeg oprette en ny database og lave en masse ting i Active Directory
- Mit SQL Server Agent-job skal scanne en mappe for filer og udføre masseindsættelser, når det finder nye
Dette er ikke en udtømmende liste; Jeg kunne nok fylde en side. Pointen er, at udførelsen af disse opgaver fra SQL Server udgør betydelige forhindringer:
Sikkerhed
For alt, hvor du mener, at SQL Server har brug for filsystem eller anden adgang på OS-niveau, vil du typisk enten (a) give eksplicitte carte blanche-rettigheder til SQL Server-tjenestekontoen (og/eller SQL Agent/proxy-konti), eller (b) bare indstille SQL Server-tjenestekonti til at køre som en eksisterende domænekonto, der allerede har alle disse rettigheder. Dette er den "nemme" løsning – nu, i stedet for individuelt at give adgang til denne mappe og den del og denne anden ressource, tørrer du bare dine hænder, fordi de allerede er domæneadministratorer. Derefter aktiverer du indstillinger på serverniveau, der er deaktiveret som standard, men som står i vejen for at udføre en eller flere af ovenstående opgaver (f.eks. xp_cmdshell ).
Jeg tror ikke, jeg behøver at forklare niveauet af eksponering, disse handlinger kan repræsentere. Eller hvilke slags problemer kan der ske, hvis dette er en egentlig medarbejderkonto, og den pågældende medarbejder forsvinder – eller konstaterer, at han/hun er utilfreds, før de går væk. Yikes. Jeg har set flere tilfælde, hvor en fælles konto bruges til alle SQL-servere. Gæt, hvad der sker, hvis/når du skal ændre adgangskoden til en domænekonto, der aktivt bruges af snesevis eller hundredvis af SQL Server-instanser? Er du ligeglad med, hvor ofte det vil ske, hvis du ikke udelukker denne bruger fra politikker for nulstilling af adgangskode?
Ydeevne
Ud over sikkerhedsproblemer kan det at gå uden for databaseserveren medføre forsinkelser, mens SQL Server er afhængig af en ekstern proces, som den ikke har kontrol over. Skal databasetransaktionen virkelig vente på, at en fil bliver komprimeret og kopieret, eller på, at en FTP-overførsel er fuldført, eller på, at din backup-domænecontroller reagerer? Hvordan virker dette sammen, når flere brugere udfører lignende opgaver, som alle konkurrerer om den samme båndbredde og/eller diskhoveder? Du skal også overveje, at når først SQL Server har bedt en batch-fil om at gøre noget, så rulles den indeholdende transaktion tilbage, du kan ikke rulle den eksterne handling tilbage.
Svaret
Tja, normalt – og der er altid undtagelser – er svaret at bruge eksterne processer til disse opgaver, der virkelig er eksterne i forhold til SQL Server. Brug PowerShell, brug C#, brug batchfiler; pokker, brug VBScript. Tænk på, hvilke af disse opgaver der virkelig skal håndteres *med det samme* og mens transaktionen stadig er aktiv – jeg formoder ikke mange. Byg en køtabel til disse, og skriv til køtabellen inde i transaktionen (som vil blive rullet tilbage, hvis transaktionen ikke lykkes). Derefter skal du have en baggrundsopgave eller et script, der bruger rækker fra køtabellen, udfører den eller de tilknyttede opgaver og sletter eller markerer hver række som afsluttet. Tilføjet bonus:SQL Server Agent er ikke påkrævet her, så du kan bruge enhver virksomhedsplanlægger, og metoden fungerer stadig med SQL Server Express.