Hello Curtis
That may be irrelevant, if the other streams are still in the queue when all the
streams that are running finishes, switching the database out of hot mode till
the other streams come out of the queue may be acceptable depending on how the
streams were configured. Ultimately, to minimize time in the "hot" mode and
overhead, some sort of filesystem freeze should be used as is available from
Veritas Filesystem or Sun's old Backup Copilot product.
Besides multi streaming an individual server is a pointless exercise if your
site is large enough to have enough simultaneous sessions from different servers
to begin with. It's the old parallel processing performance problem, too fine
a granularity will not actually amortize the overhead required. If you have
more database servers to backup than the number of streams that you are willing
to allow to your storage units concurrently, there's no point in
multi-streaming. Also, if the database is distributed across a RAID, the RAID
hardware will hopefully already have squeezed out whatever performance gain that
could be had by parallelism making multiple streams a moot point, if the
database is all on one volume, multi-streaming will slow it down and with modern
disks going towards monolithic drives with very few platters, any kind of
parallelism will likely slow it down as more data is now on the same physical
device.
The only thing I use multi-streaming for is when I have an unreliable link.
That way, the backup is broken up into smaller backups that would not invalidate
each other when a problem does occur ie.: if the link temporarily goes out, only
a small piece needs to get requeued rather than the whole thing. In this case,
I would also constrain the class to a limited number of concurrent jobs in order
to limit the number of segments disrupted by a network blip. Other than for
that use, I consider multi-streaming to be just plain evil. The only problem I
have there is that I have to increase the period of time, jobs are allowed to
remain in the queue for and that can only be done globally rather than on a per
class basis, wish Veritas would change that...
Now, arguably, there may be cases where a specific server is so critical that
they want to be able to dedicate all resources to that server during the backup
period. At that point, my view is that they need a more robust filesystem like
Veritas Filesystem and perhaps a local tape changer and drives if the need for a
short backup window is so critical. Playing with multi-streaming will just
accommodate that server at the expense of overall capacity.
Regards,
John I Wang
Sr. Systems Engineer
Steverson Information Professionals
---
Enron Networks
Enron Building room 3427e
ph (713) 345-4888
cell (832) 493-1263
fax (713) 646-8462
pg pagejwang AT skytel DOT com or 1-877-390-4155
|--------+------------------------>
| | curtis@backupc|
| | entral.com |
| | |
| | 06/20/01 06:39|
| | PM |
| | |
|--------+------------------------>
>--------------------------------------------------------------------|
| |
| To: morms AT es DOT com |
| cc: veritas-bu AT mailman.eng.auburn DOT edu, (bcc: John |
| Wang/Contractor/Enron Communications) |
| Subject: RE: [Veritas-bu] Re: start notify and multiple |
| data streams |
>--------------------------------------------------------------------|
This is a nice idea except for one thing. It doesn't account for jobs that
are in QUEUED. If a job is queued, it will not have a stream_number
yet. In fact, it won't even have a process on the client yet.
That's why we use bpdbjobs to check for queued jobs. Check out:
http://www.backupcentral.com/bpstart.workaround.tar.gz
At 05:09 PM 6/20/2001 -0600, you wrote:
>Xu,
>
>I am in the process of testing a script to deal with this issue. This
>start_notify script uses 'if STREAM_NUMBER=1 then' <put our database in hot
>backup mode>. Each stream that starts creates it's own tmp file named
>stream"$STREAM_NUMBER".active. Each stream that ends deletes it's own
>stream"$STREAM_NUMBER".active file and looks for any others. If any other
>.active files exist, the script just exits, otherwise, it brings the
>database out of hot backup mode.
>We will set up a cron job to pull the database out of hotbackup in the
>mornings and clean up any leftover .active files just in case the end_notify
>fails for any reason.
>
>Good Luck,
>Melinda Orms
>Evans & Sutherland
---
W. Curtis Preston
Principal Consultant for Storage Designs, your storage experts
Webmaster: http://www.backupcentral.com Phone: 760 631 7991
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
