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/log_full.sh # Alarm program path
TAPEDEV /apps/informix/ids.93/devnull # Tape device path
LTAPEDEV /apps/informix/ids.93/devnull # Log tape device path
DYNAMIC_LOGS 2
BAR_BSALIB_PATH /opt/tivoli/tsm/client/informix/bin64/libTDPinf64.sl
BAR_ACT_LOG /apps/informix/ids.93/bar_act.log
BAR_DEBUG_LOG /apps/informix/ids.93/bar_dbug.log
BAR_MAX_BACKUP 5
BAR_NB_XPORT_COUNT 1
BAR_XFER_BUF_SIZE 31
ISM_DATA_POOL ISMData
ISM_LOG_POOL ISMLogs
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/evidence.sh

The /apps/informix/ids.93/devnull is a link to /dev/null.
The /apps/informix/ids.93/etc/log_full.sh 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?

Hi,

You should set the LTAPEDEV to /dev/null

AND

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.

Greetz,

RobP

Hi,
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 ON–Bar 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.

Regards.

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)?

Regards.