OmniBack Cell Manager

[Simon Hargrave]

People

I currently have an OmniBack cell on HP/UX which is getting to it's maximum size. I'm going to split it into 2 cells handled by MoM.

My intention is to buy a Cell Manager for NT, and move some of the cells over to there for management.

My question is, given that the Cell Manager for NT is 1/4 the price of the same for UNIX, is it limited in any way, or is it just as capable provided the hardware is up to it?

Also, any official word on release 4.0? I suspect this might solve the problem because this is more efficient than 3.5 for database size, but I need to expand its use like now!

Cheers



Sy

[Shannon Petry · Accepted solution]

Hmmm I thought that the NT Windblows version and UNIX version were the same price...I'll have to talk to my HP rep, cuz I may have been ripped off!


Anyway, I moved a Cell Server from UNIX to NT, then had to move it back to a different UNIX box. The big problem was performance, the second problem was that it would fail on host lookups about half the time.

I called HP about this, but because there is no nsswitch, or way to define how hosts are resolved, there are loads and gobs of problems. I even made winnt\system32\drivers\etc\hosts and included all my hosts their, and that did not work.

the MS mentality is to use WINS (even craptive directory prefers to issue WINS lookups over strict DNS to any request). So this way, if it's internal you never know what the helk your gonna get!

Needless to say since performance of DISK->TAPE was less than 50% what it was on UNIX even for windows clients, and the backup's only working 50% of the time, I put it back on UNIX!


For size problems, I would recommend (you may have already done this) you write-ascii then read-ascii on the OBII server to remove junk on the logs. I am usually doing this bi-monthly and have allocated 8 GB for Index and database, and backing up about 1/2TB every month. Anually, I archive the full database, and start over.

Regards,
Shannon

[Dave Wherry]

How large is your database? I recently took the OmniBack class and the instructor spoke of a client who's database was around 16GB. Not recommended, but it works.
I agree that it usually comes down to database management. Purge old records. Check your retention times and your log level. Many people seem to configure backups to report at the Warning level. That just helps to fill the database. Setting that to Major is usually adequate. I inherited my database and many weekly jobs were set with permament protection. Then the tapes would would later be reinitialized and the database kept those useless records.
Before going as far as MoM I would look at database maintenance.

[Clovis Borges_1]

Hello Simon,

If your Omniback is cell_server HP-UX or NT
you do not have limitation.For omniback is it indifferent.

The size for your database is the same for example.

But.....

When you perform backup in NT system you cannot backup up files in look for another aplication,so if the system are using other
process to the same file that you want backup up,you can have much more time for backup.

Other....

If you have much NT system for backup you can have OFM (Open file Manager).
HP has one omniback that work with OFM special to NT system.

Clovis Borges.

[Simon Hargrave]

Cheers.

I'm surprised at the 16Gb database size you speak of - I thought the physical limit was 8Gb? Ours is currently about 6.5Gb, and the problem is that to do an ASCII export/import would take a good weekend to complete, so we can't do it regularly (in fact haven't yet).

I also don't think this'll shrink the database usage too much because the vast majority of it is file versions, and I already purge this extensively.

Problem is too that we have a business requirement to backup Oracle archive logs to tape every 15 minutes, and 48 hours of backup downtime doesn't help this! And where do you keep 48 hours of OLTP archlogs!!!

I think I'll not bother with NT, because we already get random backup failures with our current UNIX machine, so we're moving the database to a bigger server.

We backup about 8 UNIX servers and 30 NT servers, totalling about 2 million file versions per night! We only just manage to keep up to it with the purge, because the backup window is so big. It's bacing up constantly from about 6pm to about 10am, then every 15 minutes for the archive logs!

Great fun...

[Dave Wherry]

You could do the ascii write/read on another system. Install OB and you get the temporary license which is good for something like 60 days. Copy your database files over to that server and do the write/read. You can then move that database back to your production cell manager and come up on that database. You would then have to import the tapes that were used during that time into the database so you have your current information.

[Simon Hargrave]

Nice idea, but how do I get this to work? I've copied the entire database (/var/opt/omni/db plus a few extension files that were lying around), and started the database up on the other machine.

However it now says that the CDB was created on a different cell, so I can't report, export or in fact do anything with it!

[Clovis Borges_1]

Hi,

Maybe the command omnidbutil -change_cell_name
can help you.

This option changes owner of catalog database to current cell server.

Clovis Borges.

[Dave Wherry]

Simon,
Sorry I did not reply sooner. I've been out of the office.
I'm also sorry I can not tell you all the steps to bring the database up on another system. I've had casual discussions about it with an OB instructor and the RC. We never got down to details. They did make it sound as easy as just copying those files over to the new system. Maybe the suggestion from Clovis will do the trick.
If I come across more information I'll post it.

[Simon Hargrave]

Cheers

The -change_cell_name thing worked a treat!



Sy

[Ben Spencer]

purging will not shrink the database. It marks things for removal, but space is not recovered until a writeascii/readascii is done. We do this on a monthly basis because of the length of time it takes. Our catalog is right at 2GB and it takes 6-8 hours to accomplish. BUT it is the only thing that keeps the database from growing. I also have to worry about archiving logs for Informix. I suspend archiving for the duration and we have enough logs defined that we don't run out.
I would look closely at the output from /opt/omni/bin/omnirpt -report db_size -ascii
and /opt/omni/sbin/omnidbutil -extendinfo
and see just how much space might be regained by doing the readascii.

This really is one of the week points of omniback. HP recommends regular write/readascii to keep the catalog healthy but how does one do this when the readascii is so slow (it takes 4 times as long as the write). This is one of the reasons we are considering different backup software.
Henry

[Ben Spencer]

Beware! Changing the cell server name may appear to work but may come back to bite you later on. We just upgraded from a K570 to an L3000 and we copied the database to the new machine. The sysadmin did a cell server name change based on bad advice from HP. We lost a number of sessions, monthly and annual backups along with a number of daily backups when I change the cell server name back to what it needed to be. I wound up having to restore to a backup 3 days earlier and then importing tapes. Importing tapes is an extremely slow process.