There is a new transform component available for SQL Server Integration Services.  It’s called the Balanced Data Distributor (BDD) and the download is available here.  The BDD provides an easy way to amp up your usage of multi-processor and multi-core servers by introducing parallelism in the data flow of an SSIS package.

Functionality of the BDD

The functionality of the BDD is very simple:  It takes its input data and routes it in equal proportions to its outputs, however many there are.  If you have four outputs, roughly ¼ of the input rows will go to each output.  Instead of routing individual rows, the BDD operates on buffers of data, so it’s very efficient.

Some of you will already be noticing that there is no transformational value in the BDD, and no control over which data rows go to which output.  You may be wondering, what the heck is the value of that?

The value of the BDD comes from the way modern servers work:  Parallelism.  When there are independent segments of an SSIS data flow, SSIS can distribute the work over multiple threads.  BDD provides an easy way to create independent segments. 

This diagram gives a trivial example:

If you run this data flow on a laptop, there probably won’t be any speed advantage, and there may even be a speed cost.  But suppose you run this on a server with multiple cores and many disk spindles supporting the destination database.  Then there might be a substantial speed advantage to using this data flow.

When to use the BDD

Using the BDD requires an understanding of the hardware you will be running on, the performance of your data flow and the nature of the data involved.   Therefore it won’t be for everyone, but for those who are willing to think through these things there can be significant benefits.  Here is my summary description of when to use BDD: 

1. There is a large amount of data coming in.
2. The data can be read faster than the rest of the data flow can process it, either because there is significant transformation work to do or because the destination is the bottleneck.  If the destination is the bottleneck, it must be parallelizable.
3. There is no ordering dependency in the data rows.  For example if the data needs to stay sorted, don’t go and split it up using BDD.


Relieving bottlenecks in the SSIS Data Flow

Let’s talk about bottlenecks, since changing bottlenecks is what BDD is all about.  A bottleneck is whatever limits the performance of the system.  In general there are three places that could be the bottleneck in an SSIS data flow:  The source, the transformations, or the destination.

Bottlenecks in the Source

If the limiting factor is the rate at which data can be read from the source, then the BDD is not going to help.  It would be better to look for ways to parallelize right from the source.

Bottlenecks in the Transformations

If the limiting factor is the transformation work being done in the data flow, BDD can help.  Imagine that there are some lookups, derived columns, fuzzy lookups and so on:  These could easily be the components limiting performance.  Make two or four or eight copies of the transformations, and split the data over them using the BDD.  Let the processing run in parallel.  If there are several transformations in the data flow, put as much as you can after the BDD, to get more things running in parallel.

Bottlenecks in the Destination

If the limiting factor is the destination, BDD might be able to help - you need to determine whether the destination can be run in parallel.  You might be surprised at some times when it can.  One example is when loading data into a simple heap (table with no indexes) in SQL Server.  With the database properly distributed over a number of disks, it is quite possible to load in parallel with good performance.  When working on the ETL World Record a while ago, we used a heap for a side experiment and found that loading 56 streams concurrently into a single heap was almost as fast as loading 56 streams into 56 independent tables.  Many sites already drop or disable their indexes during data loading, so this could be more of a freebie than you would expect.  More recently we saw a benefit from parallel loading into SQL Server Parallel Data Warehouse (PDW).  PDW is an architecture designed for parallelism!

When the destination does not support parallel loading

A final case to consider is when the limiting factor is the transformation work being done in the data flow but the destination cannot receive data in parallel for some reason.  In this case, consider using BDD to parallelize the transforms followed by a Union All to rejoin the data into a single flow; then a single destination can be used.  Here is an illustration:

Best practice – balanced!

One final note:  Whatever you put behind the BDD, be sure the same work is being done on all paths.  It doesn’t make logical sense to have the paths be different, and from a performance point of view, you want them all to be the same speed.  Remember, the “B” in BDD stands for “Balanced”.

Conclusion

Someday maybe SSIS will be able to do the work of the BDD automatically, but for now you have an easy way to amp up your usage of multi-processor and multi-core servers by introducing parallelism in the data flow of an SSIS package.

