Onbar is a utility that comes with the online product starting with the 7.21.UC1 version. This utility has the ability to.

• Perform parallel backups and restores of online.
• Automatic & continuous backups of the logical logs.
• Use 3rd Party Storage Managers to to store the online backups.

GOOD PLACES TO START

1. OnBar Functionality/How To
2. Components of OnBar
3. Debugging Onbar
4. Frequently Asked Questions/Known Problems

�

Home   Index

�

�

�

�

�

�

�

�

�

---

Components of ONBAR

To put simply, Onbar's basic function is to carry backups between the storage manager and the Online engine. In order to do this OnBar makes use the components mentioned in the diagram above. Many of those components are used to store information about various backups as well as information about how to make connections to the SM and Online engine. Onbar also uses these components to record what it has done and the success of its operations.

Home   Index

�

�

�

�

�

�

�

�

�

�

�

�

�

ONBARS FUNCTIONAL SPECIFICATIONS

OnBar Operations

1. Whole System Backups - (onbar -b -w) A whole system backup is indicated with the '-w' flag in the onbar command. When this is set Onbar will backup each dbspace serially and such that there will not be any need for logical recovery if a restore is required. A whole system backup will back up every dbspace in the instance.

2. Dbspace Backups - (onbar -b -L 0 dbsp1 dbsp2 ...) A dbspace backup is when Onbar will backup a single dbspace or a group of dbspaces as specified by the argument list passed the the OnBar command. If you are backing up multiple dbspaces, then the backups are done in parallel. The amount of backups that can be done at 1 time is restricted to the value of BAR_MAX_BACKUP (see OnBar Configuration Parameters). You may also put the list of dbspaces you want to be backed up in the a file and has that file referenced by OnBar (see the usage below). If a restore is done utilizing these backups then logical recovery is required to sync up these dbspaces with the other dbspaces.

3. Logical Log Backups - (onbar -l) Onbar will request all logical logs from the engine to be backed up and pass them to the storage manager.

4. Continous Logical Log Backups - (onbar -C -l ) Onbar will start continous logging just like ontape -c

5. Fake Online Backup - (onbar -b -F) Onbar will tell the engine to do a 'fake' backup. This is like archiving to /dev/null. This added feature is useful if you want to change the logging mode af a database and do not have the time to perform and archive. NOTE. This does not take the place a regular archive because nothing is sent to the storage manager so nothing can be restored.

