Reporting on TDPSQL Job. Is my TSM admin full of it?

[osi9400]

I am executing TDPSQL jobs on each of my 20-something SQL Servers. These jobs are executed through a script (either by SQL Agent or Windows Task Scheduler) on the box -- these jobs are not initiated by the TSM server. Each job edits the log file on that particular server.

I do not have access to the TSM server, but my TSM admin tells me he cannot send me a report on these since the jobs were not initiated by TSM. For example, he created a report on the B/A jobs since these are scheduled at the TSM server.

What are my options for determining if my daily SQLServer backups were successful? I am getting tired of logging into each server daily to inspect the log. Is my TSM admin's story legit? I don't understand why he can't report on the SQL jobs since the data is in the catalog (I can see the databases when I do a restore in the GUI).

We are on very recent 5.x.x.x releases of on the four TSM Servers (AIX) and TDPSQL. No plans for 6.x yet.

Any advice?

 

[heada]

He can examine the TSM activity log and look at number of objects backed up/ archives and the number of objects that failed. He can also generate a list of nodes that haven't contacted TSM in "x" number of days. From that you should be able to get a list of servers that missed the backups or had failures. This is for any operation with the TSM server so it doesn't have to be initiated by TSM.

-Aaron

 

[moon-buddy]

I am executing TDPSQL jobs on each of my 20-something SQL Servers. These jobs are executed through a script (either by SQL Agent or Windows Task Scheduler) on the box -- these jobs are not initiated by the TSM server. Each job edits the log file on that particular server.

I do not have access to the TSM server, but my TSM admin tells me he cannot send me a report on these since the jobs were not initiated by TSM. For example, he created a report on the B/A jobs since these are scheduled at the TSM server.

What are my options for determining if my daily SQLServer backups were successful? I am getting tired of logging into each server daily to inspect the log. Is my TSM admin's story legit? I don't understand why he can't report on the SQL jobs since the data is in the catalog (I can see the databases when I do a restore in the GUI).

We are on very recent 5.x.x.x releases of on the four TSM Servers (AIX) and TDPSQL. No plans for 6.x yet.

Any advice?

Or:

If you keep logs on the node itself, you can write scripts that parse the last part of the log and e-mail the result to you on a daily basis. No need to log in to the nodes individually.

I have done this for the System Admin FYI.

 

[osi9400]

Care to share a sample script?

Or:

If you keep logs on the node itself, you can write scripts that parse the last part of the log and e-mail the result to you on a daily basis. No need to log in to the nodes individually.

I have done this for the System Admin FYI.

 

[moon-buddy]

Care to share a sample script?

I will get back to you soon... How good is your DOS scripting?

 

[moon-buddy]

Care to share a sample script?

Here is some insights on how a script on the node can help:

1. You will need some UNIX style utilities like:

tail - http://malektips.com/xp_dos_0001.html

2. A DOS based mailing program like bmail - http://www.pcworld.com/downloads/file/fid,58039-order,2-page,1-c,email/description.html

3. Here is a sample script:

@echo off

tail -n sql.log >> LOG.txt

bmail -t [email protected] -a "SQL Log for %DATE%" -m LOG.txt -f [email protected]


the -n at the tail command must be substituted for the number of lines that you need to see for the backup status starting FROM THE BOTTOM of the log. Since logs are appended, you are really retrieving the latest log entry which is the most current backup result.