RTCXDS Transaction Log Full

Occasionally on a Skype for Business server deployment, you may find yourself getting hit with 57005 errors out of nowhere, with the frontends complaining that they’re unable to push data to the RtcXds Blob Store. The error is nice enough to go into some further detail – in the screenshot listed below, you’ll see that the SQL exception which was returned was “The transaction log for database ‘rtcxds’ is full due to ‘LOG_BACKUP'”

The main problem here is that while other databases’ log files are set to expand quite nicely, the RtcXds logfile is inexplicably capped at 16GB. The database itself is unlimited, but once that transaction log is full everything will cease being able to write to the database. At any time you can check the size of the logfiles by running the following command in a Query window:

DBCC SQLPERF (LOGSPACE)

In my case, the rtcxds logfile was at 100%.

The quick and dirty way to get around it is just to perform a backup of the logfile to disk, but I’d prefer to give it some extra headroom, as well as a maintenance plan so that we don’t face this problem again.

First, let’s perform an initial backup of the logfile to disk so that we know it’s safely stored somewhere before we start messing with it. Connect to the database with SQL Management Studio, right click on the RTCXDS database and select tasks>backup. Select Transaction Log and ensure that Copy-only backup is unticked. In the destination section, choose a location and filename. Click OK and wait for the backup to complete.

Next, open a new query window where we’ll execute the following TSQL

BACKUP log rtcxds TO DISK = 'NUL:';

ALTER DATABASE rtcxds MODIFY FILE (NAME = rtcxds_log, MAXSIZE = 50GB);

In this command we’ll run another backup, but this time we won’t write it anywhere. This will ensure that we’re able to modify the actual file in the second line, which will set the new maximum size of the logfile to 50GB. Change this to whatever you prefer and execute by either pressing the execute button or hitting F5.

The final step is to set up a maintenance plan to back up your transaction log to disk on a regular basis. I’ll cover that in another post.

Advertisements

LyncLab, part 1: Everything you wanted to know about Hyper-V but were too afraid to ask.

If you’re anything like me, you build up and tear down your lab on a regular basis. You might do this because you’re studying, you might want to try out new ways of doing things, or you might just want to flex your buid muscles while you’re in an operations period to keep your skills fresh. I run a local lab on my home desktop, and found myself tearing it down quite regularly, so I decided it was time to script, streamline and document the process as much as possible.

In this first entry of this series, we’ll do the groundwork for the Lab. We’ll install Hyper-V, create a template disk which can be “cloned” for future builds – all machines will use differencing disks so we can keep the footprint of our lab to an absolute minimum.

The first machine will be a Windows 2012 R2 Server Core install, which is as lean as you can get. We’ll also run a windows update from the comandline, and finally we’ll sysprep the machine in preparation for cloning.

In future entries in this series, we’ll make a child differencing disk and install Server GUI, which will then become the parent disk for any machines which require it, we’ll create an Active Directory, a Lync 2013 Enterprise pool, and maybe a few more goodies.

Continue reading