IBM Service saying this is like the doctor telling you to take two
aspirin and call back in the morning. It can't hurt, it might fix it,
and it'll keep you busy and out of their hair for quite a while. But
this process is SO costly in terms of downtime!
MANY database inconsistencies correct themselves, if left alone. The
reclamation and migration processes are great database fixers.
Consider doing an audit of only your online disk storage pools, which is
MUCH faster. Since the disk storage pools are the new stuff, there is a
pretty good chance (but not a total certainty!) that is where the
problem is. The time savings make it worth trying. The formulas already
posted in this thread still apply, but you are dealing with so many
fewer objects that the time becomes reasonable. (tens of minutes,
compared to days) Migrating your disk storage pools to tape as much as
possible will, of course, shorten this time accordingly. This is
undocumented (YMMV, Standard Disclaimers Apply, and do not cut the tag
off your mattress!) IBM Service told me about this when I complained
about how long a full audit would take, and it fixed my database
problem: DSMSERV AUDITDB DISKSTORAGE FIX=YES followed by all your other
auditdb options such as file=... The undocumented part is the
DISKSTORAGE parameter, telling it to only audit the disk storage pools.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
On Fri, 15 Nov 2002, Michael Moore wrote:
>Robert,
>The reason for the audit, is due to possible corruption in some objects.
>IBM has recommended the Unload/Load/Auditdb to correct these. Right now,
>we are have a way around the problem, but I will need to perform the audit
>eventually.
>
>Thanks for the information!!
>
>Michael Moore
>VF Services Inc.
>105 Corporate Center Blvd.
>Greensboro, NC 27408
>336.424.4423 (Voice)
>336.424.4544 (Fax)
>336.507.5199 (Pager)
>
>
>
> "Robert L. Rippy"
> <robert_rippy@KINDREDHEAL To: ADSM-L AT
> VM.MARIST DOT EDU
> THCARE.COM> cc:
> Sent by: "ADSM: Dist Stor Subject: Re: Whats the
> Risk?
> Manager"
> <ADSM-L AT VM.MARIST DOT EDU>
>
>
> 11/15/02 04:02 PM
> Please respond to "ADSM:
> Dist Stor Manager"
>
>
>
>
>
>
>You are looking at about 6 hours per 1 million database pages with a good
>cushion of extra time. This has been the norm for my load/unloads. Also,
>there is no audit required if the load is successful. The load will correct
>any discrepencies if found. If you have a a 40GB database at 50% util you
>should have around 5 million pages and that would take about 30 hours. But
>it depends on server type also. This is all based on using AIX 4.3.3 and
>Model H50. Use the formula below to tell how fragmented your database is:
>
>Assigned capacity "11000" * (Pct.Util "55.4" / 100 ".554") = Usable Data
>in MB "6094"
>(Assigned Capacity "11000" - Maxium Reduction "3220") - Usable Data in MB
>"6094" = Variance "1686".
>(Variance "1686" / Assigned Capacity" 11000") * 100 = % Fragmented
>"15.327"
>
>The below database is 15.327 fragmented.
>
>Example here:
>Available Assigned Maximum Maximum Page Total
>Used Pct Max.
> Space Capacity Extension Reduction Size Usable
> Pages Util Pct
> (MB) (MB) (MB) (MB) (bytes)
> Pages Util
>--------- -------- --------- ---------
> ------- --------- --------- ----- -----
> 12,000 11,000 1,000 3,220 4,096
> 2,816,000 1,559,099 55.4 62.3
>
>
>Thanks,
>Robert Rippy.
>
>
>
>From: Michael Moore <Michael_Moore AT VFC DOT COM> on 11/15/2002 03:30 PM
>
>Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>To: ADSM-L AT VM.MARIST DOT EDU
>cc:
>Subject: Whats the Risk?
>
>We may need to perform an Unload/Load/AUDITDB process against our TSM
>server. The problem is, I need a good estimate as to how long everything
>is going to take. The powers that be want a good estimate before I take
>the server down before any extended outage. What I was considering to
>determine the time, so as not to impact our production server, is the
>following on our test server:
>
>1. Run a full backup of the production database.
>2. Increase the size of the test database to match production. Production
>= 40gb, Test = 3gb
>3. Restore (DSMSERV RESTORE DB) the production database to the test
>database.
>4. Unload the new test database.
>5. Load the test database.
>6. Run AuditDB against the test database.
>
>I have already ran this process against the current test database, with
>the following results (database = 3gb capacity, 1gb assigned, 24.4%
>utilized):
>
>Unload - 2 minutes
>Load - 20 minutes (long wait on a tape drive - limited resources).
>Auditdb - 12 minutes.
>
>We are running v4.2.2.12, on OS/390 v2.10. I am waiting for v4.2.3 to be
>applied to test.
>
>As far as I can tell, there is no risk to the production environment.
>Unfortunately, I do not have a stand alone LPAR to perform this test. The
>test server and production server run on the same LPAR.
>
>Am I missing anything? Is this too risky?
>
>Thanks for any input that can be provided!
>
>Michael Moore
>VF Services Inc.
>105 Corporate Center Blvd.
>Greensboro, NC 27408
>336.424.4423 (Voice)
>336.424.4544 (Fax)
>336.507.5199 (Pager)
>
|
