Hi,

is it necessary to have separate pools for each instance?
Well, it depends.

If you want to back up all these instances at the same time,
then it may indeed be useful. Otherwise you may see
waiting times.

If your schedule spreads the backups of the three instances
over time without overlapping each other, then probably you
don't need different pools for each. This anyway may be
more efficient in terms of resource utilization. Different pools for
dbspaces and logs I still recommend.

There may be other worthy considerations, e.g. if you want to
keep backups of the instances strictly separate (for easier
administration of backup mediums), etc.

Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management

IBM Deutschland GmbH
Chairman of the Supervisory Board: Hans Ulrich Märki
Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael
Diemer
Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart,
HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940

"Carlos Augusto Moreira" <gutomore@gmail.com> wrote on 18.07.2007
19:20:31:

> Hi Martin!
> Thanks for your reply!
> I'm actually don't have two pools or polices for each kind of back up,
but it's really necessary?
> If so, I'
> l'l ask the Tivoli Manager to create one for each.
> As I'm planning to backup a XPS instance and another IDS, do you think
that it's necessary
> to have one pool/police for each instance/backup type?
> One for the 9.20 data and one for the its logs
> One for the XPS data and one for the its logs
> One for the 9.30 data and one for its logs?
>
> Thanks Indeed!
> Guto.

> On 7/18/07, Martin Fuerderer <MARTINFU@de.ibm.com > wrote:
> Hi,
>
> make sure that you have setup Tivoli to use separate (different)
> volumes and pools for dbspaces and logs. This is the equivalent
> to the ISM_DATA_POOL and ISM_LOG_POOL onconfig
> parameters for ISM.
> Then make sure that Tivoli can access (i.e. write to) these volumes
> concurrently.
>
> I see that you have BAR_MAX_BACKUP set to 10. That means
> onbar will start 10 processes to backup 10 dbspaces in parallel.
> If this is too much for your Tivoli setup, then decrease this number
> to leave Tivoli some resources to also handle the log backup
> in parallel with the backup of dbspaces.
>
> Regards,
> Martin
> --
> Martin Fuerderer
> IBM Informix Development Munich, Germany
> Information Management
>
> IBM Deutschland GmbH
> Chairman of the Supervisory Board: Hans Ulrich Märki
> Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
> Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael
> Diemer
> Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart,

> HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940
>
> informix-list-bounces@iiug.org wrote on 18.07.2007 15:02:08:
>
> > Hi All!
> > I'm trying to make a 23Gb Level 0 Backup of a IDS 9.20UC2 instance,
> > testing the new Tivoli Backup System, but I'm facing this issue:
> >
> > The dbspaces backup starts fine, but then comes the logical log
> > backups ( one per minute )
> > that are fullfilled so fast, and the Tivoli stops the dbspace backup
> > in order to backup the logs.
> > With it, I'm not able to make a backup of the dbspaces.
> >
> > Here's my configs:
> > Informix Dynamic Server 2000 Version 9.20.UC2
> > BUFFERED LOG
> >
> > TAPEBLK 16 # Tape block size (Kbytes)
> > TAPESIZE 24000000 # Maximum amount of data to put on
> > tape (Kbytes)
> > LTAPEBLK 512 # Log tape block size (Kbytes)
> > LTAPESIZE 2000000 #Max amount of data to put on log tape
> > (Kbytes)
> > LOGFILES 160 # Number of logical log files
> > LOGSIZE 3000 # Logical log size (Kbytes)
> > CCFLAGS 0x400000 #ARCHIVE PARAMETER
> > BAR_ACT_LOG /var/tmp/informix_backup_logs/bar_act.log
> > BAR_DEBUG_LOG /var/tmp/informix_backup_logs/bar_dbug.log
> > BAR_BSALIB_PATH /opt/tivoli/tsm/client/informix/bin/libTDPinf.so
> > TAPEDEV /usr/informix/rawmsg/backup_devices/tapedev
> > LTAPEDEV /usr/informix/rawmsg/backup_devices/ltapedev
> > BAR_DEBUG 6 #( setted to 6 just to debug the problem )
> > BAR_MAX_BACKUP 10
> > BAR_RETRY 5
> > BAR_NB_XPORT_COUNT 1
> > BAR_XFER_BUF_SIZE 31
> > RESTARTABLE_RESTORE on
> > BAR_PROGRESS_FREQ 0
> >
> >
> > Any suggestions are welcome!
> >
> > Thanks!
> > Guto.- Brasil
> >
> > _______________________________________________
> > Informix-list mailing list
> > Informix-list@iiug.org
> > http://www.iiug.org/mailman/listinfo/informix-list