Re: ISM and OnBar Users

Yeah, we've tried to use OnBar/ISM with Informix AD/XP 8.21.UD2, and it's a mess. Theoretically, you should be able to do everything from the command line, but it doesn't always work that way. Keep in mind that, in order to do an archive, you must be backing up the logical logs. ISM will not let you do an archive if 'LOG_BACKUP_MODE' is set to NONE (otherwise known to 7.x as '/dev/null'). For starters, I seem to remember something about not being able to use hardware compression when backing up the logical logs. You must first do 'ism_startup -s server_name' as root. This can be done from the command line. You should be able to label and mount tapes from the command line, but all it would do for us is sit there and spin. It seems to work better if you do this using IECC. Don't forget to give the tape size, although ISM would sometimes write 20 meg on a 20 gig tape and think it was full and call for another one. If this happens, the only solution was to stop and restart ISM. Our problem was that with AD/XP it was almost impossible to do a clean kill on an OnBar archive, in which case you would at least have to bounce the engine. We finally developed a procedure whereby we unloaded critical tables (using external tables) through named pipes, then through compress, writing in parallel to our DLT tapes using dd. We're ok as long as we don't have to span tapes... HTH, Milton J. Vidrine, Jr. Melvin Mariney wrote: > Hi, > > Are there any ISM and OnBar users out there? If so, can you share any > of your experience with the products? I'm looking for things like: > > Can Compression be used for daabase and log backups? > Can you run the products from the command line or Unix cron? > Do you have to set up ISM using the client under IECC? > > Any info. would be greatly welcome and appreciated. > > thanks > > > -- > > Melvin Mariney > e-mail: melvin.mariney2@bridge.bellsouth.com

Milton, Glad to hear you can use IECC, we don't use it because we can't get it to install on our NT Workstations. Too many network requirements prevent it from installing on our corporate network. Your problem is more related to the release of XPS 8.21.UD2, and not having the right patches for your AIX system. UD2 has been reported to have a host of bugs. UD3 is supposedly on the horizon, be sure to upgrade to it when you get the chance. We downgraded back to UC1 on advice of our ATG resource from UD2, and have also brought the OS up on a few patches. These patches have helped the engine greatly, especially with shared memory problems. The OS was not managing shared memory properly, and the patches are known to improve things. We still have switch problems, but things are improving. Regarding onbar, we have been successfully using it for a while now, with ADSM. I have not messed with ISM, as I haven't had the time. Everything I do with onbar is on the command-line. We run onbar weekly, but actually dump tables nightly to disk and ADSM picks up the unload files, which make table-level restores a breeze. Onbar does not allow table-level restores, so using onbar to actually restore the data base would only be considered as a disaster recovery mechanism. ADSM compresses files according to our sys admin, so no need to do this, unless your file space is limited. I have my nightly backup simply delete the files on disk from yesterday, because ADSM actually allows me 45 days to recover anything deleted, and there is the option for archiving files up to a year or more. I'd be sad to use anything else at this point. Speaking of onbar here are some deficiencies with it: 1. No table-level restore, unless you consider one-table/dbspace a table-level restore. This is extremely lame. 2. No warm restore "overwrite" feature, where I could actually restore a dbspace backup over a perfectly good dbspace. This is a simple overwrite of data. This is only doable if I: 1. delete soft links to raw devices 2. bounce the engine 3. deleted dbspaces "appear" to be down to the engine to allow restore 4. relink raw devices ( data is still good ) 5. perform restore, hope to god the end-user didn't drop data base or drop tables, because restoring the logs actually will re-delete the table or data base. Point-in-time-restore is wholistic to instance and could corrupt other data bases, tables, etc. This is totally unacceptable as far as doing a warm restore especially when I'd like to simply restore good data over bad data. It would be so nice to force an overwrite of data. Quite often we need to restore a table due to loading problems based on business decisions. 3. Point in time restores are wholistic, meaning the whole damn instance has to be restored, no selectivity to it. This means essentially no ability to recover deleted tables or data bases. If the dbspace is restored, it's difficult to control what is recovered and what is not. For example, I delete 20 tables and I want to bring 10 back and leave the rest. I may have rebuilt these other 10 and now want to bring back a specific set. Can't do it currently, and am forced to restore the logs, which journaled changes. Maybe I don't want the logs, and want to recover data! Hello! 4. No ability with onmode to mark only a specific dbspace down. Onmode -O goes after the whole damn instance. 5. onstat -g arc is not enough of a backup report. There should be the option to see the onbar jobs I created with "onbar -b -L 0 -q "que-name" Onbar is required to make the engine do things, but in reality onbar is functionally useless because of the limited restore capabilities. What's the point of a backup if you can't restore with it? The reason things stay the way they are is because there are not enough DBA people out there for Informix. Of the few that ARE out there, they are not being asked by Informix what needs to be done to improve utilities. Thanks, Tim "Milton J. Vidrine, Jr." wrote: > > Yeah, we've tried to use OnBar/ISM with Informix AD/XP 8.21.UD2, and it's > a mess. Theoretically, you should be able to do everything from the > command line, but it doesn't always work that way. Keep in mind that, in > order to do an archive, you must be backing up the logical logs. ISM will > not let you do an archive if 'LOG_BACKUP_MODE' is set to NONE (otherwise > known to 7.x as '/dev/null'). > > For starters, I seem to remember something about not being able to use > hardware compression when backing up the logical logs. > > You must first do 'ism_startup -s server_name' as root. This can be done > from the command line. > > You should be able to label and mount tapes from the command line, but > all it would do for us is sit there and spin. It seems to work better if > you do this using IECC. Don't forget to give the tape size, although ISM > would sometimes write 20 meg on a 20 gig tape and think it was full and > call for another one. If this happens, the only solution was to stop and > restart ISM. Our problem was that with AD/XP it was almost impossible to > do a clean kill on an OnBar archive, in which case you would at least > have to bounce the engine. > > We finally developed a procedure whereby we unloaded critical tables > (using external tables) through named pipes, then through compress, > writing in parallel to our DLT tapes using dd. We're ok as long as we > don't have to span tapes... > > HTH, > Milton J. Vidrine, Jr. > > Melvin Mariney wrote: > > > Hi, > > > > Are there any ISM and OnBar users out there? If so, can you share any > > of your experience with the products? I'm looking for things like: > > > > Can Compression be used for daabase and log backups? > > Can you run the products from the command line or Unix cron? > > Do you have to set up ISM using the client under IECC? > > > > Any info. would be greatly welcome and appreciated. > > > > thanks > > > > > > -- > > > > Melvin Mariney > > e-mail: melvin.mariney2@bridge.bellsouth.com -- - -- --- Tim Schaefer ---- tschaefe@mindspring.com --- http://www.inxutil.com -- -