{"id":233,"date":"2018-06-23T19:01:47","date_gmt":"2018-06-23T19:01:47","guid":{"rendered":"https:\/\/projects-42.nl\/?p=233"},"modified":"2018-06-24T14:30:27","modified_gmt":"2018-06-24T14:30:27","slug":"mssql-keep-your-transaction-logs-from-exploding","status":"publish","type":"post","link":"https:\/\/projects-42.nl\/index.php\/2018\/mssql-keep-your-transaction-logs-from-exploding\/","title":{"rendered":"MSSQL: keep your transaction log’s from exploding"},"content":{"rendered":"

I recently discovered that my employers database server was running out of storage space on the database volume. After some searching I traced the problem to our Xendesktop site transaction log file witch had grown almost 80GB in 3 months.<\/p>\n

I never noticed problems with the transaction logs before but previously the SQL server was a physics machine with around 1 TB storage for the databases while the new database server is a VM with only 350GB available for the databases.<\/p>\n

If you work with Microsoft SQL server from time to time, you might know that a database usually consists of two files. The database file “<dbname>.mdf” and the transaction log file “<dbname>.ldf”. The database file stores the current version of the database while the transaction log file saves all changes to the database. It is important to have a transaction log, because it enables you to rollback the database to a point in time, or recover the database after a software crash or an unexpected power failure.<\/p>\n

There are 3 modes in with the transaction log can operate: Full, Bulk-logged and Simple. I wont be going into detail about the different recovery models, Microft has a good article<\/a> about this subject.<\/p>\n

In short, Full saves all transactions indefinitely while Simple removes them after committing them to the database. Bulk-logged is almost the same as Full but it has some enhancements for logging bulk transactions.<\/p>\n

Our Citrix database was configured to use the Full recovery model, this is the default setting.<\/p>\n

To solve this issue while retaining the ability to recover data in the event of a crash we will have to set up transaction log back-ups. If configured right this can be an automated process.<\/p>\n

Follow the following steps to back-up a transaction log:<\/p>\n

\"\"
From the SQL Server Management Studio, click right on the DB of witch you want to backup the transaction log. Navigate to Tasks<\/strong> and click “Back Up…<\/strong>“.<\/figcaption><\/figure>\n

 <\/p>\n

\"\"
In the Back Up Database dialog on the General tab, change the backup type to “Transaction log” and specify a destination for your backup.<\/figcaption><\/figure>\n

 <\/p>\n

\"\"
In the Back Up Database dialog on the Media Options tab, check the “Verify backup when finished” checkbox if you want SQL server to verify the backup after it finishes.<\/figcaption><\/figure>\n

 <\/p>\n

\"\"
In the Back Up Database dialog on the Backup Options tab, Set backup compression to “Compress backup” (unless you just want to move your transaction log in witch case you can live the setting in the default).<\/figcaption><\/figure>\n

 <\/p>\n

At this point you can simply click the OK button and the backup will start. In this case it will be a one time only backup. We ICT people like to automate things so we wont have to repeat actions over and over again. Fortunately, we can turn this process in a automated task.<\/span><\/p>\n

 <\/p>\n

\"\"
to turn the above process in an automated task, click the downward arrow next to the script button at the top of the dialog and select “Script Action to Job” (or press “Ctrl+Shift+M”).<\/figcaption><\/figure>\n

 <\/p>\n

Unfortunately SQL server Express edition wont allow automated jobs so for the rest of the process i have used a much older SQL Server Standard Instance<\/p>\n

 <\/p>\n

\"\"
Clicking on the “create job” button will open a new dialog named “New Job”. Most of the information on this page and the script itself are already added to the new job. Navigate to the “Schedules” tab to schedule the new job.<\/figcaption><\/figure>\n

 <\/p>\n

\"\"
At the schedule tab we can create new schedules. in this case we want to backup the transaction log every Sunday at 1 AM. You can set multiple schedules for each job.<\/figcaption><\/figure>\n

 <\/p>\n

\"\"
On the notifications tab we can set what type of notifications we want to receive from this Job. You can configure this to your liking. Click OK to Save the Job.<\/figcaption><\/figure>\n

 <\/p>\n

If everything went as planed, we now have an automated transaction log backup Job. Unfortunately the transaction log remains the same size as it was before. to release the backed up space we need to shrink the Transaction log.<\/p>\n

WE DON’T WANT TO SHRINK THE TRANSACTION LOG TO OFTEN, GROWING THE LOG IS A SLOW PROCESS!!!<\/strong><\/p>\n

If your transaction log is huge and you want to reclaim <\/span><\/span> some of the space, continue following these steps:<\/span><\/p>\n

to be able to shrink the transaction log file, we first need to switch the database to simple recovery mode.<\/p>\n

click right on the database you want to shrink and click on “Properties”<\/strong>.<\/p>\n

\"\"
In the property’s dialog, select the options tab and select “Simple” from the recovery model drop down list. Click “OK”<\/strong> to apply the change.<\/figcaption><\/figure>\n

 <\/p>\n

\"\"
Right click the database you want to shrink, navigate to Tasks -> Shrink and click “Files”<\/strong>.<\/figcaption><\/figure>\n

 <\/p>\n

\"\"
In the shrink File dialog, change the file type to “Log”<\/strong> and make sure the shrink action is set to “Release unused space”. Click “OK”<\/strong> tot start the shrink action.<\/figcaption><\/figure>\n

Don’t forget to change the recovery model back to full, if it was set to full to begin with \ud83d\ude09<\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

I recently discovered that my employers database server was running out of storage space on the database volume. After some searching I traced the problem to our Xendesktop site transaction log file witch had grown almost 80GB in 3 months. I never noticed problems with the transaction logs before but previously the SQL server was […]<\/p>\n","protected":false},"author":1,"featured_media":235,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[52,53,51,54],"class_list":["post-233","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-general-ict","tag-mssql","tag-sql","tag-sql-server","tag-transaction-log"],"_links":{"self":[{"href":"https:\/\/projects-42.nl\/index.php\/wp-json\/wp\/v2\/posts\/233","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/projects-42.nl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/projects-42.nl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/projects-42.nl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/projects-42.nl\/index.php\/wp-json\/wp\/v2\/comments?post=233"}],"version-history":[{"count":5,"href":"https:\/\/projects-42.nl\/index.php\/wp-json\/wp\/v2\/posts\/233\/revisions"}],"predecessor-version":[{"id":254,"href":"https:\/\/projects-42.nl\/index.php\/wp-json\/wp\/v2\/posts\/233\/revisions\/254"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/projects-42.nl\/index.php\/wp-json\/wp\/v2\/media\/235"}],"wp:attachment":[{"href":"https:\/\/projects-42.nl\/index.php\/wp-json\/wp\/v2\/media?parent=233"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/projects-42.nl\/index.php\/wp-json\/wp\/v2\/categories?post=233"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/projects-42.nl\/index.php\/wp-json\/wp\/v2\/tags?post=233"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}