|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Monday, May 13, 2013 2:53 PM
Points: 375,
Visits: 947
|
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: 2 days ago @ 1:56 PM
Points: 6,997,
Visits: 13,941
|
|
Nice in-depth article.
Just curious - do you have any metrics as to how efficient this is? DTS has gotten a black eye in the past as to being less performant than more streamlined tools like bcp or bulk insert, and SSIS seems to be getting hit with it just by being its replacement. The process you're describing seems to be very efficient process-wise; I just don't have anything that big to load up these days to get an idea of how well this behaves?
Never mind for now the ease of setting this up - I can see how much faster it would be to set one of these up than the "manual way"...
---------------------------------------------------------------------------------- Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Monday, May 13, 2013 2:53 PM
Points: 375,
Visits: 947
|
|
Thanks Matt!
I don't use DTS (or competing products) enough these days to speak about how SSIS performs when compared to them. I can tell you:
1. In general SSIS is way faster than DTS. In tests I did with the Beta versions of SSIS I saw a typical 20% - 40% performance boost. When coupled with an upgrade from SQL Server 200 to 2005, I saw those numbers increase even more. SSIS gives you more and different options for piping data through the enterprise so it is possible to achieve much better performance. 2. Staging updates makes a measurable impact in incremental loads compared to using the OLE DB Command.
:{> Andy
Andy Leonard CSO, Linchpin People Follow me on Twitter: @AndyLeonard
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: 2 days ago @ 1:56 PM
Points: 6,997,
Visits: 13,941
|
|
Cool! I will have to see if I can run the next "big one" I get this way to get a feel, but it sounds like performance has definitely been improved.
Thanks!
---------------------------------------------------------------------------------- Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Tuesday, April 16, 2013 2:22 AM
Points: 1,
Visits: 32
|
|
Hi Andy, one case is missing in your article: deleted rows (rows in the database but no longer in the input data). And just another question: do you really think that comparing the whole data between two tables is faster then truncating a table and reloading it complete (if you have a time windows for doing this, of course)? Until now, I have such a time window but after reading your article I think about loading data by your way, because it is the best way to have all data 24x7 online. Thanks a lot.
Rainer kroos
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Wednesday, April 10, 2013 7:29 AM
Points: 51,
Visits: 236
|
|
just a wee thought on this article. Surely what you are talking us through here is the same as is accomplished by the Slowly changing dimension 'box' . Which automagically creates all the tsql to do the updates,additions and deletions. With support for keeping a history of changes.
It's quite a mad one but a bit of reading up on slowly changing dimensions really helps! :)
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Friday, March 08, 2013 10:18 AM
Points: 47,
Visits: 165
|
|
Good introduction to SSIS! One thing you wrote surprised me: that using a select statement would be faster than using a view. I don't understand why this is the case.
Since you promised that this would be the first of a collection of articles on SSIS, I would like you to address a situation in which either the input or the output is not SQL Server. For my own purposes, I would like a demonstration of how to handle output to another database such as DB2 or MySQL.
Thanks for a nice article.
Arthur
Arthur Fuller cell: 647-710-1314
Only two businesses refer to their clients as users: drug-dealing and software development. -- Arthur Fuller
|
|
|
|
|
Old Hand
      
Group: General Forum Members
Last Login: Monday, May 13, 2013 2:53 PM
Points: 375,
Visits: 947
|
|
Great comments!
Rainer: Deleted rows can be correlated with a Right Join instead of a Left Join, and Filtered the same as New Rows. For the Delete action I stage the rows (much like the Updates) and run a set-based query after the Data Flow. I do believe loading incrementally is faster than than truncating and reloading in any database that is scaling, or is of sufficient size and experiencing a certain threshold of changes (this is my way of quoting Andy Warren: "It Depends" ;)).
Surely what you are talking us through here is the same as is accomplished by the Slowly changing dimension 'box' .
Yussuf: Yep - it's a lot of the same stuff accomplished with the SCD transformation (optimized some). Unless you're familiar with the concepts of ETL for Kimball-based databases, the SCD Wizard can be a bit intimidating. You essentially work through the same thought process you would work through here, but it looks different to the first-time developer. I would say the converse is more accurate: "the SCD is a very cool wrapper for incremental loads."
...using a select statement would be faster than using a view.
Arthur: Gosh I hope I didn't say that. If I did, forgive me. I argue against selecting a Table or View by name from the dropdown in the same way I argue against writing T-SQL with "Select *..." at the beginning. Extra lookups take place for column names and the like when you execute "Select *". The same applies in SSIS which is, after all, executing SQL against the database.
:{> Andy
Andy Leonard CSO, Linchpin People Follow me on Twitter: @AndyLeonard
|
|
|
|
|
SSCarpal Tunnel
       
Group: General Forum Members
Last Login: 2 days ago @ 2:51 PM
Points: 4,003,
Visits: 1,485
|
|
yussuf.khan (2/11/2008) just a wee thought on this article. Surely what you are talking us through here is the same as is accomplished by the Slowly changing dimension 'box' . Which automagically creates all the tsql to do the updates,additions and deletions. With support for keeping a history of changes.
It's quite a mad one but a bit of reading up on slowly changing dimensions really helps! :)
In my experience the SCD is not very efficient once you get above a thousand rows or so. As the name implies, the SCD is targeted at tables that do not change often, and dimension tables are typically on the small side. It works great and I've used it, but in the right situations. Andy's approach probably scales a lot better.
Nice article Andy!
|
|
|
|
|
SSChampion
        
Group: General Forum Members
Last Login: 2 days ago @ 12:22 PM
Points: 10,571,
Visits: 11,871
|
|
|
|
|