Re: What are the definitions to the fields in an ixbar file?
This is a discussion on Re: What are the definitions to the fields in an ixbar file? within the Informix forums, part of the Database Server Software category; --> IDS9.50/IDS10.00 ? ..... I want this fix ... Chucho! rwboardley@west.com wrote: > Hello, > > Does anyone know what ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-20-2008, 08:28 AM
| ||||
| ||||
 Re: What are the definitions to the fields in an ixbar file? IDS9.50/IDS10.00 ? ..... I want this fix ...  Chucho! rwboardley@west.com wrote: > Hello, > > Does anyone know what the three additional fields at the end of line > are in the ixbar file for IDS9.50/IDS10.00? > > Thank you. > Bob Boardley > > Brice Avila wrote: > >>Hello, >> >>I wonder if anyone has put together a definition of all the fields in >>a typical ixbar file? I'm in a job that allows me to read a lot of >>ixbar files. While I know what most of the fields are, I'm curious >>about the fields I don't know about. Below is what I know. If you > > know > >>what the other fields are, or can help me fine-tune what I know I'd >>appreciate it. I promise to post the full answer later on this >>newsgroup. Thanks in advance. >> >>Brice Avila >>Minneapolis, Minnesota >> >> >> >>The Informix ixbar file >> >>Sometimes referred to as the "emergency boot file", the ixbar file >>contains all of the information that pertains to backed-up dbspaces >>and logical logs. This data is needed if a restore is necessary >>without access to the sysutils database (i.e. when the Informix >>instance is down). Each time a database object is backed-up, this > > file > >>is updated as well the sysutils database. The emergency boot file >>resides in the $INFORMIXDIR/etc directory and is called >>"ixbar.<servernum>", where <servernum> is the value of the SERVERNUM >>onconfig parameter. For instance, if the onconfig parameter SERVERNUM >>is "21" the emergency boot file name is "$INFORMIXDIR/etc/ixbar.21". >> >>Below is some information that one can use to read the ixbar file. >>Here is an example ixbar file: >> >> bavila rootdbs R 0 512 0 0 1036939216 2002-11-10 09:43:19 1 >> bavila llogdbs3 CD 0 513 0 0 1036939411 2002-11-10 09:43:56 1 >> bavila llogdbs2 CD 0 514 0 0 1036939412 2002-11-10 09:44:12 1 >> bavila llogdbs4 CD 0 515 0 0 1036939413 2002-11-10 09:44:18 1 >> bavila llogdbs5 CD 0 516 0 0 1036939414 2002-11-10 09:44:25 1 >> bavila plogdbs CD 0 517 0 0 1036939415 2002-11-10 09:44:35 1 >> bavila llogdbs CD 0 518 0 0 1036939416 2002-11-10 09:46:00 1 >> bavila prodidx ND 0 519 0 0 1036939418 2002-11-10 10:07:51 1 >> bavila prodtbls ND 0 520 0 0 1036939417 2002-11-10 10:10:20 1 >> bavila 4447 L 0 521 0 0 1036941024 2002-11-10 10:10:54 1 >> >>Column 1: The SERVERNAME >> >>The SERVERNAME is the name of the Informix instance. It is the same > > as > >>the $INFORMIXSERVER environmental variable, and the SERVERNAME >>configuration parameter in the Informix onconfig file. In the first >>line of the above example, "bavila" is the servername. >> >>Column 2: Object name >> >>The object name is the name of the dbspace or the unique logical log >>number. All of the dbspace names are listed in the last column of the >>"onstat -d" command. The unique logical log number matches the fourth >>column of the "onstat -l" command. In the first line of the above >>example, "rootdbs" is the object name. >> >>Column 3: Object type >> >>The object type is one of the following: >> >>"L", for logical log number. >>"ND", for non-critical dbspace. >>"CD", for critical dbspace (a dbspace that has either logical logs, > > or > >>physical logs). >>"R", for rootdbspace >> >>All restores start with a restore of the rootdbspace, followed by >>critical dbspaces, then non-critical dbspaces, and finally logical >>logs. >> >>In the example above: >> >>1. "rootdbs" is confirmed as the name of the rootdbs. >>2. "llogdbs", "llogdbs2", "llogdbs3", "llogdbs4", "llogdbs5" and >>"plogdbs" are confirmed as critical dbspaces. >>3. "prodidx" and "prodtbls" are confirmed as non-critical dbspaces. >>4. "4447" is a unique logical log id for a log that was backed-up. >> >>Column 4: Whole system backup flag. >> >>A whole system backup will backup all the dbspaces in an Informix >>instance, complete with logical logs needed to restore the whole >>instance, all in one backup stream into one image. It is the onbar >>backup type that is closest to the "ontape" type of backup. One CAN >>backup extra logical logs and restore an instance to the time of the >>last logical log backup. Since the dbspaces in a whole backup are >>backed-up serially, it is the slowest type of onbar backup. Whole >>backups and restores have the "-w" flag: >> >>A whole system backup flag is set to "1" if the backup was a whole >>system backup. The above example did not have the "-w" flag to the >>onbar command. >> >>Column 5: Action_id. >> >>An Informix unique identifier that is associated with the onbar > > backup > >>command. It is one of the composite keys to the sysutils:bar_action >>table, and the sysutils:bar_instance table. In the first line of the >>above example, the action_id is 512. >> >>Column 6: Backup Level. >> >>Informix offers 3 levels of backups, specified in the "-L" flag on > > the > >>onbar command. If there is no "-L" flag, a level 0 backup is assumed. >>The following is a definition of the different Informix levels of >>backups: >> >>* A level 0 archive will backup all of the information in an Informix >>instance. >>* A level 1 archive will backup all of the information in an Informix >>instance that has changed since the last level 0 archive. >>* A level 2 archive will backup all of the information in an Informix >>instance that has changed since the last level 0 or level 1 archive. >> >>If a level 1 or level 2 archive is attempted without a previous level >>0 archive, the above errors will occur. The solution is to run a > > level > >>0 archive first. More information on backup levels is available in > > the > >>Informix Backup and Restore Guide. >> >>In the above example, a level 0 backup was used. >> >>Column 7: Copyid_hi. >> >>The copyid_hi is a unique identifier of the object that is stored in >>the storage manager. In the first line of the above example, the >>copyid_hi is "0". >> >>Column 8: Copyid_lo. >> >>The copyid_lo is another unique identifier of the object that is >>stored in the storage manager. In the first line of the above > > example, > >>the copyid_lo is "1036939216". >> >>Column 9 and 10: Timestamp >> >>The time the backup of the particular object was started. In the > > first > >>line of the above example, the rootdbs backup was started at >>"2002-11-10 09:43:19". >> >>Column 11: Onbar version. >> >>The version of the XBSA library. Informix supports all storage >>managers that use XBSA version 1.1 protocol. >> >>Column 12: RSAM time (if available) >> >>Column 13: Required act_id (if available) >> >>One of the composite keys to the sysutils:bar_action table, and the >>sysutils:bar_instance table. >> >>Column 14: Archive verified by Archecker (if available) >> >>"Archecker" is an Informix utility that performs backup validation of >>onbar backups. Archecker has been integrated into the onbar utility >>since version 7.3, though not documented in the Informix Backup and >>Restore Guide until the version 9.2 documentation set. >> >>Archecker for onbar is compatible with NetBackup to validate backups >>made from version IDS 7.30 and above, XPS version 8.30 and above and >>IDS2000 version 9.20 and above. Archecker is designed to validate >>level 0 backups with little impact on production systems. Archecker >>will ensure that all data required to restore an instance exists and >>is in the correct format. >> >>If this column exist, an Archecker backup has been run before. It's >>format is 0=no, 1=yes. >> >>Column 15: Archecker verified datetime (if available) >> >>The time that Archecker was run. > > > sending to informix-list      |
Linear Mode
