Follow Up: VMware Forums Orlando

I had a number of questions asked this afternoon both during and after I presented on running SQL Server virtualized with VMware.  In order to make this easily distributable, and cover all the topics completely, I decided to use my blog as a central point to provide follow up.

1. If you want a copy of the slide deck from the presentation, you can download it from here.
   
   
2. A question was raised regarding the use of multiple files for a database to match the number of processors on the SQL Server. This is a contested subject, and various experts will argue different sides of it. There is a posting in the PSS Blog from Microsoft Full Timer Robert Dorr regarding this subject:
   
   http://blogs.msdn.com/psssql/archive/2007/02/21/sql-server-urban-legends-discussed.aspx
   
   This posting discusses this question for both user databases as well as tempdb. It is the most recently set of information available at this point in time.
   
   
3. Another question involved running SQL Server on x86 versus x64. Microsoft has a whitepaper that covers the advantages of a 64 bit environment. From a personal implementation perspective, the first migration from SQL 2000 to SQL 2005 I made in VMware was an x86 to x64 migration, and I have only gone to 64 bit since.  The performance difference is considerable, and the ability to scale RAM beyond 4GB without PAE and AWE, while gaining an extension of the VAS, makes it worth doing alone.  If your ESX host hardware is 64 bit then you should definitely consider this migration.
   
   Since this requires that you reinstall the OS as 64 bit as well, this is where I built the server disconnected from the network. To do this, you have to schedule a brief outage of your existing production server to allow you to name the new server the same name and join it to your domain. Once this is done, you can take the new server off the network, and start the SQL 2000 server again. Then you simply work on the new server using the Virtual Infrastructure Client, and install and configure SQL as needed. Transfer your Logins to the new server using the appropriate scripting code from the following link:
   
   http://code.msdn.microsoft.com/SQLExamples/Wiki/View.aspx?title=TransferLogins&referringTitle=Home
   
   Once the new server is ready, to migrate over, shut down the SQL 2000 server.  Detach the database storage LUN from the old server and attach it to the new server and power on the SQL 2005 server.  Attach the individual databases to the SQL Instance.  From there follow standard upgrade procedures, rebuilding indexes and updating statistics, and test the applications out.
   
   
4. SQLIO, the tool used in providing the disk subsystem benchmark results is available for download from Microsoft.  Included with it is a document that details how to use it.  Ideally, you will be able to run this on a system prior to installing SQL Server on it, and prior to it going into production.
   
   
5. Prior to migrating or planning to migrate into VMware, it is important to know where you are starting performance wise.  In an ideal world, you would be monitoring SQL Server consistently either with perfmon, or one of the commercially available tools like Spotlight on SQL, or SQL Diagnostic Manager.  (My graphs were created from a .NET application I wrote so they won't look like either of these.)  If you decide to go the PerfMon route, the counters you need to collect can be found on Kevin Kline's Screencasts.

If there are further questions, please feel free to contact me through my blog profile and I will answer them.