SQL Log question

Another vote for the Olla Hallengren maintenance job. Without SQL Enterprise edition, index rebuilds are "offline" (disruptive), reorgs are "online", so unless you have scheduled maintenance windows, avoid rebuilds if poss!

Also you're right, there's a lot of conflicting advice to do with shrinking. I'd say for "normal" operations don't, for the simple reason that a DB/log will size to the volume it needs. Unfortunately in IT there's rarely any such thing as "normal". When a one-off rogue transaction from a poorly coded application balloons a log file by 500Gb, causing a knock on effect to backup windows, storage issues on the BI system where you're restoring the database, replication latency etc etc, then by all means shrink. Just be aware of what you're doing, and make sure you've got sensible autogrowth values in place (don't use percentage growth values either). In my experience you want to avoid excessive VLFs for all sorts of reasons, so shrink and grow sensibly.

You can monitor free space within DB/Log file with a query like:

select convert(decimal(12,2),round((a.size-fileproperty(a.name,'SpaceUsed'))/128.000,2)) as FreeSpaceMB from dbo.sysfiles a with (nolock) WHERE name = '<logicalfilename>'
 
There is no compression being used on the backups as the option is not set to compress.

If it stops backing up the 35gb log every week with the change in config the space problems on the backup server is resolved.

I ran query

USE master
GO

DBCC SQLPERF(logspace)

It showed that 1.4% of 36gb is actually in use in the log file.
 
Back
Top Bottom