| Is the database on a file system or raw device? If a
file system, which one? If a file system, is the data
reasonably contiguous?
Any backup will first be potentially limited by how fast
you can read data off the disk. For sequentially reading
data UNIX file systems can read a bit faster than from
a raw device, because the file systems support read-ahead
(I know UFS does, I'm pretty sure AdvFS does). But, if the
data is not well organized, what read-ahead there is will
limited by how large the reads will be.
The next potential limit is the bus bandwidth. If the arrays
are on the same HSZ then the SCSI bus can be a limit. In a
perfect world Fast/Wide SCSI-2 is capable of 20 MB/sec. With
the arrays on the same HSZ neither will likely get more than
half and it does, the other loses. While the array may support
higher bandwidth, the controller and host connection may not.
The next and most likely limit is writing to the array. RAID-5
writes are well known for being slow. The cache will help for
a few seconds, but after that you're limited by how fast you
can write to the array. Depending on how you move the data
if the HSZ sees relatively large write requests it can use the
RAID-3 write algorithms, which are better for sequential writes.
Unfortunately, the HSZ limits I/Os to 64 KB, so you're dependent
on the cache to collect enough data to write in larger swaths.
For a single large file on UNIX or a raw file system, dd(1)
is probably the simplest thing to use. It will let you set
the block size, which can be larger than the 64 KB limit of
the HSZ, since the driver *will* crave up the larger requests
into smaller ones. If using a raw device you'll probably need
to use a block size that is a factor of the device size. My
guess is that your performance will be write limited. I don't
recall what the RAID-5/3 sequential write performance is like,
but it could easily be better than that of an TZ88.
|
| If you use NetWorker Save and Restore and its Data Module for
Oracle, you can backup multiple data files or multiple raw
partitions in parallel. These parallel streams can be directed
to multiple tape drives. You also have the ability to backup the
database while it is online (in archivelog mode).
If you use multiple tape drives, you'll probably be limited by
your ability to read data from the source RAID set.
Start with DECWET::NETWORKER (dir/title=dmo) and the SPDs (50.98,
64.46) for more information. To see what a near-term future
release can do, see http://www.legato.com/press/digora_pr.html
Wes Ono
NetWorker Engineering
|
| ref.1
some clarifications :
1. The customer uses AdvFS and the database would normally
have few, large files.
2. All the disks will be connected to a single HSZ40.
3. There is a single TZ87/TZ88 drive available as an
alternate to disk backup.
I have seen single DLT backups (on a turbolaser at a different
customer site) at a speed of 5gb/hr (tar) to 7gb/hr (dump).
How would the disk backup in note .0 compare with this,
what kind of backup speed can be expected, say with dd or
dump.
Ajit
|
| Hi
Without more data or a test, it is not possible to know.
At 5 gig/hour that is 1.5 MB /sec...and 7 gig an hour is is aroun
2.2 MB/sec...that is pretty much tape speed depending on a bunch
of factors...the disk has to be doing that much I/O also...
In theory, the HSZ can do 8-12 MB second...so in theory if this is
I/O bound, the tape is the bottleneck. You could backup to disk, or
use another tape drive....I would suggest the tape drive myself
as the disk backups still don't give you the ability to move it
away from the machine (and the HSZ).
regards
Eric
PS: I agree with .-1, use NetWorker.
|