SSRS Error: The version of the report server database is either in a format that is not valid...

Problem:

If like me you come across the error below after navigating to http://reportsystem/reportserver

The version of the report server database is either in a format that is not valid, or it cannot be read. The found version is '163'. The expected version is '162'. (rsInvalidReportServerDatabase).

Luckily this was in a DEV environment and was part of our patching cycle to test SQL Server 2012 SP2+CU5. 

As we already knew changes were made to the SQL Servers in terms of patching there was a good chance it was related ;-)

Although this MSDN wasn't the exact problem, it did lead me to a simple solution in the end.

Solution:

As we host separate SSRS servers to the database it was notices that the SSRS instance hadn't been patched. Normally this doesn't cause issues within reporting server reviewing the MSDN pointed me in the right direction due to MS changing the DB versions within this patch.

Therefore patching the Reporting Services instance to 2012 SP2 + CU5 resolved the issues. 

4k or not 4k, that is the question?

Yesterday I was reading a blog by Bob Door (blog) on 512e/Advanced Form Sector drives due to hit the market soon, from the likes of Seagate and WD.

For any serious DBA it is worth taking 30 minutes of your time to read the blog and do your own research

http://blogs.msdn.com/b/psssql/archive/2011/01/13/sql-server-new-drives-use-4k-sector-size.aspx

While doing my research I came across an excellent article from Brian Madden (blog). This post goes into the in/outs of the drive performance .



Enjoy

JL

SQL Server time-out with a difference, PREEMPTIVE my AR5E

Ok, let me say this is my 1st proper technical blog, so please gentle with any comments ;-)

The other day I was looking into an issue in our development environment which was causing timeouts. The dev's usual complain, but normally is their code causing the issue (dont get me started)... In this instance the query was pretty well written, CPU on the host was low, memory usage at the OS and SQL Level was all within an acceptable range and disk usage was also minimal for this environment. So, what was going on? One thing to also mention is that SSMS also used to time-out on the odd occasion.

Using a recent post by Paul Randal (blog) for a waittypes survey, I checked what the top waits were on the dev server. Some of the common one's appeared in there like WRITELOG, CXPACKET etc but one that stood out was PREEMPTIVE_OS_LOOKUPACCOUNTSID.

I knew a lot of the PREEMPTIVE_% waittype are new to 2008/R2, but this I had no idea what it was. I did however take an educated guess it was something to do with AD, and referring to the "master of all" google I stumbled across a post by Steve Hindmarsh (blog).

After reading the post with "hopeful" interest I found that this wasn't the cause of the problem, but it did however point me in the right direction...

I had an idea from this post that it has to be something with AD or Network routing, as the post covers issues with untrusted domains within mssql.

Well, after a 15 minute debate with the networking "commander in chief" we found the issue! DNS... Yes, the server was setup by the "techies" with 1 invalid DNS server and the other severely overload. Therefore when SQL Server was trying to authenticate the Windows user(s) it was causing SSMS and application to time-out.

Another lesson learnt; don’t always assume that it is an issue with SQL Server!!!

Hope this post help anyone with this issue and I look forward to your comments..

Thanks

So.. It my 1st blog.

There is not going to be any technical details in this blog, as I am currently working on a "good" first article.

I intend to only add techincal blog so I can share my SQL Server tips/tricks/workarounds/ideas.

Hope you all keep a close eye and look forward to you comments on future posts.

Thanks

JL