Tömma Sql loggarna efter backup ?

[heatsinkfan]

Hej jag är ny här och ganska ny inom sql, så hej till alla...

 

Det verkar vara så att våra transaktionsloggar växer sig allt för stora.

Jag skulle vilja veta hur jag kan tömma transaktionsloggarna efter att backup är gjord och vill helst att detta ska ske per automatik.

 

föklara för mig som om jag vore 5 år.

 

 

mvh hsf

 

[/JAG]

hej

 

Ta backup på transaktionsloggen...

 

.ldf filen krymper inte för att transaktionsloggen är tömd.

högerklicka på databasen och välj. all tasks -> shrink för att krympa filen.

 

 

vilken SQL version?

 

 

[Anjuna Moon]

Transaktionsloggarna finns där av en anledning och det är för att kunna återställa databasen till ett tidigare tillstånd. Transloggar krymper man inte, man raderar dem när man anser att man inte behöver dem längre.

Sätt upp en vettig maintenance-plan, baserad på era behov/krav.

 

Om du ex. gör en fullständig backup en gång i veckan och efter varje sådan backup inte har behov av att återställa till ett tillstånd som ligger före denna (men vid en tidpunkt mellan tidigare fullständiga backuper) så är det bara att se till att din maintenance-plan raderar loggarna efter 7 dagar.

 

Att transaktionsloggar blir väldigt stora i databaser med mycket uppdateringar är fullt normalt och därför är det av stor vikt att man har en sund plan för att hantera att dessa raderas (eller exporteras till annan media om man har sådana arkiveringsbehov). Gör man inte detta råkar man lätt ut för att hårddisken blir full och de beroende systemen kraschar (något som ofelbart alltid inträffar när ingen finns i närheten för att åtgärda det

 

[heatsinkfan]

 

tack för detta!

 

[Anjuna Moon]

Återkom om du behöver tips på hur du sätter upp din maintenance, jag har dessvärre mycket erfarenhet av detta

Beskriv isåfall verksamheten och hur datan är relaterad till den.

[inlägget ändrat 2009-02-25 09:25:28 av Anjuna Moon]

[heatsinkfan]

Otroligt skönt att höra att det finns hjälpsamma människor på det här stället.. Jag kommer att återkomma till dig! no doubt!... .. det lär inte dröja heller..

 

 

 

[Anjuna Moon]

Otroligt skönt att höra att det finns hjälpsamma människor på det här stället.. Jag kommer att återkomma till dig! no doubt!... .. det lär inte dröja heller..

Jag är inte inne här lika ofta som förut, men jag bevakar tråden. Ibland blir det snabba svar, ibland tar det kanske ngn dag.

 

[heatsinkfan]

Jag tycks inte få Data.MDF och speciellt Log.LDF filerna små.

 

växer sig otroligt stora .. aka.. 7 gig etc

 

[heatsinkfan]

skulle verkligen behöva hjälp med en fin maintenance plan..

 

mvh hsf

 

[gcm]

Rekommenderar att du läser om det i Books Online, där finns det en hel del om de frågor du behöver svar på.

 

Sedan vill jag, rent allmänt och det är min personliga åsikt, rekommendera alla som driftar MS SQL Server att gå en administrationskurs hos en auktoriserad Microsoft-utbildare. Det finns alldeles för mycket information i databaser runt om i verkligheten som driftas av tekniker med alldeles för lite kunskap om underhåll på produkten.

 

Storleken på din datafil/-er de som har ändelsen mdf och även ibland ndf styrs uteslutande på hur dina tabeller ser ut och hur många rader de består utav, samt de index du har kopplade till dessa. En databas på 7GB kan ses som fruktansvärt stor eller fasligt liten beroende på hur den är designad. Tyvärr tror många att normalisering är av ondo vilket, även min åsikt, är direkt fel. Ju hårdare du lyckas normalisera din databas, dvs smalare och fler tabeller med hårdare styrning på datatyper, fler constraints osv, desto lättare är det att indexera databasen rätt baseat på faktiskt nyttjande vilket ger mindre datafiler och enklare underhåll, och framförallt bättre prestande. En nyckelregel är att det finns inga frågor som man ska behöva vänta på.

 

Storleken på din transaktionslogsfil, du behöver inte fler än en per databas om du underhåller databasen rätt, bör vara så liten som möjligt vilket innebär att den bör inte vara större än ett normalt dygns tillväxt i logfilen. Utöver detta bör den ha en tillväxtfaktor baserat på ytterligare utrymme som behövs vid större dataladdningssceniarier, ifall du importerar större mängder data. Eller ännu hellre ska dessa hanteras som bulk-operationer, och databasen konfigurerad i BULK_LOGGED Recovery Model.

 

En rekommendation är att du kör dygnsbaserad fullständig backup av databasen till disk, och kompletterar med timbaserad transaktionsloggsbackup till disk. Då kommer din transaktionslogg inte växta till enorma proportioner. Låt databasen stå i FULL Recovery Model. Vid de dygn du ska köra större importer av data, låter du loggfilen växa och efter importen krymper du filen och initierar om backupcykeln med en fullständig backup. Innan importen kör du givetvis en transaktionslogsbackup.

 

Ex:

F - Tx24 - F - Tx20 - Import - REBUILD INDEX - DBCC SHRINKFILE(logfil, storlek) - F - Tx24 - F osv

 

Beroende på log flush/checkpoint kommer din logfil krympa eller inte, på direkten eller inom en stund.

 

Det som är bra med maintenance plans är att de är enkla att sätta upp, ger ett rätt så ok underhåll, är lätta att övervaka och lätta att anpassa. Nackdelen är i princip det samma. Vet man inte hur databasservern arbetar med content, hur trasaktionsloggen fungerar, hur datafilerna är konstruerade, hur man konfigurerar säkerhet, återställer backup osv är risken stor att man får ringa mig eller någon av mina kollegor. Att rekonstruera data från en databas som ligger på ett kraschat disksubsystem är inget roligt uppdrag med ganska små chanser till fullständig recovery.