Problem in TSM with active/archive logs

myrepublic

Newcomer
Joined
Aug 5, 2011
Messages
1
Reaction score
0
Points
0
PREDATAR Control23

Hi guys,

I am new to TSM world. Pardon me for my naive questions.

I have TSM 6.2.1 configured for 4 nodes. Server and clients are on windows. These client nodes are scheduled for daily backup with 1 hr interval gap between 2 backups(8:00 PM to 11:00 PM). Next day when I log in to my system I find that my TSM server is not running. When I try to start the server (using dsmserv), it throws an error something like "rdbdb.c : Server LOG space exhausted" and server wont start. I somehow figured that it is because of my active log size is full. So I move some active logs from its current location to some other storage location(other hard disk) without configuring anything in TSM. After that TSM server starts perfectly fine. When I query last scheduled backup, it shows that scheduled backup of one node is "completed" while backup of other 3 nodes are still "In Progress". While querying session, TSM shows no session for these nodes is currently active.

TSM was configured by someone before I knew anything about TSM. In current configuration, 1 local drive is dedicated for active log and it is currently full. 1 local drive is dedicated for archive log and it is also full. So whenever this problem occurs everytime I have to move my active log to other location.

Now I have some questions regarding this problem.
• Are active/archive logs required for any TSM operation?
• Can I change the the current path of storage of active and archive logs? If so how and what about older logs generated?
• How can I limit the size of active and archive logs? After limiting it, will it have any implication on any TSM operation?

Thanks.
 
PREDATAR Control23

Quick response - if you back up the db, that should clear your logs. The logs are needed for keeping DB2 consistent, so moving them around and/or deleting them can be problematic.
 
PREDATAR Control23

Hello,

You really should read up on how TSM operates. Visit TSM infocenter, it's really good.

As for the logs... basically it's like this:


TSM writes all incomplete transactions (those that started and are still running) into ACTIVE log. Once they're complete, the server commits the transaction to the DATABASE and then moves the entries from ACTIVE to ARCHIVE log.

You can see how much of active log is used by running "query log". This will change all the time while server is running since it constantly writes to it and then empties it when it commits the transaction. It just needs to be large enough to handle your long-running transactions.

If the ACTIVE log gets filled, the server stops. The correct response to this is to increase the log size by increasing the ACTIVELOGSIZE parameter in dsmserv.opt (the main server configuration file, this is the default file name) and start the server again.

ARCHIVE log directory is emptied automatically by TSM once you do a full DB Backup (this should be a part of daily/weekly maintenance schedule). You can delete archive log entries yourself if you have disk space problems but then if you're doing a DB restore (in case of disaster) then you won't be able to bring the database to its most current state.

If you delete/move the ACTIVE log while the server is NOT running, the server will re-create it at the new location.

In summary, the anwers for your questions are these:

1) yes, active/archive logs are essential for TSM operation and you should not manage them outside of TSM (move, copy, delete etc.)

2) yes, find a file named "dsmserv.opt", this is the main configuration file for your server instance. Have a look at Database options documentation to see what directives are related to your task (ACTIVELOGDIR, ACTIVELOGSIZE and ARCHLOGDIR).

3) the size of active log is specified in dsmserv.opt. Archive log should not have a size limit.


IMPORTANT: TSM will automatically do a DB backup once the *filesystem* where archive logs are located gets filled beyond 80%. If your disk is occupied by other files this may put TSM into an endless loop where it does DB backup every 10 minutes in an attempt to make more space available by emptying archive logs.

If you're stuck you can delete the archive logs manually but you'll lose data if you need to do a DB restore (restore the TSM database, not client files).

Hope this helps.
 
PREDATAR Control23

hello
sorry or bring back from dead an old topic
but I made similar mistake ,my hdd on windows tsm server was full so I cut/paste some archive logs to another disk,after 42 days i figured my mistake and copyed back those files to the original location

are those archive log deleted auto by tsm? so by moving them away for 2 days maybe I lost the autodelete for those files ?
any suggestions ?

thanks.


*edit*

after a few hours the files auto deleted so I gues everything worked fine.
 
Last edited:
PREDATAR Control23

Sorry to bump this old thread but i have a similar issue with one of my TSM-servers.

The active and archive logs got full and TSM stopped. I managed to update the dsmserv.opt and add failover log archive path which is currently filling up. But my question is if this will be enough? Since i managed to start TSM about an hour ago and then immediately started a full database backup to clear some of the logfiles in the archive log. But the backup only managed to complete about 450 GB of the database, which is around 1 TB before TSM stopped again. Now the active log and archive log is full and my failover archive log is about 65% full.

My question; The size of my active log is 128 GB and since tsm isn't running at the moment. If my failover path has enough space for all pending transactions from the active log to complete and move to the failover path. Will i be able to start TSM again or will the active log continue to write transactions even when TSM is stopped? (Guessing not, since it sounds quite obvious when i write the question) But a definitive answer would be great.

And worst case; The failover log gets full aswell. Is it possible to delete some of the old archive logs to make room? And if so i guess i should start to delete the oldest ones? And then try to start TSM again and hopefully finish a full database backup. Can you somehow calculate how much room the full database backup will need if the TSM database is around 1 TB? Will it be enough to have the 128 GB of active log empty?
 
PREDATAR Control23

Will i be able to start TSM again or will the active log continue to write transactions even when TSM is stopped? (Guessing not, since it sounds quite obvious when i write the question) But a definitive answer would be great.

And worst case; The failover log gets full aswell. Is it possible to delete some of the old archive logs to make room? And if so i guess i should start to delete the oldest ones? And then try to start TSM again and hopefully finish a full database backup. Can you somehow calculate how much room the full database backup will need if the TSM database is around 1 TB? Will it be enough to have the 128 GB of active log empty?

No activity is written to logs when the server is down.

You cannot delete archive log files.

If you the archivelogfailover gets full before the database backup ends, you will need to follow this: http://www-01.ibm.com/support/docview.wss?uid=swg21668753

If I were you, I'd disable sessions and schedules to buy you more time to run the database backup. To do so, add those 3 lines in dsmserv.opt before starting the server:

NOMIGRRECL (Prevents migration and reclamation from kicking off when the server is started)
DISABLESCHED YES (prevents any schedules from starting when the server is started)
EXPINT 0

Once the server is started, issue: disable sessions

Once the database backup is over, remove the 3 lines from dsmserv.opt, restart TSM, issue: enable sessions.
 
PREDATAR Control23

If you are short on time, run TSM DB backup in multiple session (but it will consume one or more tapes, depends on numstreams).
Active log path will be cleared after starring instance, DB2 recovery will rollback unfinished transactions and clean logs.
In worst case scenario it is possible to remove some archlog files manually but you need to know which ones exactly - DB2 stores in archlogpath some logs created _before_ last DB backup.
 
Top