顾问给出了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"