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.)
When should I use the full recovery model and when should I use the simple recovery model for databases?
You should use the full recovery model when you require point-in-time recovery of your database. You should use simple recovery model when you don't need point-in-time recovery of your database, and when the last full or differential backup is sufficient as a recovery point. (Note: there is another recovery model, bulk logged. For more information on the bulk-logged recovery model see this reference)
Microsoft OLE DB Provider for SQL Server (0x80040E14) The transaction log for database 'DATABASE NAME' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
The reason you got that error (most likely) is because you haven't been backing up your transaction log. When it isn't backed up, then it will continue to physically grow the transaction log file (provided autogrowth is enabled and maxsize allows) because it can't reuse any of the "portions" of the transaction log (virtual log files). It can only mark those VLFs for reuse and allow the "wrap-around" nature of the transaction log when you do a transaction log backup (and a few other requirements, such as no active transactions, some replication aspects, etc.).
To shrink the log and making the database accessable again, I changed the recovery model from FULL to SIMPLE and shrinked the logical file log, with the following command
......
It helped, but now I need to understand WHY it helped, HOW this situation started and HOW to prevent this in the future?
This helped you because by setting your database to the simple recovery model you told SQL Server that you no longer care about point-in-time recovery, and the requirement to ensure that virtual log files no longer need to be preserved and marked as active, now a checkpoint process marks these VLFs as inactive.
Excerpt/quote taken from this MSDN reference:
Under the simple recovery model, unless some factor is delaying log truncation, an automatic checkpoint truncates the unused section of the transaction log. In contrast, under the full and bulk-logged recovery models, once a log backup chain has been established, automatic checkpoints do not cause log truncation.
Then you did a physical database file shrink and because there was free space in your transaction log now it was able to physically shrink the NTFS file.
Reading worth spending some time on:
- Recovery Models
- Managing Transaction Logs (Gail Shaw)
- Factors That Can Delay Log Truncation
EDIT after your Edit:
Is the new recovery model and databaseshrink going to be a conflict with this script?
That BACKUP DATABASE command will work with either recovery models. As for the routine database shrink... DON'T DO IT!!!! Seriously, size your database accordingly, and if you utilize the full recovery model then ensure that you are doing routine and frequent transaction log files, not just to keep the transaction log size at bay but to also meet recovery point objects.
We are not doing any other kind of backup of the databases, and therefore not the transaction logs, should we?
If your database is utilizing the full recovery model, then yes you should be doing transaction log backups. If your database is in simple recovery, then you physically can not do a transaction log backup.
As for what recovery model to use (simple vs. full), we can't make that decision for you. Only you, your business team, and your SLAs can.
Best Answer
When ADFS is installed using the built-in Windows Information Database (which runs an embedded SQL Server on the AD DC), these databases are installed in SIMPLE recovery model. You could possibly take that as an indication that it would be OK to run them in SIMPLE model in your own environment, but that is up to you.
In general, if you're taking a full SQL backup daily, you should be OK discarding any historical transaction log backups prior to the full backup to save on disk space. But this depends on your need to be able to restore the database to any point in time in the past. If your policy requires you to be able to restore the database to a specific point in time, then you'll likely need to hang onto all those full, diff, and tlog backups that comprise your RPO.