How to Truncate the Transaction Log of a SQL Server 2008\Express Database Although E2 is not responsible for the integrity of your database or for creating your backup routines, we are providing this Help Paper as an aid to help resolve a problem that is the result of not backing up or maintaining the transaction logs correctly. SQL Server implements transactions using a write-ahead log. Any changes requested to the database will first be written to the log. SQL Server ensures that the log will be written onto the disc before the actual data is written. This enables SQL Server to ensure integrity of the data, even if the system fails. If both the log and the data were written before the failure, the entire data is on the drive and integrity is ensured. If only the log was written (the data was either not written or not written completely), then the actions can be read from the log and repeated to restore integrity. If the log wasn't written, then also the integrity is maintained, even though the database is in a state as if the transaction never occurred. If it was only partially written, then the actions associated with the unfinished transaction are discarded. Since the log was only partially written, the data is guaranteed to have not been written, again ensuring data integrity. Removing the unfinished log entries effectively undoes the transaction. Once the data is written, the transaction in the log is marked as committed. The transaction log file will grow dynamically as more changes are made in the database. The log file starts at a specific size. When the free space in the log file is filled with transactions, SQL Server will automatically reserves additional free disk space from the hard drive to add to the file. Your E2 SQL Database was created using the Full Recovery Model setting. This means that if your backup routine is created correctly you can actually return your database to a specific point in time, in an emergency, by restoring backed up transaction logs. The downside is that when you do a full backup of the database, the transaction log is not automatically truncated and will continue to grow and use disk space. You can prevent this from happening by periodically truncating the transaction log or by implementing transaction log backups. If your database is set to the Simple Recovery Model, the transaction log is truncated as a part of each Full backup that you perform. The instructions provided here can be modified to manually truncate your transaction logs. First, make sure all users are out of E2 including Data Collection, PC Data Collection, E2 Trigger Server, E2 QB Server, and Quick View. The instructions below were written using the SQL Server Management Studio in the examples and may not match exactly what you will see if you use a different tool, however the basic instructions should be similar enough. 1. Log into a computer that has the SQL Server Management Studio or other 3 rd party SQL Server management tool installed. 2. If prompted, enter the appropriate login information and connect to the server.
3. Locate the Databases folder in the Object Explorer and expand it. 4. Right click on your database and select Properties from the menu.
5. In the Select a page pane, click Options. 6. At the top of the window, locate the Recovery Model field. Change this value from Full to Simple. 7. Click OK. 8. You will now need to perform a Full Backup of the problem database. This should truncate the log file for you. (Truncating the log file removes committed transactions from the log leaving only uncommitted transactions.) You could stop here and start using E2 again. However, the disk drive of your server may still be full. Complete the rest of the steps to return the free space now in the transaction log back to the disk.
9. Once you have completed the Full Backup, click the New Query button. 10. In the query tab where your cursor is flashing, type the following (replacing the XXXXX with the name of your database): DBCC SHRINKFILE (XXXXX_LOG, 2) 11. Click the Execute button. 12. You should see something similar in the results to the example below when the command has completed. 13. You have a choice to make now. You can either leave the database in the Simple Recovery Model or change it back to the Full Recovery Model. If you leave it as Simple, you will only be able to perform full backups of the database, but the transaction log will be automatically truncated after the backup and should not need to grow as large as it just was. If you change it back to Full, then you have more options for backups, but will need to manage the transaction log to keep it from becoming too large. If you decide to leave it as Simple, then skip to step 16. If you want to change it back to Full, then proceed to step 14. 14. Right click on your database in the Object Explorer.
15. Select Properties from the menu. 16. Click the Options page. 17. Change the Recovery Model from Simple back to Full. 18. At this point, it would be a good idea to make a backup of your database, since you are now unable to restore transaction logs for point-in-time data recovery. 19. Close the management tool. You are now ready to begin using E2 again. **Important - It is highly recommended that you review your Disaster Recovery plan. Please work with the person responsible for your network and computers to determine your backup and database maintenance strategy.