En påske med EDB aktivitet?

En ergerlig melding å få midt i påsken. Logget på serveren for å sjekke ut hva som kan være galt. Den aktuelle disken har 140 GB å ta av, dette er jo gangske enkelt ikke mulig! Etter å ha undersøkt saken fant jeg transaksjonsloggen til CompanyWeb hadde grodd ut over alle grenser. Den var over 120GB stor! Hva i alle dager skal jeg gjøre nå?

Jeg hentet MS SQL Server boka og begynte og sjekke opp saken. På den aktuelle server som har 6 15’RPM disker (R1 for Os, R5-3 disker for data, R0 med 1 disk for logfiler), hadde altså CompabyWeb som var oppgradert til MS SQL Server 2000 fylt opp 120GB og det var nesten ikke plass igjen på disken. Etter å ha sjekket denne fant jeg noen kataloger som kunne flyttes til en annen disk. Dette frigjorde 20GB. Sjekke hos Microsoft og fant: How to stop the transaction log of a SQL Server database from growing unexpectedly KB873235. (Mange interessante linker her.) Dette så i grunn greit ut. Jeg kjørte maintenance plan i MS SQL Server. Men hva er DBCC SHRINKFILE?

Jeg kjørte maintanace plan – backup av transaksjonsfil og deretter backup av database. Deretter måte jeg kjøre DBCC SHRINKFILE.

Figur 1 - At DBCC SHRINKFILE ligger her kan neppe være åpenbart for alle? Ok, jeg fyrte denne opp.

Figur 2 - Kjøre denne etter og ha stilt 10%..... Dette ga overhode ingen resultater. Kikket derfor på Files... for å se hva dette var...

Figur 3 - Valgte her den aktuelle log filen.

Figur 4 – Klikket Shrink file to og etter å ha klikket litt på GB felte oppdaget jeg at den låste seg på størrelsen Space used. Forsøkte dette uten resultater.

Kjørte deretter en ny backup av transaksjonsfilen og backup av databasen. Dette i et forsøk på å komme rundt problemet i en slags obskure logikk. Neste gang jeg gikk inn i figur 4 la jeg merke til at størrelsen på filen hadde endret seg. Etter å ha fundert noe på saken besluttet jeg å oppgi en større vedri en minimumsverdien. Dette og i kombinasjon med gjentatte translog og db backups løste til slutt saken, som du kan se er filen nå 8,87MB. Det er ganske enkelt ufattelig at denne filen kunne bli 120GB!

Figur 5 – Dette er stedet hvor jeg kjørte operasjonene gjentatte ganger....

Hva fikk jeg så med meng i denne prosessen?

1)      Når du lager en maintenace plan, bør databasene grupperes etter type av transactional logging (full recovery mode osv...) I motsatt fall får du feilmeldinger i job historien.

2)      Det er ikke lurt og velge operasjoner som krever single user mode for eks rebuilding index.

3)      Det er også god grunn til å dele opp maintanace planen. Slik at master og andre system databaser går for seg og deretter brukerdatabaser etter punkt 1.

For å finne resultatet av en jobb:

Figur 6 – Her sjekket jeg opp resultat av maintenance plan kjøringer.