06-26-2000 04:11 AM
Does anyone have any experience having two or more backups running concurrently? I am interested if it is possible from the OB database point of view, as well as performance expectations on the Cell Manager.
06-26-2000 04:48 AM
i have a 10/588 Libray with three DLT7000 drives which are connected each to a different server.
At 7:00 pm i start three backups and have no problem with it.
My Cell server is a K220 with 2 proc. and 1GB memory and i see no crititals on the system when OB does concurrent backups.
06-26-2000 05:46 AM
06-30-2000 03:51 PM
Omniback can indeed do multiple backups to multiple tape drives - but you are correct in asking if the DATABASE will slow us down or is a constraint.
Often you will find the network is a bigger constraint.
However it is possible that the database is a constraint. There are a few things you can do.
Obviously, you could slow Omniback down, using settings like network load, and concurrency (or fewer tape drives.) this would allow more backups to run at the same time - but each would run slower than it's 'best case.'
You could also lower the database usage by LOGGING less information - our default is to log full path and filename, date, etc... ('log all.') If you choose directories or none - this will reduce the amount of catalog data - and so the database has less to do. The database will also not grow as fast if you reduce this logging.
If your database is smaller, of course access to it is quicker. It will be important then to keep only the data that you really need, and do database maintenance frequently. Don't use permanent protection, purge out unneeded data, do the omnidbutil -writeascii / readascii processes regularly.
If you are running backups from the command prompt (omnib) use the -no_monitor syntax - monitoring sessions need to query the database - the fewer monitoring sessions, the less competition for database access.
The omniback database is a database - if performance is an issue look to things like moving it to a faster hard drive (or hard drives) memory management, and so forth.
Finally - if you keep Omniback so busy that the database LOCKS - you are keeping Omniback too busy - reschedule jobs, log less, etc.
If you do get locking issues, that can be tweaked a bit so that Omniback doesn't hang up prematurely - but it can't really be fixed. Locking issues will slow down Omniback under some circumstances. This is regarded generally as a performance issue, and the advice would be to spread your backups over time, slow them down, etc...
By the way - remember that Omniback is a database. If you add an index to a database, does that improve performance? For some things yes, for other things it slows it down...
Guess what? We improved 3.1. And for some things it is slower - it is more noticably slower if you are upgrading from 2.55.
As always..check patches. There is a performance issue for OB II 3.1 addressed in a current patch.