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)
|
