By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,779 Members | 1,101 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,779 IT Pros & Developers. It's quick & easy.

TSM Troubles

P: n/a
We have a DW and are using TSM for the logs and backups. We are
constantly
getting retry messages in the db2diag.log inidicating that DB2 won't
try to
archive for another 5 minutes. This is a continuous problem. I
understand an
occasional message like this is ok, but not constantly...Has anyone
else
experienced this problem with TSM not being able to keep up? Our logs
are
going to TSM disk pool then off to tape. Also, I am thinking that
cutting a log every 15 minutes is a good number (4 per hr). What is
everyone else using as a rule of thumb here? Thks, John
Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Ian
John wrote:
We have a DW and are using TSM for the logs and backups. We are
constantly getting retry messages in the db2diag.log inidicating that
DB2 won't try to archive for another 5 minutes. This is a continuous
problem. I understand an occasional message like this is ok, but not
constantly...Has anyone else experienced this problem with TSM not
being able to keep up? Our logs are going to TSM disk pool then off
to tape. Also, I am thinking that cutting a log every 15 minutes is
a good number (4 per hr). What is everyone else using as a rule of
thumb here? Thks, John

Have you investigated why your user exit is failing? This would be
the first place to start -- i.e. see what the return code from the
TSM server is.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 12 '05 #2

P: n/a
Thanks Ian but all we know is that it is not completing fast enough.
As you know the error codes returned are limited to a few and we have
been able to track those down. I have another question. Has anyone
experimented with setting the user exit BUFFER_SIZE variable (this is
the buffer db2 passes to TSM during a log archive request) to larger
then 4096K or 32K in a DW environment? The default of 32K (v8.1) does
not appear to be adequate for large DW logs.


jo******@hotmail.com (John) wrote in message news:<f8**************************@posting.google. com>...
We have a DW and are using TSM for the logs and backups. We are
constantly
getting retry messages in the db2diag.log inidicating that DB2 won't
try to
archive for another 5 minutes. This is a continuous problem. I
understand an
occasional message like this is ok, but not constantly...Has anyone
else
experienced this problem with TSM not being able to keep up? Our logs
are
going to TSM disk pool then off to tape. Also, I am thinking that
cutting a log every 15 minutes is a good number (4 per hr). What is
everyone else using as a rule of thumb here? Thks, John

Nov 12 '05 #3

P: n/a
Ian
John wrote:
Thanks Ian but all we know is that it is not completing fast enough.
As you know the error codes returned are limited to a few and we have
been able to track those down. I have another question. Has anyone
experimented with setting the user exit BUFFER_SIZE variable (this is
the buffer db2 passes to TSM during a log archive request) to larger
then 4096K or 32K in a DW environment? The default of 32K (v8.1) does
not appear to be adequate for large DW logs.


I assume that you are using the sample user exit that IBM provides for
writing to TSM (db2uext2). If so, it should be creating a file called
ARCHIVE.LOG in the location defined by AUDIT_ERROR_PATH ... This file
should have more information about why the user exit is failing (i.e.
a TSM return code).

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.