A 64-bit platform still under construction

The super-size editions of Windows Server 2003 and SQL Server 2000 are hindered by missing pieces

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. 

41FE64win-in.gif
Click for larger view.
41FE64winrevsql-in.gif
Click for larger view.

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. 

Also missing from 64-bit SQL Server is isql.exe (included in SQL Server 2000 for backward compatibility), which allows users and administrators to run T-SQL code from the command line. Of course, it’s only a minor change to use osql.exe (the SQL Server 2000 version of isql.exe) instead, but as we all know, sometimes making simple changes to production code can have cascading effects.  

SQL Mail is another victim. Any objects that use SQL Mail, such as stored procedures and triggers, will not only stop sending messages, they will also produce errors every time they’re executed. This also means that any of the other mail-extended, stored procedures won’t work anymore, either.

Microsoft claims that the 64-bit version of T-SQL is completely compatible with the 32-bit version. But this “compatibility” won’t help developers and administrators who call DTS packages and SQL Mail from triggers and stored procedures. Calls to these programs are often embedded in T-SQL code. Being able to call on these programs may not officially be part of the T-SQL language, but developers and administrators won’t care when digging through code with their bosses breathing down their necks, or perform functions manually that used to be automatic.

The fact that Microsoft chose to keep DTS and SQL Mail out of this release is going to cripple all but the smallest percentage of clients who make the switch. Any organizations hoping to port backward-compatible databases to the 64-bit architecture should give their SQL code a once over.  They should also take a look at their third-party management and monitoring tools; many of these install agents are on the server itself, relying on RPCs for drill-downs, and may no longer be fully functional.

I measured the OLTP (online transaction processing) performance of the 64-bit versions of both SQL Server 2000 and Oracle9i on Windows Server 2003 by creating varying user loads where each user performed 15 OLTP-intensive operations. One would think that SQL Server has a clear advantage over Oracle on Windows simply because it isn’t hindered by cross-platform architecture. Not only that, but the SQL Server team should have knowledge about Windows that the Oracle team doesn’t. Yet, having the inside track on Windows doesn’t seem to have bought SQL Server any performance advantages. The two products performed similarly, and the subtle differences in my test results could easily be adjusted either way by a skilled DBA.

Even though SQL Server’s performance was quite acceptable from an OLTP standpoint, its high potential for broken code represents a huge performance issue. And whereas 64-bit Oracle is a mature, feature-rich RDBMS, 64-bit SQL Server just isn’t a complete product. The relational engine is very stable, but there are too many things missing. No doubt SQL Server will evolve into a mature 64-bit database, but today it’s more a proof of concept than a full release.

The 64-bit versions of Windows Server 2003 and SQL Server 2000 are solid platforms with speed and power to spare, but the missing features are enough to knock them out of the market for the majority of customers. Who should take a look? The SQL Server release is for only those shops doing strict OLTP with fairly static configurations that don’t require more than a very moderate amount of administration and troubleshooting. Nothing fancy: just reads and writes, no major imports, no alerting.

On the Windows side, the missing .Net Framework makes for a hard sell to 64-bit customers. The new OS could serve enterprises that need to consolidate file and print servers, domain controllers, or Web servers as long as they don’t rely on .Net. There’s nothing to prevent you from running legacy (pre-.Net) Web applications on this platform, if the Itanium hardware is within your budget. But you can probably get the extra performance you need a lot cheaper from a 32-bit cluster.

41FE64win-bl.gif
InfoWorld Scorecard
Setup (5.0%)
Value (10.0%)
Performance (25.0%)
Interoperability (5.0%)
Manageability (25.0%)
Scalability (15.0%)
Availability (15.0%)
Overall Score (100%)
Microsoft SQL Server 2000 Enterprise Edition for 64-Bit Itanium Systems 7.0 5.0 3.0 7.0 3.0 7.0 7.0 4.8
Microsoft Windows Server 2003 Enterprise Edition for 64-bit Itanium Systems 7.0 5.0 8.0 8.0 8.0 3.0 6.5
Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies