Tim,
We archive Oracle databases and redo logs directly to file class. We
have not had this issue to this point - you had better not have jinxed
us! All of our fileclass volumes are predefined, the database uses 30g
vols, the logs 3g.
I looked at the apar you referenced, and my take is that as long as you
have a reasonable hi/low migration threshold, and the server can get a
tape drive when it needs to offload, I don't see where you would reach
the full condition during a backup. Especially in your case where you
are preempting large files direct to tape anyway (using the 2g limit).
We do our migration immediately after the copypool backup. Restores
from fileclass are as fast as disk, and sometimes better if they
multi-thread.
-steve
-----Original Message-----
From: Rushforth, Tim [mailto:TRushforth AT WINNIPEG DOT CA]
Sent: Wednesday, February 02, 2005 4:10 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Clients backing up directly to devtype FILE
We have a Storage Pool hierarchy like:
DISK Stgpool (nolimit) --> FILE Stgpool (2GB limit) --> TAPE Stgpool
(nolimit)
Clients backup directly to DISK, files smaller than 2GB migrate to FILE
stgpool, everything else migrates to TAPE.
Clients backup overnight and we start migration from DISK at the end of
the workday so that recent backups are all on disk.
One problem with this is that client restores from DISK from previous
nights backup are limited to one session. We could migrate earlier in
the day but then the larger last nights backups would be on TAPE which
we don't want.
One solution to this is to change the initial DISK Stgpool to type FILE.
APAR IC36524
(http://www-1.ibm.com/support/docview.wss?rs=663&context=SSGSG7&dc=DB550
&q1=maxsize&uid=swg1IC36524&loc=en_US&cs=utf-8&lang=en) indicates that
device type DISK should be used as the initial stgpool.
Just curious if anyone is using DEVTYPE File as the initial stgpool and
what experiences they have with it.
Any other suggestions to improve this setup?
Thanks,
Tim Rushforth
City of Winnipeg
|
