Løsning af SQL Server Fejl 5: Adgang Nægtet

Mange databaseadministratorer og udviklere har på et tidspunkt stødt på den frustrerende fejlmeddelelse: "Operativsystemfejl 5: Adgang nægtet." Denne fejl opstår typisk, når du forsøger at gendanne en backup, oprette en ny database, tilknytte en eksisterende database eller endda under almindelig drift. Fejlen indikerer, at SQL Server-processen ikke har de nødvendige rettigheder til at læse eller skrive til den fil eller mappe, den forsøger at få adgang til. Selvom det kan virke alarmerende, er årsagen næsten altid relateret til filsystemets tilladelser og kan løses med en systematisk tilgang. I denne artikel vil vi dykke ned i de bagvedliggende årsager til Fejl 5 og give en omfattende guide til, hvordan du fejlfinder og løser problemet.

Hovedårsager til 'Adgang Nægtet' Fejl 5 i SQL Server

For at løse et problem effektivt, er det afgørende at forstå, hvorfor det opstår. Fejl 5 er sjældent et problem med selve SQL Server-softwaren, men snarere med det miljø, den opererer i. Her er de mest almindelige syndere:

• Utilstrækkelige Tilladelser: Den mest hyppige årsag er, at den servicekonto, som SQL Server-tjenesten kører under, ikke har læse/skrive-rettigheder til den mappe, hvor databasefilerne (.mdf, .ndf, .ldf) eller backup-filerne (.bak) er placeret. Det er ikke din personlige brugerkonto, der er afgørende, men den konto, som selve SQL Server-tjenesten bruger.
• Forkert Filsti: En simpel tastefejl i filstien, når du kører et T-SQL-script til at oprette eller gendanne en database, kan føre til denne fejl. Hvis stien ikke eksisterer, kan SQL Server ikke få adgang til den.
• Kørsel uden Administratorrettigheder: Hvis du bruger SQL Server Management Studio (SSMS) uden at køre det som administrator, kan det i visse situationer begrænse dine muligheder for at udføre operationer, der interagerer dybt med filsystemet.
• Filen er i Brug eller Skrivebeskyttet: Hvis en anden proces (f.eks. et antivirusprogram eller en anden backup-software) har låst filen, eller hvis filattributterne er sat til 'skrivebeskyttet', vil SQL Server få en adgang nægtet fejl.
• Korrupte Filer: I sjældnere tilfælde kan en korrupt database- eller backupfil forårsage uforudsigelige fejl, herunder adgangsproblemer, når SQL Server forsøger at læse filens metadata.
• Problemer med Netværksdrev: Når du forsøger at tage backup til eller gendanne fra et netværksdrev, bliver tilladelsesproblematikken mere kompleks. SQL Server-servicekontoen skal have eksplicitte rettigheder til at tilgå netværksressourcen, hvilket ofte kræver konfiguration af domænekonti.

Trin-for-trin Løsninger til at Rette Fejlen

Nu hvor vi kender de potentielle årsager, lad os gennemgå løsningerne systematisk. Start med den mest sandsynlige og simple løsning først.

Løsning 1: Kør SSMS som Administrator

Dette er den hurtigste ting at prøve. Luk SQL Server Management Studio ned. Find SSMS-ikonet i din Start-menu, højreklik på det, og vælg "Kør som administrator". Dette giver SSMS forhøjede rettigheder og kan i nogle tilfælde løse simple tilladelseskonflikter, især på udviklingsmaskiner.

Løsning 2: Verificer og Tildel Korrekte Mappetilladelser

Dette er den mest almindelige løsning. Du skal sikre, at SQL Server-servicekontoen har de nødvendige tilladelser.

1. Find SQL Server Servicekontoen: Først skal du identificere, hvilken konto din SQL Server-instans bruger. Åbn SSMS og kør følgende forespørgsel:
   SELECT servicename, service_account FROM sys.dm_server_services;
   Resultatet vil vise dig kontonavnet, f.eks. 'NT Service\MSSQLSERVER' for standardinstansen eller en domænekonto som 'DOMÆNE\sqlservice'.
