Although your cache hit pct is great, the most obvious thing I see is that
you just have ONE physical volume for this size DB! Spreading this size
DB out over multiple volumes will probably increase your performance.
David B. Longo
System Administrator
Health First, Inc.
3300 Fiske Blvd.
Rockledge, FL 32955-4305
PH 321.434.5536
Pager 321.634.8230
Fax: 321.434.5509
david.longo AT health-first DOT org
>>> ldahl AT JPL.NASA DOT GOV 03/25/04 03:38PM >>>
Hi Mark,
Output from q db f=d:
Available Space (MB): 118,780
Assigned Capacity (MB): 70,000
Maximum Extension (MB): 48,780
Maximum Reduction (MB): 15,924
Page Size (bytes): 4,096
Total Usable Pages: 17,920,000
Used Pages: 11,215,255
Pct Util: 62.6
Max. Pct Util: 77.3
Physical Volumes: 1
Buffer Pool Pages: 32,768
Total Buffer Requests: 2,151,221,843
Cache Hit Pct.: 99.04
Cache Wait Pct.: 0.00
Backup in Progress?: No
Type of Backup In Progress:
Incrementals Since Last Full: 0
Changed Since Last Backup (MB): 2,785.80
Percentage Changed: 6.36
Last Complete Backup Date/Time: 03/24/04 17:33:13
This is the standard amount of expiration we see:
03/14/04 17:27:07 ANR0812I Inventory file expiration process 1692
completed:
examined 23194393 objects, deleting 1690917 backup
objec
cts, 0 archive objects, 0 DB backup volumes, and 0
recov
very plan files. 0 errors were encountered.
This is currently running:
Process Process Description Status
s Number
-------- --------------------
-------------------------------------------------
26 Expiration Examined 22853888 objects, deleting 20518954
bac
ckup objects, 0 archive objects, 0 DB backup
vo
olumes, 0 recovery plan files; 1 errors
encount
tered.
I don't think the policies were correctly expiring data prior to the
upgrade. We've had numerous nodes that seemed to be storing much more than
their policy dictated. We tried to force expiration on the files and it
didn't seem to make much of a difference. Unfortunately we've been tweaking
policies and trying to force a lot of data to drop off prior to the upgrade
so I can't point to any particular reason why expiration is now expiring so
much data. You can see the db size has dropped as well due to the
expiration - and we performed an unload/reload less than a month ago prior
to the upgrade. Being the db volume is one volume it could be disk
contention, but it's a raw volume fiber attached (Sun T-3's).
Luke
"Stapleton, Mark" wrote:
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Luke Dahl
> > We upgraded our TSM Server (Solaris 9) from 5.1.6.4 to 5.2.2.1 last
> >week. Prior to the upgrade our expiration usually lasted about 24
> hours
> >(53Gb database). It would generally post results like this: examined
> >16446439 objects, deleting 59582 backup objects
> >Our 3494 library showed est. capacity of 60Tb and approximately 88 pct.
> >util.
>
> What is your db's cache hit ratio? 24 hours for a 53GB database is
> manifestly too long. It should get through expiration in 2-3 hours. Give
> us the output from Q DB F=D.
>
> >Any idea why expiration wasn't running properly prior to the upgrade?
> >Data integrity looks good but we've just cleared out loads of space. I
> >don't recall a known bug in expiration processing in 5.1.6.4 but may
> >have missed something. Thanks for your thoughts and input.
>
> How, exactly, did you "clear out loads of space"?
>
> --
> Mark Stapleton
##############################################################
This message is for the named person's use only. It may
contain confidential, proprietary, or legally privileged
information. No confidentiality or privilege is waived or
lost by any mistransmission. If you receive this message
in error, please immediately delete it and all copies of it
from your system, destroy any hard copies of it, and notify
the sender. You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message
if you are not the intended recipient. Health First reserves
the right to monitor all e-mail communications through its
networks. Any views or opinions expressed in this message
are solely those of the individual sender, except (1) where
the message states such views or opinions are on behalf of
a particular entity; and (2) the sender is authorized by
the entity to give such views or opinions.
##############################################################
|
