The Right Way to Move Tempdb Files on Azure Virtual Machines

In the “real world”, the best practice for disks layout would be:

• log files on a separate disk partition
• data files on a separate disk partition
• tempdb files on a separate disk partition.

But if you compare the “real world” to the Windows Azure Virtual Machines world, you can say it’s like Thailand – “same same, but different”.
The basic approach stays the same. Log and data files should be separated and tempdb should be on a designated drive.

The difference is that on Azure Virtual Machines, you are provided with drive “D:” which is a temporary storage.
You can use this drive to store temporary data, which you can afford to lose at any time.
Tempdb should ring a bell at this point.

Any data on this drive, including all files and folders, will be deleted on restart. Since we can’t create directories from within SQL Server, it will be simpler to just move the tempdb files to the root of drive D. You can do that using the following T-SQL command:

USE MASTER
GO
ALTER DATABASE tempdb MODIFY FILE (NAME= tempdev, FILENAME= 'D: \tempdb.mdf') 
GO
ALTER DATABASE tempdb MODIFY FILE (name = templog, filename = 'D: \templog.ldf') 
GO

After the transfer and the restart of SQL Server, you can manually ‎delete ‎the files from the old drive.

It is so simple – what can go wrong, right? Well, I’m glad you asked.
I recently moved the tempdb files to the D: drive on a production environment, did everything by the book as I should have, but when I tried to log on to the server it kept on failing.

First I looked at the MSSQLSERVER service to see if it’s running or not.
Well, it’s not accurate. I first panicked (production environment are always more stressful than staging). after 5 seconds I told myself “stop panicking and go take a look at the SQL Server service”.
So I did. It was on “running” status but when I refreshed it I saw that the service was actually down.
To find out what the hell happened, I looked at the windows application log and saw an error that indicated a problem of the server to recreate the files that I just moved: The tempdb files.

The Solution:

Using computer management, I needed to add a new account with administrative permissions to create files with direct access to the D: drive and make SQL Server run under the new account using SQL Server Configuration Manager. I granted the relevant permission to the account by adding it to the local administrators group.

Image may be NSFW.
Clik here to view.

Image may be NSFW.
Clik here to view.

After I did that, the service was “running” and stayed that way, I could log on to the server and the tempdb files were in the right position: drive D.

The post The Right Way to Move Tempdb Files on Azure Virtual Machines appeared first on .