Category: SQL Server

Symptoms and findings

In the event log event id 12291 from SQLISPackage100 is recorded, together with event id 208 from the MSSQL Agent service:

In the MSSQL log for the job, the following error is recorded:

The package execution returned DTSER_FAILURE (1).

Resolution

This was caused by some of the job tasks not having their database selections stored properly:

So the solution was simple, just select the proper databases and remember to save the maintenance plan afterwards

Innimellom vokser  SQL data eller logfiler til gigantiske proporsjoner, uten at de nødvendigvis inneholder noe fornuftig.Du kan få en liste over  loggbruk og størrelse ved å kjøre følgende kommando:

DBCC sqlperf(logspace)

Transaksjonsloggen bør vanligvis ikke være større enn ca 25% av databasestørrelsen, men det kommer an på hvor ofte den tømmes. Dersom den plutselig blir betydelig større enn normalt for en gitt database er det grunn til bekymring og videre etterforskning.

Hvor stor databasen er og hvor mye av plassen som brukes til noe fornuftig kan du sjekke for en og en database med følgende kommandoer:

USE [DatabaseNavn];
GO
EXEC sp_spaceused @updateusage = N'TRUE';
GO

I SQL 2008 management studio kan du også få opp en Disk usage rapport som gir fancy kakediagram og forklaringer i tillegg.

For å krympe en fil må du vit hva den heter. Dette sjekkes i databaseinnstillinger. Det er ikke det faktiske filnavnet du er ute etter, men det logiske navnet.

USE [Databasenavn]
GO
DBCC SHRINKFILE ([logisk filnavn], [Ønsket størrelse i MiB])
GO

For å unngå diskfragmentering bør du angi en størrelse som er omtrent det du tror den trenger å være. For loggfiler har vi en tommelfingerregel som sier at samlet størrelse på loggfilen (og det skal helst bare være en) bør være 25% av samlet størrelse på datafil(ene). Dette vil gi et godt utgangspunkt.

Feilsøking

Innimellom vil en shrinkfile resultere i en eller annen feilmelding (sjekk messages-vinduet). Det skyldes vanligvis en av følgende:

• For lite ledig diskplass
• Slutten av filen er i bruk. (loggfiler er delt opp i mindre virtuelle logger)
• Databasen/loggen er korrupt

Først og fremst bør du sjekke i feilloggen om databasen er korrupt eller om den har andre feil relatert til problemdatabasen.

Dersom du har for lite diskplass, frigjør plass om mulig. Eventuelt kan du dismounte basen og flytte den til en annen større disk først.

For å sjekke hvor mange elementer loggen består av kan man kjøre DBCC LOGINFO:

Status 0 angir at fragmentene kan fjernes ved krymping. Siden Shrinkfile bare sletter fra slutten av filen(som er bunnen  av listen over), kan den bare slette opp til og med den siste fragmenten med status 0.

Dersom siste fragment ikke har status 0 kan du korrigere dette. Hvordan du går frem avhenger av om du bruker Simple recovery eller ikke. Dersom du har simple recovery, kjør denne kommandoen isteden:

USE [Databasenavn]
GO
CHECKPOINT
DBCC SHRINKFILE ([logisk filnavn], [Ønsket størrelse i MiB])
GO>

Dersom det ikke virker første gang, kjør den flere ganger. Du kan sjekke fremgang ved å kjøre Loginfo som nevnt over.

Om du bruker full eller bulk logged recovery, ta en backup av loggen og prøv igjen. Kjør eventuelt flere backup etter hverandre om det ikke hjelper på første forsøk. Om alt annet feiler kan du bytte til simple recovery model midlertidig, men det bør være siste utvei. Noen anbefaler å ta basen offline og slette loggfilene. Dette er direkte farlig, da det kan føre til at basen ikke lar seg åpne igjen etterpå. Siden prosedyren over ofte brukes for å rydde opp etter en feilsituasjon er dette særdeles risikabelt. Loggfilen er den viktigste filen til databasen.

Se https://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/ for mer informasjon (engelsk).