顾问给出了QAD的答复,这个问题,早有人提出了
全是E文,研读中
How to probkup database > 2GB to specific volume sizes ?
Fixes:
When the situation arises that:
- a backup is about to exceed the capacity of the largest backup media
available to that user (for example: a 40/80GB DLT), or
- when backing up the database, it will span more then one tape or file,
implementation of of a multi device backup needs to be considered.
To manipulate the tape or specify the next file, when Progress (using a
probkup) asks for the next volume however, Progress simply waits for
confirmation that it can proceed. Manually entering the next device or
switching tapes, is not always possible, as this process is (usually)
unattended.
In cases such as these, it is necessary to automate scripts so that it is
not necessary to manually enter the key strokes that are needed to continue
with the backup procedure. Arranging the unattended load of the second media
is discussed in this Solution.
To assist in automating this procedure, the probkup utility must be run
interactively (at least once) so that the necessary keystrokes can be
captured and recorded. Once the keystrokes have been recorded, they can be
entered into a text file and redirect into the probkup procedure as follows:
probkup dbname /dev/rmt1 -vs n < input.file
WHERE:
+ dbname is your database name,
+ /dev/rmt1 is the first backup volume to be created
+ -vs parameter indicates the volume size - that is, the number of blocks
that can be written to each volume.
Previously, in V7 and before, the default block size on the OS dictated the
database block size, hence, the OS blocksize was the database blocksize. The
introduction of variable block size in V8 (and higher), the -vs parameter
value now references the database block size, where units are in in database
blocks, not in Kb or Mb. In the case of tape devices, the value of n should
be set lower than the size of the tapes that are being used and greater than
the blocking factor (-bf) depending on the database block size (and the
number of Storage Areas in Version 9 and above). In the case of files, it
should be set to the considered available physical file size divided by the
database block size.
Similarly, in cases where the first tape or volume size (if backing up to a
file) has been filled and it is necessary to use a new device name or file
name, this methodology can also be employed. In such a circumstance, a new
device/file name will be prompted for as follows:
Please enter next device/file name or type "quit" to exit:
At this point, either a different file name or a device name needs to be
indicated. If the same device name is entered without changing tapes, the
backup will be overwritten. It is therefore also necessary to change tapes
or enter a different device name that has been prepared for the remaining
portion of the backup. Please note, that once this procedure has passed its
first run, it is HIGHLY recommended to follow this proofing by restoring
this backup to ensure that it was successful.
This input.file may be as simple as one line. In the following example,
however, assume that the backup is going to span 4 tapes and there are 4
different tape drives that output can be sent to.
The input.file would then read as follows:
************************ input.file ******************************
/dev/rmt2 (hard return)
/dev/rmt3 (hard return)
/dev/rmt4 (hard return)
(hard return)
************************ End of File: input.file *******************
In other words, after the initial probkup command (as displayed above) has
been executed, the next device or file name has been prompted for 3
additional times. By including the NEXT 3 devices, the input file will send
the input to the next prompt made by the probkup utility. Bear in mind that
after each new device/file name a hard return must be included in the input.
file in order to continue. The first device/file name is provided on the
command line when executing the probkup utility initially.
To restore the multivolume probkup, the exact reverse methodology is
employed, viz:
prorest dbname /dev/rmt1 -vs n < input.file
Please note, if restoring over an existing database, a "y" yes prompt will
need to be added to the "input.file" to automate the response.
Please keep in mind that it is highly recommended that this procedure is
fully tested and documented prior to implementing it into a production
environment.
Notes:
References to Written Documentation:
For additional information on this topic and an example of how to backup a
database exceeding 2GB to a multiple files please refer to:
17530, "How to PROBKUP/PROREST a DB larger than 2Gb to disk files"