Friday, October 5, 2012

Query to fetch long running DTS Jobs


Sometimes the DTS packages will run unusually taking long time which leads to slow down the performance of the server.

The reason might be the bad SQL used in the package or the scheduled time for the package to run. Use the below query to find the long running DTS packages and its information.

We can not get the long running job information which is currently executing using system table msdb.dbo.sysjobhistory.

Below query gives the information about the DTS jobs which has got executed recently and took more than one hour duration to execute.

SELECT     j.name                                                                                  ,
           h.run_status                                                                            ,
           durationHHMMSS = STUFF(STUFF(REPLACE(STR(h.run_duration,7,0), ' ','0'),4,0,':'),7,0,':'),
           [start_date]   = CONVERT(DATETIME, RTRIM(h.run_date) + ' ' +
           STUFF(STUFF(REPLACE(STR(RTRIM(h.run_time),6,0), ' ','0'),3,0,':'),6,0,':'))
FROM       msdb.dbo.sysjobs AS j
           INNER JOIN
                      ( SELECT  job_id,
                               instance_id = MAX(instance_id)
                      FROM     msdb.dbo.sysjobhistory
                      GROUP BY job_id
                      )
                      AS l
           ON         j.job_id = l.job_id
           INNER JOIN msdb.dbo.sysjobhistory AS h
           ON         h.job_id                                                     = l.job_id
           AND        h.instance_id                                                = l.instance_id
WHERE      STUFF(STUFF(REPLACE(STR(h.run_duration,7,0), ' ','0'),4,0,':'),7,0,':') > '000:60:00'
AND        CONVERT(DATETIME, RTRIM(run_date))                                      > = CONVERT(DATETIME, RTRIM(GETDATE()-6))
ORDER BY   CONVERT(INT, h.run_duration) DESC,
           [start_date] DESC

After I searched many sites, I have found that the usage of extended stored procedure xp_sqlagent_enum_jobs will give the exact information about job status

EXECUTE master.dbo.xp_sqlagent_enum_jobs 1, 'ICON-EU\sevells'

By executing this, you can find the currently executing job which shows the state as “1”. To know the status, check the column ‘Running’ with the following values

0 - Returns only those jobs that are not idle or suspended.
1 - Executing.
2 - Waiting for thread.
3 - Between retries.
4 - Idle.
5 - Suspended.
7 - Performing completion actions.

Hope this helps to know more details about the long running DTS jobs.



Friday, May 4, 2012

SQL Server 2000 - DTS Package fails when run through job





It will work fine if we execute the DTS package that transfers data from excel file to SQL Server database, but the problem comes when it is scheduled to run in a regular interval through SQL server agent job.

Error:

The Microsoft Jet database engine cannot open the file G:\foldername\filename.xls'.  It is already opened exclusively by another user, or you need permission to view its data.

Cause:

The account that runs the job will not be able to access the file

We should check whether the user that runs the job must have the appropriate privileges to access the folder\file and also the permissions to run the job.

But sometimes the job will not work, even if the account has system administrator privilege to run the job and full control to access the file,

The exact reason will be the account under which the SQL server agent is running may not have access to the file

Workaround:

Adding the SQL Server agent service account to the folder or file under security and providing full control permission to access the file will devise the DTS job run successfully.


Monday, January 16, 2012

Point in time restore of a table


There are chances of getting unintentional update or delete to a table, in that case restore the most recent backups is the best solution using which we can get the data almost completely.
Instead of restoring the backup to the original database, it is better and convenient to restore the backup files to a newly created database, since it is very easy to fetch only the data that has got deleted or updated to the original database
First step is to restore the last full backup to the database by using the following script,

   RESTORE DATABASE testdb
   FROM C:\backup\originaldb.bak
   WITH MOVE original_data TO 'D:\data\test.mdf',
        MOVE original_log TO 'D:\log\test.ldf',
   NORECOVERY, STOPAT = '01/07/2012 12:10 am'

MOVE option is used to move the newly restoring database to another directory since we have our original database files in the current directory

STOPAT option should be the approximate time at which the update or delete action was performed on the table

