I have an SSIS package which has a connection to a database. I took the database down to test a scenario, but the package gives me the following error in the output window when starting the package when the DB is offline:
SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "DBNAME" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
I need to check the connection when the package is run and notify a user, via email, that the DB is down. How would I go about doing this?
I have the code to send the email, I just need to do the DB check when the package is run.
Use a script task. Try to open a connection to your database and if it fails then Dts.TaskResult = Dts.Results.Failure.
A great post about this issue here :
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/7de0216b-3a0a-40ce-8149-f566a05010c9/ssis-check-database-connection-and-if-disconnected-send-email-alert?forum=sqlintegrationservices
Make your DB check occur outside of your package. How is the package run? Scheduled in SQL Agent or kicked off by the user? Instead of just running DTEXEC, first run a script that checks connectivity, i.e. using SQLCMD.EXE.
But really a better way is to run the package as normal then check the SSIS logs afterwards and send an appropriate message. Otherwise you'll be cooking up all different kinds of custom pre-execution checks to run.
I'm no batch script expert but here's an example of a bit of code you can use to test connectivity to a SQL Server and call another batch script if it fails, otherwise run the package with DTEXEC.
SQLCMD -S YOurServer -E -Q "SELECT ##VERSION"
IF ERRORLEVEL 1 (
CALL YourEmailScript.CMD
)
ELSE
(
DTExec /f "\\pathtodtsxfile\file.dtsx"
)
This is not production quality code. I would not recommend calling your DTEXEC in this way, it's just an example.
I finnally got it working. What I did was, create an XML file with the database settings, data source, initial catalog etc. Then added a script task, added some code to read the settings from the XML file and create a SQLConnection and connect to the DB in a try catch. If there is an error send an email, and in the finnaly closed the SQL connection.
But to get this working you HAVE to ensure that you connection has the property 'DelayValidation' set to TRUE. If not the package will fail to aquire a connection before the script task gets executed.
Related
I have an SSIS package to load data from multiple CSV files into an SQL staging table, then aggregate the rows of the staging table and insert those records into a destination table and finally delete the staging table rows.
The Package works fine when run manually.
When run using the windows task scheduler(using a .bat file), the package manages to load data from CSV into staging but doesn't do the aggregation ,insert and delete steps.
There are no errors seen in the Task scheduler post execution.
In the SSIS logs however, the following error was seen: Executing the query "" failed with the following error: "Retrieving the COM class factory for component with CLSID {32E37890-EC10-4F89-8D74-1B8CAA4C95F2} failed due to the following error: 8007007e The specified module could not be found. (Exception from HRESULT: 0x8007007E).". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly .
I am not very savvy with the tool so wasn't able to understand what the error meant or how to resolve this.
I have not found the need to use any parameters in this package as the operations are quite straight forward and did not require any.
The .bat file contains
"C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\DTExec.exe" /f "E:\Third Party Supply Performance\CNMA_DATA_EXTRACTION\CNMA_3RDPARTY_SUPPLY_DATA_EXTRACT\CNMA_3RDPARTY_SUPPLY_DATA_EXTRACT\CNMA_DATA_EXTRACTION.dtsx"
Could someone share some guidance on this issue or what I may be missing in terms of package design?
I migrated from SQL Server 2008 to 2019. On the old server there is set up a job, which calls a dtsx file. It needs database access, file system access because it saves tmp files to disk, and internet conneciton to send this file.
The connection string is defined followings:
<DTS:ConnectionManager
DTS:ConnectionString="Provider=SQLOLEDB.1;Password=p#ssword;Persist Security Info=True;User ID=MyUser;Initial Catalog=MyDB;Data Source=SQLServer\Instance;" />
If I run it using the Execute Package Utility it works. If I run it through the SQLServer Job, I get the error that the user is not granted to access the file system. The owner of the job is the same I am logged in and run the package using the Utility.
In the history i see:
The job failed. The Job was invoked by User Domain\RightUser.....
where RightUser is the Owner (and same as before, the same user run the package using the utility)
but the second row of the error:
Executed as user: NT Service\SQLAgent$AnotherUser.
And I have no idea where this AnotherUser comes from.
Whats wrong?
Furthermore, I don't really like the hardcoded password in the connection string, If the job run in its owner context, should it work changing the connection string to Integrated Security=True;, right?
This is a very common problem with running SSIS packages. That other user is SQL Agent, which in reality runs the package (this is the default user running the steps in jobs). Job owner has got nothing to do with running the SSIS packages. SQL Agent user name is set during the SQL Server installation. If it's omitted, the installer creates automatically a username like you described.
To the second question, yes you are right. If the user, who executes the package, has the correct permissions to the SQL Server described in the connection string, the userid and password are unnecessary. But in your case, the package is run by the SQL Agent with NT Service -level username, so it might be impossible to add that username to the SQL Server. You should set up a proper username for running the SSIS package and set it as a proxy account to the SQL Server, like described here: https://community.spiceworks.com/how_to/129293-configure-an-ssis-package-to-execute-as-a-proxy-account
I have an SSIS package that has run for months daily with no problem. Suddenly it is failing every day with the error above. No changes to the package or the stored procs it runs have been pushed, to my knowledge, no changes to the database environment have been made including permissions for the service account that owns the job.
This is a SQL Server 2008 package that connects to a SQL server 2008 R2 database. The configuration is through the ssisconfig table and it defines which server to use through an environment variable.
The component in question is using a stored proc. In the proc, all fields are explicitly cast to the same data type of the table the data is being staged too. The proc runs fine by itself. It is a relatively complex proc that has two table variables and a CTE.
I can't run it from my local on prod and dev is not failing. If I open the prod SSIS package while I am set to the environment variable that the job owner uses, I do not get a validation error on this component. ValidateExternalMetadata is set to true for this component. For the entire package though, Delay Validation is set to True. I do get a validation error that would be expected on a task using a variable that is set dynamically in an earlier task. This error, however, is many, many steps later than the step it is currently failing on.
Usually in the past when we have had this sort of unspecific error, I have been easily able to see the problem with the data that caused the sudden failure. But none of the data in the proc result set is even close to being incorrect for the datatypes defined for staging table for that field. None of the required fields are missing data either.
I am out of ideas for what else to look at. If the environment didn't change, the actual code didn't change and the data looks correct, what is left to try?
As I have commented for details error, you can try below link from Microsoft:
Debug SSIS Package while calling from Agent
Some info from link:
Reasons that the package may have failed are as follows:
The user account that is used to run the package under SQL Server Agent differs from the original package author.
The user account does not have the required permissions to make connections or to access resources outside the SSIS package.
The package may not run in the following scenarios:
The current user cannot decrypt secrets from the package. This scenario can occur if the current account or the execution account
differs from the original package author, and the package's
ProtectionLevel property setting does not let the current user
decrypt secrets in the package.
A SQL Server connection that uses integrated security fails because the current user does not have the required permissions.
File access fails because the current user does not have the required permissions to write to the file share that the connection
manager accesses. For example, this scenario can occur with text
log providers that do not use a login and a password. This scenario
can also occur with any task that depends on the file connection
manager, such as a SSIS file system task.
A registry-based SSIS package configuration uses the HKEY_CURRENT_USER registry keys. The HKEY_CURRENT_USER registry keys
are user-specific.
A task or a connection manager requires that the current user account has correct permissions.
Method 1: Use a SQL Server Agent proxy account Create a SQL Server Agent proxy account. This proxy account must use a credential that
lets SQL Server Agent run the job as the account that created the
package or as an account that has the required permissions.
This method works to decrypt secrets and satisfies the key
requirements by user. However, this method may have limited success
because the SSIS package user keys involve the current user and the
current computer. Therefore, if you move the package to another
computer, this method may still fail, even if the job step uses the
correct proxy account.
Method 2: Set the SSIS Package ProtectionLevel property to ServerStorage Change the SSIS Package ProtectionLevel property to
ServerStorage. This setting stores the package in a SQL Server
database and allows for access control through SQL Server database
roles.
Method 3: Set the SSIS Package ProtectionLevel property to EncryptSensitiveWithPassword Change the SSIS Package ProtectionLevel
property to EncryptSensitiveWithPassword. This setting uses a password
for encryption. You can then modify the SQL Server Agent job step
command line to include this password.
Method 4: Use SSIS Package configuration files Use SSIS Package configuration files to store sensitive information, and then store
these configuration files in a secured folder. You can then change the
ProtectionLevel property to DontSaveSensitive so that the package is
not encrypted and does not try to save secrets to the package. When
you run the SSIS package, the required information is loaded from the
configuration file. Make sure that the configuration files are
adequately protected if they contain sensitive information.
Method 5: Create a package template For a long-term resolution, create a package template that uses a protection level that differs
from the default setting. This problem will not occur in future
packages.
Above link will help you through logging and other possible scenarios of failure of your package from SQL Agent. I suspect that your user of Agent has been corrupted. But that is an assumption. You first enable the logging of SSIS by following link :
Enable SSIS Package Logging
Some info from link
To set the logging level for a package by using the Execute Package
dialog box
In SQL Server Management Studio, navigate to the package in Object Explorer.
Right-click the package and select Execute.
Select the Advanced tab in the Execute Package dialog box.
Under Logging level, select the logging level. See the table below for a description of available values.
Complete any other package configurations, then click OK to run the package.
Hope this will help you in the first place. If not please let me know.
I have an SSIS package that takes data from a MySQL database and puts it in to a SQL Server table. The connection to MySQL is ADO.net. The package runs fine in BIDS.
I would like to deploy the package to be run as a Job on SQL Server 2008. The MySQL connection requires sensitive data to be either stored within the package or held in some external configuration source. If it is stored within the package it will either by encrypted with a key specific to my windows user profile or must be protected via a password.
I have tried three methods of setting up a SQL Server Agent job to execute this pacakge, and all fail:
Using a Password
I set the ProtectionLevel of the package to EncryptSensitiveWithPassword and supply a password for the package. I then save a copy of the package to the msdb. I can then connect to SSIS and run the package, at which point I am prompted for a password.
When I try to schedule this as a job in SQL Server I am prompted to enter the password by clicking on the Configurations tab of the Job Step Properties and I can see that the /DECRYPT switch has been added to the Command Line tab. The Run As property is set to the SQL Server Agent Service Account, which is mapped to a database login that has sysadmin server role. When I attempt to start this job I get the following error:
Executed as user: DOMAIN\UserROLE. Microsoft (R) SQL Server Execute Package Utility Version 10.0.5500.0 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 12:31:30 Error: 2012-07-03 12:31:31.20 Code: 0xC00291EC Source: Get Data Execute SQL Task Description: Failed to acquire connection "DATA_SOURCE". Connection may not be configured correctly or you may not have the right permissions on this connection. End Error DTExec: The package execution returned DTSER_FAILURE
It seems that using this method the package password itself is not stored anywhere for the job to access it.
Using an XML configuration file
I then created a copy of the package and set the ProtectionLevel to DontSaveSensitive and I set up a package configuration to store the MySQL credentials in an XML file. I then save this to the msdb and then when I run the package from
Integration Services I can provide a path to the config file, and all is well. However, once again when I set up a job for the package I point to a configuration file on the server but the job fails with the same error. I am wondering whether this is because the SQL Server Agent does not have an associated windows account that would allow it to read from the XML file stored in the file system.
Using a SQL Server table configuration
This time I created a copy of the package and set the ProtectionLevel to ServerStorage. I then created a [SSIS Configurations] table in the target SQL Server database. I modified the entries in this table to contain the password for the MySQL data source. Again, the package runs successfully from Integration Services, but fails with the same error as previously when run from a job. I have checked that the SQL Server Agent is able to read from the [SSIS Configurations] table ok - I set up a standalone job to test this.
Does anyone have any suggestions about what else I should do here?
I am thinking of giving up on SQL Server Agent Jobs for this and going back to having the package scheduled simply by the windows scheduler but thought before throwing in the towel I would try here first.
I am using the method of encrypting the password by setting EncryptSensitiveWithPassword as you discribed above and don't see anything you do wrong. Remember to use option keep protection level of the original package when importing the package with integration services, but it looks like you're doing that, too.
Try setting the role SQLAgentOperatorRole to your SQL Server Agent Service Account, you didn't mention that and i am not sure if you did. This could possibly solve your permission problems. (liked to answer by commenting this, but i lack of permissions here, too :)
I Have a package stored in SQL Server which works properly with logging when I run it directly by right-clicking it in SQL Server, with logging.
Logging is set to 'SSIS log provider for Text File'.
When I run it from an SQL Server Agent Job, it works fine, without errors but the logging isn't done.
The job runs with the my user, the same one that I use to start the package from SQL Server
Anyone know why and how to make it log
Thanks
I found my problem, my job is own by my user but each step is executed by SQL Server Agent Service Account, which didn't have access to rhe folder containing my logs.
I don't understand why there are no errors raised by this...