I need to migrate all the DTS packages created in SQL Server 2000 to SSIS 2012. What are the differences between SQL Server 2000 and SQL Server 2012. Are there any differences in SQL statements like Insert, Update, Delete etc. What are the things I should be aware of to upgrade the DTS packages to SSIS?
You cannot migrate package directly from DTS written in SQL Server 2000 to SSIS in SQL Server 2012. You could do an intermediate conversion from DTS to SSIS 2005 or 2008 and then upgrade them to SSIS 2012 packages, but I would not advise this, as the conversion wizard is not brilliant and you will also loose most of the benefits of SSIS over DTS.
Therefore, I would strongly advise re-writing the packages in SSIS 2012, replicating the functionality of your original DTS packages. I appreciate that depending on the number of packages involved, this may be a big, time consuming task, but it is the best way.
In terms of differences, I have listed a few more notable ones below:
DTS was COM based, and although under the covers SSIS still uses many COM objects, it is wrapped in .NET
SSIS has sequence containers so that objects can be grouped together
SSIS 2008 and 2012 support C# as well as VB.NET
DTS only allowed mapping column names, but SSIS has a rich set of data transformations
ActiveX scripts, if any, in your DTS package have to be thrown away
In SSIS you need to map Unicode and ASCII manually
SSIS supports 64-Bit
There is no difference between SQL Server 2000 and SQL Server 2012 in terms of basic DML, such as INSERT, UPDATE and DELETE, but SQL 2008 onwards also has a MERGE statement which allows UPSERTs. This is not supported properly in SSIS natively, but there are third party UPSERT components, including a free one on CodePlex.com
Amongst the SSIS Data Flow transformations, however, there are components such as a Slowly Changing Dimension (SCD) component and a OLEDB Command component which allows you to update rows. however, both of these transformations poorly performing and there is usually a better way.
Related
I need to store the duration of running SSIS packages until execution into SQL database. How can I calculate it.
If you are using SQL 2012+, you are definitely urged to use SSIS Catalogs (SSISDB). Main reason for that - new extensive package logging execution system. View catalog.executions contains necessary for your task data.
If you are on SQL 2008 or run packages out of SSIS Catalogs - then you have to craft something on your side. You might parse results output of DTExec - it always reports runtime duration.
We are planning to migrate an Oracle 10g database to SQL Server 2008 R2. At the moment nothing is implemented in the target database and this will give us the opportunity to change and improve the existing schema during the migration.
Not only the data, but also stored procedures and views have to be imported.
I already worked with SSIS and I found an excellent product for data manipulation. A colleague mentioned SSMA for the migration. However after some research on the net it seems that it would be suitable mainly for data migration and conversion, while SSIS seems to provide a wider set of functinalities (Tasks, custom scripts, etc).
Which are the pro/contra of the two products and which one would best fit for the task?
I would recommend a hybrid approach. Use SSMA to convert the schema and objects from Oracle to SQL Server. Then improve and or change the objects as you see fit on the SQL end. Once your satisfied with your new schema. Use SSIS to move the data still waiting on the Oracle side into the new schema waiting for it on SQL.
As for a quick comparison of SSMA and SSIS... SSIS is by far superior for the ETL aspects of moving data from one place to another; but I wouldn't necessarily recommend it for the creation/modification phase of what you describe above. I think you'll find that process much easier with SSMA. On the flip side SSMA doesn't offer much in the way of transformation during the copy process.
I would go for an hybrid of the two.
Do you know you can trig SSMA from command line? This way you can execute the SSMA migration as a part of the SSIS solution.
You can also save your SSMA project as an SSIS package:
Once migrated keep doing the extra work with SSIS.
I have been given a task to migrate 2005 packages to 2008, I was looking for discontinued features by SSIS 2008 on http://technet.microsoft.com/en-us/library/bb500429(v=sql.100).aspx
It seems VSA is discontinued and replace by VSTA. As I am doing such work first time I just wanted to check opening packages BIDS 2008 and then deploying them in 2008 enviorment will do or I will need to some other stuff also?
To me, the VSA -> VSTA change you just mentioned simply means that now we can code in C# :D
Overall, to migrate you just need to opne the package on BIDS 2008, but there are a few things you need to take care yourself. What it comes to my mind for example is the behavior of lookup tasks have changed a little (the way no match rows are treated) and the order variables are loaded from config files changed too. I mean, just by running and debugig your pakcages you should be able to test these kind of things
The migration is done very well by just opening the package, even the code change.
A couple gotchas are:
1. If you have ConnectionString in your config, you have to change Provider from SQLNCLI.1 to
Provider=SQLNCLI10.1; (or add the old provider to your new SSIS 2008 production server.
2. I have a case where a space gets in there and gives me an error. I fix in Connection connectionString property by removing the space. It is hard to see in BIDS. Provider= SQLNCLI10.1;
Our team has created a SSIS Package that imports data from an Oracle Source into a SQL Database, the package used Oracle Provicer for OLEDB to client to the Oracle SOR.
The major Data type difference between the Source and the Destiantion Databases is that while the Source has string columns has Unicode the Destination DB supports a non Unicode format.
We added Data conversion components and let the package run, while it works on the Development server (which has oracle 11g components) it does not seem to work on the Test server (Oracle 8 Installed)
Also we tried to add Cast Statements to the Source query, however the external and the output columns do not seem to pick up the Converted format.
Have tried, Dervied Columns, Data Conversions til now
Need Ideas badly
I got the code to work by Setting the ValidateExternal Meta Data Property for the Source Task, also before starting development with SSIS and Oracle ensure you do have the Oracle Provider for .NET ODTwithODAC112030 package installed.
There is a bug in one of the older versions of the oracle components -- to integrate with visual studio correctly (and still run under a 64bit environment post deploy) you need to use the ODAC112040 32bit -- note the older .30 version still had the bug;
We are doing a huge Data Migration Project using SSIS packages. We were insisted on not using stored procedures in SSIS packages. Can you please suggest whether we should be using stored procedures in SSIS packages or not? What are the advantages of using stored procedures?
It is correct that merge statements can easily be used in SSIS and your directive to encapsulate everything in SSIS is not necessary, as SQL processing aggregations faster than SSIS, for example. Further, if you are not deploying to SSISDB or have proper logging wrappers or email alerts, then troubleshooting your ETL is going to be more difficult via the SQL agent than otherwise as the errors are frequently more cryptic - thus the SSISDB and its reports in 2012. SSIS can be extremely powerful, however.
Here is a fairly blatant benchmark that will tell you never to use the out of the box SCD ever in SSIS. Taskfactory however does have a nice deployable which does basically merges behind the scene.
SSIS has more powerful functions than Stored Procedures.
However you can easily use Execute T-SQL Statement tasks in SSIS for existing tasks, and then build out from there.
SSIS is superior at the vast majority of ETL
Below Via Microsoft
Microsoft Integration Services is a platform for building enterprise-level data integration and data transformations solutions. You use Integration Services to solve complex business problems by copying or downloading files, defining business logic, sending e-mail messages in response to events, updating data warehouses, cleaning and mining data, and managing SQL Server objects and data. The packages can work alone or in concert with other packages to address complex business needs. Integration Services can extract and transform data from a wide variety of sources such as XML data files, flat files, and relational data sources, and then load the data into one or more destinations.
Integration Services includes a rich set of built-in tasks and transformations; tools for constructing packages; and the Integration Services service for running and managing packages. You can use the graphical Integration Services tools to create solutions without writing a single line of code; or you can program the extensive Integration Services object model to create packages programmatically and code custom tasks and other package objects.
A stored procedure in SQL Server is a group of one or more Transact-SQL statements or a reference to a Microsoft .NET Framework common runtime language (CLR) method. They can be called from within SSIS just the same as the unencapsulated SQL statement. For more information about it, please see: http://msdn.microsoft.com/en-us/library/ms190782(v=sql.110).aspx