Five TPC-E benchmark results on SQL Server 2008 R2 published to date with five hardware partners show how SQL Server is driving scalability to new levels on x64 servers.  The top result more than doubles the top perf on SQL Server 2008. Congratulations to Intel on the performance of the Nehalem-EX processor, which now holds the top two performance positions. (See this video for more on the breakthrough performance of Windows and SQL Server on Nehalem-EX.)

Here are the TPC-E results published on SQL Server 2008 R2 as of 4/20/10. 

Sponsor	System	tpsE	Price/ tpsE	System Availability Date	Server Procs/ Cores/ Threads	CPU Type
	NEC Express5800/ A1080a-E	3,141	768.92 USD	6/24/10	8/64/128	Intel Xeon X7560 2.26GHz
	IBM System x3850 X5	2,022	493.92 USD	7/30/10	4/32/64	Intel Xeon X7560 2.26GHz
	Unisys ES7000 Model 7600R Enterprise Server (16s)	2,012	958.23 USD	5/6/10	16/96/96	Intel Hex-core Xeon X7460 2.66GHz
	Dell PowerEdge R910	1,933	328.58 USD	5/6/10	4/32/64	Intel Xeon-Quad Core x7560 2.27GHz
	HP ProLiant DL385G7	887	296.00 USD	5/6/10	2/24/24	AMD Opteron(tm) 6176 SE 2.3GHz

You can find out more about R2 at www.sqlserverlaunch.com.

- Charles Levine

The TPC-E publication was 2,012 tpsE with a price performance of $958.23 USD/tpsE.  The configuration will be available by May, 6, 2010.  The TPC-H publication was 102,778 QphH@3000GB with a price performance of $21.05 USD/QphH@3000GB.  This configuration will also be available by May 6, 2010. 

You can see all the details for these outstanding results on the TPC web site at the following links:

Unisys ES7000 7600R Enterprise Server – TPC-E

Unisys ES7000 7600R Enterprise Server – TPC-H

* – SQL Server 2008 R2 will be generally available by May 6, 2010.

** – Windows Server 2008 R2 is generally available now.

- Jamie

Our partners at Dell and HP have published 2 new TPC-H results with SQL Server 2008 using Fusion-io’s ioDrive solid-state technology.  These are the first TPC results using solid-state technology and they illustrate the high performance along with total cost-of-ownership savings you can achieve.  These results dramatically improved the price/performance for systems using industry standard components.  These results prove that solid-state technologies can be used to reduce costs without giving up high levels of performance.

HP also published a 300GB result on their ProLiant DL785 platform with SQL Server 2008.  This publication illustrates the high performance and solid price/performance using industry standard components from HP and Microsoft.   

Please follow the links for all the details on each benchmark result.

- Jamie

Before getting in to my findings, let me give a little anecdote heard from a colleague: There is at least one SSIS customer that now uses SSIS and the Attunity connectors to move data from an Oracle database to an Oracle database, because SSIS with Attunity outperforms any of the Oracle options! While I can’t corroborate that, the information to follow is from my own measurements.

To do this work, I used two machines each with 24 cores (64-bit, 2.4 GHz), one for SSIS and one for Oracle. The machines were practically an embarrassment of riches for this simple benchmark. The SSIS machine had flat files to read (when loading data into Oracle) or write (when extracting data from Oracle). The SSIS packages were super simple, just a flat file source and an Oracle destination, or an Oracle source and a flat file destination. The data was 75 million rows, 133 bytes per row, of the LINEITEM table from the TPC-H benchmark, as generated by the DBGEN utility.

Some basic findings (remember, you mileage will vary):

