[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::rdb_60

Title:Oracle Rdb - Still a strategic database for DEC on Alpha AXP!
Notice:RDB_60 is archived, please use RDB_70..
Moderator:NOVA::SMITHISON
Created:Fri Mar 18 1994
Last Modified:Fri May 30 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5118
Total number of notes:28246

5086.0. "Version mis-match problem ?" by ORAREP::TAVIS::MIRO () Thu Feb 27 1997 12:57

    We have move an ACMS application from a node :
      AlphaVMS 6.2    rdb 6.1-04   Turbo 8400     ACMS 4.1-0
    
    To  AlphaVMS 6.2  RDB 6.1-1    Alphaserver 1000a        ACMS 4.1-0
    
    
    We have move the acms images and all required components.
    
    The acms server dies.
    From the RDB monitor log I can see that the server attached to the
    database.
    The acms server has a initialization routine that starts a transaction
    The process dies when trying to perform the initializtion routine.
    (SQLMOD)
    
    My question is : Does this have anything to do with the difference
    versions of RDB ?
    
    Please advise.
    -----------------------------------------------------------------------
    27-FEB-1997 19:52:21.60 - received user attach request from 2FE:1
      - process name ACMS00BSP002001, user TFH_ACMS_SUP
      - for database "_$1$DKA100:[000000.RDB.AP0000]AP_DB.RDB;3"
      - sending normal user attach reply to 2FE:1
    
    27-FEB-1997 19:52:21.60 - received user attach request from 2FD:1
      - process name ACMS00BSP001000, user TFH_ACMS_SUP
      - for database "_$1$DKA100:[000000.RDB.AP0000]AP_DB.RDB;3"
      - sending normal user attach reply to 2FD:1
    
    27-FEB-1997 19:52:22.04 - received user image termination from
    000002FE:1
      - abnormal user termination detected
      - database monitor created recovery process RDM_RB_1 (000002FF)
      - user termination suspended until recovery ready
    27-FEB-1997 19:52:22.48 - received recovery attach from 2FF:1
      - process name RDM_RB_1, user SYSTEM
      - sending normal recovery attach reply to 2FF:1
    
    27-FEB-1997 19:52:22.50 - received recovery ready from 2FF:1
      - process name RDM_RB_1, user SYSTEM
    
    -----------------------------------------------------------------------
    $ acms/start appl ap_appl_v0001
    %ACMSOPR-E-STRTAPLERR, Error while attempting to START APPLICATION
    AP_APPL_V0001
    -ACMSEXC-E-WP_TRM, Server Process for server AP_RW_SERVER defined in
    group AP_GR
    OUP_V0001 died unexpectedly
    -ACMSTWP-E-INIT_ERR, Error executing server initialization procedure
    %ACMSOPR-E-ERROR, Some operations may not have been performed
    
    -------------------------------------------------------------------
    
    Process UIC  : [001,004]
    Process name : ACMS01ACC001000
    Username     : SYSTEM
    Image file   : $1$DKA0:[SYS0.SYSCOMMON.][SYSEXE]ACMSACC.EXE;1
    
    %ACMSACC-I-EVENT, Event
    -ACMSACC-E-ERRSTARTA, Error occured starting application
    -ACMSEXC-E-WP_TRM, Server Process for server !AS defined in group !AS
    died unexp
    ectedly
    -----------------------------------------------------------------------
    Type   : ERROR     Time   : 27-FEB-1997 19:51:57.93
    Appl   : AP_APPL_V0001
    Text   : Error executing server initialization procedure
    -SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
    address=00884E18, PC
    =010E000D, PS=00020194
    -----------------------------------------------------------------------
    
T.RTitleUserPersonal
Name
DateLines
5086.1ORAREP::HERON::GODFRINDOracle Rdb EngineeringThu Feb 27 1997 14:0518
>    From the RDB monitor log I can see that the server attached to the
>    database.
>    The acms server has a initialization routine that starts a transaction
>    The process dies when trying to perform the initializtion routine.
>    (SQLMOD)
>    
>    My question is : Does this have anything to do with the difference
>    versions of RDB ?

Can you put additional tracing info in the initialization routine to try and
isolate the step that fails ? Put differently, are you sure the error comes
from Rdb ? If so, from what statement ?

Some other fairly recent notes (a month or so) indicate problems in an ACMS
application that caused access violations at commit. They got solved
eventually by upgrading some SNA software.  Look at note 4754.

/albert
5086.2more info - will supply more if neededORAREP::TAVIS::MIROThu Feb 27 1997 14:3121
    Thanks for your reply.
    
    That same application works fine on the development machine.
    When we moved all required files to the "production machine " and run
    the acms application we got the error. (no source files)
    
    Yes, the error is in the initialization routine which has 2 calls
    in it.
    1. Start transaction - seems to work since we see attachment to the
       database.
    2. Commit - immedialty after. Maybe this one fails.
    
    The question is why ? Is it due to the difference in the RDB version or
    maybe something else that I did not manage to isolate.
    
    If you have ideas or can point to some direction that will be great
    help.
    
    Thanks,
    Moshe
    
5086.3ORAREP::HERON::GODFRINDOracle Rdb EngineeringMon Mar 03 1997 02:2223
Moshe,

>    Yes, the error is in the initialization routine which has 2 calls
>    in it.
>    1. Start transaction - seems to work since we see attachment to the
>       database.
>    2. Commit - immedialty after. Maybe this one fails.

See if you can isolate the exact statement that does fail.
    
>    The question is why ? Is it due to the difference in the RDB version or
>    maybe something else that I did not manage to isolate.

The symptoms look similar to that other case I mentionned. There too, the 
problem started happening after an Rdb upgrade, so everyone suspected a problem
within Rdb. However, it turned out in the end that it was caused by another
totally unrelated product (an SNA API). The exception indicated some memory
corruption within Rdb structures (the structures used by the SQL and Dispatch
layers are in user mode, so are susceptible to corruptions by user code or
other software). I suspect that corruption had been there all along, but simply
hit some place that did not affect Rdb ... 

/albert