Report server log file eating up diskspace – ReportServerTempDb

I got a 400Gb log file for my birthday today.

This 400gb made me mad, It’s just a temp db. And all processes are down this morning. Looking around on the internet, this seems to be a common known problem, some even  state this problem is acknowledged by Microsoft.i can be.. engineer

After reading some blogs on possible solutions. I decided I need to solve the disk problem first. First checks you need to do before you start the troubleshoot:

You need to rule out that you didn’t bring this over yourself, the ReportTempDb needs to be in Simple mode, this means there are no logbackups and the it should automatically reclaim space in your logfiles, well, this is how it should work. But in this case the logspace keeps growing. Indicating something is wrong with the reportserver, when it already is in Simple mode.

Also It could be worthwhile to check which reports are costing you, since not only your log space is invaded by report servers, your CPU is probably a victim too..

After these checks, we have 2 routes to go, but today we’ll will start with the quick and dirty one, solve the disk shortage, since all processes are put to a stop due to this ‘Stay Puft’ logfile. We need to shrink this beast, I should tell you, shrinking your database is pure evil and risk taking. You should never ever ever do this! …Unless even Microsoft says it’s ok. And it’s just tempdata. It should’ve just deleted itself.

First, we are gonna run a full backup of the ReportserverTempDb, to an external location, ofcourse. Once this is done, we canstart with the clean up of the logfile.

Bring your database level to full mode, this allows you to alter the filegroups.

Right click tthe ReportServerTempDb database Go to the option shrink –> files and check the available free space and check the release unused space button.

This should give you some space, in my case, 400Gb, whoohoo, Dobby is free! Don’t forget to put your ReportServertempDb back into simple mode!

You could also shrink the log file with the ‘shrink file’ option, but like I said earlier, it’s better to avoid this option, because it could lead to faulty logfiles when you need to recover. But I case of this ReportServerTempDb the risk is low.

Now that we have got some diskspace back, we need to dig deeper to find out the cause of this log file eating up all your precious disk space. Next topic will be how we can fix this Stay Puft log file growth.

Beginning Node.js – Testing – part 5

This is part 5 of the series: beginning Node.js. In this part we are testing our REST API with Mocha, Chai and Superagent.

Testing for the newbie

To test your Node API’s you will need to install the following dependencies:

  • Mocha. Mocha is a library to run tests, AKA a test runner, or test infrastructure. Install it globally, like so: npm install -g mocha.
  • Chai. With Chai you can use “assert that.. ” or “should be.. ” or “expect that.. “. Depends on the test philosophy you are using (BDD, TDD and the likes)
  • Superagent. Superagent is a library that can test a web api, like so: superagent.get(‘http://localhost:3001/food’)

Of course there are alternatives (Jasmine, Should ..) but in my humble experience the above 3 work just fine. At first I was wondering why I needed so many libraries but I guess this all about the freedom to mix and match the modules you like the most. Which is quite nice.

Test the API

This is an example test to the ‘list’ function of all the food. Does the API return a JSON array? Well, it should, so I expect it to be.

First, Create a folder named ‘test’
Then put a file in it. (e.g. test1.js), with these contents:

}

Now run the test with the command: mocha.

Another test

With SuperAgent you can also test a POST action (be sure not to use your production db, but more about different environments later).

Run the test:

So, this was just a wee intro to testing web API’s. There is lots more to discover about this subject!

I just put the code online at github. This is still a work in progress though.