about 2 days (net), and make for a new
DB
taking up about 220 GB (as opposed to the current used space of 260 GB) ...
anyway, I've never run ESTimate DBREorgstats to completion.
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG
Please attach this message's subject to my preceding message, erroneously titled
Re: ADSM-L Digest - 26 Jun 2012 to 27 Jun 2012 (#2012-151).
Thanks,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
[which reminds me of the urgent need to start collecting
pertinent statistics from elsewhere :-]
((Please notify me of your questions opinions by e-mail -
I no longer find the time to regularly scan all of ADSM-L)).
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49
-restore tends to help _me_
(newer GUIs have it in the -Restore-Options menu).
BTW, file spaces with millions of files are common here, too ;-)
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
:-() -TESTFLAGS=DISABLENQR
~because~ the (now documented) option meanwhile is called -DISABLENQR=YES.
So one should try
RESTORE ... -DISABLENQR=YES
first, and if the client is old enough to reject that, use -TESTFLAGS
(or -TRACEFLAGS with real ancient clients).
Best regards,
Wolfgang J
occasional additional incremental exports ala (4), and - only
when successful - advance STARTDATE STARTDATE accordingly,
prior to the first backup of CLIENT to SERVER-B.
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
(with Logmode = Normal) - that's about
the same as under previous versions (that's 5.5.3.0 and 5.5.2.1).
So far (and that's since V3.7), the habit of installing server versions
from the patches hierarchy when possible, didn't hurt us here ;-).
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel
, however, once nothing is
mounted,
TSM takes the (normally empty) mount point directory for the root of the file
space,
so it does not indicate an error during backup, but will duly inactivate all
files
of that virtual file space ...
Beware!
Best regards,
Wolfgang J. Moeller moel
issuing
critical clean me tape alerts like mad.
Guess its heads have been worn off for some time ...
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
memory growth
(as it happens, this machine also has lots of unrelated LDAP client load).
It is rumored that various LDAP clients based on the same open source
exhibit this behaviour, and apparently the bug isn't fixed yet. Watch out!
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49
Server (14.4) lists...@vm.marist.edu
To: Wolfgang J Moeller moel...@gwdg.de
Subject: Re: get ADSM-L LOG1012 (8th attempt)
get ADSM-L LOG1011
get ADSM-L LOG1012
get ADSM-L LOG1101
thanks
You're welcome!
Summary of resource utilization
[...]
... I receive ADSM-L LOG1011 and ADSM-L
I didn't keep notes about the statistics back then.
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
heuristically) doing away
with silly continuation lines, decimal commas, etc. :-)
Happy hacking,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
(which they did up to 5.2).
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
not follow symlinks at all.
[...]
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
Robert Clark writes:
Dumb question, but have you examined the client to see if there are any
circular links?
(For example a link low in the tree that points higher in the tree.)
To a first approximation, this doesn't seem to be the problem -
I can see the extensive memory usage even with a
directories.
And did you ever see _cumulative_ memory growth (aka memory leak?).
There got to be something pretty weird with this machine ...
I'm still working with TSM support.
On 07/07/10 01:19, Wolfgang J Moeller wrote:
Good morning,
on a (real big!) x86_64 machine, with freshly installed SuSE
) client versions, unless it was known
that a recent 6.x version did indeed solve a problem of this kind ...
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
2WEEKS keeping its files for 10 years ... but sure it's possible.
Regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf
have to REMOVE NODE more often than the average TSM operator,
in order to see such things. [You'd also better(?) have some tool
in addition to TSM SELECT in order to spot all of this weirdness. ;-]
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516
Clients ?
5.- Last question, in order to restore the client node. Are there differences
between these procedure and multiplexing competitors ones ? ...
[...]
Can't contribute to these two questions.
Best regards,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516
for its output which (heuristically) normally does away
with those silly continuation lines, decimal commas, etc. :-)
Happy hacking,
Wolfgang J. Moeller moel...@gwdg.de
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
TSM server 5.5.2.1 on AIX 5.3 - watch this:
==
tsm: SMq pr
Process Process Description Status
Number
-
791 Space ReclamationVolume GU0405 (storage pool L32POOL), Moved
Does anyone have a script that will show the volumes associated with a
collocation group?
select distinct vv.volume_name from nodes nn, volumeusage vv -
where nn.collocgroup_name=upper('$1') and vv.node_name=nn.node_name
You DON'T want to use the collocgroup table.
Wolfgang J
determined.
Now my long term averages are in: for the interesting (V5.5) TSM servers
around here, the Log Consumption ranges from 5000 to 9000 MB/day.
So, does this tell me anything about future (V6) Log Space requirements?
Wolfgang J. Moeller @ GWDG Goettingen, Germany
25 matches
Mail list logo
