What do you mean by "partial"? If you mean only the online disk storage
pools with
dsmserv auditdb diskstorage fix=yes
I just did one of those on Friday, with a 40GB database. What determines
the time with the diskstorage parameter is the size and fullness of your
online disk storage pools. I migrated as much as possible first, and it
only took 30 minutes.
As for a full auditdb, I am thinking of scheduling one for the week
between Christmas and New Years whether I need it or not, because that
is the only time in the year I can afford that kind of downtime. The
estimate of one whole week of downtime for a 30GB database is probably
accurate. Because of this horrendous time requirement for auditdb, we
haven't done one in 6 years, since back when ITSM was called WDSF. It
took a week, with a much smaller database, but on a much slower
computer.
My medium-term strategy for dealing with this is to split my server into
multiple images of ITSM. My goal is to have no database larger than
10GB. This strategy also has advantages in much easier database backups
requiring much fewer tapes, by backing up the databases to one another.
These images might or might not be running on the same physical machine.
I hope I don't run into licensing issues for a strategy that is purely
to address RAS issues (especially Availability and Serviceability) in
the product.
My longer-term strategy for dealing with this is quite simply to buy the
fastest computers, with the fastest disk drives, possible to run the
ITSM server, and to get systems that contain fewer, faster processors,
as opposed to more, slower processors, within the same budget. This also
means avoiding RAID5 disk, which is slower than JBOD, for a randomly
accessed thing like the ITSM Database. There are certain constrained
processes, like auditdb and expiration, where you simply need raw
computing muscle. Faster disk drives are in my budget for next year.
IBM's strategy for dealing with this issue has been too one-dimensional.
They have only addressed the Reliability part of RAS, by fixing bugs and
other issues that cause you to need to do a dbaudit, so that you need to
do it less frequently. They have done well in this area. My colleagues
who run big databases for other purposes are awestruck at the activity
level and reliability of the ITSM database, which in sheer transaction
rate is the busiest database in the whole university enterprise. But
given that ITSM is such a database driven system, the A and the S in RAS
are being overlooked a bit when there is a periodic need to do something
requiring a week of downtime.
HEY IBM: This is an issue you've got to address with this product. The
need to periodically audit, and/or unload/reload, the database arises.
But the downtime required for those processes is unacceptable - on the
order of a week for an average sized ITSM system. We can afford several
hours, but not a week, of downtime.
Zoltan: Sorry for straying off the topic, but it's a Sunday morning and
I'm sitting here at home with a warm cup of tea, so the mind will
wander. In summary, if your audit will be limited by being a
"diskstorage" audit, go ahead. It won't take too long, especially if you
migrate beforehand. A couple of hours is more than enough. But once you
get into the tape storage pools, start thinking about taking many days.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
============ "In theory, theory and practice are the same, =============
========= but in practice, theory and practice are different." =========
On Sat, 7 Dec 2002, Zoltan Forray/AC/VCU wrote:
>This doesnt make me feel very "warm and fuzzy" since I am about to do an
>audit, per IBM's request to resolve an issue with EXPORT.
>
>My DB is close to 30GB and we have an average to low MP3000 (only 1-CPU).
>
>I have alloted 2-3 DAYS outage for my audit.
>
>Per IBM's recommendation, I am only doing a "partial" audit so it should
>not take as long as a full audit, I HOPE !
>
>
>
>
>
>Schaub Joachim Paul ABX-PROD-ZH <joachim.schaub AT ABRAXAS DOT CH>
>Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>12/04/2002 03:06 PM
>Please respond to "ADSM: Dist Stor Manager"
>
>
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: AW: How long for auditdb
>
>
>Nowbody nows!
>
>It is recomended to keep the DB Size > 10GB ?
>
>I have seen DB Audits run on strong Z/OS LPAR's about one week (DB Size
>25GB).
>The calculation factors are many. It exists a high variability, different
>client platforms, filesize, definitions under the policy domain, etc.,
>etc...
>Split the Audit in its Subparameter, good Infos on the List.
>
>regards
>
>joachim
>
>-----Ursprüngliche Nachricht-----
>Von: brian welsh [mailto:brianwelsh3 AT HOTMAIL DOT COM]
>Gesendet: Mittwoch, 4. Dezember 2002 20:47
>An: ADSM-L AT VM.MARIST DOT EDU
>Betreff: How long for auditdb
>
>
>Hello,
>
>AIX 5.1 (H70, 1 GB memory, dual processor), TSM 4.2.2.8, NSM Model C01.
>Database 20 GB (36 GB utilized for 55%).
>
>I know it was on the list before, but I'm wondering if someone recently
>did
>an auditdb and can tell me the time it took.
>
>After reading the messages posted on the list I can't believe that an
>auditdb took so long, and all the time TSM-server is halted.
>
>In this time and in our organization it's impossible to halt the
>TSM-server
>for example 20 hours or maybe more.
>
>Hope to get some reaction, so I can estimate how long the downtime will
>be.
>
>Thanks,
>
>Brian.
>
>
>
>
>_________________________________________________________________
>Chatten met je online vrienden via MSN Messenger. http://messenger.msn.nl/
>
|
