MS SQL 2000 Server - Transaction log van 20 GB

[Verwijderd]

Ik heb MS SQL Server 2000 SP3a draaien op Windows 2003. Nou heb ik daar een database van 30 MB...

Tot mijn verbazing staat daar dus een transaction log bij van 20 GB!!!! Hoe krijg ik dit weer in orde ? Ik heb de database al geprobeerd te schrinken, backuppen. en zelfs al verwijder ik het bestand (SQL Service gestopt) en dan maakt hij het 20 GB logbestand gewoon weer aan als ik de backup terug schrijf!

Hoe kan dit ? en hoe los ik dit op ??

[Verwijderd]

Wat voor applicatie maakt gebruik van die DB? Backuppen zou het log moeten shrinken, maar soms lukt dat niet.

Wat je kan proberen is het volgende. In de query analyser vul je het volgende script aan en voer je het uit. Mocht het niet goed gaan wijzig dan bijvoorbeeld parameters @MaxMinutes en @NewSize.

Vergeet niet DATABASENAME en LOGFILENAME in te vullen. Om de exacte benaming te vinden kan je in de query analyzer het volgende script draaien:

code:

USE DATABASENAME
EXEC sp_helpfile

Het script:

code:

SET NOCOUNT ON
   DECLARE @LogicalFileName sysname,
           @MaxMinutes INT,
           @NewSize INT

   -- *** MAKE SURE TO CHANGE THE NEXT 4 LINES WITH YOUR CRITERIA. ***
   USE     DATABASENAME       -- This is the name of the database
                                  -- for which the log will be shrunk.
   SELECT  @LogicalFileName = 'LOGFILENAME',                                                                                 
      -- identify the logical file 
      -- name that you want to shrink.
           @MaxMinutes = 1,             -- Limit on time allowed to wrap log.
           @NewSize    = 100  -- in MB

   -- Setup / initialize
   DECLARE @OriginalSize int
   SELECT @OriginalSize = size -- in 8K pages
     FROM sysfiles
     WHERE name = @LogicalFileName
   SELECT 'Original Size of ' + db_name() + ' LOG is ' + 
           CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' + 
           CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
     FROM sysfiles
     WHERE name = @LogicalFileName

   CREATE TABLE DummyTrans
     (DummyColumn char (8000) not null)

   -- Wrap log and truncate it.
   DECLARE @Counter   INT,
           @StartTime DATETIME,
           @TruncLog  VARCHAR(255)
   SELECT  @StartTime = GETDATE(),
           @TruncLog = 'BACKUP LOG ['+ db_name() + '] WITH TRUNCATE_ONLY'
   -- Try an initial shrink.
   DBCC SHRINKFILE (@LogicalFileName, @NewSize)

   EXEC (@TruncLog)

   -- Wrap the log if necessary.
   WHILE     @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired
         AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)  -- the log has not shrunk    
         AND (@OriginalSize * 8 /1024) > @NewSize  -- The value passed in for new size is smaller than the current size.
     BEGIN -- Outer loop.
       SELECT @Counter = 0
       WHILE  ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))
         BEGIN -- update
           INSERT DummyTrans VALUES ('Fill Log')  -- Because it is a char field it inserts 8000 bytes.
           DELETE DummyTrans
           SELECT @Counter = @Counter + 1
         END   -- update
       EXEC (@TruncLog)  -- See if a trunc of the log shrinks it.
     END   -- outer loop
   SELECT 'Final Size of ' + db_name() + ' LOG is ' +
           CONVERT(VARCHAR(30),size) + ' 8K pages or ' + 
           CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
     FROM sysfiles 
     WHERE name = @LogicalFileName
   DROP TABLE DummyTrans
   PRINT '*** Perform a full database backup ***'
   SET NOCOUNT OFF

Edit: excuses voor het layout-vern**ken

[ Voor 4% gewijzigd door Verwijderd op 09-11-2004 23:00 ]

[Gunner]

Je kan in SQL toch instellen hoe groot hij de log moet maken? Full of Minimal of zoiets?

Ik heb ook zo'n probleem een keer meegemaakt, ook een grote logfile. Draaide een Exact DB op. Door het veranderen van de size binnen SQL heb ik het opgelost dat die log weer klein werd. Alleen iets veranderen als je zeker weet waar je mee bezig bent, dit hoeft niet per definitie de oplossing te zijn

[cavey]

mja, zoals in het script al staat, ik gebruik meestal deze combi:

backup log database with truncate_only

dbcc shrinkfile ('logischenaamvandedatabase.ldf',size)

oid, check voor correcte syntax BOL (heh, of gewoon het bovenstaande script van HPE ontleden )

ymmv...

[Verwijderd]

Bedankt voor de info .... de Log file is nu nog maar 100 MB... Het programma dat gebruik maakt van die database is nu ook 100x sneller

[Verwijderd]

Gezien je DBA niveau, zou ik je adviseren om in de properties van je database het "recovery model" op "simple" te zetten.
Dat betekend dat je niet meer kunt restoren naar een specifieke tijd, maar alleen een complete backup dump terug kunt zetten. (die gigantische logfile groei heb je dan niet meer)

Ik denk dat dat wat makkelijker voor je is. (als hij 100 mb is, kun je hem ook makkelijk 3 x per dag als full backup naar schijf dumpen)