ITEM: CG5471L

having a problem with sysback/getting error from sbfwd

Environment:  3.2.5  59H
              sysback 3.3.3.6

Description:  Customer is issueing the following command to restore data
  from a vg on a remote 7331 parallel backup

        sysrestore -h \ -v raidvg -d -f vdev2 \

  He sees the following messages:

     rewinding
     forwarding to raidvg
     sbfwd:  cannot attach to shared memory for buffer status
     sbfwd:  permission denied

Action:  Explained the message is comming from the sbfwd2 command.  A
  shared memory segment has been created but is failing on the attach.
  The shared memory segment is created when operating against parallel
  devices.

  Customer had huge chunks of shared memory being used by oracle 
  databases.  Customer will try restore when databases are down.

  But a work around is:

    Customers backup looks like this:
    
    Tape 1  (rmt 2)
    ----------------
    Image 1 | Image 2 | Image 3 | Image 4 | Image 5 | Image 6 | Image 7
     boot    mkinstape   dummy    sysback    rootvg   raidvg    raid2vg

    Tape 2  (rmt 3)
    ----------------
    Image 1  |  Image 2  |  Image 3  |  
     rootvg     raidvg      raid2vg

    tctl -f /dev/rmt2 rewind
    tctl -f /dev/rmt3 rewind

    sbdevice -f 5 /dev/rmt2
    sbdevice -f 1 /dev/rmt3

    sysrestore -h \ -v raidvg -d -n -f vdev2 \

    This restored the customer data.  He will rewind and reposition to
    get data from raid2vg.

    This worked because by manually positioning tapes, the sbfwd2 was
    never called thus eliminating the need to attach to a shared 
    memory segment.  But the sbread2 which is required to read from the
    parallel device will also need to attach to a shared memory 
    segment.  Why the workaround does not fail on the sbread2 is still
    being researched.

    But customer will look into his shared memory resources.

Response:

Action:  Customer called back in and stated that he tried to do the
  verify of his parallel backup with the oracle database not running.

  This freed up over 100M of shared memory.

  But customer still received the sbfwd error message about not being
  able to attach to shared memory for buffer status.

Action:  Problem is opened with developer.

Next:  CWCA


ON the server system.

chmod ug+s /usr/sbin/sbfwd2

This corrected the problem.  When you do a remote backup, you are
sbnet on the server system.  The sbfwd2 command will open up a 
shared memory segment.  It can't do this if it is the sbnet user
on the server.  The setuid will correct this and did.

Next Action:
  Closing with customer approval



Support Line: having a problem with sysback/getting error from sbfwd ITEM: CG5471L

Dated: December 1996 Category: N/A

This HTML file was generated 99/06/24~13:30:18

Comments or suggestions?
Contact us