A solid ETL tool. Data doesn't stay in one place, SSIS keeps it going where it needs to go.
April 06, 2018
A solid ETL tool. Data doesn't stay in one place, SSIS keeps it going where it needs to go.
Score 10 out of 10
Vetted Review
Verified User
Overall Satisfaction with SQL Server Integration Services
Like most businesses, we have various sources of data that management likes to be able to compare to each other. I use SSIS primarily to move data between our source systems and data marts and warehouses that our reporting software can be pointed at. I also use SSIS to deliver scheduled file exports to external customers or to import files into one of our critical systems for use. I even tend to use it for non-SQL related things such as file system and ftp tasks. If it needs to be extracted, transformed, or loaded somewhere, I use SSIS to do it.
- There are many good workflow tools and ways to control the order in which things happen. In a short amount of time, you can quickly create a package that will move data from point A to point B and have it scheduled to run 4 times a day. Or if you need error handling or other business logic, you can spend more time and completely automate repetitive tasks. Robust? Check!
- SSIS can consume multiple sources of data. From flat files, to Excel, to Oracle, or DB2...I've been able to access multiple data types and move them in and out of SQL databases with SSIS. We had one linux system that ran a Basis database system and there was a need to have something done, but no one could figure out how to make it work. I was able to use SSIS to import files and execute code on a server that had nothing to do with SQL server. So flexible? Check!
- We already use SQL server almost exclusively for our enterprise database needs. The fact that we already have access to this tool at no additional cost to the business is a bonus. The fact that it is powerful, even better. Value? Check!
- I know in my "pros" comments, I said it was nice because we already had access to SSIS by virtue of being able to install it on existing SQL servers with no additional license cost. But, if you rely heavily on SSIS, you will want to have it on its own server rather than letting it share resources with a very active SQL server. That means additional licenses. It can consume a lot of resources, depending on the amount of data you're pushing through SSIS at any given time.
- Current versions of SSIS do a much better job of managing deployment of packages into production. It used to be an all-or-nothing proposition so if you had to make a small change to a project that had many packages in it, you'd have to redeploy the entire project which means lots of extra testing. The introduction of package level deployment was welcome.
- SQL server and SSIS play very well together when they have enough resources. If you're using virtual servers and can add CPU/RAM/Space easily, then by all means, put them together and manage the resources so they stay out of each other's way. If you don't have the capability to do that, then you'd be better off having SSIS on a separate server. When everything is working well, it is amazing. But if you make SSIS and SQL fight over resources, it's not pretty (SQL wins that fight by the way in case you were wondering!)
- If I'm being honest, I haven't had to point SSIS to a huge variety of source systems. It could be that SSIS doesn't play well with certain DBMS' (I've heard Sybase compatibility complaints before) and you'll need to do some research and testing before actually using it in production.
- I use SSIS to automate tasks that I'm repeatedly asked to do. "Hey, can you go into the system and close any open orders that we've fully filled?" Sure....then I schedule a package to do that for me every hour so I'm never asked again. It saves me time, which gives value to the company.
- It removes the risk of human error. When people build files and send them, there's the risk that it doesn't happen the same way every time or gets forgotten. With SSIS, you spend some up front time building a process, but then you deploy it and forget it (unless it emails you that there was an error. You are putting error handling in your ETL, right?). Very repeatable and consistent business solution.