I implemented SSIS package which moves data from Sql Server database to another one. This package has set of Data Flow Tasks which copy data simultaneously in different tables. Each Data Flow Task contain OLE DB datasource and Sql Server destination.
Package worked fine until I decided to implement transaction. I found that it is not possible to just set TransactionOption to Supported on package level, because SSIS cannot handle transactions in multiple simultaneous processes. So, I decided to use this way:
http://consultingblogs.emc.com/jamiethomson/archive/2005/08/20/SSIS-Nugget_3A00_-RetainSameConnection-property-of-the-OLE-DB-Connection-Manager.aspx
But now I have another problem. I have "Unable to bulk copy data. You may need to run this package as an administrator" errors. These errors occur in random places. For example if I ran package in the first time Data Flow Task named "Task A" can be executed correctly, but when I run package in the second time it can throw the error.
How do I can implement transaction in my case? (Changing of package in order to perform execution of Data Flow tasks sequentially is not an option)
I got a recent error with our MS SQL Server 2008R2 and SSIS. Found the error:
[SQL Server Destination [16]] Error: Unable to bulk copy data. You may need to run this package as an administrator.
[SSIS.Pipeline] Error: component "SQL Server Destination" (16) failed the pre-execute phase and returned error code 0xC0202071.
but could not solve it with running as Admin. The error only came with one step and I finally found out that I get rid of the error when I increased the timeout of the SQL Server Destination. Funny is that with the read of external ADO NET Source I get a proper error that helped me to see the timeout is the problem.
Related
I have a package that connects to two different DBs, does some calculations, and then inserts values into each DB. The package worked great in our old env, but migrating it over to the new one has proven pretty unpleasant. We had to switch from Windows Auth to SQL Auth and the Connection Manager test works fine, but I'm getting the following error when attempting to execute my SSIS package from Visual Studio:
SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER.
The AcquireConnection method call to the connection manager "DB1"
failed with error code 0xC0202009. There may be error messages posted
before this with more information on why the AcquireConnection method
call failed.
[SSIS.Pipeline] Error: OLE DB Source failed the pre-execute phase and returned error code 0xC020801C.
What has me really puzzled is the failing task isn't even the first time that connection is used in the package. Just before reaching that Dataflow task, an Execute SQL Task fires against the same connection and is successful. I can also go into the task itself and hit "Preview" and it returns data.
Does anyone have any ideas where else to look?
I've tried:
setting to 32bit Execution
deleting and recreating the task
delay validation = true
I am dealing with my problem on some Windows Server 2019 (Core) with one running SQL Server 2019 CU4 instance each.
What we try to do
We are currently building a data warehouse with distributed databases. The individual layers of the DWH are located on one database server each. The data exchange between the layers/servers takes place via SSIS ETLs, which use Linked Servers to reach the other layers and drag and drop data. Each layer also has its own SSIS service instance and executes the corresponding SSIS packets.
The SSIS packages are called by SQL Server Agent jobs. We have a job that executes the SSIS packets (#1), which in turn calls another job (#2) as the last step, which after a short wait time executes the calling job (#1). Thus, controlled by schedules, a loop is created and data is continuously transferred with ETLs.
I hope this was not too much unnecessary background
The error
Basically the job is running and there are numerous successful executions. However, we are observing interruptions at job #1 without helpful information regarding the error. This means that the job history log refers to the SSIS log, which again only contains an "unexpected termination". In the SSIS log, we only see behavior that indicates that the ETL packet active at that time stopped after validation. Depending on the log level, nothing is logged at all, not even the execution of single packages of the project. The package where this error occurs is different and not limited to a specific one.
What I have already tried
Re-create the jobs and SSIS Enviroments by hand (scripted before)
Using the 32Bit Runtime
Upgrade the SSIS project/package version to
2019
Increase the log level to "verbose"
Patching the SQL Server to CU4
Save ssis dump files (couldn't find them or they weren't created)
Search Windows and SQL Server Logfiles
Does anyone have some suggestions or some ideas how to become more error specific informations?
Thank you very much and take care :)
UPDATE We have an error message (OLE DB 0xC0202009 and 0X80004005)!
In order to exclude the use of environments as a cause, I manually set the parameters in the SSIS job step instead of overwriting them by selecting an environment.
Long story short: Today it turns out that the parameter for an OLE DB Connection String is not passed correctly.
The following is specified as a parameter in the job step:
However, the following connection string is specified in the context of the error message:
Please note that some arguments are added twice to the parameter (red).
What could have caused that?
I use SQL Server 2014 and SSIS with Visual studio 2013.
I need to make some changes in one OLTP database (Here it is my destination database) in several tables with one of my SSIS package, and some times that takes a lot of time to execute and during this time it locks some tables in OLTP database and I can't anymore work with may application which works with OLTP database.
Before my package have been run one time in day and it was at midnight but now we decided to run this package every 30 min.
I need to use snapshot isolation level in OLTP databse to be sure that SSIS package does not lock the table for long time.
At first I want use IsolationLevel equal to Snapshot but it does not work.
Then I found that I should handel the Isolation leve manually inside the ControlFlow for using the Isolation Snapshot.
I have created a sample because my real SSIS package is really huge.
I have created a database and then, I have set Allow snapshot isolation with true.
After that I have created a SSIS package in which I have these variables:
Then I have created a Control flow like that :
In the first SQL Execution Task I have run this command:
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
Then in second SQL Execution Task I have started a Transaction :
BEGIN TRANSACTION
Then I have added a Dataflow task. Inside of my DataFlow task there are two OLE DB. One as source and second one is destination.
The source and target are both in the same server and in the different database.
Then I change the property of my Connection Manager like below :
And then I have installed and configured my MSDTC in my computer. (Source and Destination are both on the same server and ssis package is running in the same server).
Then I configur my service like that :
Then in my firewall I have given the access to MSDTC like that :
Then I have configured my firewall's advance configuration like that :
All of the Task in my SSIS package have these configurations for IsolationLevel and TransactionOption :
My control flow has these configurations :
When I run the package I get this error in my OLE DB destination.
[OLE DB Destination [2]] Error: SSIS Error Code
DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER.
The AcquireConnection method call to the connection manager
".<ServerName>.<DatabaseName>" failed with error code 0xC001A004.
There may be error messages posted before
this with more information on why the AcquireConnection method call failed.
[SSIS.Pipeline] Error:
OLE DB Destination failed validation and returned error code 0xC020801C.
What should I do to be able to handel manually the transaction and isolation level as Snapshot in my SSIS package?
I am loading data into a potgres database using ssis and oledb drivers. The package executes inserts and some updates using execute sql task. It runs fine through most of the steps but then fails on one final update sql task and I receive the following cryptic Microsoft error msg.
failed with the following error: "timeout expired
". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.”
The target postgres servers are sitting on ubuntu and it seems that the ssis package runs successfully on one server then randomly fails on another.
I created an SSIS package to pull data from OLAP Cube and push it into SQL Server using SSIS 2012. I deployed the same on the SQL Server SSIS DB and created a SQL Server Agent Job to run the package. I have an account configured to run the job (not by creating proxy in the job, but SQL Server Agent is running under that account), that has access to the OLAP Cube. The job is running sometimes and failing sometimes.
Why the job behaving weirdly? Any help on the issue will help me a lot.
I am using SQL Server 2012 SP1 enterprise edition (11.0.3000.0) (if it helps). The error message which pops up when it fails is :
OLE DB Source failed the pre-execute phase and returned error code 0xC0202009
SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80040E05.
An OLE DB record is available. Source: ""Microsoft OLE DB Provider for SQL Server 2012 Analysis Services."" Hresult: 0x00000001 Description: ""Error Code = 0x80040E05, External Code = 0x00000000:."".
"
I have had the same error on SQL2008 and now on SQL2012 SSIS, but have been able to eliminate / workaround.
We have a Loop Container in our Control flow that contains a data-flow task with an MDX source. The MDX query for the data-flow source is dynamically built (via an expression) on each iteration of the Loop container (however it always returns the "same shaped" results - only the filters in the WHERE clause are different).
We've found the error to be somewhat intermittent - sometimes the package will complete successfully, other times it will fail with the 0x80040E05 error at varying iterations thru the container loop.
To alleviate the problem we setup the SQL Agent job-step for this package to re-try on failure for up to 5 retries - not an ideal workaround, but it helped to improve the success rate of the Job.
We have no idea why this error is occurring or what is causing it, however it appears to be timing-related in some way and I have only seen the issue when using a SSAS OLE-DB data source with a dynamically generated MDX query. I have managed to virtually eliminate the error from occurring with a not ideal workaround in the SSIS package - no idea why this works/helps (hopefully Microsoft will be able to work it out and resolve the issue as it's been plaguing us since SQL2008 and is still here in SQL2012 SP1...
Workaround for MDX causing 0x80040E05 error:
Within our loop container we have added a Script task with OnSuccess precedent constraint to the data-flow task that contains the dynamically generated MDX source query. The script task simply introduces a WAIT in the processing immediately after the data-flow task completes of about 5 seconds, before allowing SSIS to continue with the next iteration (e.g. System.Threading.Thread.Sleep(5000)).
With this delay in place we have had much more stable SSIS package executions - dont know why, but that's what we have observed. Also note that when we migrated to SQL2012 SSIS packages the 0x80040E05 error returned, however we were able to eliminate it once more by increasing the WAIT time to 10 seconds on this script task.
Now waiting for 10 seconds is not an ideal solution / workaround to this problem - particularly when it is contained within a Loop Container (in our case it has added nearly 30 minutes of "WAIT time" to the package execution duration), however this workaround is better than having the package fail 80%+ of the time