Undgå logfil

HAR sat databaserne til Simple recovery mode (i går), men den viser alligevel ca. 800 MB i dag (måske vokser den ikke til i morgen) - fjerner lige hakket i Autogrowth

Log filerne kryper ikke af sig selv.

Der er en skummel DBCC kommando til at goere det med.

http://support.microsoft.com/kb/907511

Du skal måske være lidt forsigtig med at fjerne autogrowth. Så rissikerer du at load jobbet fejler, når den har behov for større log fil.

Følgende artikkel (http://www.microsoft.com/technet/prodtechnol/sql/2005/dwsqlsy.mspx) har lidt forklaring på hvordan du kan minimere logging, og maximere performance:

In order to load data very fast, the database recovery model must be either Bulk Logged or Simple, and the table must either be empty or contain data but no indexes. If these conditions are met, a non-logged load is possible. In SQL Server 2000, before partitioned tables existed, these conditions are typically met only in the initial historical data warehouse load. Some customers with large data warehouses have built a quasi-partitioned structure by constructing a UNION ALL view over separate physical tables; these tables were populated each load cycle using a non-logged technique. This approach was not entirely satisfactory, and SQL Server 2005 partitioned tables provide superior functionality.

Følgende artikkel beskriver brug af Table partioning for fast loads:

Consider Table Partitioning for fast loads (hele artikkelen: http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/dw_perf_top10.mspx)

• For the large tables common in Data Warehouses, table partitioning offers important performance and manageability advantages. For example, the fastest type of load is a non-logged bulk copy. The requirements for non-logged bulk copies are that indexes must be dropped. This is not feasible on a huge billion row table UNLESS you use table partitioning. This allows one to create a staging table identical to the large table (minus indexes). A fast non-logged bulk copy is used to load data. Thereafter, indexes are added to the staging table followed by constraints. Then, a meta-data only SWITCH IN operation switches pointer locations for the populated staging table and the empty target partition of the partitioned table resulting in an fully populated partition and empty staging table. Besides a fast bulk copy, the staging table allows us to eliminate blocking in the large partitioned table during the load. For more information refer to “Loading Bulk Data into Partitioned Tables”. In addition to fast loads, partitioned tables allow fast deletes (or archiving purposes or sliding window deletes) where large logged deletes are replaced with meta-data only partition SWITCH OUT operations that switches pointer locations for the full partition (to be ‘deleted’) and an empty monolithic table. The SWITCH OUT results in an empty partition and a fully populated monolithic staging table. Thereafter the monolithic table can either be dropped or added to a partitioned archive table using SWITCH IN. Partitions also provide manageability improvements when combined with specific filegroup placement, allowing for customized backup and restore strategies.

Det skal ogsaa siges at naar du tager regelmaessig backup af data og log (det goer du selvfoelgelig) saa "toemmes" logfilen saa den ikke vokser mere end noedvendigt. Dette er fordi den saa har "reserveret" pladsen, selvom den er tom, fordi den forventer at komme op i den stoerrelse igen. Derudover kan du opsaette et job til at trimme dem regelmaessigt hvis det virkeligt er et problem.

Jeg tror ikke at han tager regelmæssig backup af log fil - jævnfør 20/09-2007 10:01:45 ...

Arne: der tages backup af databaserne hver nat (BackupExec står for backup'en direkte).
Bjornicle: det undrer at logfilen, som normalt kun er på 500 MB, pludselig en dag, med SAMME data mængde som dagen før, giver en logfil som er 36 gange større!

Arne: du har ret, man SKAL være forsigtig med at fjerne Autogrowth - men jeg troede at SQL Server bare ville mindre portioner i logfilen/udskifte indholdet oftere, så man ikke kunne roll-back så langt (hvilket intet betyder i denne sammenhæng).

Der er ingen indeks på tabellerne og data slettes fra tabellerne INDEN data hentes igen.

Måske jeg skulle kigge på BCP?

En logfil vokser saa meget den har brug for, og ved backup toemmes den, men beholder stoerrelsen, da den regner med at skulle bruge dette plads igen (da den har skulle bruge det tidligere). Hvis den er vokset med 36 x 500 mb (dvs. at loggen er paa 17 gb) saa er det fordi den har haft brug for dette plads, en backup vil toemme filen, og saa kan du truncate den hvis du vil (brug management studio til det).

Jeg fandt forleden en db som var paa 2.5 gb, og den skulle egentlig kun bruge ca 1.5 gb, saa jeg frigjorde pladsen, men at goere dette fik loggen til at vokse tilsvarende, muligvis har du vaeret ude i noget tilsvarende.

Du kan ogsaa kigge paa hvordan du sletter data'en, f.eks. hvis du laver en "delete from <table>" bliver der genereret en log med de slettede data, hvorimod hvis du laver en "truncate table <table>" bliver der ikke lavet en log over det.

Hvis du ikke skal bruge loggen, kan du trimme den saa langt ned som muligt, dvs. tage backups og truncate filen, og saa saette recovery til "simple", hvorefter den ikke fylder mere i filen (den fjerner den heller ikke).

Det sidste du nævner har jeg allerede gjort i går - Detach'ed databasen, slettet logfilen, Attach'ed databasen igen og sat Recovery til Simple.

Ja, SQL'en hedder
DELETE FROM [Table]
Prøver at ændre den til
TRUNCATE TABLE [Table]

Eftersom du har sat recovery til simple, goer det ikke saa meget om du bruger delete eller truncate, bortset fra at truncate er hurtigere.
Der er vel heller ikke kommet en ny logfil efter du har sat recovery til simple ?

Jo, når jeg re-attached databasen siger den at den ikke kan finde logfilen (som jo er slettet), men den generer selv en ny!

>men jeg troede at SQL Server bare ville mindre portioner i logfilen/udskifte indholdet oftere, så man ikke kunne roll-back så langt (hvilket intet betyder i denne sammenhæng).

Log bruges vil primært til to formål;
-Kunne lave en rollback hvis den ikke bliver færdig med det den har startet
-Kunne rulle på ændringer i databasen siden sidste backup.

Det sidste punkt funger kun hvis du bruger recovery model full. Men det første punkt kan du kun unndgå hvis du laver bulc copy. Hvis den ikke laver bulk copy, og loggen går fuld, vil den lave en roll back på den transaktion den er ved at lave.

Tak for svaret, lorentsnv.

Læg et svar, allesammen og tak for hjælpen.

Ingen point til mig tak :)

Hvad blev din løsning på problemet?

svar

Logfilen slettet og (af SQL Server) genereret igen.
Recovery model: Simple
Logfilens nuværende størrelse: 1,2 GB.