Just before Microsoft officially announced Windows 2000 (Win2K), the SQL Server development team jumped into light speed and recorded the Transaction Processing Performance Council's (TPC's) top TPC-C performance score of all time. I've known since Microsoft released SQL Server 7.0 that I would be writing this column sooner or later. But I'm shocked and amazed that I'm writing it so soon.

The team achieved this TPC-C benchmark score by using Win2K with SQL Server 2000 running on 12 8-way Compaq ProLiant 8500 servers. Each ProLiant system had eight 550MHz Pentium III CPUs. The total cost for the cluster system was $4.3 million. The top TPC-C number this system provided was 227,079 tpmC—almost twice the previous record of 135,815 tpmC, which an IBM team set with Oracle8i running on a single 24-CPU AIX-based IBM RS/6000 S80 enterprise server that cost more than $7.1 million. The new SQL Server TPC-C scores are also a 68 percent improvement over the best clustered result of 135,461 tpmC, achieved on a 4-node, 96-processor Sun Solaris cluster running Oracle8i. Nearly as good as the tpmC numbers are the price per tpmC marks. The SQL Server team achieved the top SQL Server scores at a price point of $19.12 per tpmC, less than half the cost of the previous Oracle scores.

These results are even more surprising when you look at the clustered platform that the team used for TPC testing. Until now, SQL Server hasn't supported partitions or clustering for scalability. SQL Server supported clustering only for failover or high-availability scenarios. The SQL Server 2000 and Win2K systems that set these TPC-C benchmark scores used new distributed partitioned view technology. Distributed partitioned views consist of joined, updateable views that span multiple servers. Technically, this setup isn't a true clustered implementation. According to Microsoft, SQL Server won't support true clustering until the post-SQL Server 2000 release, code-named Yukon. The primary difference between a true cluster and the distributed federated views that SQL Server 2000 uses is that distributed federated views don't provide administrative transparency. You manage each server independently, but because the servers act in unison, they're considered federated—not clustered. However, partitioning is transparent to the application, and you manage the database as a single entity. Table partitioning occurs horizontally across multiple servers, creating many smaller tables called member tables. Each member table has the same schema and its own subset of rows. You manually place each table on a separate SQL Server system to divide the processing load across the systems. A distributed partitioned view lets all the member tables appear to the application as one table.

You can see the TPC-C results at http://www.tpc.org/new_result/ttperf.idc. Although benchmarks don't reflect the performance that you'll see in your environment, TPC-C scores do give you an idea of the platform's high-end scalability. The recent TPC-C scores should put to rest any questions about SQL Server scalability. Can you wait to see the numbers that the upcoming 64-bit implementation of SQL Server will hit?