The Rants of a SQL Server DBA

Part of this is going to be the SQL Server DBA in me ranting, so be patient and know as it says in the lovely site disclaimer, this is MY OPIONION and yes, I stick by this opinion 100%.

I have very strong feelings on who and how a SQL Server, especially one with SSRS is installed.  Microsoft’s continued mis-marketing, (albeit successful for sales) and ease of installation has created database environments that are misconfigured, poor-performing and poorly designed-  BY DEFAULT. 
Few experts in .Net or SSRS, when asked, know what transaction logs, filegroups, lock escalation or sp/dbcc procedures are.  If you don’t know what each and every one of these are for, you shouldn’t be installing SQL Server.  If you don’t know why the tempdb and transaction logs should be on separate spindles or why it’s not a good idea to have one, monstrous, huge drive, (see the first part of this sentence for a clue…) then you shouldn’t be installing SQL Server.

What are the rules of thumb a DBA follows when we are installing?

• Install the SQL Server as a dedicated SQL Server admin account that has the least amount of privileges required to perform all database tasks, (If I see one more database owned by “domain\standard user of database” I’m going to break something…:))
• If this is a production database, high use, I’m going to want multiple filegroups, (Oracle DBA’s can think tablespaces at this point… :))  I am good with the primary filegroup for the standard tables, but I want another for indexes, a third, fourth, fifth, etc. for high use objects.
• I do want multiple drives and I do not want to place my binaries in the default location on the C:\ drive.  The last thing my NT Admin needs is me filling up the drive that the OS resides on.  Give me a designated SQL Server binaries drive with plenty of room for upgrades, it’s only going to get larger.
• I want drives for my data, my indexes, tempdb, transaction logs and backups.  Do not skimp on space and I am more than happy to tell you the ratio of sizes needed for the backups per retention period. 
• Don’t give me RAID5 for my databases, you’ll only tick me off when people start complaining about the I/O issues.  I know you get less MB in the end, but trust me, RAID0+1/RAID10 is worth the cost.
• Don’t give admin access to every Tom, Dick and Harry to the box.  You don’t do it to your Oracle servers, why would you do it to these database servers? 
• Last, but not least-  treat them with the respect any database server deserves.  Back them up, move the files off to tape, secure the systems, leave the database admin work to a DBA.

So, what started the rant?  One of my poor NT Admin’s went through a challenging process that renamed a service account.  After he corrected all this procedure broke, we arrived a couple days later to find that no one could run any of the reports through the web from this main reporting server.

It turns out, when this SQL Server with SSRS was installed and configured for our company by a third party vendor it was performed with the service account that the NT Admin was forced to rename. Due to this, it was the “db owner” of the Reporting Server, including all the encryption internally and cached authentication had “run out”.

I found the error immediately, as there were also SQL Server Agent jobs attempting to authenticate with the service account, so the following message was reported in SQL Server’s error logs:
Message
[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user ‘DOMAIN\SERVICE_ACCT’, error code 0xffff0002. [SQLSTATE 42000] (ConnIsLoginSysAdmin)
It wasn’t as simple as renaming the database owner for the ReportServer database, as there are encryption keys that are created at the time of installation.  I will say, they have simplified the process for 2008 vs. earlier versions though! 🙂

• Change the ownership of the ReportServer and ReportServerTempdb databases to the DOMAIN\NEW_SRVC_ACCT database, (as it should have originally been performed as.) using the stored proc sp_changedbowner.
use
 
go
exec sp_changedbowner ‘DOMAIN\NEW_SRVC_ACCT’
go
• Start the Reporting Services Configuration Manager and connect to the database repository for the SSRS.

1. Click on Service Account and change from “Network Service” to “Use Another Account”.  Type in the username and password of the new DB Owner you specified in the sp_changedbowner step.
2. Click Apply
3. Click on “Encyrption Keys” on the left and choose to backup, (always, always backup after every change.)
4. Choose a secure local location, (and also make a copy of these on your backup server each time..) and password protect it.
5. Click Apply.
6. You have now officially reset everything in the Network service from the old domain user account to the new one.  You now have to reset all back to the Network service.
7. Click again on Service Account and Change the “Use Another Account” back to “Network Service”
8. Click Apply
9. Click on “Encryption Keys” and make another backup, saving to a new file name each time you perform this step, (date and time in file name helps…)  Save off a copy of the final encryption keys to the backup server is essential if you wish to recovery the SSRS some day, so DON’T FORGET!!
10. Change the ownership of any other databases with a simple execution of the sp_changedbowner as seen above, (only SSRS requires the other steps…) and change any agent jobs or other services that are running as the now missing service account. 

• Test reports and you should be good to go.

Many issues, like the one above, can be avoided if a DBA works with the NT Admin to ensure the server is build correctly to support SQL Server and if a DBA performs the installation and configuration of the database server.

**Added 10/07/10 after an email or two with a couple other SQL Server DBA’s-
IF you don’t know any of the topics that I listed for requirements to install SQL Server, it should also be a requirement to know these before you are aliased as DBO or given admin privileges on a SQL Server box-  nuff’ said!!
~done rant!~ 🙂