Many factors influence backup time. An optimistic minimum backup time
can be estimated by examining your hardware environment and determining
the speed of the slowest component of the backup process. Divide the
volume of data by the transfer rate for this component and you will have
a minimum time, assuming you can saturate the capacity of that component.
As a general rule, log parameters should not impact backup duration
because backups are not logging normal database changes.
You also didn't indicate what version of DB2 you are using.
An example that is impractical for production:
Database: locally attached IDE disk drives on RAID 5 type adapters.
Transmission: 100mbit ethernet
Backup: Large storage appliance using multiple disk drives.
1. IDE drives can read data at 100mByte/second
2. Storage appliance using multiple disk drives will at least equal IDE
3. Ethernet can transmit 12mByte/second (an optimistic number)
The ethernet connection will be the slowest component.
2t/12m = 174763sec = 48.5+ hours
Note that if your ethernet thruput is 50% of maximum; this will increase
the duration to nearly 100 hours!
Backing up to a duplicate set of locally attached disk drives would take
at least 6 hours using these figures.
Current mainframe technology has mechanisms for taking a snapshot of
disk drives which can cut backup interference times to minutes or less.
Once the snapshot is taken; the backup is run against it and its
duration is not a critical factor to database availability. This type of
technology may also be applicable to your environment.
Philip Sherman
Kums wrote:
How much time does it take to backup a datbase of size 2 terra byte?
Can you specify the tool you use, technique and registry variables
with values for your system, so that I get an idea?
How many tablespaces, and what are the sizes of those(rough figures
would suffice).
logbufsiz
TSM management class
TSM node name
logfilsiz
logprimary
logsecond
pasting sample userexit will be helpful.
