SQL Server Performance : SQL Server Performance

An ETL World Record Revealed (Finally)

Data & SQL Storage Performance Team — Wed, 04 Mar 2009 02:38:00 GMT

We suppose a more appropriate title would have been: Better Late Than Never.

David should begin by apologizing. Last month was the first anniversary of the ETL world record we set last year with SSIS, loading 1 TB of data in under 30 minutes. While Len did a nice blog post on the project at the time, we had promised to return to our favorite ETL practitioners (that's you) with more details, pulling back the curtain on Oz so to speak.

It only took a mere year to get around to that, and a lot of water has gone under the bridge since then. Happily, the paper's now done and published to the web for your reading pleasure. Whew!

-David Powell, Len Wyatt & Tim Shea

Windows Server 2008 + SQL Server 2008 = Geo-replication Benefits

Data & SQL Storage Performance Team — Tue, 25 Nov 2008 05:04:00 GMT

After running an experiment, using datacenters on each coast of the U.S., our friends in MSCOM ops verified that the combination of Windows Server 2008 and SQL Server 2008 are great for enabling database geo-replication, thanks to a 100X gain in performance. The experiment provided sufficient evidence to motivate a more ambitious proof-of-concept case study with MSDN.

A new whitepaper, published this week, explains how SQL Server 2008 was able to take advantage of the all-new core networking stack in Windows Server 2008 to deliver revolutionary gains in replication performance across wide-area networks. The paper includes information on an MSDN case study, in which MSCOM ops significantly lowered MSDN page load times, thanks to replication of MSDN content from the U.S. to Europe.

-David

SQL Server is Movin' On Up!

Data & SQL Storage Performance Team — Mon, 10 Nov 2008 21:34:00 GMT

At last week's WinHEC in Los Angeles, SQL GM Quentin Clark joined Windows Server VP Bill Laing on stage, to announce our upcoming support for more than 64 logical processors, the current limit in Windows and SQL Server. This expanded scale-up capability is planned to be released in SQL Server code named "Kilimanjaro", when running on top of Windows Server 2008 R2.

We expect to support up to 256 logical processors in this release, though that's a soft limit. The hard limits are much higher than this, but we won't support what we can't test. You'll likely see this 256LP soft ceiling get higher in each release, now that we've finally done the heavy lifting of raising the roof on Windows and SQL Server.

The keynote demo (@33:26), which Bill and Quentin did together, went well. Many thanks to our friends at HP and IBM for all their support and for the use of these great servers.

In case you're wondering, a logical processor is a sub-unit of a physical processor/socket/package. Typically today an LP means a core, but it can also mean a hardware thread (nee hyper-threading).

-David Powell

TPC-E – Raising the Bar in OLTP Performance

Data & SQL Storage Performance Team — Fri, 24 Oct 2008 02:46:00 GMT

Glenn Paulley, Director of Engineering at Sybase iAnywhere, posted a commentary titled “The State of TPC-E” on his blog three weeks ago (10/3/08). A better title would have been “All TPC-E Results Are On Microsoft SQL Server. Why?” Mr. Paulley takes issue with Brian Moran’s statement that “the most rational answer is that Oracle and IBM have tried to top Microsoft’s numbers and simply can’t”. He says that while it may be true, he doubts it and says there are other plausible reasons why DB2 and Oracle have yet to publish any TPC-E results. Curiously, he doesn’t say why Sybase hasn’t published TPC-E results. Since he is, presumably, in a position to know, one can only conclude that he would rather not say. Readers can reach their own conclusions about what that might mean.

To his credit, he cites this IBM whitepaper for explaining that TPC-E was designed to be more realistic than TPC-C. There are numerous ways, detailed in the whitepaper, in which TPC-E is far superior to TPC-C. Let’s compare TPC-E to TPC-C. As the table below shows, in TPC-E the schema is substantially richer and more complex, there are twice as many transactions, and only TPC-E requires essential capabilities such as referential integrity and RAID protected storage.

	TPC-C	TPC-E
Schema
Number of database tables	9	33
Foreign keys	9	50
Tables with foreign keys	7	27
Check constraints	0	22
Partitioning Characteristic	unrealistic; single dimension common to 8 of 9 tables	realistic; two independent dimensions
Transactions
Number of transactions	5	10
Database roundtrips per transaction	1	min 1; max 5
Capabilities
Referential Integrity Required	No	Yes
Storage Protection (e.g. RAID) for Database Required	Log Only	Everything
Timed Database Recovery test	No	Yes

Mr. Paulley chooses to focus on the query complexity of TPC-E. While that’s somewhat interesting, a comparison to TPC-C would have provided important context. For example, TPC-E has 156 DML statements. Although TPC-C doesn’t include pseudo-SQL the way that TPC-E does, if it did and followed the TPC-E style, it would be fewer than 30 DML statements. By this measure, TPC-E has more than five times as many distinct DML operations as TPC-C.

But more importantly, TPC-E is not and was never intended to be a query optimizer test. The pseudo-SQL code in TPC-E is an example, not a requirement. Unlike TPC-H which strictly limits changing the specified SQL, in TPC-E test sponsors are free to rewrite the SQL anyway they like as long as it is functionally equivalent. One vendor might rewrite it to remove all joins while another might rewrite it to include more joins or more complex joins. The same is true of group by and order by clauses. In our view, Mr. Paulley’s objection that TPC-E isn’t a good optimizer test is misplaced.

After discussing query complexity, Mr. Paulley offers four reasons why Microsoft is the only database vendor publishing TPC-E results.

· “TPC-E is a moving target” – While it’s true that the TPC-E spec is up to version 1.6.0, the assertion that the workload has changed significantly is unsupported by the facts. None of the transactions has changed in any way that impacts performance. All spec revisions have been classified as “minor” changes by the TPC and results across all spec revisions are comparable. The number of revisions to the spec since it was first released actually reflects a deep commitment by the members of the TPC-E committee to clean up rough edges and address areas of ambiguity before they become issues in published results. A better gauge of the high quality of the TPC-E spec is that to-date 18 results have been published by six vendors spanning 15 months, but there have been no compliance challenges.

· “Both DBMS vendors and hardware suppliers have a substantial investment in TPC-C expertise.” On this point we agree with Mr. Paulley. But we draw different conclusions. All of the major DBMS companies have spent years picking through every detail of TPC-C. It has been optimized to such a degree that it long ago stopped driving customer-relevant engineering improvements. TPC-C is 16 years old and has changed little since 1992. Saying that we should continue using TPC-C because we know it so well is like saying that we should drive horse and buggies because we have a lot of expertise in blacksmithing. This is a mindset trapped in the past and doesn’t serve our customers.

· “TPC-E isn’t that cheap.” In fact, TPC-E is substantially less expensive to configure and run than TPC-C. Two results from IBM within the last month prove the point. As you can see in the table below, running on the same server, the TPC-C configuration was more than five times more expensive than the TPC-E configuration. Further, on the four proc server, the TPC-C result had 1361 disks with no data protection, while the TPC-E result had 400 disks with RAID-5. Which is the more customer-relevant configuration?

	TPC-C	TPC-E
Hardware	IBM System x3850 M2	IBM System x3850 M2
Procs / Cores / Threads	4 / 24 / 24	4 / 24 / 24
Performance	684,508 tpmC	729 tpsE
Price/perf	2.58 $/tpmC	457 $/tpsE
Total System Cost	$ 1,763,438	$ 333,646
Publication Date	9/15/08	9/15/08
Availability Date	10/31/08	10/10/08
Memory	256 GB	128 GB
Storage	1,344 x 73.4GB disks 16 x 500GB disks 1 x 73GB	400 x 73.4GB disks
Data Storage Protection	None	RAID-5
TPC Result Details	Link	Link

· “Customers continue to desire and reference TPC-C results.” Granted, TPC-C has stood the test of time. But today it is outdated, over-optimized, and of questionable relevance. Customers hold onto TPC-C because it is familiar and available, not because it is better. Database vendors need to exercise leadership. As Mr. Paulley says “Microsoft is an early adopter of TPC-E”. At this point, though, the early adopter window has passed. TPC-E was ratified 20 months ago. The first result was published 15 months ago. There are 18 published results. We believe that customers will readily embrace TPC-E as a superior benchmark as more results become available.

The more time that goes by, the more one is inclined to believe that Brian Moran is right – other database vendors aren’t publishing because they can’t beat the existing SQL Server results. We invite Sybase and Mr. Paulley to prove us wrong. We are confident that once Sybase runs TPC-E instead of just writing about it, Mr. Paulley will gain a new appreciation for just how challenging and technically rigorous TPC-E is compared with TPC-C.

Charles Levine

SQL Server Performance Engineering

SQL Server 2008 is on its way with great performance

Data & SQL Storage Performance Team — Wed, 06 Aug 2008 20:01:00 GMT

Just left the final shiproom meeting for SQL Server 2008, and am happy to say every team has signed off, so the product is now in the hands of manufacturing, and in process toward web and media availability for you. We've shipped! MSDN and TechNet subscriber downloads are now live, with more to come.

It's been less than three years since SQL Server 2005, but we're pleased to give you a great new release of SQL Server which not only adds fantastic new capabilities to your data platform, but also delivers broadly better performance. We used new industry standard benchmark workloads, and customer workloads, to drive us toward delivering better real-world performance...and we didn't take the easy road.

The best example of that is our use of TPC-E, a far more modern, realistic, and challenging benchmark workload than its predecessor. We used TPC-E to improve the scalability of our relational engine, in ways that should be more relevant to your own OLTP database workloads. We're proud of partners, like IBM, NEC, and Unisys, who were able to demonstrate great scalability, up to 64 cores, using SQL Server 2008 running TPC-E, and like Fujitsu-Siemens and Dell, who have shown industry leading price/performance. Results like these should also be more useful for system sizing.

Almost five years of effort by TPC members were invested in the development of TPC-E, and it shows. The workload uses synthetic data which is far more realistic, by modeling real-world data. And compared to its antique predecessor, TPC-E's schema has ~3X more tables and primary keys, 2X as many columns, and 4X more foreign keys. And here's a radical thought for a modern OLTP benchmark workload: include check constraints, referential integrity, and reliable storage. Don't customers actually put DBMS servers into production expecting that?

Because we believe so strongly TPC-E drives us to better meet your needs, I am announcing today this is the first release of SQL Server which will not include published TPC-C benchmark results. Like other great thoroughbreds, TPC-C had a great run, and we were proud to ride it while it was still relevant to customers. But today, we're turning that great old race horse out to pasture for a well-deserved rest.

In SQL Server 2008, we have also invested lots of effort to improve our data warehousing performance, and the performance of our BI services. SSIS, SSRS, and SSAS, each show many double-digit gains in performance, which we hope you will enjoy. The new world record we set with SSIS, loading 1 TB of data in under 30 minutes, gives you a sense of this commitment to BI performance. We are also proud of our first-ever TPC-H 10 TB result.

There are a couple other ways in which this release improves on our past work. First, we've focused more energy on improving 64-bit SQL Server's performance on x64 AMD Opteron and Intel Xeon architectures. Given the price and density of RAM, and great new x64 CPUs available, this is a perfect time to take a closer look at the performance of your database servers, and consider doing fresh deployments, or migrations, on x64 SQL Server, which can use the additional RAM for everything, not just the buffer cache. Second, we invested more heavily in performance regression testing, both in automation and in the breadth of our test coverage. These investments have been reflected in broadly positive feedback from the community as well as internal and external beta sites. While we'll always have more to do, we feel this release marks an important step forward.

Welcome to the beginning of a new era for SQL Server. We hope you enjoy working with SQL Server 2008 and look forward to your feedback.

-David Powell
SQL Performance Engineering

ETL World Record!

Data & SQL Storage Performance Team — Wed, 27 Feb 2008 22:36:00 GMT

Today at the launch of SQL Server 2008, you may have seen the references to world-record performance doing a load of data using SSIS. Microsoft and Unisys announced a record for loading data into a relational database using an Extract, Transform and Load (ETL) tool. Over 1 TB of TPC-H data was loaded in under 30 minutes. I wanted to provide some background material in the form of a Q&A on the record, since it’s hard to give many details in the context of a launch event. We are also planning a paper that talks about all this, so think of this article as a place-holder until the full paper comes along. I hope you find this background information useful.

- Len Wyatt

How fast was the data load?

More than one terabyte of data was parsed from flat files, transferred over the network and loaded into the destination database in less than 30 minutes, a world record beating all previously published results using an ETL tool. That is a rate in excess of 2 TB per hour (650+ MB/second). To be precise, 1.18TB of flat file data was loaded in 1794 seconds. This is equivalent to 1.00TB in 25 minutes 20 seconds or 2.36TB per hour.

Why is this important?

Businesses have ever-increasing volumes of data stored in many heterogeneous systems. Thay want to know that an ETL tool they choose will be able to support any data volumes they might require. Microsoft has been making a significant investment in SQL Server Integration Services (SSIS), and this record illustrates the capability of SQL Server Integration Services 2008, SQL Server 2008 and the Unisys ES7000 to handle a significant volume of data at a dramatic speed.

Why not just do a bulk load of the data?

It is rare in businesses today that data is always available on the destination system, and does not need to be standardized or corrected for errors before loading. These rare cases are the times that bulk loading data makes sense. Data integration can involve complex transformation rules, error checking and data standardization techniques. ETL tools like SSIS can perform these functions such as moving data between systems, reformatting data, integrity checking, key lookups, tracking lineage, and more. SSIS has proven itself to be a versatile ETL tool, and now it is shown to be the fastest one as well.

What data did you choose to load?

DBGEN tool from the TPC-H benchmark was used to generate 1.18 TB of source data. The data were partitioned by DBGEN, allowing it to be loaded in parallel from multiple systems. DBGEN generates data on customers, parts, suppliers, orders and line items. It is broadly representative of a wholesale business. The data contain a variety of data types, including dates, money amounts, integers, strings and flags.

Please note that the ETL loading results are not TPC-H benchmark results and should not be compared to TPC-H benchmark results.

Was this a certified benchmark?

There is no commonly accepted benchmark for ETL tools. Microsoft thinks there should be. Industry standard benchmarks can lead to healthy competition, better products, and better publication of the techniques used to get high performance. Microsoft would welcome the opportunity to join with others in the industry to define a common benchmark that reflects the real-world uses of ETL tools.

The use of TPC-H data for this project was a convenience. This is not a TPC-H benchmark result.

How does this compare to your competitors?

Multiple competitors have published results based on TPC-H data. Informatica has the fastest time previously reported, loading 1 TB in over 45 minutes. SSIS has now beaten that time by more than 15 minutes.

There are other claims of fast times that have been made, but on non-standard data sets and without enough information to allow any meaningful comparison. This is part of the reason Microsoft would support the creation of an industry standard ETL benchmark.

What system configuration was used?

The database server ran on a Unisys ES7000/one Enterprise Server , with 32 socket dual core Intel® Xeon^TM 3.4 Ghz (7140M) processors , 256 GB RAM and 8 dual port 4Gbit HBA’s . The SQL Server data was stored on an EMC Clariion CX3-80 SAN with 165 (146 GB/15 krpm) spindles. The database server ran a pre-release build of SQL Server 2008 Enterprise Edition (V10.0.1300.4, built just before the “February 2008 CTP”) on the Windows Server 2008 x64 Datacenter Edition operating system.

Four servers acted as data sources, modeling the fact that data comes from a variety of systems in a modern enterprise. Each source server ran SSIS packages that sent data across the network to the database server. The source servers ran SSIS from SQL Server build V10.0.1300.4, on the Windows Server 2008 operating system. Source data came from flat files, as it was generated by DBGEN.

For the source servers, 4 Unisys ES3220L servers with Windows2008 x64 Enterprise Edition were used. Each server is equipped with 2 x 2.0GHz quad core Intel® processors, 4GB RAM, a dual port 4Gbit Emulex HBA and Intel PRO1000/PT network card. The source data was read from 2 x EMC Clariion CX600 SAN’s with 45 spindles each.

The Source servers were connected to the ES7000/one server database server with private dual port 1Gb Ethernet connections.

Why use multiple source systems?

Modern large businesses are complex operations. Large data sets are often the result of multiple data feeds. This made the test more realistic by mimicking a real world ETL scenario.

What do the SSIS packages look like?

There was just one package, though the source systems ran multiple instances of it. It is quite simple: There is one control flow for each “stream” of data generated by DBGEN. The control flow has one data flow for each table, each data flow reading data from a flat file source and writing to the SQL Server database via OLEDB. Using this data set there is a one-to-one column mapping between the flat file data and the database tables.

Did Windows Server 2008 figure in to this?

A lot of innovative engineering work in Windows Server 2008, including significant improvements in memory management, PCI and block storage I/O, and core networking, helped achieve this great performance. Because of these advances, Windows Server 2008 sustained about 960 megabytes per second over the Ethernet network, during processing of one large table.

Were secret internal tricks were needed to make this work?

No secret internal tricks or special builds were needed. Although this project used a pre-release version, it was a regular SQL2008 Enterprise Edition build. No special code in the product was used. Everything we did could be replicated by others.

The main thing done in the relational database was to use “soft NUMA” and port mapping to get a good distribution of work within the system. This is a published technique; you can find articles about it on MSDN. We also set the –x flag on starting SQL Server. This reduces the time SQL Server spends collecting performance statistics at run-time.

In SSIS we made sure the data types used in the SSIS data flows matched the types used in SQL Server, so the data did not need to be converted again after the initial conversion of strings read from flat files. Fast Parse is set on the text file fields where it applied.

The network connections on the server used the built-in Intel PRO/1000 GbE controllers. Released versions of network drivers were used, and Ethernet jumbo frames were configured to better support this bulk streaming scenario. Window Server 2008’s new TCP/IP receive window autotuning was set to “restricted”. The IntPolicy tool was used to ensure the ES7000 server NICs’s interrupts & DPCs occurred on a CPU affinitized to the same NUMA node as the NIC.

A complete list of settings and optimizations will be included in the paper when it is released.

What's swimming in your bufferpool?

Data & SQL Storage Performance Team — Fri, 18 May 2007 20:19:00 GMT

When doing a performance investigation a useful thing to do is look at what data is present in the buffer pool. This can be used to analyze impact of running a query on the state of data pages in buffer pool. By collecting the pre and post picture of buffer pool, you can see the cost of running a query in terms of physical IOs that happened. You may argue that this can be done by looking at statistics IO output; however if you are running a series of queries and want to see a consolidated data and not data about individual queries, this query is a great help.

The contents of the buffer pool can also reveal which pages are accessed most frequently by your applications and often reflect the actual I/O that is happening. How can frequently access pages in memory also cause disk I/O? When lots of different objects are accessed overtime the proportion of data in the buffer pool reflects the frequency of access. This happens because data pages of infrequently accessed objects get kicked out of main memory over time.

If you are not familiar with the buffer pool, it contains several types of objects such as data pages and plans. For more information on the buffer pool see Buffer Management http://msdn2.microsoft.com/en-us/library/aa337525.aspx

The following query can be used to look at the contents of the buffer pool -

select

count(*)as cached_pages_count,

obj.name as objectname,

ind.name as indexname,

obj.index_id as indexid

from sys.dm_os_buffer_descriptors as bd

inner join

(

select object_id as objectid,

object_name(object_id) as name,

index_id,allocation_unit_id

from sys.allocation_units as au

inner join sys.partitions as p

on au.container_id = p.hobt_id

and (au.type = 1 or au.type = 3)

union all

select object_id as objectid,

object_name(object_id) as name,

index_id,allocation_unit_id

from sys.allocation_units as au

inner join sys.partitions as p

on au.container_id = p.partition_id

and au.type = 2

) as obj

on bd.allocation_unit_id = obj.allocation_unit_id

left outer join sys.indexes ind

on obj.objectid = ind.object_id

and obj.index_id = ind.index_id

where bd.database_id = db_id()

and bd.page_type in ('data_page', 'index_page')

group by obj.name, ind.name, obj.index_id

order by cached_pages_count desc

An example of what it returns –

1. Run following command to remove all clean data pages from the buffer pool – (DO NOT TRY THIS COMMAND ON PRODUCTION MACHINES)

DBCC DROPCLEANBUFFERS

Running buffer pool analysis query had following results –

cached_pages_count ObjectName IndexName IndexId

------------------ ------------------ ---------------------- -----------

15 sysobjvalues clst 1

3 sysallocunits clust 1

2 syshobtcolumns clust 1

2 sysrowsetcolumns clust 1

2 sysrowsets clust 1

2 sysschobjs clst 1

…

2. Run the following query on AdventureWorks database –

select * from Person.Address

where city like 'Bothell'

This is going to read from disk the data pages needed to execute the query. Run the buffer pool analysis query again to see the change.

cached_pages_count ObjectName IndexName IndexId

------------------ ------------------ ---------------------- -----------

278 Address PK_Address_AddressID 1

15 sysobjvalues clst 1

4 sysmultiobjrefs clst 1

3 sysallocunits clust 1

2 syshobtcolumns clust 1

2 sysrowsetcolumns clust 1

…

As you can see now there are data pages in buffer pool from the Address table. Additionally since only clustered index pages for Address table are present, no other indexes were used in the query.

Another tool which can help in this case is DBCC MEMORYSTATUS output. The advantage of the query in the entry is nice result set which can be stored in a temp table.

Authors:

Tony Voellm

Gaurav Bindlish

Two handy papers on common database performance considerations

Data & SQL Storage Performance Team — Fri, 23 Mar 2007 19:51:00 GMT

Len posted recently the link to the new Analysis Services performance guide. If you also care about SQL Server engine performance, these two papers are worth a quick read:

Troubleshooting Performance Problems in SQL Server 2005, which takes you through steps for identifying and resolving typical database performance problems.
Physical Database Storage Design, explores considerations that should be weighed when mapping logical database designs to available physical storage. Drive capacity continues to grow by leaps and bounds but I/O channel rates and disk latency have grown much more slowly, so this is a topic that's not likely to go away for DBAs any time soon.

Enjoy!

-David

High Volume Update Performance

Data & SQL Storage Performance Team — Fri, 16 Feb 2007 19:39:00 GMT

SQL Server does a great job of optimizing processing across a wide range of runtime scenarios, while also providing a flexible configuration and execution environment. One of the tradeoffs associated with this level of flexibility is that different configurations and implementations, while logically equivalent in terms of results, can yield very different performance.

Recently while performing data conversion on a large database my team encountered a good example of this situation. As part of the conversion we needed to UPDATE several VARCHAR and one DATETIME column(s) on a 500 million row table. Due to the highly variable string lengths in the target VARCHAR columns some page splits where expected, and because all values of the target columns needed to be touched a table scan was unavoidable. As this was a onetime conversion I didn’t initially worry about its performance, and because I was using a new server with 16 CPUs and 128 GB of RAM, I assumed SQL Server would provide good performance, even with an in-place update of this size.

After running for 24 hours, I took a look at the performance monitor counters. The process was serialized on a single CPU, and disk bound on the volume containing the target table. Given the time invested I decided to let the update finish, which it did in 2 days, 11 hours.

Discussing the latency with other team members, we speculated that physical disk contention might account for a significant portion of the run time. Because we were changing all the rows in the table we had the option of using INSERT instead of UPDATE to split the read and write I\O to different disks. To set this up we scripted the table and created a work table with the same schema. We also needed to move one physical data file to a separate file group. Of course, following the update, the table also needed to be copied back to the original file group.

At this point we were ready to test the INSERT, which ran in 8 hours, an 86% reduction in run time. Additional execution time can be saved by using SELECT INTO (recovery model was simple), which is minimally- logged. You cannot specify a file group when using SELECT INTO, so to retain the split I\O performance you must set the target file group as the default before running the insert. Also any existing indexes must be rebuilt. Results are summarized in the table below:

Statement Runtime (H:M) % Runtime Reduction

Update 59:11 na

Insert 8:23 86.8

Select Into 5:02 91.5

See the following for more information regarding recovery models and minimally-logged operations:

BOL: ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/8cfea566-8f89-4581-b30d-c53f1f2c79eb.htm

MSDN: http://msdn2.microsoft.com/en-us/library/ms191244.aspx

This exercise provided an example of how certain operations can be non-optimal even with a great database like SQL Server. More importantly, it showed how certain optimizations (in this case for I\O, by allowing all reads from one disk and all writes to another), can result in great performance. If you think about it, this is the same reason we put the log files on a different drive from the data files in a database. The log drives can do simple sequential writes. Thanks to Umachandar Jayachandran and Len Wyatt for contributing to this article.

-- Robin