OEBU and Y2K compliance - Veritas Net Backup

This is a discussion on OEBU and Y2K compliance - Veritas Net Backup ; Hi everybody, I am having a problem trying to restore Oracle database using Netbackup 3.1 and OEBU 2.2.0.7 The following is the log from trouble ticket I opened with Oracle. Has anybody seen this before? Any suggestions? Leonid LOG: Ct ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: OEBU and Y2K compliance

  1. OEBU and Y2K compliance


    Hi everybody,

    I am having a problem trying to restore Oracle database using Netbackup 3.1
    and OEBU 2.2.0.7
    The following is the log from trouble ticket I opened with Oracle. Has anybody
    seen this before? Any suggestions?
    Leonid

    LOG:

    Ct has EBU for backup. 2.2.0.7 installed.
    He has Veritas Netbackup for Media Management Software.

    His restore does not work when he species
    TO = "12/19/1999" or similar with 12 in month.

    NetBackup log tries to find information
    From date: "01/09/1970"
    To Date: "01/11/1970" and fails.

    I am not sure why it is looking for information in that date range.


    But in 7.3.4 the bp.conf file must also be put in $ORACLE_HOME.
    It is there.

    TO="11/19/1999" works fine when he specifies it in the restore script.

    I could not find any information on WebIVbased on the above information.

    I asked Ct to send the RESTORE script, the standard output error messages
    and logfile along with the backup set information. Iwill send these in a
    mai
    l to me.

    I will take a look and see what I find.
    For further help Imay need to engage Ben also, if required.
    @cus



    29-DEC-99 17:33:14 GMT

    Hi Soumendra,

    These are the files related to TAR 12605535.600

    <> <> <>
    <> <>

    ==============
    OEBU_rthire.res:
    ==============

    restore database
    backup_host = "peoplesun"
    db_name = "rthire"
    to = "12/12/1999 14:00:00"
    recover = "12/12/1999 14:01:00"
    parallel = 1
    log = "/u01/oracle/backup/logs/OEBU_rthire.log"

    ==============
    list_backups.log:
    ==============
    Oracle7 Enterprise Backup Utility Tool: Release 2.2.0.7.0 - Production on
    Tu
    e Dec 28 17:30:55 1999
    Tape API: Release 3.1
    Tape Management Software: Release 3.1.0.0
    ...

    I did not see any backup for 12/12/1999 in the list.



    29-DEC-99 17:47:37 GMT


    ========
    output.log:
    ========
    sphinx:rthire> . ./OEBU_rthire_restore.sh
    Oracle7 Enterprise Backup Utility: Release 2.2.0.7.0 - Production on Tue
    Dec
    28 17:23:20 1999

    Copyright (c) Oracle Corporation 1979, 1996. All rights reserved.

    CORE Version 3.5.4.0.0 - Production
    NLSRTL Version 3.2.4.0.0 - Production

    ORACLE_HOME = /u01/oracle/product/7.3.4
    System name: SunOS
    Node name: sphinx
    Release: 5.6
    Version: Generic_105181-11
    Machine: sun4u
    Tape API: Release 3.1
    Tape Management Software: Release 3.1.0.0

    RESTORE job started with pid=29597 on Dec 28 1999 17:23:20

    Starting parsing of command script "/u01/oracle/backup/OEBU_rthire.res"
    restore database
    backup_host = "peoplesun"
    db_name = "rthire"
    to = "12/12/1999 14:00:00"
    recover = "12/12/1999 14:01:00"
    parallel = 1
    log = "/u01/oracle/backup/logs/OEBU_rthire.log"
    Ending parsing of command script


    Starting Catalog Database verification
    Catalog Database verified
    Ending Catalog Database verification


    Starting Instance Manager verification
    Found Instance Manager (brd) process running with pid = 20851
    Ending Instance Manager verification


    Starting Target Database state verification
    Connecting toTarget Database
    ORACLE_SID: rthire
    ORACLE_HOME: /u01/oracle/product/7.3.4
    DBNAME: RTHIRE
    Username: ebudba

    Connected to idle instance.















    4/dbs/initrthire.ora". Use STARTUP_PFILE in script if using a different one



  2. Re: OEBU and Y2K compliance

    I had a similiar problem and Oracle mentioned a Y2K problem with version 2.2.0.7
    so they had me install the patch to bring it up to version 2.2.0.9. Well, I don't
    have the problem anymore but have a different one now so I am still stuck, but I
    would install the patch to get you to 2.2.0.9 They have the patch online for
    Solaris and other systems. I am running on DYNIX/ptx though and they didn't have
    one immediately online so they had to dig one up from somewhere.

    Leonid wrote:

    > Hi everybody,
    >
    > I am having a problem trying to restore Oracle database using Netbackup 3.1
    > and OEBU 2.2.0.7
    > The following is the log from trouble ticket I opened with Oracle. Has anybody
    > seen this before? Any suggestions?
    > Leonid
    >
    > LOG:
    >
    > Ct has EBU for backup. 2.2.0.7 installed.
    > He has Veritas Netbackup for Media Management Software.
    >
    > His restore does not work when he species
    > TO = "12/19/1999" or similar with 12 in month.
    >
    > NetBackup log tries to find information
    > From date: "01/09/1970"
    > To Date: "01/11/1970" and fails.
    >
    > I am not sure why it is looking for information in that date range.
    >
    > But in 7.3.4 the bp.conf file must also be put in $ORACLE_HOME.
    > It is there.
    >
    > TO="11/19/1999" works fine when he specifies it in the restore script.
    >
    > I could not find any information on WebIVbased on the above information.
    >
    > I asked Ct to send the RESTORE script, the standard output error messages
    > and logfile along with the backup set information. Iwill send these in a
    > mai
    > l to me.
    >
    > I will take a look and see what I find.
    > For further help Imay need to engage Ben also, if required.
    > @cus
    >
    > 29-DEC-99 17:33:14 GMT
    >
    > Hi Soumendra,
    >
    > These are the files related to TAR 12605535.600
    >
    > <> <> <>
    > <> <>
    >
    > ==============
    > OEBU_rthire.res:
    > ==============
    >
    > restore database
    > backup_host = "peoplesun"
    > db_name = "rthire"
    > to = "12/12/1999 14:00:00"
    > recover = "12/12/1999 14:01:00"
    > parallel = 1
    > log = "/u01/oracle/backup/logs/OEBU_rthire.log"
    >
    > ==============
    > list_backups.log:
    > ==============
    > Oracle7 Enterprise Backup Utility Tool: Release 2.2.0.7.0 - Production on
    > Tu
    > e Dec 28 17:30:55 1999
    > Tape API: Release 3.1
    > Tape Management Software: Release 3.1.0.0
    > ..
    >
    > I did not see any backup for 12/12/1999 in the list.
    >
    > 29-DEC-99 17:47:37 GMT
    >
    > ========
    > output.log:
    > ========
    > sphinx:rthire> . ./OEBU_rthire_restore.sh
    > Oracle7 Enterprise Backup Utility: Release 2.2.0.7.0 - Production on Tue
    > Dec
    > 28 17:23:20 1999
    >
    > Copyright (c) Oracle Corporation 1979, 1996. All rights reserved.
    >
    > CORE Version 3.5.4.0.0 - Production
    > NLSRTL Version 3.2.4.0.0 - Production
    >
    > ORACLE_HOME = /u01/oracle/product/7.3.4
    > System name: SunOS
    > Node name: sphinx
    > Release: 5.6
    > Version: Generic_105181-11
    > Machine: sun4u
    > Tape API: Release 3.1
    > Tape Management Software: Release 3.1.0.0
    >
    > RESTORE job started with pid=29597 on Dec 28 1999 17:23:20
    >
    > Starting parsing of command script "/u01/oracle/backup/OEBU_rthire.res"
    > restore database
    > backup_host = "peoplesun"
    > db_name = "rthire"
    > to = "12/12/1999 14:00:00"
    > recover = "12/12/1999 14:01:00"
    > parallel = 1
    > log = "/u01/oracle/backup/logs/OEBU_rthire.log"
    > Ending parsing of command script
    >
    > Starting Catalog Database verification
    > Catalog Database verified
    > Ending Catalog Database verification
    >
    > Starting Instance Manager verification
    > Found Instance Manager (brd) process running with pid = 20851
    > Ending Instance Manager verification
    >
    > Starting Target Database state verification
    > Connecting toTarget Database
    > ORACLE_SID: rthire
    > ORACLE_HOME: /u01/oracle/product/7.3.4
    > DBNAME: RTHIRE
    > Username: ebudba
    >
    > Connected to idle instance.
    >
    > 4/dbs/initrthire.ora". Use STARTUP_PFILE in script if using a different one



  3. Re: OEBU and Y2K compliance

    Well, everything works fine to a point and then I get the errors below. I
    currently have a call in to veritas and am waiting to hear back from them.
    When I do I will post again. Anyway, the OS info for our system is as follows:

    System name: DYNIX/ptx
    Node name: wrasse
    Release: 4.0
    Version: V4.4.4
    Machine: i386
    Tape API: Release 2.0
    Tape Management Software: Release 3.2.0.0


    An portion of the log file with the errors I get and oracle EBU error
    explanations are as follows:

    ..
    ..
    ..
    Ending Database job building

    Starting Shutdown of target database for offline backup
    Issuing Statement: SHUTDOWN IMMEDIATE;
    Database dismounted.
    Database shutdown.
    Ended Shutdown of target database for offline backup

    Starting backup to tape

    Number of parallel I/O streams: 1
    Oracle block size: 8192 bytes
    Disk input/output size: 131072 bytes
    Maximum tape I/O size: 262144 bytes
    Buffer size per I/O stream: 1048576 bytes

    Starting BFS "00006539046f85" on 24-APR-2000 09:00:05 (30.008 MB)
    "/u08/oracle/data/hs01/system01.dbf" for 30.008 MB
    EBU-7043: Sbtwrite: System error
    on 04/24/2000 09:19:17 [ 13048 : britwrite ]
    EBU-503: Additional Operating System information, error -1:
    on 04/24/2000 09:19:17 [ 13048 : britwrite ]
    EBU-4306: Error occured while writing data to tape
    on 04/24/2000 09:19:17 [ 13048 : britwrite ]
    EBU-7023: Sbtclose: System error
    on 04/24/2000 09:19:17 [ 13048 : britclose ]
    EBU-503: Additional Operating System information, error -1:
    on 04/24/2000 09:19:17 [ 13048 : britclose ]
    EBU-4305: Error occured while closing a Backup File Set (handle 9)
    on 04/24/2000 09:19:17 [ 13048 : britclose ]
    BFS in progress "00006539046f85" cancelled on 24-APR-2000 09:19:17



    Ending backup to tape

    EBU-2012: Job 49 failed due to tape management error
    on 24-APR-2000 09:19:17 [ 12937 : brcdodbfil ]

    Database Backup job 49 FAILED on 24-APR-2000 09:19:17

    BACKUP job FAILED on 24-APR-2000 09:19:18




    It never even tries to load the tape in the drive. The oracle explanation of
    the EBU errors follows:

    Oracle Error Message Definitions

    hs01% oerr ebu 7043
    7043, 0, "Sbtwrite: System error"
    // *Cause: Error in Media Management Layer Software
    // *Action: Resolve with media management software vendor
    // *Type: Internal
    // *Contact: MML Vendor Support with the log file for the operation.
    hs01%
    hs01% oerr ebu 503
    503, 0, "Additional Operating System information, error %d: %s"
    // *Cause: An error during an Operating System operation was detected,
    // this error is the cause of the preceding error.
    // *Action: Please correct the Operating System error before retrying the
    // operation. If unable to determine the underlying Operating System
    // error, contact your System Support Engineer.
    // *Type: Internal
    // *Contact: Refer to your Operating System documentation.
    hs01%
    hs01% oerr ebu 4306
    4306, 0, "Error occured while writing data to tape"
    // *Cause: The Media Management Layer (sbtwrite) reported an error
    // while the BRIO process was writing to tape.
    // *Action: Resolve with media management software vendor
    // *Type: Internal
    // *Contact: MML Vendor Support with the log file for the operation.
    hs01%
    hs01% oerr ebu 7023
    7023, 0, "Sbtclose: System error "
    // *Cause: Error in Media Management Layer Software
    // *Action: Resolve with media management software vendor
    // *Type: Internal
    // *Contact: MML Vendor Support with the log file for the operation.
    hs01%
    hs01% oerr ebu 4305
    4305, 0, "Error occured while closing a Backup File Set (handle %d)"
    // *Cause: The Media Management Layer (sbtclose) reported an error
    // while closing a Backup File Set. The error message contains
    // the value obtained by the BRIO process when the Backup File
    // Set was opened.
    // *Action: Resolve with media management software vendor
    // *Type: Internal
    // *Contact: MML Vendor Support with the log file for the operation.
    hs01%


    That's it for now.



    Dan Kalusche wrote:

    > What other problems are you having with EBU? We are also running DYNIX/ptx,
    > and that has been the source of most of our EBU problems.
    >
    > Tim Meyer wrote:
    > >I had a similiar problem and Oracle mentioned a Y2K problem with version

    > 2.2.0.7
    > >so they had me install the patch to bring it up to version 2.2.0.9. Well,

    > I don't
    > >have the problem anymore but have a different one now so I am still stuck,

    > but I
    > >would install the patch to get you to 2.2.0.9 They have the patch online

    > for
    > >Solaris and other systems. I am running on DYNIX/ptx though and they didn't

    > have
    > >one immediately online so they had to dig one up from somewhere.
    > >
    > >Leonid wrote:
    > >
    > >> Hi everybody,
    > >>
    > >> I am having a problem trying to restore Oracle database using Netbackup

    > 3.1
    > >> and OEBU 2.2.0.7
    > >> The following is the log from trouble ticket I opened with Oracle. Has

    > anybody
    > >> seen this before? Any suggestions?
    > >> Leonid
    > >>
    > >> LOG:
    > >>
    > >> Ct has EBU for backup. 2.2.0.7 installed.
    > >> He has Veritas Netbackup for Media Management Software.
    > >>
    > >> His restore does not work when he species
    > >> TO = "12/19/1999" or similar with 12 in month.
    > >>
    > >> NetBackup log tries to find information
    > >> From date: "01/09/1970"
    > >> To Date: "01/11/1970" and fails.
    > >>
    > >> I am not sure why it is looking for information in that date range.
    > >>
    > >> But in 7.3.4 the bp.conf file must also be put in $ORACLE_HOME.
    > >> It is there.
    > >>
    > >> TO="11/19/1999" works fine when he specifies it in the restore script.
    > >>
    > >> I could not find any information on WebIVbased on the above information.
    > >>
    > >> I asked Ct to send the RESTORE script, the standard output error messages
    > >> and logfile along with the backup set information. Iwill send these in

    > a
    > >> mai
    > >> l to me.
    > >>
    > >> I will take a look and see what I find.
    > >> For further help Imay need to engage Ben also, if required.
    > >> @cus
    > >>
    > >> 29-DEC-99 17:33:14 GMT
    > >>
    > >> Hi Soumendra,
    > >>
    > >> These are the files related to TAR 12605535.600
    > >>
    > >> <> <> <>
    > >> <> <>
    > >>
    > >> ==============
    > >> OEBU_rthire.res:
    > >> ==============
    > >>
    > >> restore database
    > >> backup_host = "peoplesun"
    > >> db_name = "rthire"
    > >> to = "12/12/1999 14:00:00"
    > >> recover = "12/12/1999 14:01:00"
    > >> parallel = 1
    > >> log = "/u01/oracle/backup/logs/OEBU_rthire.log"
    > >>
    > >> ==============
    > >> list_backups.log:
    > >> ==============
    > >> Oracle7 Enterprise Backup Utility Tool: Release 2.2.0.7.0 - Production

    > on
    > >> Tu
    > >> e Dec 28 17:30:55 1999
    > >> Tape API: Release 3.1
    > >> Tape Management Software: Release 3.1.0.0
    > >> ..
    > >>
    > >> I did not see any backup for 12/12/1999 in the list.
    > >>
    > >> 29-DEC-99 17:47:37 GMT
    > >>
    > >> ========
    > >> output.log:
    > >> ========
    > >> sphinx:rthire> . ./OEBU_rthire_restore.sh
    > >> Oracle7 Enterprise Backup Utility: Release 2.2.0.7.0 - Production on Tue
    > >> Dec
    > >> 28 17:23:20 1999
    > >>
    > >> Copyright (c) Oracle Corporation 1979, 1996. All rights reserved.
    > >>
    > >> CORE Version 3.5.4.0.0 - Production
    > >> NLSRTL Version 3.2.4.0.0 - Production
    > >>
    > >> ORACLE_HOME = /u01/oracle/product/7.3.4
    > >> System name: SunOS
    > >> Node name: sphinx
    > >> Release: 5.6
    > >> Version: Generic_105181-11
    > >> Machine: sun4u
    > >> Tape API: Release 3.1
    > >> Tape Management Software: Release 3.1.0.0
    > >>
    > >> RESTORE job started with pid=29597 on Dec 28 1999 17:23:20
    > >>
    > >> Starting parsing of command script "/u01/oracle/backup/OEBU_rthire.res"
    > >> restore database
    > >> backup_host = "peoplesun"
    > >> db_name = "rthire"
    > >> to = "12/12/1999 14:00:00"
    > >> recover = "12/12/1999 14:01:00"
    > >> parallel = 1
    > >> log = "/u01/oracle/backup/logs/OEBU_rthire.log"
    > >> Ending parsing of command script
    > >>
    > >> Starting Catalog Database verification
    > >> Catalog Database verified
    > >> Ending Catalog Database verification
    > >>
    > >> Starting Instance Manager verification
    > >> Found Instance Manager (brd) process running with pid = 20851
    > >> Ending Instance Manager verification
    > >>
    > >> Starting Target Database state verification
    > >> Connecting toTarget Database
    > >> ORACLE_SID: rthire
    > >> ORACLE_HOME: /u01/oracle/product/7.3.4
    > >> DBNAME: RTHIRE
    > >> Username: ebudba
    > >>
    > >> Connected to idle instance.
    > >>
    > >> 4/dbs/initrthire.ora". Use STARTUP_PFILE in script if using a different

    > one
    > >



  4. Re: OEBU and Y2K compliance


    What other problems are you having with EBU? We are also running DYNIX/ptx,
    and that has been the source of most of our EBU problems.

    Tim Meyer wrote:
    >I had a similiar problem and Oracle mentioned a Y2K problem with version

    2.2.0.7
    >so they had me install the patch to bring it up to version 2.2.0.9. Well,

    I don't
    >have the problem anymore but have a different one now so I am still stuck,

    but I
    >would install the patch to get you to 2.2.0.9 They have the patch online

    for
    >Solaris and other systems. I am running on DYNIX/ptx though and they didn't

    have
    >one immediately online so they had to dig one up from somewhere.
    >
    >Leonid wrote:
    >
    >> Hi everybody,
    >>
    >> I am having a problem trying to restore Oracle database using Netbackup

    3.1
    >> and OEBU 2.2.0.7
    >> The following is the log from trouble ticket I opened with Oracle. Has

    anybody
    >> seen this before? Any suggestions?
    >> Leonid
    >>
    >> LOG:
    >>
    >> Ct has EBU for backup. 2.2.0.7 installed.
    >> He has Veritas Netbackup for Media Management Software.
    >>
    >> His restore does not work when he species
    >> TO = "12/19/1999" or similar with 12 in month.
    >>
    >> NetBackup log tries to find information
    >> From date: "01/09/1970"
    >> To Date: "01/11/1970" and fails.
    >>
    >> I am not sure why it is looking for information in that date range.
    >>
    >> But in 7.3.4 the bp.conf file must also be put in $ORACLE_HOME.
    >> It is there.
    >>
    >> TO="11/19/1999" works fine when he specifies it in the restore script.
    >>
    >> I could not find any information on WebIVbased on the above information.
    >>
    >> I asked Ct to send the RESTORE script, the standard output error messages
    >> and logfile along with the backup set information. Iwill send these in

    a
    >> mai
    >> l to me.
    >>
    >> I will take a look and see what I find.
    >> For further help Imay need to engage Ben also, if required.
    >> @cus
    >>
    >> 29-DEC-99 17:33:14 GMT
    >>
    >> Hi Soumendra,
    >>
    >> These are the files related to TAR 12605535.600
    >>
    >> <> <> <>
    >> <> <>
    >>
    >> ==============
    >> OEBU_rthire.res:
    >> ==============
    >>
    >> restore database
    >> backup_host = "peoplesun"
    >> db_name = "rthire"
    >> to = "12/12/1999 14:00:00"
    >> recover = "12/12/1999 14:01:00"
    >> parallel = 1
    >> log = "/u01/oracle/backup/logs/OEBU_rthire.log"
    >>
    >> ==============
    >> list_backups.log:
    >> ==============
    >> Oracle7 Enterprise Backup Utility Tool: Release 2.2.0.7.0 - Production

    on
    >> Tu
    >> e Dec 28 17:30:55 1999
    >> Tape API: Release 3.1
    >> Tape Management Software: Release 3.1.0.0
    >> ..
    >>
    >> I did not see any backup for 12/12/1999 in the list.
    >>
    >> 29-DEC-99 17:47:37 GMT
    >>
    >> ========
    >> output.log:
    >> ========
    >> sphinx:rthire> . ./OEBU_rthire_restore.sh
    >> Oracle7 Enterprise Backup Utility: Release 2.2.0.7.0 - Production on Tue
    >> Dec
    >> 28 17:23:20 1999
    >>
    >> Copyright (c) Oracle Corporation 1979, 1996. All rights reserved.
    >>
    >> CORE Version 3.5.4.0.0 - Production
    >> NLSRTL Version 3.2.4.0.0 - Production
    >>
    >> ORACLE_HOME = /u01/oracle/product/7.3.4
    >> System name: SunOS
    >> Node name: sphinx
    >> Release: 5.6
    >> Version: Generic_105181-11
    >> Machine: sun4u
    >> Tape API: Release 3.1
    >> Tape Management Software: Release 3.1.0.0
    >>
    >> RESTORE job started with pid=29597 on Dec 28 1999 17:23:20
    >>
    >> Starting parsing of command script "/u01/oracle/backup/OEBU_rthire.res"
    >> restore database
    >> backup_host = "peoplesun"
    >> db_name = "rthire"
    >> to = "12/12/1999 14:00:00"
    >> recover = "12/12/1999 14:01:00"
    >> parallel = 1
    >> log = "/u01/oracle/backup/logs/OEBU_rthire.log"
    >> Ending parsing of command script
    >>
    >> Starting Catalog Database verification
    >> Catalog Database verified
    >> Ending Catalog Database verification
    >>
    >> Starting Instance Manager verification
    >> Found Instance Manager (brd) process running with pid = 20851
    >> Ending Instance Manager verification
    >>
    >> Starting Target Database state verification
    >> Connecting toTarget Database
    >> ORACLE_SID: rthire
    >> ORACLE_HOME: /u01/oracle/product/7.3.4
    >> DBNAME: RTHIRE
    >> Username: ebudba
    >>
    >> Connected to idle instance.
    >>
    >> 4/dbs/initrthire.ora". Use STARTUP_PFILE in script if using a different

    one
    >



  5. Re: OEBU and Y2K compliance


    Tim,
    We are seeing the same thing here. I've opened a call with Veritas on this.
    In the past, we've seen problems occur with the libobk file that is used
    in the database extension, for Sequent computers. They redid a libobk for
    us at one time. I'll ask if there are any updates for that.
    Dan

    Tim Meyer wrote:
    >Well, everything works fine to a point and then I get the errors below.

    I
    >currently have a call in to veritas and am waiting to hear back from them.
    >When I do I will post again. Anyway, the OS info for our system is as follows:
    >
    >System name: DYNIX/ptx
    >Node name: wrasse
    >Release: 4.0
    >Version: V4.4.4
    >Machine: i386
    >Tape API: Release 2.0
    >Tape Management Software: Release 3.2.0.0
    >
    >
    >An portion of the log file with the errors I get and oracle EBU error
    >explanations are as follows:
    >
    >..
    >..
    >..
    > Ending Database job building
    >
    > Starting Shutdown of target database for offline backup
    > Issuing Statement: SHUTDOWN IMMEDIATE;
    > Database dismounted.
    > Database shutdown.
    > Ended Shutdown of target database for offline backup
    >
    > Starting backup to tape
    >
    > Number of parallel I/O streams: 1
    > Oracle block size: 8192 bytes
    > Disk input/output size: 131072 bytes
    > Maximum tape I/O size: 262144 bytes
    > Buffer size per I/O stream: 1048576 bytes
    >
    > Starting BFS "00006539046f85" on 24-APR-2000 09:00:05 (30.008 MB)
    > "/u08/oracle/data/hs01/system01.dbf" for 30.008 MB
    >EBU-7043: Sbtwrite: System error
    > on 04/24/2000 09:19:17 [ 13048 : britwrite ]
    >EBU-503: Additional Operating System information, error -1:
    > on 04/24/2000 09:19:17 [ 13048 : britwrite ]
    >EBU-4306: Error occured while writing data to tape
    > on 04/24/2000 09:19:17 [ 13048 : britwrite ]
    >EBU-7023: Sbtclose: System error
    > on 04/24/2000 09:19:17 [ 13048 : britclose ]
    >EBU-503: Additional Operating System information, error -1:
    > on 04/24/2000 09:19:17 [ 13048 : britclose ]
    >EBU-4305: Error occured while closing a Backup File Set (handle 9)
    > on 04/24/2000 09:19:17 [ 13048 : britclose ]
    > BFS in progress "00006539046f85" cancelled on 24-APR-2000 09:19:17
    >
    >
    >
    > Ending backup to tape
    >
    >EBU-2012: Job 49 failed due to tape management error
    > on 24-APR-2000 09:19:17 [ 12937 : brcdodbfil ]
    >
    > Database Backup job 49 FAILED on 24-APR-2000 09:19:17
    >
    >BACKUP job FAILED on 24-APR-2000 09:19:18
    >
    >
    >
    >
    >It never even tries to load the tape in the drive. The oracle explanation

    of
    >the EBU errors follows:
    >
    >Oracle Error Message Definitions
    >
    >hs01% oerr ebu 7043
    >7043, 0, "Sbtwrite: System error"
    >// *Cause: Error in Media Management Layer Software
    >// *Action: Resolve with media management software vendor
    >// *Type: Internal
    >// *Contact: MML Vendor Support with the log file for the operation.
    >hs01%
    >hs01% oerr ebu 503
    >503, 0, "Additional Operating System information, error %d: %s"
    >// *Cause: An error during an Operating System operation was detected,
    >// this error is the cause of the preceding error.
    >// *Action: Please correct the Operating System error before retrying the
    >// operation. If unable to determine the underlying Operating

    System
    >// error, contact your System Support Engineer.
    >// *Type: Internal
    >// *Contact: Refer to your Operating System documentation.
    >hs01%
    >hs01% oerr ebu 4306
    >4306, 0, "Error occured while writing data to tape"
    >// *Cause: The Media Management Layer (sbtwrite) reported an error
    >// while the BRIO process was writing to tape.
    >// *Action: Resolve with media management software vendor
    >// *Type: Internal
    >// *Contact: MML Vendor Support with the log file for the operation.
    >hs01%
    >hs01% oerr ebu 7023
    >7023, 0, "Sbtclose: System error "
    >// *Cause: Error in Media Management Layer Software
    >// *Action: Resolve with media management software vendor
    >// *Type: Internal
    >// *Contact: MML Vendor Support with the log file for the operation.
    >hs01%
    >hs01% oerr ebu 4305
    >4305, 0, "Error occured while closing a Backup File Set (handle %d)"
    >// *Cause: The Media Management Layer (sbtclose) reported an error
    >// while closing a Backup File Set. The error message contains
    >// the value obtained by the BRIO process when the Backup File
    >// Set was opened.
    >// *Action: Resolve with media management software vendor
    >// *Type: Internal
    >// *Contact: MML Vendor Support with the log file for the operation.
    >hs01%
    >
    >
    >That's it for now.
    >
    >
    >
    >Dan Kalusche wrote:
    >
    >> What other problems are you having with EBU? We are also running DYNIX/ptx,
    >> and that has been the source of most of our EBU problems.
    >>
    >> Tim Meyer wrote:
    >> >I had a similiar problem and Oracle mentioned a Y2K problem with version

    >> 2.2.0.7
    >> >so they had me install the patch to bring it up to version 2.2.0.9.

    Well,
    >> I don't
    >> >have the problem anymore but have a different one now so I am still stuck,

    >> but I
    >> >would install the patch to get you to 2.2.0.9 They have the patch online

    >> for
    >> >Solaris and other systems. I am running on DYNIX/ptx though and they

    didn't
    >> have
    >> >one immediately online so they had to dig one up from somewhere.
    >> >
    >> >Leonid wrote:
    >> >
    >> >> Hi everybody,
    >> >>
    >> >> I am having a problem trying to restore Oracle database using Netbackup

    >> 3.1
    >> >> and OEBU 2.2.0.7
    >> >> The following is the log from trouble ticket I opened with Oracle.

    Has
    >> anybody
    >> >> seen this before? Any suggestions?
    >> >> Leonid
    >> >>
    >> >> LOG:
    >> >>
    >> >> Ct has EBU for backup. 2.2.0.7 installed.
    >> >> He has Veritas Netbackup for Media Management Software.
    >> >>
    >> >> His restore does not work when he species
    >> >> TO = "12/19/1999" or similar with 12 in month.
    >> >>
    >> >> NetBackup log tries to find information
    >> >> From date: "01/09/1970"
    >> >> To Date: "01/11/1970" and fails.
    >> >>
    >> >> I am not sure why it is looking for information in that date range.
    >> >>
    >> >> But in 7.3.4 the bp.conf file must also be put in $ORACLE_HOME.
    >> >> It is there.
    >> >>
    >> >> TO="11/19/1999" works fine when he specifies it in the restore script.
    >> >>
    >> >> I could not find any information on WebIVbased on the above information.
    >> >>
    >> >> I asked Ct to send the RESTORE script, the standard output error messages
    >> >> and logfile along with the backup set information. Iwill send these

    in
    >> a
    >> >> mai
    >> >> l to me.
    >> >>
    >> >> I will take a look and see what I find.
    >> >> For further help Imay need to engage Ben also, if required.
    >> >> @cus
    >> >>
    >> >> 29-DEC-99 17:33:14 GMT
    >> >>
    >> >> Hi Soumendra,
    >> >>
    >> >> These are the files related to TAR 12605535.600
    >> >>
    >> >> <> <> <>
    >> >> <> <>
    >> >>
    >> >> ==============
    >> >> OEBU_rthire.res:
    >> >> ==============
    >> >>
    >> >> restore database
    >> >> backup_host = "peoplesun"
    >> >> db_name = "rthire"
    >> >> to = "12/12/1999 14:00:00"
    >> >> recover = "12/12/1999 14:01:00"
    >> >> parallel = 1
    >> >> log = "/u01/oracle/backup/logs/OEBU_rthire.log"
    >> >>
    >> >> ==============
    >> >> list_backups.log:
    >> >> ==============
    >> >> Oracle7 Enterprise Backup Utility Tool: Release 2.2.0.7.0 - Production

    >> on
    >> >> Tu
    >> >> e Dec 28 17:30:55 1999
    >> >> Tape API: Release 3.1
    >> >> Tape Management Software: Release 3.1.0.0
    >> >> ..
    >> >>
    >> >> I did not see any backup for 12/12/1999 in the list.
    >> >>
    >> >> 29-DEC-99 17:47:37 GMT
    >> >>
    >> >> ========
    >> >> output.log:
    >> >> ========
    >> >> sphinx:rthire> . ./OEBU_rthire_restore.sh
    >> >> Oracle7 Enterprise Backup Utility: Release 2.2.0.7.0 - Production on

    Tue
    >> >> Dec
    >> >> 28 17:23:20 1999
    >> >>
    >> >> Copyright (c) Oracle Corporation 1979, 1996. All rights reserved.
    >> >>
    >> >> CORE Version 3.5.4.0.0 - Production
    >> >> NLSRTL Version 3.2.4.0.0 - Production
    >> >>
    >> >> ORACLE_HOME = /u01/oracle/product/7.3.4
    >> >> System name: SunOS
    >> >> Node name: sphinx
    >> >> Release: 5.6
    >> >> Version: Generic_105181-11
    >> >> Machine: sun4u
    >> >> Tape API: Release 3.1
    >> >> Tape Management Software: Release 3.1.0.0
    >> >>
    >> >> RESTORE job started with pid=29597 on Dec 28 1999 17:23:20
    >> >>
    >> >> Starting parsing of command script "/u01/oracle/backup/OEBU_rthire.res"
    >> >> restore database
    >> >> backup_host = "peoplesun"
    >> >> db_name = "rthire"
    >> >> to = "12/12/1999 14:00:00"
    >> >> recover = "12/12/1999 14:01:00"
    >> >> parallel = 1
    >> >> log = "/u01/oracle/backup/logs/OEBU_rthire.log"
    >> >> Ending parsing of command script
    >> >>
    >> >> Starting Catalog Database verification
    >> >> Catalog Database verified
    >> >> Ending Catalog Database verification
    >> >>
    >> >> Starting Instance Manager verification
    >> >> Found Instance Manager (brd) process running with pid = 20851
    >> >> Ending Instance Manager verification
    >> >>
    >> >> Starting Target Database state verification
    >> >> Connecting toTarget Database
    >> >> ORACLE_SID: rthire
    >> >> ORACLE_HOME: /u01/oracle/product/7.3.4
    >> >> DBNAME: RTHIRE
    >> >> Username: ebudba
    >> >>
    >> >> Connected to idle instance.
    >> >>
    >> >> 4/dbs/initrthire.ora". Use STARTUP_PFILE in script if using a different

    >> one
    >> >

    >



  6. Re: OEBU and Y2K compliance

    Dan,

    I got the problem fixed. I was running version 2.2.0.9 of EBU and Veritas called
    and said it was a known problem and I had to install the patch from the following
    file:

    patchS0820333.sequent4.2.tar

    All that is in it is the /usr/openv/netbackup/bin/libobk.so file. Once I did that,
    it backed up like advertised. Now though I am having problems restoring to a
    different platform (also a DYNIX/pts platform though). I get EBU errors 7009 and
    4304, both of which point to the Veritas software. I emailed the error to support
    a few minutes ago and am awaiting their answer.

    TIM

    Dan Kalusche wrote:

    > Tim,
    > We are seeing the same thing here. I've opened a call with Veritas on this.
    > In the past, we've seen problems occur with the libobk file that is used
    > in the database extension, for Sequent computers. They redid a libobk for
    > us at one time. I'll ask if there are any updates for that.
    > Dan
    >
    > Tim Meyer wrote:
    > >Well, everything works fine to a point and then I get the errors below.

    > I
    > >currently have a call in to veritas and am waiting to hear back from them.
    > >When I do I will post again. Anyway, the OS info for our system is as follows:
    > >
    > >System name: DYNIX/ptx
    > >Node name: wrasse
    > >Release: 4.0
    > >Version: V4.4.4
    > >Machine: i386
    > >Tape API: Release 2.0
    > >Tape Management Software: Release 3.2.0.0
    > >
    > >
    > >An portion of the log file with the errors I get and oracle EBU error
    > >explanations are as follows:
    > >
    > >..
    > >..
    > >..
    > > Ending Database job building
    > >
    > > Starting Shutdown of target database for offline backup
    > > Issuing Statement: SHUTDOWN IMMEDIATE;
    > > Database dismounted.
    > > Database shutdown.
    > > Ended Shutdown of target database for offline backup
    > >
    > > Starting backup to tape
    > >
    > > Number of parallel I/O streams: 1
    > > Oracle block size: 8192 bytes
    > > Disk input/output size: 131072 bytes
    > > Maximum tape I/O size: 262144 bytes
    > > Buffer size per I/O stream: 1048576 bytes
    > >
    > > Starting BFS "00006539046f85" on 24-APR-2000 09:00:05 (30.008 MB)
    > > "/u08/oracle/data/hs01/system01.dbf" for 30.008 MB
    > >EBU-7043: Sbtwrite: System error
    > > on 04/24/2000 09:19:17 [ 13048 : britwrite ]
    > >EBU-503: Additional Operating System information, error -1:
    > > on 04/24/2000 09:19:17 [ 13048 : britwrite ]
    > >EBU-4306: Error occured while writing data to tape
    > > on 04/24/2000 09:19:17 [ 13048 : britwrite ]
    > >EBU-7023: Sbtclose: System error
    > > on 04/24/2000 09:19:17 [ 13048 : britclose ]
    > >EBU-503: Additional Operating System information, error -1:
    > > on 04/24/2000 09:19:17 [ 13048 : britclose ]
    > >EBU-4305: Error occured while closing a Backup File Set (handle 9)
    > > on 04/24/2000 09:19:17 [ 13048 : britclose ]
    > > BFS in progress "00006539046f85" cancelled on 24-APR-2000 09:19:17
    > >
    > >
    > >
    > > Ending backup to tape
    > >
    > >EBU-2012: Job 49 failed due to tape management error
    > > on 24-APR-2000 09:19:17 [ 12937 : brcdodbfil ]
    > >
    > > Database Backup job 49 FAILED on 24-APR-2000 09:19:17
    > >
    > >BACKUP job FAILED on 24-APR-2000 09:19:18
    > >
    > >
    > >
    > >
    > >It never even tries to load the tape in the drive. The oracle explanation

    > of
    > >the EBU errors follows:
    > >
    > >Oracle Error Message Definitions
    > >
    > >hs01% oerr ebu 7043
    > >7043, 0, "Sbtwrite: System error"
    > >// *Cause: Error in Media Management Layer Software
    > >// *Action: Resolve with media management software vendor
    > >// *Type: Internal
    > >// *Contact: MML Vendor Support with the log file for the operation.
    > >hs01%
    > >hs01% oerr ebu 503
    > >503, 0, "Additional Operating System information, error %d: %s"
    > >// *Cause: An error during an Operating System operation was detected,
    > >// this error is the cause of the preceding error.
    > >// *Action: Please correct the Operating System error before retrying the
    > >// operation. If unable to determine the underlying Operating

    > System
    > >// error, contact your System Support Engineer.
    > >// *Type: Internal
    > >// *Contact: Refer to your Operating System documentation.
    > >hs01%
    > >hs01% oerr ebu 4306
    > >4306, 0, "Error occured while writing data to tape"
    > >// *Cause: The Media Management Layer (sbtwrite) reported an error
    > >// while the BRIO process was writing to tape.
    > >// *Action: Resolve with media management software vendor
    > >// *Type: Internal
    > >// *Contact: MML Vendor Support with the log file for the operation.
    > >hs01%
    > >hs01% oerr ebu 7023
    > >7023, 0, "Sbtclose: System error "
    > >// *Cause: Error in Media Management Layer Software
    > >// *Action: Resolve with media management software vendor
    > >// *Type: Internal
    > >// *Contact: MML Vendor Support with the log file for the operation.
    > >hs01%
    > >hs01% oerr ebu 4305
    > >4305, 0, "Error occured while closing a Backup File Set (handle %d)"
    > >// *Cause: The Media Management Layer (sbtclose) reported an error
    > >// while closing a Backup File Set. The error message contains
    > >// the value obtained by the BRIO process when the Backup File
    > >// Set was opened.
    > >// *Action: Resolve with media management software vendor
    > >// *Type: Internal
    > >// *Contact: MML Vendor Support with the log file for the operation.
    > >hs01%
    > >
    > >
    > >That's it for now.
    > >
    > >
    > >
    > >Dan Kalusche wrote:
    > >
    > >> What other problems are you having with EBU? We are also running DYNIX/ptx,
    > >> and that has been the source of most of our EBU problems.
    > >>
    > >> Tim Meyer wrote:
    > >> >I had a similiar problem and Oracle mentioned a Y2K problem with version
    > >> 2.2.0.7
    > >> >so they had me install the patch to bring it up to version 2.2.0.9.

    > Well,
    > >> I don't
    > >> >have the problem anymore but have a different one now so I am still stuck,
    > >> but I
    > >> >would install the patch to get you to 2.2.0.9 They have the patch online
    > >> for
    > >> >Solaris and other systems. I am running on DYNIX/ptx though and they

    > didn't
    > >> have
    > >> >one immediately online so they had to dig one up from somewhere.
    > >> >
    > >> >Leonid wrote:
    > >> >
    > >> >> Hi everybody,
    > >> >>
    > >> >> I am having a problem trying to restore Oracle database using Netbackup
    > >> 3.1
    > >> >> and OEBU 2.2.0.7
    > >> >> The following is the log from trouble ticket I opened with Oracle.

    > Has
    > >> anybody
    > >> >> seen this before? Any suggestions?
    > >> >> Leonid
    > >> >>
    > >> >> LOG:
    > >> >>
    > >> >> Ct has EBU for backup. 2.2.0.7 installed.
    > >> >> He has Veritas Netbackup for Media Management Software.
    > >> >>
    > >> >> His restore does not work when he species
    > >> >> TO = "12/19/1999" or similar with 12 in month.
    > >> >>
    > >> >> NetBackup log tries to find information
    > >> >> From date: "01/09/1970"
    > >> >> To Date: "01/11/1970" and fails.
    > >> >>
    > >> >> I am not sure why it is looking for information in that date range.
    > >> >>
    > >> >> But in 7.3.4 the bp.conf file must also be put in $ORACLE_HOME.
    > >> >> It is there.
    > >> >>
    > >> >> TO="11/19/1999" works fine when he specifies it in the restore script.
    > >> >>
    > >> >> I could not find any information on WebIVbased on the above information.
    > >> >>
    > >> >> I asked Ct to send the RESTORE script, the standard output error messages
    > >> >> and logfile along with the backup set information. Iwill send these

    > in
    > >> a
    > >> >> mai
    > >> >> l to me.
    > >> >>
    > >> >> I will take a look and see what I find.
    > >> >> For further help Imay need to engage Ben also, if required.
    > >> >> @cus
    > >> >>
    > >> >> 29-DEC-99 17:33:14 GMT
    > >> >>
    > >> >> Hi Soumendra,
    > >> >>
    > >> >> These are the files related to TAR 12605535.600
    > >> >>
    > >> >> <> <> <>
    > >> >> <> <>
    > >> >>
    > >> >> ==============
    > >> >> OEBU_rthire.res:
    > >> >> ==============
    > >> >>
    > >> >> restore database
    > >> >> backup_host = "peoplesun"
    > >> >> db_name = "rthire"
    > >> >> to = "12/12/1999 14:00:00"
    > >> >> recover = "12/12/1999 14:01:00"
    > >> >> parallel = 1
    > >> >> log = "/u01/oracle/backup/logs/OEBU_rthire.log"
    > >> >>
    > >> >> ==============
    > >> >> list_backups.log:
    > >> >> ==============
    > >> >> Oracle7 Enterprise Backup Utility Tool: Release 2.2.0.7.0 - Production
    > >> on
    > >> >> Tu
    > >> >> e Dec 28 17:30:55 1999
    > >> >> Tape API: Release 3.1
    > >> >> Tape Management Software: Release 3.1.0.0
    > >> >> ..
    > >> >>
    > >> >> I did not see any backup for 12/12/1999 in the list.
    > >> >>
    > >> >> 29-DEC-99 17:47:37 GMT
    > >> >>
    > >> >> ========
    > >> >> output.log:
    > >> >> ========
    > >> >> sphinx:rthire> . ./OEBU_rthire_restore.sh
    > >> >> Oracle7 Enterprise Backup Utility: Release 2.2.0.7.0 - Production on

    > Tue
    > >> >> Dec
    > >> >> 28 17:23:20 1999
    > >> >>
    > >> >> Copyright (c) Oracle Corporation 1979, 1996. All rights reserved.
    > >> >>
    > >> >> CORE Version 3.5.4.0.0 - Production
    > >> >> NLSRTL Version 3.2.4.0.0 - Production
    > >> >>
    > >> >> ORACLE_HOME = /u01/oracle/product/7.3.4
    > >> >> System name: SunOS
    > >> >> Node name: sphinx
    > >> >> Release: 5.6
    > >> >> Version: Generic_105181-11
    > >> >> Machine: sun4u
    > >> >> Tape API: Release 3.1
    > >> >> Tape Management Software: Release 3.1.0.0
    > >> >>
    > >> >> RESTORE job started with pid=29597 on Dec 28 1999 17:23:20
    > >> >>
    > >> >> Starting parsing of command script "/u01/oracle/backup/OEBU_rthire.res"
    > >> >> restore database
    > >> >> backup_host = "peoplesun"
    > >> >> db_name = "rthire"
    > >> >> to = "12/12/1999 14:00:00"
    > >> >> recover = "12/12/1999 14:01:00"
    > >> >> parallel = 1
    > >> >> log = "/u01/oracle/backup/logs/OEBU_rthire.log"
    > >> >> Ending parsing of command script
    > >> >>
    > >> >> Starting Catalog Database verification
    > >> >> Catalog Database verified
    > >> >> Ending Catalog Database verification
    > >> >>
    > >> >> Starting Instance Manager verification
    > >> >> Found Instance Manager (brd) process running with pid = 20851
    > >> >> Ending Instance Manager verification
    > >> >>
    > >> >> Starting Target Database state verification
    > >> >> Connecting toTarget Database
    > >> >> ORACLE_SID: rthire
    > >> >> ORACLE_HOME: /u01/oracle/product/7.3.4
    > >> >> DBNAME: RTHIRE
    > >> >> Username: ebudba
    > >> >>
    > >> >> Connected to idle instance.
    > >> >>
    > >> >> 4/dbs/initrthire.ora". Use STARTUP_PFILE in script if using a different
    > >> one
    > >> >

    > >



+ Reply to Thread