2. Naviger til Mappen: Brug Stifinder til at gå til den mappe, hvor dine databasefiler eller backup-filer er placeret (f.eks. `C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA` eller din backup-mappe).
3. Rediger Sikkerhedsindstillinger: Højreklik på mappen og vælg "Egenskaber". Gå til fanen "Sikkerhed" og klik på "Rediger...".
4. Tilføj Servicekontoen: Klik på "Tilføj...". Indtast det kontonavn, du fandt i trin 1, og klik på "Kontroller navne". Når navnet er fundet og understreget, klik "OK".
5. Tildel Fuld Kontrol: Med den nye konto markeret i listen, skal du sætte et flueben i "Tillad" for "Fuld kontrol". Dette giver kontoen alle nødvendige rettigheder til at læse, skrive, ændre og slette filer i mappen. Klik "Anvend" og "OK".

Efter at have anvendt disse ændringer, prøv din operation (gendannelse, oprettelse osv.) igen.

Løsning 3: Kontroller Filstier og Filnavne

Dobbelttjek dine scripts. En simpel fejl som `C//Backups` i stedet for `C:\Backups` kan forårsage fejl. Sørg for, at stien er fuldstændig korrekt, og at den mappe, du refererer til, rent faktisk eksisterer. Når du bruger SSMS' grafiske brugerflade, skal du sikre dig, at du navigerer til den korrekte fil og ikke ved et uheld vælger en forkert fil med et lignende navn.

Håndtering af Mere Komplekse Scenarier

Hvis de grundlæggende løsninger ikke virker, kan problemet være mere komplekst, f.eks. relateret til filkorruption eller specifikke konfigurationer.

Reparation af en Korrupt Database

Hvis du har mistanke om, at selve databasefilen (.mdf) er korrupt, og du ikke har en brugbar backup, kan du som en sidste udvej forsøge at reparere den. SQL Server har et indbygget værktøj til dette.

Advarsel: Brug af reparationsmuligheder kan medføre datatab. Forsøg altid at gendanne fra en backup først.

Kommandoen DBCC CHECKDB kan bruges til at kontrollere og reparere databasen. Sæt først databasen i single-user mode:

ALTER DATABASE [DinDatabase] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

Kør derefter reparationen:

DBCC CHECKDB ('DinDatabase', REPAIR_ALLOW_DATA_LOSS);

Når den er færdig, skal du sætte databasen tilbage i multi-user mode:

ALTER DATABASE [DinDatabase] SET MULTI_USER;

Sammenligning af Løsningsmetoder

Ofte Stillede Spørgsmål (OSS)

Hvorfor får jeg stadig Fejl 5, selvom min Windows-bruger er administrator?

Det er en almindelig misforståelse. SQL Server udfører ikke filoperationer med din brugerkonto. Den bruger sin egen dedikerede servicekonto. Selvom du er administrator, skal den specifikke konto, som SQL Server-tjenesten kører under (f.eks. 'NT SERVICE\MSSQLSERVER'), have de nødvendige rettigheder til filsystemet.

Kan fejlen opstå ved backup til Azure Blob Storage?

Ja. Princippet er det samme. Når du tager backup til eller gendanner fra en URL (Azure Blob Storage), skal SQL Server have tilladelse til at tilgå den cloud-ressource. Dette håndteres typisk ved at oprette en 'Credential' i SQL Server ved hjælp af et Shared Access Signature (SAS) token fra Azure. Hvis dit SAS token er udløbet, forkert, eller ikke har de rette tilladelser (læse/skrive/liste), vil du modtage en lignende 'Access is denied' fejl.

Hvad gør jeg, hvis backup-filen (.bak) er korrupt?

En korrupt backup-fil kan ikke gendannes direkte. Hvis du har en anden, ældre backup, er det den bedste løsning. Hvis ikke, findes der specialiserede tredjepartsværktøjer, der kan forsøge at udtrække data fra en beskadiget .bak-fil. Det er dog vigtigt at have en robust backup-strategi for at undgå at komme i denne situation.

Konklusion

SQL Server Fejl 5, "Adgang Nægtet", er næsten altid et symptom på et tilladelsesproblem mellem SQL Server-tjenesten og filsystemet. Ved at følge en logisk fejlfindingsproces – startende med at køre SSMS som administrator, verificere filstier, og vigtigst af alt, sikre at SQL Server-servicekontoen har 'Fuld kontrol' over de relevante mapper – kan problemet løses i langt de fleste tilfælde. Husk altid at skelne mellem din egen brugerkonto og den servicekonto, SQL Server opererer under. Med en korrekt konfiguration af tilladelser kan du sikre en stabil og problemfri drift af din database-server.