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.)
It is certainly possible to use a Maintenance Plan to handle the fragmentation issues. However, many people use the free scripts at: http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
I am part of the 'many people'. These scripts by default implement the suggested standards for reducing the fragmentation of indexes. So, if you implement the script with one of the many sample settings further down the page, it should bring your indexes into better order.
Your database is not particularly huge, so scheduling an online index rebuild on a relatively quiet time, perhaps Saturday night if that is a low use time, and let it run.
If you link to the home page (http://ola.hallengren.com/) you will also find scripts for database backups and integrity checking. It seems that you have a good backup schedule overall, though I do not know your retention period, so you do not need to change unless you personal see the need.
Second, regarding the large LOG file, you can look into the DBCC SHRINKFILE() command to reset the size of the log file. On the other hand why bother unless you need the space.
DBCC SHRINKFILE ('LogFileName', );
If it does not shrink the first time, run CHECKPOINT, backup the log again, and try to shrink the file again. Once the high order portion of the log is empty (through the log backups) the file will be able to shrink.
Best Answer
Your System Admin probably has a program such as BackupExec which backs up everything organisation-wide. Check with them.
Typically, you'll see the backup device listed as a unique identifier, if some other system is managing backups.
I occasionally use this query to check backup history details:
That should return a single row for each database backed up over the last 7 days. You can limit this to a single database by modifying the
@DBName
variable.