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:[EMAIL PROTECTED] Sent: Wednesday, February 02, 2005 4:10 PM To: [email protected] 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
