From the horse’s mouth at at the Windows Server Division WebLog:

“First and foremost, 32-bit is done. History. Archives. Windows Server 2008 R2 is the first Windows OS platform to go 64-bit only, and frankly it was high time. Customers have been unable to purchase a 32-bit server CPU for over two years now, and the advancements in CPU architectures really dictated that we squeeze as much performance out of customers’ hardware purchases as possible. The move to 64-bit is a first step.”

SQL Server database administrators everywhere are probably clapping with delight, but that clapping may slow down a little if you use virtual machines on your desktop computer for testing or development.  If you’d like to run Windows 2008 R2 as a virtual server guest, that means you need to be running a 64-bit host - which means your laptop or desktop will need to be running a 64-bit version of Windows.

Update: fellow Questie David Gugick points out that you can still run 64-bit guests on 32-bit host OS’s as long as your underlying hardware is 64-bit compliant.

Hi all, here’s a vblog entry that covers a bit more the topic of clock drift in virtualized environments.  This vblog entry corresponds to my blog post earlier this week. 

Enjoy and I look forward to your feedback - Kevin

Technorati Tags: clock drift, database administration, kevin kline, microsoft, sql server, Virtualization

Last week, I was listening to John Rives, CEO of Amniox, speak about virtualization and clustered VMS (see pictures at http://drsql.spaces.live.com/blog/cns!80677FB08B3162E4!2292.entry.  Thanks Louis!) at the local SQL Server User Group meeting in Nashville.

John gave a really interesting talk about implementing virtualization and many of the benefits and pitfalls that you might encounter.  Most of the content was review for me, but the one concept that was new was a biggee - clock drift.

Clock drift is a situation in which the actual time shown on the physical machine’s (PM) clock, for example 3:53 pm today, is no longer in sync with one or more of the clocks of virtual machines’ (VM) running on the PM, showing 12:12 pm today and 9:30 pm yesterday.  This can happen because the VMs 1) only receive a slice of the PM’s total processing power and cycles, thus getting confused on the time, and 2) the application(s) running on the VM do not manually synchronize the VM clock with the PM’s clock or an external time source.  Naturally, if you’re running SQL Server, this can be a huge data integrity problem for you - especially for any transactions that record the date and time.

This is a fairly old-school problem, it turns out, and there are lots of hits when you google for “clock drift virtualization”.  However, the state of the industry seems to be somewhat immature in that the best hits tended to be blogs and discussion forums rather than vendor documentation or best practices papers.  If you’re developing applications for SQL Server that might be implemented on a VM, do yourself a favor and make sure you include clock syncronization processes as part of the application.  Otherwise, you might have to deal with a nasty clock drift problem.

Regards,

-Kev

Technorati Tags: Virtualization