Results 1 to 3 of 3
  1. #1
    Join Date
    May 2002
    Location
    Ukaine
    Posts
    5

    Unanswered: onbar -l long duration of logs back up

    Hi all !!! answer me please why onbar -l making logs back up so long than ontape. although onbar -b -L0 mydbs make dbspaces back up fast.
    my part of onconfig
    LOGFILES 100
    LOGSIZE 500
    LTAPEDEV \\.\TAPE0
    LTAPEBLK 256
    LTAPESIZE 1950000
    LOGBUFF 32
    LOGSMAX 300
    BAR_MAX_BACKUP 4
    BAR_RETRY 1
    BAR_NB_XPORT_COUNT 20
    BAR_XFER_BUF_SIZE 31

  2. #2
    Join Date
    Nov 2001
    Location
    Germany
    Posts
    14
    Hi,
    Given the 2K pagesize for your system, your transfer buffers are sized at 63,988 bytes ( (BAR_XFER_BUF_SIZE * PAGESIZE) + 500 = 63988 ).
    The extra 500 is for overhead. This number is just fine since XBSA has a 64K limit for transfer buffers anyway.
    As you have set "LTAPEBLK 256", it is normal I think...
    A nice explanation from John Miller is :

    Just a few hints about BAR_NB_XPORT_COUNT & BAR_NB_XPORT_SIZE.
    1. The number of buffer allocated for sending data for a single onbar
    process to/from the storage manager. If you have 4 onbar process,
    you will have 4 * BAR_NB_XPORT_COUNT buffer allocated.
    2. If you change BAR_NB_XPORT_SIZE at ALL previous
    backup, both logs and archives, are invalid.
    3. Generally it is already set as large as possible. The XBSA spec
    states that this can be 1 byte less then 64KB. Informix set it to
    one database page less than 64KB. So for system with 2KB
    database page size this would be 31 (2KB*31=62KB).

    What these buffers do is hold the archive data for both informix and
    the storage manager. In an attempt to not bycopy data Informix allocates
    a set (the number determined by BAR_NB_XPORT_COUNT) of buffers
    that are filed by the kaio threads in the engine and the pointers to these
    buffers
    are passed to onbar. This means that the actual data in the buffer (which is
    sized
    by BAR_NB_XPORT_SIZE) is not moved. onbar takes this pointer and
    hands it directly to storage manager. Again the data never moves. While this
    single buffer is being passed to the storage manager, oninit is filling the
    other buffers (BAR_NB_XPORT_COUNT - 1) with data. This will
    ensure that when onbar request another buffer it is already filled with data.

    To view the status of these buffer you can use the command onstat -g stq. This
    will show you the buffer and if they are on the full size (engine has filled
    them with data) or the empty side (engine needs to fill the buffer with data).
    You should
    generally see one buffer missing of these queues and that is the buffer
    currently being processed by the storage manager.

    Hope this helps...

    Murat
    Last edited by muratmy; 05-22-02 at 07:31.

  3. #3
    Join Date
    May 2002
    Location
    Ukaine
    Posts
    5
    Thank you that you answered me! but I changed those sets and do not care I have similarly problems
    Once again thanks
    Idris

Posting Permissions

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