The transaction log is a important method to restore your database in a specific time. If you have a large database > 500 GB and if you must restore your database from a full backup, this will cost very much time. Also if you full backup your database everytime, think about how long this backup could take.
A very easy concept for SQL Server can be:
Set Recover Model of your Database Full
Create a Maintenance Plan(1) in SQL Server:
- Do FullBackup every Week maybe in D:\yourbackup\FullDBBackup.bak
- Do Differential Backup every two days in D:\yourbackup\DiffBackup.bak
- Do every 2 houers Backup your Transaction log in D:\Yourbackup\Tranlogbackup.trn
Create a Maintenance Plan(2) in SQL Server:
- Delete all older Files 8 days from D:\yourBackup*.bak
- Delete all older Files 3 Days from D:\yourBackup*.trn
In this case, you are able to recover your Database in a specifc time, very fast very easy.
SQL Server will automaticly manage your "Backup" files, older files will be deleted after your specific time range.
I would suggest that you read about SQL Server Transaction Log here:
http://www.sqlservercentral.com/articles/Design+and+Theory/63350/
For using the Maintenance Plans in SQL Server just ask BING / google :D
you should build a small test db and test this before you go in production
Seeing that the recovery model is set to simple and msdn states that the simple recovery model does not support point-in-time recovery - Does this mean that I won't be able to use my transaction log backups to restore the database in a disaster to an hour before it happened?
Even taking a transaction log backup is not supported for databases using the SIMPLE
recovery model. This is a restriction of the database engine based on how this recovery model works, and the recovery features it doesn't support, as you mentioned.
A transaction log backup maintenance plan task automatically skips databases in SIMPLE
recovery to avoid causing errors.
Which backup should be done first, the database backup or the transaction log backups? Articles that I'm busy reading say I should do the database backup first and then the transaction log backup else I will get maintenance plan errors, but I'm currently first backing up my transaction logs and then data databases and I'm not getting any errors.
For the reasons I mentioned above, it won't matter for databases using SIMPLE
recovery, as they will be skipped by the transaction log backup task.
For databases in the other two recovery models, a full backup must exist before you start taking transaction log backups (just the first time), or you will get an error -- this is probably what the articles refer to.
Point-in-time recovery ability is normally driven by business need -- in other words, you determine how critical the data is and how much you can afford to lose, then set the appropriate recovery model to meet those needs, and finally create a backup solution.
Even though SIMPLE
recovery does not support point-in-time recovery, if an hour of data loss is okay, perhaps a differential backup solution could work for you. (There are far too many variables that go into developing this kind of solution to give you a complete picture with what was provided in the question.)
Best Answer
1) The first thing you would need to figure out, what recovery model you should go with , i.e. decide accordingly as per the need between , FULL , BULK and SIMPLE recovery model.
Read here for configuring the same: Choosing the Recovery Model for a Database
2) When you create a new database in SQL Server 2008 and SQL Server 2005, the data and log files have the following characteristics by default:
Therefore the first thing you will need to look upon what is the default value you will like to give while setting up for first time.
Its better to test the activity first on test env, come up with a minimal amount of capacity planning to help define your initial size and a maximum size.
3) Once you have come up with a default values for log file, its recommended to monitor the usage of log file or track its growth:
There are various ways of doing that.
You can use below query and collect the results storing in a table over a period of time via SQL agent job:
or using
DBCC SQLPERF(LOGSPACE)
4) If a database is configured with the Full or Bulk Logged recovery model, you should back up the transaction log regularly so it can be truncated to free up inactive log space. The backup can also be used (along with the database backups) to restore the database in the event of failure.
Therefore its better to choose you're defaults correctly in order to avoid lot of event changes in log that may hamper the performance.