数据库备份大小难题

Question

I have a small SQL Server 2005 database. I take daily backup (automated) and the size of the .bak file typically comes out to be 400MB, growing by 5MB every day (which is inline with its usages).

Last night the size of the backup file jumped to 1GB. Suspecting that someone was trying to fill the database with garbage data, I ran a report ( Reports -> Standard Reports -> Disk User By Top Tables ) and the total size came out to be around 400MB.

Then thinking maybe something was wrong with the automated backup process, I immediately took backup again but the .bak file came out to be over 1GB. Before this automated backup yesterday, an automated task that defragments indexes also ran. However, all these months, a backup after this index optimization used to actually reduce the size of the .bak file.

I am trying to find an explanation for this big jump in size overnight and also why the .bak file is more than double the size of the the actual database disk usages?

UPDATE: I ran

DBCC SHRINKDATABASE(mydb) 

to remove transaction logs. Then took a backup again. The size of the .bak file came out even bigger than last time.

This is the query I ran:

    DBCC SHRINKFILE(mydb_log, 1)
    BACKUP LOG mydbWITH TRUNCATE_ONLY
    DBCC SHRINKFILE(mydb_log, 1)

Answer 1

1 - How are you backing up the data? Maintenance plans?

2 - If you are appending to the same database backup file, the backup will grow!

Check out the contents of the file.

RESTORE FILELISTONLY FROM AdventureWorksBackups WITH FILE=1;

http://technet.microsoft.com/en-us/library/ms173778.aspx

This assumes you have a dump device named AdventureWorksBackups. You can also change it to a DISK='AdventureWorks.bak'.

3 - Also, the maintenance plans do not do a good job with determining when to re-organize/update stats versus rebuild an index.

4 - Check out the ola hallengren scripts. They are way better!

http://ola.hallengren.com/

First, they create a directory structure for you.

c:\backup\<server name>\<database name>\full
c:\backup\<server name>\<database name>\diff
c:\backup\<server name>\<database name>\log

Second, each backup has a date time stamp. No appending to backup files.

Third, they clean up after themselves by passing the number of hours to keep on-line.

Fourth, they handle index fragmentation better - 5-30 = re-organize or 30+ = rebuild.

I usually set up the following for my databases.

1 - system databases - full backup every night, log backups hourly.

2 - user databases - full backup 1 x week, diff backup x 6 days, log backups hourly

Last but not least, SQL Server 2005 does not have native support for compressed backups. This does not mean you can not run a batch file to zip them up afterwards.

Third party tools like QUEST (DELL) and RED GATE used to support their own backup utility. The main reason was to fill this gap. Since SQL Server 2008, compressed backups were available. I think many of the vendors are getting rid of this utility since it is now standard.