[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
Title: | Oracle Rdb - Still a strategic database for DEC on Alpha AXP! |
Notice: | RDB_60 is archived, please use RDB_70 .. |
Moderator: | NOVA::SMITHI SON |
|
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.R | Title | User | Personal Name | Date | Lines |
---|
5086.1 | | ORAREP::HERON::GODFRIND | Oracle Rdb Engineering | Thu Feb 27 1997 14:05 | 18 |
| > 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.2 | more info - will supply more if needed | ORAREP::TAVIS::MIRO | | Thu Feb 27 1997 14:31 | 21 |
| 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.3 | | ORAREP::HERON::GODFRIND | Oracle Rdb Engineering | Mon Mar 03 1997 02:22 | 23 |
| 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
|