Patrick Purviance – SQL Server DBA Blog

Just ran into this one.   If an SSRS report user comes to you indicating that they’ve attempted to created a subscription and, although it allowed the subscription to be created, the report subscription failed to be sent via email with the following Status:

When troubleshooting, I found that the subscription owner account name did NOT match the Windows account name of the user contacting me.  In the end, the root cause was a domain name change for the affected user.  The login name on the SQL Server hosting the ReportServer database still had the old domain name for the user and used that name in the subscription setup, which failed when the credentials were used to generate and send the emailed report.

The quick fix was to execute the following via our SQL Server CMS (Central Mgmt Server):

Hope that helps if you run into this situation in your travels…

-Patrick

Check it out!!!  The Wichita SQL Server User Group has an official website.

The Wichita SQL Server User Group now has an official Facebook page for promoting the group and gaining some social media inroads. Primarily to drum up interest in the group and being to provide a discussion area, I created the page and will try to update more regularly than I am here.

I’ll be sending out email blasters thru PASS avenues and am looking for more ideas on how to attract attention for the group so we get off to a decent start and have enough board members to spread the load a little.

So……if you’re following here, or happen to find this blog, jump over to Facebook and check out the Wichita SQL Server User Group page. If you “Like” the page I can send updates to the group that way.

Sharing this for those following for WSSUG (Wichita SQL Server User Group) updates. This was shared with me by PASS’ Virtual Chapter and sounded interesting, so I’m passing it along (no pun intended).

DBA Virtual Chapter Live Meeting Event
Wednesday, December 8th

Title:

Dr. DMV: How to Use Dynamic Management Views to Monitor and Diagnose Performance Issues With High Volume OLTP Workloads

Abstract:

SQL Server 2005 introduced Dynamic Management Views (DMVs) that allow you to see exactly what is happening inside your SQL Server instances and databases with much more detail than ever before. SQL Server 2008 R2 adds even more capability in this area. You can discover your top wait types, most CPU intensive stored procedures, find missing indexes, and identify unused indexes, to name just a few examples. This session (which is applicable to both 2005, 2008 and 2008 R2), presents and explains over thirty DMV queries that you can quickly and easily use to detect and diagnose performance issues in your environment.

Meeting link: https://www.livemeeting.com/cc/8000181573/join?id=33RC8S&role=attend

The Wichita SQL Server Users Group, Inc. is now an official non-profit organization with the State of Kansas. Filing was made successfully earlier today.

A few more hurdles to clear and we’ll be able to have our first informational & planning meeting. Woohoo!

Again, I will be welcoming just about any support and volunteerism I can get to get things rolling. Once all of the requirements are in order, I will be leveraging LinkedIn, Facebook, and Twitter to generate interest for the group meetings and would appreciate all viewing this to help where they can to get the word out.

Well, that’s it for now….and in the immortal words of Bartles and James….”Thank You for Your Support”

-Patrick

Service Pack 2 for SQL Server 2008 has finally been released. I don’t usually jump on the SP bandwagon for a good 6 months, just to see what new bugs may be introduced, but I’ll probably be recommending this one within a month as I’m frustrated with not being able to use the Management Data Warehouse functionality in SQL 2008 due to an arithmetic overflow error in the data set collection processes required to gather the monitoring data for the MDW to work. For more background on that issue, see the two link below so I don’t have re-explain the problem:

To fix it, you could have installed SQL Server 2008 SP1 Cumulative Update 5 or higher, but since there were no other major issues we’ve been facing, I’ve been waiting for SP2 as it will be an easier sell here.

Here’s the link to the current page for SQL 2008 SP2:

Have you checked your TempDB data file count and sizes?
And moreover, are you monitoring its performance?

A general rule of thumb for most DBAs, for best TempDB performance in SQL Server, you should have one TempDB data file for each processor core in your SQL Server and each of those data files should be the exact same size and Autogrowth turned off. The latter point is very important for correct and balanced use of the data files allocated to to the database in that filegroup, but the former point is kind of a generalized practice to make it easier on yourself when setting up a new SQL Server. We even once had an onsite Microsoft Server Analysis rep tell us we should allocate one data file per CPU, but experience tells me this isn’t always the best solution. You really need to monitor your TempDB utilization and determine what you need. If this wasn’t TempDB, how would you determine if you needed more data files for your user databases? You’d monitor performance, right? Looking for certain wait types, right? Sure you would.

See a fantastic write up by Paul Randal (SQL Server MVP and Microsoft Regional Director) below.