Att köra DBCC Shrink-kommandon är en ganska kontroversiell fråga i hela SQL Server-gemenskapen. I den här artikeln kommer vi att granska detaljer om detta kommando och ge en kort översikt över dess användning och även varna dig för riskerna med att köra det här kommandot. Som DBA:er överlämnades ett antal databaser till från andra team eller leverantörer, och det är inte alltid vi får hantera de databaser som vi skapat. Som DBA:er måste vi, när vi är involverade i migrationer eller nya projekt, se till att vi noggrant planerar en smidig övergång av databasen till produktion och regelbunden användning. Det är i detta skede som vi måste ta hänsyn till storleken på databasen. Kan du föreställa dig att du skapar en databasapplikation utan att ta hänsyn till tillväxtprognosen för det första året eller så. Vad sägs om att skapa en SQL Server-databas med storleken så liten att den behöver växa varannan dag och höja kapacitetsdiskvarningarna mitt i natten? Det kan låta dumt, men i verkligheten är sanningen att detta händer, och ibland kanske du inte har kontroll över detta.
Få punkter att tänka på för Proactive DBA
Innan du tar över supporten av produktionsdatabaserna, se till att kolla med din föregångare vad prognoserna är när det gäller databastillväxt. Är den initiala storleken på databaserna som du kommer att hantera tillräckligt stor? Oroa dig inte för mycket om den nuvarande storleken på databasen är mycket större än den data den har för närvarande. Kom ihåg att du inte vill ha dessa diskkapacitetssamtal klockan 03:00 på morgonen när du helt kunde ha undvikit det genom att ha en databas med korrekt storlek. Det är en allmän trend för databasadministratörer i hela branschen att offra sina liv sent på kvällen på vardagliga frågor som väl inte borde ha inträffat i första hand. Tänk också på serverns diskkapacitet tillsammans med databasstorleken. Du vill inte att diskstorleken ska vara för liten än vad en databas kan ta emot. Dessa är alla enkla saker som kommer till användning vid planeringstillfället. Men som ni vet är det inte alltid en databasproffs som installerar eller konfigurerar databaser i första hand. Den viktiga punkten att notera är att få grunderna rätt med din databas när det gäller storlek och du kanske aldrig behöver köra det här kommandot. Men som alltid, som en DBA, finns det tillfällen då saker och ting inte är inom din kontroll och under denna tid kan du använda DBCC Shrink-filkommandon för effektiv användning.
När kan jag använda DBCC ShrinkFile?
Du har precis fått en diskutrymmesvarning mitt i sömnen och du har strikta SLA att uppfylla. Prioritetsnivån är en P2 och SLA kan bryta mycket snart. Och du inser att en utvidgning av disken inte kommer att hända någon gång snart, ja, i så fall, håll dina DBCC ShrinkFile-kommandon till hands så att du kan använda dem för att återta utrymmet. Som namnet antyder, krymper den filen med data eller loggfil för databasen. Men innan du börjar med att köra DBCC ShrinkFile-kommandona, försök att kontrollera varför databasfilen växer i första hand.
- Har filen växt på grund av någon långvarig transaktion?
- Finns det någon form av blockering på servern?
- Händer det någon större programversion som du inte har blivit informerad om? (Detta händer för det mesta)
- Finns det någon form av databasreplikering eller speglingsproblem som orsakar databastillväxt?
Det är viktigt att få svar på dessa frågor så snabbt som möjligt. I allmänhet finns det ett svar på alla dessa frågor och det är ett fantastiskt gratisverktyg som heter sp_whoisactive. Det finns inga ord för att beskriva den enorma användningen av detta verktyg och jag har använt det vid flera tillfällen för att fixa många produktionsrelaterade problem. Du kan ladda ner den senaste koden från denna länk:http://whoisactive.com/ . Det är lätt och enkelt att använda och returnerar resultatet på nolltid. Om du är rutinerad DBA har du redan detta till ditt förfogande.
DBCC ShrinkFile med exempel
Syntaxen för DBCC ShrinkFile är enkel och okomplicerad, se det här exemplet nedan.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Ovanstående exempel krymper FileName som tillhör YOURDATABASE till 1024 MB. Du kan utföra samma operation med SQL Server Management Studio (SSMS). Högerklicka på databasen, gå till Uppgifter , välj Förminska och sedan Filer .
När du klickar på Filer , kommer du att få detta fönster.
Här har du möjlighet att välja filtyp:Data, Log eller Filestream Data och utföra "Shrink action" efter behov. Det är lättare att använda själva DBCC-kommandot för att krympa.
Använda DBCC ShrinkFile med ytterligare alternativ
Du kan köra kommandot DBCC ShrinkFile med ytterligare alternativ – tomfil, notruncate eller truncateonly.
Töm fil
Du kan använda kommandot emptyfile som nedan.
use YOURDATABASE go dbcc shrinkfile(FileName,emptyfile)
Detta hjälper till att flytta data till andra filer inom samma filgrupp. När du är klar kommer du att kunna ta bort en databasfil om den inte längre behövs. Det finns dock några saker att notera med detta tomma filalternativ eftersom du inte skulle kunna göra mycket för att tömma innehållet i den primära datafilen med fil-ID 1. För att få fil-ID-numret, kör det här skriptet.
select file_id, name,physical_name from sys.database_files
Här, i det här exemplet, är filnamnet "mo" och fil_id är 1. När du försöker tömma filen mo som har fil_id 1, kommer du att få det här felmeddelandet.
Detta beror på att det finns systeminformation i originalfilen som inte kan tömmas. Men om du försöker samma kommando på den andra datafilen "mo2data", kommer kommandot tom fil att lyckas.
Inte avkorta
Som namnet antyder finns det inget utrymme som släpps tillbaka till operativsystemet. Detta är mer som en intern operation i filen där sidorna distribueras om i själva filen utan att ändra den övergripande storleken på databasfilen. På grund av detta finns det en enorm möjlighet att fragmentering införs. Se exemplet nedan.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,notruncate); GO
Endast trunkering
Som namnet antyder kommer ledigt utrymme att frigöras tillbaka till operativsystemet från slutet av filen. Detta är den överlägset säkraste operationen du kan köra med DBCC ShrinkFile. Se exemplet nedan.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,truncateonly); GO
Vad ska jag göra när DBCC ShrinkFile i transaktionsloggen inte fungerar som förväntat? Se den här säkra metoden för att åtgärda problemet
Det finns tillfällen då detta kommando kanske inte fungerar som förväntat. Förutsatt att du har en situation där du försöker krympa loggfilen för en databas och det verkar inte fungera. Nedan är några av de steg du kan ta för att förstå varför krympen inte fungerar som förväntat. Du kommer att märka att krympfilen kommer att visas som lyckad, men det finns ingen minskning av storleken på loggfilen. Kör i så fall det här kommandot för att kontrollera några saker om loggfilanvändningen.
select name,log_reuse_wait_desc,* from sys.databases
Från skärmdumpen kan du se att kolumnen log_reuse_wait_desc väntar på loggsäkerhetskopiering.
Här kan du se att loggbackupen för databasen måste utföras innan du verkligen kan krympa loggfilen. Om detta finns i en produktionsdatabas, försök att utföra loggsäkerhetskopieringen på en annan enhet där det finns ledigt utrymme. För att utföra loggsäkerhetskopieringen, använd exempelkommandot nedan.
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 backupkommandot, kör kommandot nedan igen för att se statusen för kolumnen log_reuse_wait_desc.
select name,log_reuse_wait_desc,* from sys.databases
Från skärmdumpen kan du se att statusen för kolumnen log_reuse_wait_desc har ändrats till "Ingenting".
Här kan du se att statusen för kolumnen "log_reuse_wait_desc" har ändrats till "Ingenting". I ditt fall kan det fortfarande visas som "LOG_BACKUP". Fortsätt att utföra loggbackuperna för databasen tills statusen ändras till "Ingenting". Anledningen till att du fortfarande kan se statusen "LOG_BACKUP" även efter att du har utfört säkerhetskopiering av transaktionsloggar är att inga VLF:er kan ha rensats efter att du körde säkerhetskopieringen av transaktionsloggen. VLF står för virtuella loggfiler och är en del av transaktionsloggens interna arkitektur. Transaktionsloggfiler består av dessa VLF:er. Du kan få information om VLF:erna genom att köra det här kommandot.
select * from sys.dm_db_log_info(5)
Här representerar 5 databasen_id. Skärmdumpen av utgången visas. Antalet rader som returneras representerar det faktiska antalet virtuella loggfiler (VLF) i databasen. Du kan kontrollera kolumnen "vlf_status" för att kontrollera statusen för den virtuella loggfilen. Värde 2 betyder att den är aktiv. Med det här kommandot kan du kontrollera de interna flaggorna i transaktionsloggfilen för att förstå varför transaktionsloggen inte frigörs även efter att ha utfört loggbackuper.
Tidigare var kommandot som användes DBCC LOGINFO som gav liknande information.
Vad ska jag göra när DBCC ShrinkFile i transaktionsloggen inte fungerar som förväntat? Något du kan utföra på icke-prod miljö. Rekommenderas dock inte på produktionsmiljö
Du skulle ha stött på på flera webbplatser som rekommenderar folk att ändra återställningsmodellen till en enkel modell och sedan köra en krympfil för att frigöra utrymme tillbaka till operativsystemet. Tänk på att om du ändrar återställningsmodellen till en enkel modell kommer det att påverka återställningen av din databas eftersom du inte skulle kunna återställa till en viss tidpunkt. Detta beror återigen på ditt företags SLA. Du kan ändra återställningsmodellen med T-SQL (nedan) eller med det grafiska användargränssnittet.
alter database DB_NAME set recovery simple
Använd GUI, ändra återställningsmodellen enligt bilden. Högerklicka på databasen, gå till "Egenskaper", klicka på "Alternativ". Under "Alternativ", välj "Återställningsmodell".
Du kommer att märka att bara att ändra återställningsmodellen till Simple inte frigör utrymmet tillbaka till operativsystemet. Du måste uttryckligen köra kommandot DBCC ShrinkFile för att krympa filen och återta utrymmet. Se exempelskriptet nedan. Detta kommando kommer att krympa ditt filnamn till 1024 MB.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Automatisk krympa databasalternativ
Du kommer att märka att det finns ett alternativ som kallas "Auto Krympa" i databasegenskaperna. Högerklicka bara på databasen för att se databasegenskapen. Under alternativsektionen ser du det här alternativet som visas. Från modelldatabasinställningen kan du se att alternativet "Automatisk krympning" är inaktiverat som standard. Så när en ny databas skapas är det här alternativet också avaktiverat. Det kan finnas vissa fall där databasproffs omedvetet kan lämna det här alternativet aktiverat utan att vara medvetna om de negativa konsekvenserna av att lämna det på.
Kör det här kommandot för att kontrollera statusen för detta alternativ för databaserna på servern.
select name,is_auto_shrink_on,* from sys.databases
Du kommer att se denna utdata.
Om du av en slump ser att den är aktiverad kan du inaktivera den antingen genom att använda GUI eller så kan du köra kommandot nedan mot databasen.
ALTER DATABASE YOUR_DATABASE set AUTO_SHRINK OFF
Andra underhållsförslag
Se dessa ytterligare tips för att undvika problemet med databastillväxt, vilket gör att du måste köra DBCC ShrinkFile-kommandon.
- Se till att återställningsmodellen för dina databaser är anpassad till affärs-SLA. Om ditt företag inte kräver en punkt-i-tid återställning för testdatabaser, lämna dem bara i en enkel återställningsmodell. Jag har sett flera tillfällen där återställningsmodellen för databaserna var klar när det går bra med återställning med den senaste fullständiga säkerhetskopian
- Se till att korrekt övervakning är på plats, särskilt med databastillväxt. Du bör varnas när loggfilanvändningen når 85 %. Detta ger dig lite tid att lösa utrymmesproblemet
- Se till att regelbundna säkerhetskopior görs om databasen är i modellen för fullständig återställning och du bör varnas om någon av loggsäkerhetskopiorna misslyckas
- Se till att det finns tillräckligt med utrymme på databasenheterna för att undvika problem med utrymmesbrist
- För databaser som kan arkiveras, utveckla några arkivstrategier så att du kan flytta äldre data till en annan databas för att skapa rapporter och göra den databasen skrivskyddad. Detta ger dig mer kontroll när det gäller storleken på databasen
- Se till att regelbundet utföra integritetskontroller av din databas med DBCC CheckDB. För mer information, se den här artikeln:https://codingsight.com/dbcc-checkdb-overview/
Slutsats
- Från den här artikeln fick du en god förståelse för att använda kommandot DBCC ShrinkFile
- Du lärde dig om riskerna med att köra DBCC ShrinkFile-kommandon
- Du lärde dig de olika alternativen vi kan tillhandahålla med DBCC ShrinkFile-kommandon
- Du såg alternativen vi kan prova om transaktionsloggen inte krymper med DBCC ShrinkFile-kommandon
- Du lärde dig om standardinställningen för automatisk krymp i databasegenskapen
- Du har också lärt dig andra förslag på databasunderhåll för att hålla dina databaser friska
- Slutligen, se till att vara redo i alla fall för de lediga dagar som kanske inte ligger inom din kontroll