At køre DBCC Shrink-kommandoer er et ret kontroversielt problem på tværs af SQL Server-fællesskabet. I denne artikel vil vi gennemgå detaljer om denne kommando og give et kort overblik over dens brug og også advare dig om risiciene ved at køre denne kommando. Som DBA'er blev en række databaser overdraget fra andre teams eller leverandører, og det er ikke altid, vi får styr på de databaser, vi har oprettet. Som DBA'er skal vi, når vi er involveret i migreringer eller nye projekter, sikre, at vi omhyggeligt planlægger en glidende overgang af databasen til produktion og regelmæssig brug. Det er på dette stadium, vi skal tage højde for størrelsen af databasen. Kan du forestille dig, at du opretter en databaseapplikation uden at overveje vækstprognosen for det første år eller deromkring. Hvad med at oprette en SQL Server-database med en størrelse så lille, at den skal vokse hver anden dag og øge kapacitetsdiskadvarsler midt om natten? Det lyder måske fjollet, men i virkeligheden er sandheden, at dette sker, og det kan nogle gange ikke være i din kontrol.
Få punkter at overveje for den proaktive DBA
Før du overtager support af produktionsdatabaserne, skal du sørge for at tjekke med din forgænger, hvad prognoserne er med hensyn til databasevækst. Er den oprindelige størrelse af de databaser, du vil administrere, tilstrækkelig størrelse? Du skal ikke bekymre dig for meget, hvis den aktuelle størrelse af databasen er meget større end de data, den har i øjeblikket. Husk, du vil ikke have disse diskkapacitetsopkald kl. 3:00 om morgenen, når du helt kunne have undgået det ved at have en database i korrekt størrelse. Det er en generel tendens for databaseadministratorer på tværs af branchen at ofre deres liv sent om aftenen på banale problemer, som godt nok ikke skulle være opstået i første omgang. Husk også serverens diskkapacitet sammen med databasestørrelsen. Du ønsker ikke, at diskstørrelsen skal være alt for lille, end hvad en database kan rumme. Disse er alle enkle ting, der kommer praktisk på planlægningstidspunktet. Men som du ved, er det ikke altid en databaseprofessionel, der installerer eller konfigurerer databaser i første omgang. Det vigtige punkt at bemærke er at få det grundlæggende rigtigt med din database med hensyn til størrelse, og du behøver måske aldrig at køre denne kommando. Men som altid, som en DBA, er der tidspunkter, hvor tingene måske ikke er inden for din kontrol, og i løbet af denne tid kan du bruge DBCC Shrink-filkommandoer til effektiv brug.
Hvornår kan jeg bruge DBCC ShrinkFile?
Du har lige modtaget en diskpladsadvarsel lige midt i din søvn, og du har strenge SLA'er, du skal opfylde. Prioritetsniveauet er en P2, og SLA'en kan blive overtrådt meget snart. Og du indser, at udvidelse af disken ikke kommer til at ske med det første, ja, i så fald, hold dine DBCC ShrinkFile-kommandoer ved hånden, så du kan bruge dem til at genvinde pladsen. Som navnet antyder, formindsker det filen med data- eller logfilen i databasen. Men før du starter med at køre DBCC ShrinkFile-kommandoer, så prøv at tjekke, hvorfor databasefilen vokser i første omgang.
- Voksede filen på grund af en langvarig transaktion?
- Er der nogen form for blokering på serveren?
- Er der en større programudgivelse, som du ikke er blevet informeret om? (Dette sker det meste af tiden)
- Er der nogen form for databasereplikering eller spejlingsproblem, der forårsager databasevækst?
Det er vigtigt at få svar på disse spørgsmål så hurtigt som muligt. Generelt er der ét svar på alle disse spørgsmål, og det er et fantastisk gratis værktøj kaldet sp_whoisactive. Der er ingen ord til at beskrive den enorme brug af dette værktøj, og jeg har brugt det ved flere lejligheder til at løse adskillige produktionsrelaterede problemer. Du kan downloade den seneste kode fra dette link:http://whoisactive.com/ . Det er nemt og enkelt at bruge og returnerer outputtet på ingen tid. Hvis du er garvet DBA, har du allerede dette til din rådighed.
DBCC ShrinkFile med eksempler
Syntaksen for DBCC ShrinkFile er enkel og ligetil, se dette eksempel nedenfor.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Ovenstående eksempel krymper FileName, der tilhører YOURDATABASE, til 1024 MB. Du kan udføre den samme handling ved hjælp af SQL Server Management Studio (SSMS). Højreklik på databasen, gå til Opgaver , vælg Formindsk , og derefter Filer .
Når du klikker på Filer , får du dette vindue.
Her har du mulighed for at vælge filtypen:Data, Log eller Filestream Data og udføre "Shrink action" efter behov. Det er nemmere at bruge selve DBCC-kommandoen til krympende formål.
Brug af DBCC ShrinkFile med yderligere muligheder
Du kan køre kommandoen DBCC ShrinkFile med yderligere muligheder – tom fil, ikke runcate eller truncateonly.
Tøm fil
Du kan bruge kommandoen emptyfile som nedenfor.
use YOURDATABASE go dbcc shrinkfile(FileName,emptyfile)
Dette vil hjælpe med at flytte dataene til andre filer inden for samme filgruppe. Når det er gjort, vil du være i stand til at slette en databasefil, hvis den ikke længere er påkrævet. Der er dog få ting at bemærke med denne tomme fil-indstilling, da du ikke ville være i stand til at gøre meget for at tømme indholdet af den primære datafil med fil-id 1. Kør dette script for at få fil-id-nummeret.
select file_id, name,physical_name from sys.database_files
Her, i dette eksempel, er filnavnet "mo" og fil_id er 1. Når du prøver at tømme filen mo, som har fil_id 1, vil du støde på denne fejlmeddelelse.
Dette skyldes, at der er systemoplysninger i den originale fil, som ikke kan tømmes. Men hvis du prøver den samme kommando på den anden datafil "mo2data", vil den tomme fil-kommando lykkes.
Ikke afkorte
Som navnet antyder, er der ikke frigivet plads tilbage til OS. Dette er mere som en intern operation i filen, hvor siderne bliver omfordelt i selve filen uden at ændre den overordnede størrelse af databasefilen. På grund af dette er der en enorm mulighed for at indføre fragmentering. Se eksemplet nedenfor.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,notruncate); GO
Kun afkortning
Som navnet antyder, frigives ledig plads tilbage til OS fra slutningen af filen. Dette er langt den sikreste operation, du kan køre med DBCC ShrinkFile. Se eksemplet nedenfor.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,truncateonly); GO
Hvad skal man gøre, når DBCC ShrinkFile på transaktionsloggen ikke fungerer som forventet? Se denne sikre metode for at løse problemet
Der er tidspunkter, hvor denne kommando muligvis ikke virker som forventet. Forudsat at du har en situation, hvor du forsøger at formindske logfilen i en database, og det ser ikke ud til at virke. Nedenfor er nogle af de trin, du kan tage for at forstå, hvorfor shrink ikke fungerer som forventet. Du vil bemærke, at formindskelsesfilen vil blive vist som lykkedes, men der er ingen reduktion i størrelsen af logfilen. I så fald skal du køre denne kommando for at kontrollere et par ting om brugen af logfilen.
select name,log_reuse_wait_desc,* from sys.databases
Fra skærmbilledet kan du se, at kolonnen log_reuse_wait_desc venter på log backup.
Her kan du se, at log-backup til databasen skal udføres, før du for alvor kan krympe logfilen. Hvis dette er på en produktionsdatabase, så prøv at udføre log backup på et andet drev, hvor der er ledig plads. For at udføre log backup skal du bruge eksempelkommandoen nedenfor.
backup log DBName to disk='C:\Program Files\Microsoft SQL Server\MSSQL15.A1\MSSQL\Backup\DBName.trn' with init,stats,compression
Når du har kørt backup-kommandoen, skal du køre kommandoen nedenfor igen for at se status for kolonnen log_reuse_wait_desc.
select name,log_reuse_wait_desc,* from sys.databases
Fra skærmbilledet kan du se, at status for kolonnen log_reuse_wait_desc er ændret til "Intet".
Her kan du se, at status for kolonnen "log_reuse_wait_desc" er ændret til "Intet". I dit tilfælde vises det muligvis stadig som "LOG_BACKUP". Fortsæt med at udføre log backups for databasen, indtil status ændres til "Intet". Grunden til, at du stadig kan se "LOG_BACKUP"-statussen, selv efter at du har udført sikkerhedskopiering af transaktionslogfiler, er, at ingen VLF'er muligvis er blevet ryddet, efter du kørte sikkerhedskopieringen af transaktionsloggen. VLF står for Virtual log files og er en del af transaktionsloggens interne arkitektur. Transaktionslogfiler består af disse VLF'er. Du kan få information om VLF'erne ved at køre denne kommando.
select * from sys.dm_db_log_info(5)
Her repræsenterer 5 databasen_id. Skærmbilledet af outputtet vises. Antallet af returnerede rækker repræsenterer det faktiske antal virtuelle logfiler (VLF'er) i databasen. Du kan kontrollere kolonnen "vlf_status" for at kontrollere status for den virtuelle logfil. Værdi 2 betyder, at den er aktiv. Med denne kommando kan du kontrollere de interne flag i transaktionslogfilen for at forstå, hvorfor transaktionsloggen ikke bliver frigivet, selv efter at have udført log backup.
Tidligere var kommandoen, der blev brugt, DBCC LOGINFO, som gav lignende information.
Hvad skal man gøre, når DBCC ShrinkFile på transaktionsloggen ikke fungerer som forventet? Noget du kan udføre på et ikke-prod miljø. Anbefales dog ikke på produktionsmiljø
Du ville være stødt på på flere websteder, at folk anbefaler at ændre genoprettelsesmodellen til en simpel model og derefter køre en formindskelsesfil for at frigive plads tilbage til operativsystemet. Husk på, at ændring af gendannelsesmodellen til en simpel en vil påvirke genoprettelsen af din database, da du ikke ville være i stand til at genoprette til et bestemt tidspunkt. Dette afhænger igen af din virksomheds SLA. Du kan ændre gendannelsesmodellen ved hjælp af T-SQL (nedenfor) eller ved hjælp af GUI.
alter database DB_NAME set recovery simple
Brug GUI'en til at ændre gendannelsesmodellen som vist. Højreklik på databasen, gå til "Egenskaber", klik på "Indstillinger". Vælg "Recovery Model" under "Options".
Du vil bemærke, at blot at ændre gendannelsesmodellen til Simple ikke frigiver pladsen tilbage til OS. Du skal eksplicit køre kommandoen DBCC ShrinkFile for at formindske filen og genvinde pladsen. Se eksempelscriptet nedenfor. Denne kommando vil formindske dit filnavn til 1024 MB.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Automatisk formindsk databaseindstilling
Du vil bemærke, at der er en mulighed kendt som "Auto Shrink" i databaseegenskaberne. Bare højreklik på databasen for at se databaseegenskaben. Under indstillingssektionen vil du se denne mulighed som vist. Fra modeldatabaseindstillingen kan du se, at "Auto Shrink"-indstillingen er deaktiveret som standard. Så hver gang en ny database oprettes, er denne mulighed også i deaktiveret tilstand. Der kan være nogle tilfælde, hvor databaseprofessionelle ubevidst lader denne indstilling være aktiveret uden at være klar over de negative konsekvenser af at lade den være tændt.
Kør denne kommando for at kontrollere status for denne indstilling for databaserne på serveren.
select name,is_auto_shrink_on,* from sys.databases
Du vil se dette output.
Hvis du ved et tilfælde ser, at den er aktiveret, kan du deaktivere den enten ved at bruge GUI'en, eller du kan køre nedenstående kommando mod databasen.
ALTER DATABASE YOUR_DATABASE set AUTO_SHRINK OFF
Andre vedligeholdelsesforslag
Se disse få ekstra tips for at undgå problemet med databasevækst, på grund af hvilket du skal køre DBCC ShrinkFile-kommandoer.
- Sørg for, at gendannelsesmodellen for dine databaser er tilpasset virksomhedens SLA'er. Hvis din virksomhed ikke kræver en punkt-i-tidsgendannelse til testdatabaser, skal du bare lade dem ligge i en simpel gendannelsesmodel. Jeg har set flere gange, hvor gendannelsesmodellen af databaserne var færdig, når tingene er i orden med gendannelse ved hjælp af den seneste fulde backup
- Sørg for korrekt overvågning på plads, især med databasevækst. Du bør advares, når logfilanvendelsen når 85 %. Dette vil give dig lidt tid til at løse pladsproblemet
- Sørg for, at der laves regelmæssige log-backups, hvis databasen er i fuld gendannelsesmodellen, og du bør advares, hvis nogen af log-backuperne mislykkes
- Sørg for, at der er tilstrækkelig plads på databasedrevene for at undgå problemer med pladsmangel
- For databaser, der kan arkiveres, skal du udvikle nogle arkivstrategier, så du kan flytte ældre data til en anden database for at oprette rapporter og gøre databasen skrivebeskyttet. Dette vil give dig mere kontrol med hensyn til databasestørrelsen
- Sørg for regelmæssigt at udføre integritetstjek på din database ved hjælp af DBCC CheckDB. For mere information henvises til denne artikel:https://codingsight.com/dbcc-checkdb-overview/
Konklusion
- Fra denne artikel har du en god forståelse for at bruge kommandoen DBCC ShrinkFile
- Du lærte om risiciene ved at køre DBCC ShrinkFile-kommandoer
- Du lærte de forskellige muligheder, vi kan tilbyde ved at bruge DBCC ShrinkFile-kommandoer
- Du så de muligheder, vi kan prøve, hvis transaktionsloggen ikke krymper ved hjælp af DBCC ShrinkFile-kommandoer
- Du lærte om standardindstillingen for automatisk formindskelse i databaseegenskaben
- Du har også lært andre forslag til databasevedligeholdelse for at holde dine databaser sunde
- Sørg endelig for at være klar under alle omstændigheder til de OFF-dage, som måske ikke er inden for din kontrol