Results 1 to 4 of 4
  1. #1
    Join Date
    Mar 2007
    Sofia, Bulgaria

    Lightbulb Unanswered: How to avoid logical log backups

    Hi all,
    We have IDS 9.3.FC6X9, one database instance, three database - performance_db (Non Logging), administration_db (Logging) and system_db (Non Logging).
    We have eight datadbspaces, eight indexdbspaces, one physdbspace, one logspace, one rootdbs and one sbspace and 647 chunks (around 1.5TBytes of data).
    As the main database (performance_db) is Non Logging we don't need to keep Logical Logs at all.
    For backup we are usin Tivoli Storage Manager.

    These are some onconfig params:
    ROOTNAME rootdbs # Root dbspace name
    ROOTPATH /apps/informix/ids.93/databases/root
    PHYSDBS physdbspace1 # Location (dbspace) of physical log
    PHYSFILE 2000000 # Physical log file size (Kbytes)
    LOGFILES 6 # Number of logical log files
    LOGSIZE 250000 # Logical log size (Kbytes)
    MSGPATH /apps/informix/ids.93/online.log # System message log file path
    CONSOLE /dev/console # System console message path
    ALARMPROGRAM /apps/informix/ids.93/etc/ # Alarm program path
    TAPEDEV /apps/informix/ids.93/devnull # Tape device path
    LTAPEDEV /apps/informix/ids.93/devnull # Log tape device path
    BAR_BSALIB_PATH /opt/tivoli/tsm/client/informix/bin64/
    BAR_ACT_LOG /apps/informix/ids.93/bar_act.log
    BAR_DEBUG_LOG /apps/informix/ids.93/bar_dbug.log
    DBSPACETEMP tempdbspace1,tempdbspace2 # Default temp dbspaces
    DUMPDIR /informix_dump # Preserve diagnostics in this directory
    DUMPSHMEM 1 # Dump a copy of shared memory
    DUMPGCORE 0 # Dump a core image using 'gcore'
    DUMPCORE 0 # Dump a core image (Warning:this aborts OnLine)
    DUMPCNT 1 # Number of shared memory or gcore dumps for
    FILLFACTOR 90 # Fill factor for building indexes
    SBSPACENAME sbspace1 # Default smartblob space name - this is where blobs
    SYSSBSPACENAME sbspace1 # Default smartblob space for use by the Informix
    SYSALARMPROGRAM /apps/informix/ids.93/etc/

    The /apps/informix/ids.93/devnull is a link to /dev/null.
    The /apps/informix/ids.93/etc/ executes "onbar -b -l" command.
    The sm_versions file is : 1|5.2.1|adsm|5
    We are doing just full backups (onbar -b -L 0) each week and keeping three consecutive backups.

    So in current configuration we are keeping (backing up) logical logs, but as far as not all databases are logging, in case of restoring, as far as I know will be restored logical logs too, which will make the three databases inconsistent.

    So we dont want logical logs to be backed up.

    If I change LTAPEDEV to /dev/null then command "onbar -b -L 0" fails:
    2007-02-12 17:36:21 24736 24734 /apps/informix/ids.93/bin/onbar_d -b -L 0
    2007-02-12 17:36:21 24736 24734 Logical Logs will not be backed up / salvaged because LTAPEDEV value is /dev/null
    2007-02-12 17:36:21 24736 24734 /apps/informix/ids.93/bin/onbar_d complete, returning 156 (0x9c)

    Please give us any suggestions how to avoid logical log backups?

  2. #2
    Join Date
    Mar 2004

    You should set the LTAPEDEV to /dev/null


    be sure to make the backup with onbar -b -w -L 0

    The "-w" options tells informix to do a whole system backup which probably is a little bit slower (should be solved in Cheetah), but this won't require logical logs. Without this option all dbspaces could have a different archive time stamp, and you need logical logs to bring them in sync.



  3. #3
    Join Date
    Mar 2007
    Sofia, Bulgaria


    Thanks for advice. I have been reading about this option (-w) also.
    But this will be too slow, as if we specify a whole-system backup the onbar_driver backs up the storage spaces serially. No onbar_d child processes are created.
    As we have around 1.5TBytes of data and with BAR_MAX_BACKUP=5 the backup takes three and a half hours to finish. Now with whole-system backup will the backup time be 5 times more (fifteen hours)?

    And what about the restore command?
    We must follow a physical restore with a logical restore (onbar -r -p followed by onbar -r -l) before data is accessible unless we use a whole-system restore onbar r w -p. Is this OK?
    If we set the LTAPEDEV configuration parameter to /dev/null on UNIX the logical logs are not salvaged in any ON-Bar restore (onbar -r or onbar -r -w).
    After the restore the database is in quiescent mode and have to run "onmode -m" or "onmode -sy" command to perform fast recovery and bring the database online.

    And one more question:
    As we keep in TSM three consecutive backups how can we restore some of the oldest backups? Because if we type just onbar -r -w this will restore the last backup. Can we use: onbar -r -p -t time -w a point-in-time restore?
    And what should be the "time" parameter (from ONBar activity log when the backups were performed)?

    If we continue to backup the logical logs (e.g. LTAPEDEV is not /dev/null), how to purge the old logical log backups from Tivoli Storage Manager (TSM)? Are they automatically removed when the full database backup is performed or they have to be removed manually running some script or command? Is there a command to purge them, or a parameter of the onbar command which to tells the TSM to override the logical logs backups?
    Can we use the following comnand somehow:
    onsmsync command - Synchronizes the contents of the sysutils database, the emergency boot files, and the storage manager catalogs. Can be used to purge backups that are no longer needed according to user-selectable policies.


  4. #4
    Join Date
    Mar 2007
    Sofia, Bulgaria

    Lightbulb Using onsmsync utility to expire/remove the Informix logs from the TSM

    I have found some more info about TSM and logical logs on IBM's site:
    Managing Informix logs that are saved on the TSM Server
    I'm reading the Informix Backup and Restore guide about onsmsync utility, but if somebody can share his experience I will appreciate that.

    As we prefer to use "onbar -b -L 0" for backup (because it is faster than "onbar -b -w -L 0") and if we continue to backup logical logs and just purge oldest of them with onsmsync utility from TSM, how should we proceed in case of restore (we mustn't restore logical logs because this will make the three databases inconsistent , as not all of them are logging)?


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts