Importance of DAILY CHECK LIST!

Here I am, back from long holidays to my blogs! I was thinking of writing in which happens to be part of any DBA on production support (it can different levels as such).  So, have chosen to blog the importance of Daily Check list.

Daily check list:

The following is purely what we have adopted as part of the routine daily check. The check can be done at one time everyday and at a convenient time so that we don't miss anything.

First thing, we have selected list of servers which are very critical for the business and have to be part of check list.

Encrypted DTS packages... continued...

Yesterday I posted the way of getting to know about the DTS Package name from a job step which is encrypted "Encrypted DTS packages - Find DTS Package name". So, now once we are aware of the proper DTS calls used in the scheduled jobs... we may want to replace the encrypted DTS names with correct readable names... which helps us to understand better.

To perform the same:
Following list of SP's come in handy; one can refer to books online to know more about the same.

sp_update_jobstep
sp_add_jobstep
sp_delete_jobstep
sp_help_jobstep

I made use of one of the above SP's and created scripts to have the DTS jobs updated:

One such example is as shown below:

USE msdb
GO
EXEC dbo.sp_update_jobstep
@job_name = 'Job Name',
@step_id = 1,
@command = 'DTSRun /S "ServerName" /N "DTS package name" /E '
GO

This will do the trick!

Encrypted DTS packages - Find DTS Package name

Happy New Year 2013 to all of you... I shall now start off with some techie stuff.

Most of us have been working on DTS\SSIS packages. Even though we get to hear very little about DTS packages now a days; sometimes it becomes inevitable to know some of the legacy left behind by older versions.

To identify which 'Encrypted' DTS package is being referenced by scheduled job.

Before I explain the method of doing the above task, let me tell you the reason why the 'DTS package calls' are 'Encrypted' at first place? I am sure many of us are already aware of the reason... but still... here it is...

Most of us are addicted to follow easy methodology; right click the DTS Package (SQL 2000) and schedule a job. The created SQL Job will have an encrypted name for DTS package in SQL job step.

For example:DTSRun /~Z0x99810D5EE6B8FC6BFEB92F1D9EB5849.....

the above value would be much more! I have cut short to keep it simple ;)

So, now the task; to identify which package is being called by scheduled job step.

For each Job which makes an encrypted call to DTS, from SQL Job Step, refer to the following steps:

1. To the end of Command (DTSRun) line, add /!X /!C
   For example:
   DTSRun /~Z0x99810D5EE6B8FC6BFEB92F1D9EB5 /!X /!C
   /!X means 'do not execute' and /!C means 'copy results onto Windows Clipboard'
2. Copy complete command DTSRUN with /!X /!C
3. Run the command from command line. One thing I noticed: The command can be either run from target server where the JOB is or from your local machine if it is the same network as of target server. I hope I did make some sense!
4. Open notepad, paste the clipboard result onto notepad. So, there it is... name of the package!!

SQL Agent Tokens

Consider a situation where in one needs to have SQL Jobs to be more independent of machine/instance and/or the main job itself. In such cases we can utilize one of the features of SQL Server called "TOKENS".

When a Job step is written using tokens it gives the same flexibility that "Variables" provide in software programs. I hope that makes sense! Many of us do understand the meaning and usage of Variables...  so will not explain the same.

When a token is used in a job step script, SQL Server Agent replaces the token at run time, before the job step is executed by the Transact-SQL subsystem.

Note: I have tried to explain the usage of tokens by making use of the following example.

For example: Consider a situation wherein we are saving the output logs of a Job from multiple servers (Development, Testing, and Production) to one central location. In such cases, we have two options of specifying the output path.

1. Manually setting the path for job on each of the Servers.

2. Or making use of "TOKENS" which makes our life easier.

Let’s make use of the tokens.

This centralization of output log location allows the use of common scripts for all environments.

Servername can be replaced by using SQL Server Agent Token [MACH], [DATE] and configure output to a common location shown below.

\abcd\Prod\SQLServersJobs\LOGS\

 The server name differentiates the environment context of the log.

Note:  The token templates used are different for SQL versions.

<Template>

SQL2000

[MACH]\[INST]_<jobname>_Step1_[DATE].log  -- Where <jobname> is the name of the job.

Example: SQL2000

\abcd\Prod\SQLServersJobs\LOGS\[MACH]_[INST]\MyJob_Step1_[DATE].log

The above would be converted to: (see that default instance returns as MSSQLSERVER)

 \abcd\Prod\SQLServersJobs\LOGS\A2MDEV101_MSSQLSERVER\MyJob_Step1_20091005.log

  SQL2005

$(ESCAPE_NONE(MACH))\$(ESCAPE_NONE(INST))_<jobname>_Step1_$(ESCAPE_NONE(DATE)).log --Where <jobname> is the name of the job.

Example: SQL2005 (SP1 & higher) & SQL2008

\abcd\Prod\SQLServersJobs\LOGS\$(ESCAPE_NONE(MACH))_$(ESCAPE_NONE(INST))\MyJob_Step1_$(ESCAPE_NONE(DATE)).log

 The above would be converted to: (see that default instance returns as MSSQLSERVER)

\abcd\Prod\SQLServersJobs\LOGS\A2MPRD151_LOGGING\MyJob_Step1_20091005.log

And that is all for now.

For more on tokens one can refer to the following web link:

http://msdn.microsoft.com/en-us/library/ms175575.aspx