1. Onbar Cold Restore - (onbar -r) When OnBar performs a cold restore it first attempts to do a cold log backup (salvage of any logical log that have not yet been backed up. Then Onbar will scan the ixbar file to get a list of all objects it needs to restored (ie all level 0, 1, 2 backups of all dbspaces as well as all logical log that will need to be rolled forward). After that Onbar simply get one of those objects from the storage manager and passes it to the online engine. Once the physical restore is complete, Onbar Will automatically start logical recovery and roll forward all logical logs it has.

2. Onbar Warm Restore - (Onbar -r dbsp2 dbsp3 ...) When Onbar performs a warm restore it will first have online back up all the logical so that it can roll forward through them after the physical restore. Next OnBar will scan through the sysutils database to get a list of the objects it needs to get from the storage menager. Once that is done, OnBar will simply get the objects from the storage manager and send then to the engine to be restored. Finally Onbar starts retrieving the logical log backups from the Storage Manager and send them to online to be applied as logical recovery.

3. Mixed restore - Obar can allow the user to perform a mixed restore. This is basically a combinations of both cold and warm restores. The user would first perform a cold restore of the cirtical dbspaces and then a warm restore of the non-critical dbspaces.

4. Physical restore - (onbar -r -p) As mentioned above Onbar will by default start logical recovery after physical recovery has finished. If the user does not want this to happen, he/she can use the '-p' option and Onbar will only perform physical recovery. Once this is done, Online will hang in fast recovery until onmode -m is issued.

5. Logical recovery - (onbar -r -l) If the user does a physical restore and then wants to perform a logical restore after that, then the user can use the '-l' option to rollforward the logs after the physical restore completes. This can't be done if modifications were done to the database between them time the physical restore completed and the logical restore startted.

6. Point in Time Recovery - (onbar -r -t {date and time} OR onbar -r -n {log number}) This will allow the user to restore the ENTIRE instance to a specific point in time. That time can be specified by either telling onbar what logical log to rollforward through or by telling onbar the time it is to stop rolling forward. NOTE: The point in time recovery feature is only to be used when performing a cold restore of the entire instance and will NOT work if you want to perform a warm restore of a set of dbspaces.

Home   Index

onbar usage
 
BACKUP:
=======
-b [-L ] [-f ] []
-b -w [-L ]
-b -F
-l [-c] [-s]
    -b backup
    -c backup current logical log
    -f pathname of file containing list of dbspaces, blobspaces
    -F fake backup
    -l backup full logical logs
    -L backup level: 0, 1, or 2
    -w whole system backup
        -s salvage logs
     list of dbspaces, blobspaces to backup
 
RESTORE
========
-r [-t  | -n ] [-f ] []
-r -p [-t ] [-f ] []
-r -l [-t  | -n  ] [-f ] []
-r -w [-p] [-t  | -n ]
    -f pathname of file containing list of dbspaces, blobspaces
    -l logical restore
    -n last logical log to restore
    -p physical restore
    -r restore
    -t point in time to stop restore.  
     list of dbspaces, blobspaces to restore
    -w whole system to restore

Home   Index

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

FREQUENTLY ASKED QUESTIONS & KNOWN PROBLEMS

PROBLEM: I get the following error on the onbar activity file: ERROR: Version of XBSA shared library is not compatible with version %1 of On-BAR. Whenever I try to start Onbar.

ANSWER: There is not a row in the sysutils:bar_version table that matches the version of the XBSA library that is being used. The most common solution to this is to run the folowing SQL statements:

• database sysutils;
• insert into bar_version values ('1', '1.0.1', 'nsm', 0);
• close database;

If that does not work then you have to find out what row onbar is trying to select. You can do that by setting BAR_DEBUG 7 and look at the BAR_DEBUG_LOG. That log should contain an SQL statement that selects from the bar_version table. Look at the values in the where clause of that select statement and manually insert a row into the bar_version table that contains those values. That way the SQLCODE from the select statement will not return 100 and the backup will be able to continue.

---

PROBLEM: I get the following error on the onbar activity file: ERROR: Could not open XBSA library /usr/lib/ibsad001.so. Whenever I try to start Onbar.

ANSWER: The XBSA libraries have not be installed yet. There is no way for onbar to communicate with a the storage manager. Have the customer check to make sure a storage manager is installed and working on the machine. Once everything is installed the XBSA library must be linked to /usr/lib/ibsad001.so.

---

PROBLEM: I can't do a warm restore of a dbspace that is NOT marked as offline or inconsistant

ANSWER: bring online up with the undocumented enviornment variable ARCHIVE_TEST = 'Y'. This will make online mark the dbspace as offline just before it tries to restore it. This will allow Onbar to restore any dbspace not matter what the flags are.

---

PROBLEM: Onbar returns the error Not supportted on this platform whenever I issue any Onbar command.

ANSWER: This is due to Bug 73420. The 7.22.UC2 product did not come with Onbar for some reason.

---

PROBLEM: Onbar dbspace backup fails and the BAR_ACT_LOG shows errors -239 and -100.

ANSWER: This is due to bug 74755. The customer will run in to problem if a dbspace became a critical dbspace in between dbspace backups. A dbspace will become a critical dbspace when the physical/logical is moved inside it. A workaround would be to update the bar_object table in the systutils database. Set obj_type = "CD" where obj_name={THE DBSPACE NAME}. For more information on sysutils, click here.

ANSWER: A whole system backup will backup up every dbspace serially while the regular (without the -w option) backup will try to backup up each dbspace in parallel. One benifit of using the the 'whole' system backup option is that when restoring you will have the option to only do a physical restore with out applying the logical log. An archive done without using the -w option will need the logical recovery in order to bring all dbspaces consistent with eachother.

ANSWER: Onbar will only send the data/archive to the storage manager. What the storeage manager does with the sent data is not anything Informix/ Onbar has controll of. Therfore the user must configure the storage manager to send backups to the UNIX filesystem instead of a tape. Most Storage Managers will allow you to utilize a unix file as a tape device.

ANSWER: When an oninit -i is run, the ixbar file is cleared out. However, a backup copy of that file is made. The old ixbar file will be named ixbar.server_num.yymmdd.hhmmss. You will have to copy this back to ixbar.server_num. For more info on the ixbar file follow this link

ANSWER: Onbar -r -w will only restore 'whole system' archives ( archives that were taken by running onbar -r with the -w option). Since none were taken in this case, onbar will give the above error.

ANSWER:

ANSWER: This issue is addressed in The Tech Info Article #6003. It syas that this is a known prblem specific to to 7.23.UC3 version of Onbar on the AIX platform. It is fixed in 7.23.UC4.

ANSWER: In the process of ADSM client software installation, The red book talks about adding lines to dsm.sys file (in chapter 6) for the Servername. It does not talk about adding some more lines. These lines are needed for Informix's onbar to work with ADSM. If we do not insert these lines into the file we get the above error message.

ADSM server to which the client ADSM talks
TCPPort        XXXX 
   ## Should be the port number used for
   ## informix server in services file
COMMmethod   TCPip
   ## Communication method if it is TCP.
TCPServeraddress XXX.XXX.XXX.XXX
   ## ADSM Server Address in the host file
Passwordaccess  GENERATE  
   ## Should be used in order to not to ask
   ## password in the backup and restore    
   ## process.

Home   Index

�

�

�

�

�

�

