Takes as Long as it Takes SQL, Break on Me, I have a DAC…

The DAC, what is it? It is the Dedicated Administrator Console. Basically it is a way to connect to your SQL Server when all the other connections are tied up. But it takes a little bit of pre-planning so that you can use it when things go bad with your SQL Server.  Let’s enable it so you can test using it and know that it is there in the future.


EXEC sp_configure 'remote admin connections', 1;
GO
RECONFIGURE
GO

I was always afraid to use the DAC because I thought I had to use the command line and I am terrible with cmd. But did you know, you can connect to it through Management Studio? Now I can feel right at home when I trouble shoot a sick server.  To connect to a server using the DAC put “admin:” in front of the name of the server like this:

DAC

I use my elevated windows login for this point, but you can use what ever sys admin account that you have.

There are a few words of caution. You can only have one connection to your DAC on each server at a time. So don’t try to connect Object explorer to it. I have SQLPrompt and noticed that my server would send an alert on Severity Error 20 because SQL Prompt was trying to connect at the same time and was failing. Just be aware that you might get an error, but if everything is correct you can look down at the connection at the bottom of the query window and see you are connected.  If someone else is using the DAC, you won’t be able to use the connection, so it is a good idea to always close it when you are done.

Kendra Little b|t has a fantastic post for Brent Ozar Unlimited about the DAC and most importantly to me, how to tell who is connected.  This is the code that she wrote to help identify who is connected:


SELECT
CASE
WHEN ses.session_id= @@SPID THEN 'It''s me! '
ELSE '' END
+ coalesce(ses.login_name,'???') as WhosGotTheDAC,
ses.session_id,
ses.login_time,
ses.status,
ses.original_login_name
from sys.endpoints as en
join sys.dm_exec_sessions ses on
en.endpoint_id=ses.endpoint_id
where en.name='Dedicated Admin Connection'

Now when SQL Server Breaks on you, there is a tool that prevents us from shattering like glass.

I can hear music when Power Pivot is near…

Guess who presented for the first time at a SQL Saturday? It was also the Utah Big Mountain Data Conference.  I wanted to share my presentation in case anyone else wants to learn Power Pivot.

I love Power Pivot and think it can make a difference in how you look at data everyday.  If you have questions that you need answers to, I am happy to help.

Big Thanks to everyone that was so supportive with this presentation!

Beach Boys Data Demo

SQLSaturday Powerpoint – Unleash the Power of Power Pivot

Someone says “You’re in the wrong place master, you better leave”

Moving system databases. Whenever I have brought this up with a co-worker they seem to get a bit freaked out and want to avoid moving them.  I used to be the same, but happily now I am comfortable moving them around.

Let me first tell you why I want to move them.  I like to have my Data files on the D: drive, Log files on the E: drive, Backup files on the F: and my Tempdb files on the G: Drive.  These are all SAN drives.  This method keeps me consistent for all my servers and I am able to quickly know where to find everything I need.  I am also able to easily identify which drive my problem is on.  But my favorite reason is that in the past (three separate times), I have lost the OS to my SQL Server.  Because I had master, model, and msdb on the D: drive, after a quick re-install of SQL and the correct patch, I was able to re-point to master and everything came up beautifully without further recovery.  I had over 70 databases on one of these instances, and this method prevented me from having to restore each one along with log files. It was a wonderful surprise the first time it worked.

There are performance reasons for splitting out your files on to different drives, but we can get into that later because it requires its own post.

This step comes before I split out my tempdb files, so I am only moving one. You could easily add more lines of code to allow you to move more tempdb files.

So let’s get to the code and you will see how easy it is to do.  You will never fear moving the system databases again. This code is set up for SQL2008, but is easily modified for whatever version you are using.  Just set it up to match the folder structure.


--Check to see where your files are now.

SELECT *
FROM sys.master_files

--Move your files
USE master
GO

ALTER DATABASE model
MODIFY FILE (NAME = modeldev, FILENAME = 'D:\MSSQL10.MSSQLSERVER\MSSQL\DATA\model.mdf');
GO

ALTER DATABASE model
MODIFY FILE (NAME = modellog, FILENAME = 'E:\MSSQL10.MSSQLSERVER\MSSQL\DATA\modellog.ldf');
GO

ALTER DATABASE msdb
MODIFY FILE (NAME = MSDBData, FILENAME = 'D:\MSSQL10.MSSQLSERVER\MSSQL\DATA\MSDBData.mdf');
GO

ALTER DATABASE msdb
MODIFY FILE (NAME = MSDBLog, FILENAME = 'E:\MSSQL10.MSSQLSERVER\MSSQL\DATA\MSDBLog.ldf');
GO

ALTER DATABASE  tempdb
MODIFY FILE (NAME = tempdev, FILENAME = 'G:\MSSQL10.MSSQLSERVER\MSSQL\DATA\tempdb.mdf');
GO

ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = 'G:\MSSQL10.MSSQLSERVER\MSSQL\DATA\templog.ldf');
GO

Stop the SQL Server and physically copy over the files. Restart the SQL Server and verify they moved your files moved.

SELECT *
FROM sys.master_files

Now here is the next part of the magic.  Go to the SQL Server Configuration Manager, right click on your SQL Server and go to Advanced.  There is a line for Start-up Parameters.  You will also need to modify this string to match your version, but I simply paste this in:

-dD:\MSSQL10.MSSQLSERVER\MSSQL\DATA\master.mdf;-eC:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Log\ERRORLOG;-lE:\MSSQL10.MSSQLSERVER\MSSQL\DATA\mastlog.ldf

Then I stop my SQL Server, copy my master files to the right locations and start up SQL Server again.  It is so easy.  Test it out a few times until you are comfortable and then it will be like you are moving them around with a magic wand.