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.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