• Putting data into an Oracle database using the Attunity connectors clocked 30,000 rows per second, on the order of 20 times faster than using the OLE DB connectors to Oracle.
• Extracting data from Oracle moved 36,000 rows per second, about 20% faster than using the OLE DB connectors.
• The above measurements were taken using “mixed” data types: Numbers were put in NUMBER fields, dates were put in DATE fields, etc. A funny thing happened though when all the data was put in string fields (VARCHAR2 use used for everything). Now we could hit 42,000 rows per second loading data into Oracle, and 76,000 rows per second extracting from Oracle!
• The Fast Load option is supposed get higher performance through the use of the DirectPath API. In my experiments, I didn’t see a consistent advantage of Fast Load over non-Fast Load. The thing that Fast Load did seem to do was shift more of the CPU time from the Oracle process to the SSIS process. This could mean that if you have multiple concurrent SSIS packages sending data to Oracle, using Fast Load might let Oracle receive the data faster. Given my experience with Fast Load, I can only recommend that you check its performance in your own situation. Note: I’ve been told that Fast Load will be fixed in a maintenance release later this calendar year. So while I’m not promising anything, it’s likely that this will change.
• The default batch size for the Oracle destination connector is 100 rows. Setting the batch size to 10,000 rows gave a boost of 10% to 50%, depending on other elements of the configuration. (When using Fast Load, you specify the buffer size instead of the row count. So estimate the buffer size needed to hold the number of rows you want, and use that number.)
• When using the Oracle source, setting batch size to 10,000 rows gave a boost of around 10%, depending on other elements of the configuration.
• I wanted to know how important it was for SSIS to be on a separate machine from the Oracle database. There was a good network connecting the source and destination servers, and also plenty of CPUs and memory on the servers. What I saw was a negligible difference between the case where SSIS and Oracle were on the same server and the case where SSIS and Oracle were on separate systems. My recommendation: Look at what resource is the most loaded in your environment, and configure to lighten the load on that resource.

The idea that performance with string data would be so different from performance with natural data types was a big surprise. The difference was especially pronounced when extracting data from Oracle. Now let’s face it, we would prefer to see data extracted from Oracle and placed in SQL Server databases! Given the big speed disparity and the fact that most real-world data needs to be in natural data types, I wondered if the same thing would happen if data was cast to string types in the query that SSIS issues against Oracle. So instead of having SSIS simply read the table, I gave it this query to run:

select
    TO_CHAR(L_SHIPDATE),
    TO_CHAR(L_ORDERKEY),
    TO_CHAR(L_DISCOUNT),
    TO_CHAR(L_EXTENDEDPRICE),
    TO_CHAR(L_SUPPKEY),
    TO_CHAR(L_QUANTITY),
    L_RETURNFLAG,
    TO_CHAR(L_PARTKEY),
    L_LINESTATUS,
    TO_CHAR(L_TAX),
    TO_CHAR(L_COMMITDATE),
    TO_CHAR(L_RECEIPTDATE),
    L_SHIPMODE,
    TO_CHAR(L_LINENUMBER),
    L_SHIPINSTRUCT,
    L_COMMENT
from ATTUSER.LINEITEM

Then before inserting the data into SQL Server using the SQL Server destination, I put in a data conversion task to get all the data into the correct types.

At this point you must be thinking, “Surely converting the data twice can’t be the fastest way!” Well, here are the results: The first run below read the mixed data types using the Attunity Oracle source with default settings, converted to SQL Server types, then wrote to the SQL Server destination. The second run was like the first, with the addition of setting the batch size larger. The third run was like the first, but on reading from Oracle all the columns were converted to text as discussed above. The last test was like the third, with the addition of setting the batch size larger. Using the string conversion and larger batches, the run was over two times faster than the obvious out-of-the-box configuration.

Overall, the Attunity connectors for Oracle really were fast, as expected. In doing this work a few lessons turned up that hopefully help you get optimal performance.

- Len Wyatt

Pat Gelsinger did a side-by-side performance demo which launched an SSRS report, running reporting queries against a 1.5 TB SSAS OLAP cube, built using a Microsoft adCenter data set. The demo showed how Nehalem-EP is 2X faster than a Xeon 5400 on the same workload, with the same DRAM and I/O configuration. Not too shabby, but we've seen even faster results (~3-4X faster) on workloads which are more memory bandwidth-intensive, like data warehousing or in-memory OLAP workloads.

Also yesterday, our good friends at Fujitsu, Dell, and IBM, used SQL Server 2008 to show off the performance of Intel's new processor, in their latest 2P server platforms, by delivering great new TPC-E results which have break-through per-processor performance and price/performance. Please follow the links for the full scoop on each benchmark result. Congratulations to each!

-David

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

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

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

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