Windows Server 2003 and SQL Server 2000 for 64-bit Itanium systems promise huge performance gains over their 32-bit counterparts,
and they deliver on that promise. But there are many other factors to consider when upgrading to a new platform, such as whether
you can run old applications as is and manage them in the same familiar way.
It’s not necessary for any piece of software to be completely compatible with all of its predecessors, but it is necessary
for an upgrade’s benefits to be far greater than those gained by staying on the current platform. This weighing of benefits
was the focus of my tests of 64-bit Windows and SQL Server. What would I gain by porting to this new platform? And what would
I lose?
In Windows, I expected to see full compatibility with Active Directory, the .Net Framework, file/OS recovery, the entire OS
feature set, and a tremendous increase in performance. In SQL Server, I expected to see the advertised fully backward-compatible
T-SQL (Transact-SQL) code, a superior performance increase from increased memory, and the entire set of features and management
tools I’ve been using in the 32-bit version.
In both cases, I found the performance gains I was looking for, but neither product delivered all the goods. Both Windows
and SQL Server are missing important features that severely limit their usefulness. In its current state, 64-bit Windows presents
a viable alternative to the 32-bit platform only in a few narrow circumstances.
Dueling Windows
Getting Windows Server 2003 installed is extremely easy; I didn’t encounter any surprises. Management is relatively easy,
as well. All of the management features found in the 32-bit version are available in this version. And the two versions interoperate
very well, so having only one or two 64-bit boxes in your organization shouldn’t cause any problems.
The 64-bit architecture provides a theoretical memory address space of 18 exabytes (18 billion gigabytes). In the real world,
though, Windows Server 2003 Enterprise Edition is limited to 64GB of memory, and it can support up to eight processors. If
you need even more horsepower, then Windows Server 2003 Datacenter Edition supports up to 512GB of memory and 64 processors.
This means that 64-bit Windows is extremely scalable, and most customers will reach practical limits long before they reach
the physical limits built into the software.
Even the 32-bit version of Windows Server 2003 improves greatly on the file and print services of Windows 2000, and it is
not necessary to port to the 64-bit platform to see some dramatic improvements in this area. However, a good deal of file
and print server performance depends on CPU, bus speed, and the amount of memory the system has to serve requests. By taking
advantage of more capable hardware, 64-bit Windows can provide a significant performance boost here.
Microsoft hit a home run with SCR (Shadow Copy Restore) and ASR (Automated System Recovery) in the original Windows Server
2003, and these features also work flawlessly in the 64-bit version. SCR allows administrators to take a ghost image of an
entire system in order to recover after a major system failure. ASR allows admins to take snapshots of disk partitions and
puts restores in the hands of users, who can revert back to previous versions of their files with a couple clicks.
One critical piece that didn’t make the leap to 64-bit Windows is the .Net Framework, which seriously limits the capabilities
of the OS both as an application server and as a Web server. Even if you are not running .Net Web code, you would probably
be better served with a load-balancing cluster on 32-bit Windows Server 2003. And considering the relatively high price of
Itanium hardware, porting any Web code to this platform would not be cost-effective.
My performance testing focused on Active Directory and messaging, and involved running side-by-side address lookups and e-mail
messaging simulations that pit the 32-bit and 64-bit versions of Windows against each other. Microsoft has already published
test results showing significant Active Directory performance increases in Windows Server 2003 (32-bit) over Windows 2000.
My test results show how 64-bit buries 32-bit Windows under the same testing conditions.
I ran each simulation for about 10 minutes. In that time, the 32-bit system completed 9,254 lookup operations at 15.3 operations
per second, while the 64-bit system completed 106,354 operations at 169.9 operations per second. The e-mail messaging tests
showed similarly incredible performance gains. Here, the 32-bit system performed 5,227,548 operations at 8,698.1 operations
per second, while the 64-bit system performed 8,117,030 operations at 13,505.9 operations per second.
In both tests, but especially in the address lookups, lower disk queue numbers exhibited by the 64-bit system showed that
the OS was relying more on the increased memory and bus speed of the Itanium hardware, while the 32-bit system was having
to do more paging, causing requests to pile up in the queue. Simply put, the 32-bit system did what it could, but it simply
couldn’t compete with the huge resource pool of the 64-bit architecture.
Son of SQL Server
Installing the new SQL Server was a breeze. Microsoft has switched to the Microsoft Windows Installer, which not only puts
both SQL Server and Analysis Services into the same install (it’s about time), but anyone who has ever installed Office will
run through this with ease. And porting current SQL Server databases over to 64-bit is as simple as drag and drop — even an
inexperienced DBA can do it.
But when 64-bit SQL Server is installed and the databases are ported over, the headache begins. The possibility for miscellaneous
code failures and management glitches is high. Microsoft has not included any management tools with this release, and this
omission will be a thorn in the side of any administrator using this product. SQL Enterprise Manager, Query Analyzer, and
SQL Profiler are the most important tools to any DBA, and the only way to use them on the new platform is to connect with
these tools from 32-bit clients.
This approach leaves a lot to be desired. From the client, I found Enterprise Manager quirky at best; many times it reported
incorrect information, refused to refresh properly, and even got servers mixed up. Query Analyzer is often used to troubleshoot
poorly running SQL code, and being able to connect directly from the server itself is the only way to eliminate outside factors
in the client/server equation. SQL Profiler is quite often used remotely, but not having the option to run this auditing function
on the server inconveniently ties DBAs to their workstations for scheduled audits.
In theory, it shouldn’t matter where the management tools sit, but in practice, the tools are quirky enough that not having
them directly on the server makes it impossible to reliably perform simple management functions.
Other important pieces are missing. For starters, this version of SQL Server doesn’t include native DTS (Data Transformation
Services) components. Administrators can run DTS packages against 64-bit SQL Server from another (32-bit) machine, but they
cannot schedule and run loads and transformations natively on Itanium. Most database administrators consider DTS a major component
of their systems, and they’ll be reluctant to move their databases to a new platform without it, regardless of the extra horsepower.