Been there, tried that, no go ;-)
unfortunately, Richard is right, only with devclasses of type
server... As to why? well, probably some developer could enlighten
us ;-)
On 19 nov 2008, at 14:04, Bos, Karel wrote:
Try
delete volhist todate=today type=dbb volume= force=yes
Or sometihing like
Try
delete volhist todate=today type=dbb volume= force=yes
Or sometihing like that.
Regards,
karel
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Remco Post
Sent: woensdag 19 november 2008 10:11
To: ADSM-L@VM.MARIST.EDU
Subject: del volhist?
H
On Nov 19, 2008, at 4:10 AM, Remco Post wrote:
tsm: server>del volhist todate=today t=dbb dev=drm
ANR6978E DELETE VOLHISTORY: Invalid device class UNKNOWN.
The message could be more helpful, but per the manual, DEVclass can be
used on the command only if the device class type is SERVER.
I wou
Is there something other than 'del volhist' that trims the volhist file? The
oldest entries in my volhist are 30 days but if I search actlog I don't find
any sign that a 'del volhist' command was run.
>>> [EMAIL PROTECTED] 04/13/05 9:31 AM >>>
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTEC
Another good idea for my current TSm database.
Not being the GURU that most are in here .
How do I get the definitions of what each command below is going to do for
me. I am familiar with the first two but the later I am not.
Regards
Paul Giglio
EMI CAP music
-Original Message-
From: ADSM:
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On
Behalf Of David E Ehresman
>If one uses DRM to expire data base backups, should one still routinely
>do a "del volhist type=all today="? Why or why not?
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On
Behalf Of Talafous, John
Using the "del volhist" command in conjunction with DRM may potentially
cause deletion of DB backup tapes that are vaulted. Hence, TSM DRM will
not process the volume via vault retrieve.
If you do both, be sure your "DRM DB Backup Series Expiration Days"
value in DRM is less than the TODate val
Yep, increasing the recovlog is doing the job. Thanks to all! Thanks for
not just saying RTFM too. I really do plan to read it front2back when I
get some time to do so. I need 3 months off just to read the 100 or so
manuals I want to absorb better. A well planned setup saves time, I do
know that.
A
Alexander,
TSM won't let you delete those volumes since they are all part of the
most recent DB backup set.
It appears that you are doing incremental DB backups at random times
which indicates that the DB backup trigger is causing these backups.
The DB backup trigger happens when the log space star
Is your database in "roll forward" mode or normal? If it's in roll
forward, what's your database backup trigger set at? You may simply be
filling the log to the trigger, making incremental backups happen. If this
is what's happening, maybe you could expand the size of your log?
[EMAIL PROTECTED]
HEre's the output:
tsm: TSM>q volh t=dbb
Date/Time: 03/21/2005 11:00:48
Volume Type: BACKUPFULL
Backup Series: 112
Backup Operation: 0
Volume Seq: 1
Device Class: LTOCLASS1
Volume Name: ITG044L2
Volume Location:
Command:
Date/Time: 03/24/2005 18:16:08
Alex -
You need to follow through by doing: Query VOLHistory Type=DBBackup
It may be that all the dbbackups are in the same, latest series, and
the last series must remain.
And, certainly, you need to look into why all the dbbackup tapes are
being produced. They are probably incrementals, suggesti
It would help if we could see the output of the following command:
q volh t=dbb
It might be that this is the most recent DB backup in which case it
won't let you delete it.
--
Regards,
Mark D. Rodriguez
President MDR Consulting, Inc.
=
13 matches
Mail list logo
