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 [EMAIL PROTECTED] ============ "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 <[EMAIL PROTECTED]> >Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> >12/04/2002 03:06 PM >Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]] >Gesendet: Mittwoch, 4. Dezember 2002 20:47 >An: [EMAIL PROTECTED] >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/ >