NORECOVERY option is used to make the database unavailable for the users to access. It specifies that roll back not occur. This allows roll forward to continue with the next statement in the sequence. It tells SQL Server that recovering the database is not finished and that subsequent restore files will occur.

Next step is to restore the transaction log files, starting with the first transaction log backup that was created after the full backup. Restore the log files in sequence with NORECOVERY option.

   RESTORE LOG testdb
   FROM C:\backups\originaldb_transationallog1.trn
   WITH MOVE original_data TO 'D:\data\test.mdf',
        MOVE original_log TO 'D:\log\test.ldf',
   NORECOVERY, STOPAT = '01/07/2012 12:10 am'

  RESTORE LOG testdb
   FROM C:\backups\originaldb_transationallog2.trn
   WITH MOVE original_data TO 'D:\data\test.mdf',
        MOVE original_log TO 'D:\log\test.ldf',
   NORECOVERY, STOPAT = '01/07/2012 12:10 am'


Finally restore the database with recovery option to make the database available to use. It signifies that roll back should be performed after roll forward is completed for the current backup.

  RESTORE LOG testdb WITH recovery
  
Now to get the data from newly restored db to an accidental updated/deleted table in the original database, use the following query

UPDATE A
SET A.col=B.col
--specify the col which has got updated or deleted
FROM originaldb.dbo.Tbl_tht_needs_to_be_updated A
INNER JOIN testdb.dbo.tbl_newly_restored B
ON A.pkeycol=B.pkeycol
--Use where condition if you want to restore specific data
         
 Note: If you have same database with the tables having same data in different server, you can create linked server to fetch the data and restore it to the updated/deleted table.



Monday, October 3, 2011

SSIS package does not run when you call the SSIS package from a SQL Server Agent job step

When you call the SSIS package from a SQL Server Agent job step, the SSIS package does not run. However, if you do not modify the SSIS package, it will run successfully outside SQL Server Agent.
It works if the package is created in the same environment with the same credential and scheduled it in a job with the same credential with a proxy account, but when working with multiple servers with different credential, some issues may arise.

For example:

  • When the package developer use BIDS to create and save the package and another developer tries to run the package, it will throw an error “Login Failed for the user “
  • If the package developer deploys the package to the production and when schedule it to execute through SQL server agent job, the job will fail.

Reason:
  • 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.
Resolution:

Use a SQL Server proxy account:  The Proxy account must use credential that allows SQL server agent run the job as the account that has the required permissions. This method decrypts secrets and satisfies the key requirement by the user.
But the same will not work if we move the package to different computer even if we use the correct proxy account.
Set the SSIS Package Protection Level property to ServerStorage: Change the SSIS Package Protection Level property to ServerStorage. This setting stores the package in a SQL Server database and allows access control through SQL Server database roles. The one major drawback is that it will not work when deploying a package from a development environment in BIDS to another environment.
Use SSIS Package configuration files Use config file to store sensitive information, and then store this 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 in a job, the required information is loaded from the configuration file.  Ensure that the configuration files are protected as if they contain sensitive information. The disadvantage here is to maintain a configuration file in a secured folder and there may be chances of viewing the config file or getting login failed issue again.
So the best option that works well in development environment where several developers may want to edit the same package is to create the package with the connection manager on windows authentication account with least privilege or create a package template that uses a protection level that differs from the default setting. This problem will not occur in future packages.


Permission to execute the package:

db_ssisadmin
Enumerate own packages.
Import packages.
or
Enumerate all packages.
Delete own packages.
sysadmin
View own packages.
Delete all packages.

View all packages.
Change own package roles.

Execute own packages.
Change all package roles.

Execute all packages.
Bitmap

Export own packages.


Export all packages.


Execute all packages in SQL Server Agent.

db_ssisltduser
Enumerate own packages.
Import packages.
Enumerate all packages.
Delete own packages.
View own packages.
Change own package roles.
Execute own packages.

Export own packages.

db_ssisoperator
Enumerate all packages.
None
View all packages.
Execute all packages.
Export all packages.
Execute all packages in SQL Server Agent.
Windows administrators
View execution details of all running packages.
Stop all currently running packages