Hi Richard,
My device class for the storage pools is DISK and I have read that it is
better to use a device type of FILE when using ATA disk. Is this true and
if so, how can I correct this? Our disk is EMC ATA Raid-3. We thought to
get cheap disk as a landing spot for our backups and then do a quick sweep
to tape, but I'm really hurting here and we also have a data center move
coming up so this is crucial for that move.
I have the caching of the migrated files turned off. I believe that this
is the only place that caching comes into play with TSM? I thank you for
your help and any suggestions!!!
Storage Pool Name ORACLE
Storage Pool Type PRIMARY
Device Class Name DISK
Estimated Capacity (MB) 1032192.0
Pct Util 96.2
Pct Migr 96.2
Pct Logical 100.0
High Mig Pct 70
Low Mig Pct 60
Migration Processes 3
Next Storage Pool TAPE_ORACLE
Maximum Size Threshold -
Access READWRITE
Description Oracle Disk Storage Pool
Overflow Location -
Cache Migrated Files? NO
Collocate? -
Reclamation Threshold -
Maximum Scratch Volumes Allowed -
Delay Period for Volume Reuse -
Migration in Progress? YES
Amount Migrated (MB) -
Elapsed Migration Time (seconds) 143029
Reclamation in Progress? -
Volume Being Migrated/Reclaimed -
Last Update Date/Time 2005-08-16 20:30:16.000000
Last Update by (administrator) LIDZR8V
Reclaim Storage Pool -
Migration Delay 0
Migration Continue YES
Storage Pool Data Format Native
Copy Storage Pool(s) -
Continue Copy on Error? -
CRC Data NO
********************************
Joni Moyer
Highmark
Storage Systems
Work:(717)302-6603
Fax:(717)302-5974
[EMAIL PROTECTED]
********************************
"Richard Sims"
<[EMAIL PROTECTED]>
To
08/17/2005 08:35 "Joni Moyer"
AM <[EMAIL PROTECTED]>
cc
Subject
Re: Migration Speed Has Plummeted
Joni - Save yourself some grief and check ADSM QuickFacts for caching.
(It's a storage pool option.)
As to the migration performance: You need to do fact gathering as
part of
analysis. With older tapes and drives, you may be encountering
increasing
difficulty in writing blocks on the old tapes, which should be
reflected in
the AIX Error Log, if happening. Disk transfer speed may be related
to how
it is set up (RAID type, etc.). Disks which the OS vendor (IBM) doesn't
recognize may receive too-small queue limits. Here is one of my AIX
notes:
Disk performance Disk controllers typically
afford some
nice degree of parallelism
in order to
improve performance/
throughput. Vendors
tend to be parochail - or at
least play
it safe... If you attach an
IBM disk to
AIX, it sets attributes to a
nice number
for Queue Depth; but if you
attach a
non-IBM disk to AIX, it goes
max
conservative, limiting Queue
Depth to 1,
causing performance to suffer.
Ref: AIX doc "Setting SCSI-
Adapter and
Disk-Device Queue Limits"
System performance can
essentially
freeze if, for example, disk
formatting
is occurring on the Shark,
and system
paging space is also on the
Shark.
In AIX5, some settings you
can make:
1. Change maxperm, minperm
(away from
their default setting of
75, 25).
Possibly, lower maxperm
to 24,
minperm to 12.
2. Turn on I/O Pacing -
judiciously, as
it can also hurt
performance.
A simple way of testing disk
speed is
to time how long it takes to
write a
file of a given size, as via
command:
time dd if=/dev/zero bs=64k
count=1000
> /Some/DiskFile
where the count value may be
increased
as needed.
See also: minperm, maxperm;
Queue Depth,
disk attribute
Also, if you fall behind in migration, things just get worse as disk
fragmentation occurs, and the arm gets frantic exercise seeking all
over the
place for its next file block as a lot of distributed space on the
disk is
occupied by lingering data. This is one of the reasons that caching
is a
performance hit.
Richard Sims
On Aug 17, 2005, at 8:19 AM, Joni Moyer wrote:
>
> How do you know if caching is turned on? How/where can you turn it
> off? I
> am having lousy migration speed perfomance as well. What can I look
> at/change? I have an AIX 5.2 server at TSM 5.2.4.0 with LTO2 tape
> drives
> attached. Thanks!
>
