Errors ANR2371E and ANR2034E

stetsip

ADSM.ORG Member
Joined
Nov 14, 2012
Messages
13
Reaction score
0
Points
0
Hi,

I have the following errors in TSM:

ANR2034E: QUERY SPACETRIGGER: No match found using this criteria.

ANR2371E: QUERY DBBACKUPTRIGGER: Database backup trigger is not defined.


How can i fix these errors?

Thank you in advanced!
 
From the message it appears that someone issue q spacetrigger and q dbbackuptrigger.
The error is due to no spacetrigger or dbbackuptrigger define.

How can i fix these errors?
You have three solutions.
1. Ignore the message.
2. Do not issue the q spacetrigger and/or q dbbackuptrigger command.
3. Define a spacetrigger . Do you know what the spacetrigger will do?
Not sure what version of TSM Server that your running.
With 7.1 there is no define dbbackuptrigger.

Good Luck,
Sias
 
From the message it appears that someone issue q spacetrigger and q dbbackuptrigger.
The error is due to no spacetrigger or dbbackuptrigger define.


You have three solutions.
1. Ignore the message.
2. Do not issue the q spacetrigger and/or q dbbackuptrigger command.
3. Define a spacetrigger . Do you know what the spacetrigger will do?
Not sure what version of TSM Server that your running.
With 7.1 there is no define dbbackuptrigger.

Good Luck,
Sias
Hi,
Thank you for your reply.
I have TSM version 5.4.
I dont know what spacetrigger does...
Probaply the schedules installed issue q spacetrigger and/or q dbbackuptrigger command...
If i dont define a spacetrigger it will ok?

Thank you
 
I have TSM version 5.4.
Okay, so we a running an old version of TSM before the database became a DB2 database.
I am sure that your aware that version have not been supported since 2014.

I dont know what spacetrigger does...
Tivoli Storage Manager allocates more space when space utilization reaches a specified value.
This can be for the database, recovery log and/or the storage pool.

The dbbackuptrigger - A backup occurs when the specified percentage of the assigned capacity of the recovery log is reached.

I am sure someone is going to say "What if its not in roll foreward".
In a nutshell.
With roll-forward mode and an intact recovery log, you can recover the database up to its most current state (the point at which the database was lost).
Normal mode - Does not require a recovery log to restore to a point-in-time. The recovery log keeps only uncommitted transactions, and its size is not affected by normal mode.

Probaply the schedules installed issue q spacetrigger and/or q dbbackuptrigger command...
I do not recall of such action. Unless someone define a schedule that define a trigger.
If you think that there is a schedule that is defining a trigger. Take a look at the schedules and delete that schedule.

If i dont define a spacetrigger it will ok?
You don't have to define the space trigger.
In the event that the recovery log becomes 100% full prior to the subsequent database backup, the application will experience a crash due to insufficient space in the recovery log.
In such a scenario, it is necessary to extend the recovery log (dsmfmt -log file_name size, dsmerv extend log), backup the database, and once the backupdb complete. Restart the server in the foreground to ensure a seamless startup of the TSM Server. Then we halt the application and restart it in the background.
NOTE: The above is just the basic, there are more steps.

NOTE: The max size of the recovery log is 13GB .
The server will not automatically extend the recovery log beyond 12GB.

The spacetrigger will automatically add space to recovery log.
Depending on how we set up the space trigger, if we reach the max limit of the recovery log or we have the recovery log at max limit of 13GB and the TSM Server crash due to the recovery log is 100% full.
Your ONLY solution is to restore the database from the most recent backup.
Do we even know how often the data base is being backed up?

Anyone who remember how to recovery from an over committed recovery log or if I forgot something, please add your 0.02.

Good Luck,
Sias
 
Back
Top