tags:

views:

106

answers:

2

Hi

We have a database that has configuration data in. When the applications are run against it, they basically do lots of calculations and then write some data to file. Unlike normal installations, we do not really need the transaction log. What I mean here is that we could take a backup of the database and use it without applying transaction logs to it to get it up to date.

Since the transaction logs are not that important to us, what should be the best backup strategy? Currently the transaction log is enormous (10 GB where as the database is about 50 MB, this was over a few months).

Could we just do an initial backup of the database and then each few days or less backup the transaction log, overwriting the current one? Or could we just delete the transaction log all together and have a new one started?

JD.

+6  A: 

Ensure the database is running in the Simple Recovery Model.

Doing so negates the need for you to perform transaction log backups. This recovery model automatically ensures that the inactive portions of the transaction log can become immediately available for reuse.

No longer concerned with the Transaction Log management, you can focus your attention on your backup strategy.

A weekly FULL Database Backup, perhaps with daily Differential Backups may suit your requirements.

Recovery Model Overview

John Sansom
Thanks. Just to recap, Simple is the way to go. However, we do write data to the database but this data can be calculated from the backed up database (the link mentions that Simple is good for databases where data does not change).I suppose just a full database backup when we change the configuration data will be all that is required. Can we automate this and do we need to do anything else like shrinking the transaction log?JD.
JD
Just did some more reading. The recovery interval for the SQL server instance is 0 mins. From what I understand is, automatic checkpoints take place which means that the transaction log is truncated (which frees up space for reuse). Is this correct? If so, then I really do not need to run any scripts (just have a full database backup).
JD
@JD: Using the Simple Recovery Model means that you cannot recover a database to a specific point in time (because this requires transaction log backups) should the need arise. Provided point-in-time recovery is not a requirement, perhaps data is relatively static or can be recovered by another means e.g. you have a FULL database backup or data can be recovered from re-importuning a data feed, then the Simple Recovery Model will suit your needs. Also you are correct in that the Simple Recovery model automatically manages the truncation of the Transaction Log file for you.
John Sansom
Thanks for the advice.
JD
@JD: You're welcome, glad to help!
John Sansom
A: 

As I understand, you do not write any data to your database. And for this reason the best backup strategy for you will be: 1. Change recovery model to simple and shrink the transaction log, using DBCC SHRINKFILE. 2. Make one full backup of your database.

Sergey Olontsev
Thanks HawX. Your reply helped.
JD