All, this may be slightly off topic but I have been asked to help
investigate an intermittent problem with a database, but they think that a
possible cause could be a communications problem and something to do with
tcp/ip configuration. I am really looking for suggestions to trouble shoot
and trace what is going on at this level sys_check is a start....
Thanks for your help
Charlotte
----------------------------------------------------------------------------
-----
Below are extracts of the problem I have been sent, sorry for the
length......
* DataLoaders - Parse raw data files external to the database then
insert results into the database
* DataDerivers - Perform various functions on data already loaded into
the database then insert the results into other tables on the same database.
Both of these processes use a elements of Java and JDBC to parse the data
and insert into the database.
We are currently experiencing a serious intermittent problem during the
execution of the second class of overnight jobs, the DataDerivers.
It is wothwhile noting that the data used by the DataDerivers has remained
static for several months, they therefore parse the same datasets every
night and (should) produce the same results every day.
The full error stack reported by Oracle/JDBC is shown below however what
appears to be happening is that a Java thread is happily connected to the
database passing data back and forward when something kills the comms.
These errors are intermittent and do not occur in the same place and time,
which, as the source data and code are static, suggests communications might
be the cause.
To further complicate matters, we have nights where all the processes
complete without error, most recently last Saturday and Sunday nights. It is
also possible to successfully re-run a previously failed process at any
time.
Current list of possibilities:
1. TCP/IP Configuration
Formida UK have spoken about this error with their developers in the US. One
of the suggestions on seeing the error message was that it may be related to
a TCP/IP timeout.
If you look at the error message stack reported back from Oracle the
starting point (ie furthest back in the stack) is:
at oracle.net.ns.Packet.receive (pc 201)
The thinking is that this indicates a problem receiving data packets back
into the program.
As can be seen from the oracle diagram showing how the JDBC driver works it
shows a use of TCP/IP.
Therefore the question of whether the TCP/IP configuration need checking
arises. Eg There is "KEEP ALIVE' parameter -is there error due a TCP/IP
timeout whilst waiting for packets???
java.lang.NullPointerException
at oracle.net.ns.Packet.receive (pc 201)
at oracle.net.ns.NetInputStream.getNextPacket (pc 48)
at oracle.net.ns.NetInputStream.read(byte[],int,int) (pc 21)
at oracle.net.ns.NetInputStream.read(byte[]) (pc 5)
at oracle.net.ns.NetInputStream.read() (pc 6)
at oracle.jdbc.ttc7.MAREngine.unmarshalUB1 (MAREngine.java:718) (pc
6)
at oracle.jdbc.ttc7.MAREngine.unmarshalSB1 (MAREngine.java:690) (pc
1)
at oracle.jdbc.ttc7.Oall7.receive (Oall7.java:372) (pc 15)
at oracle.jdbc.ttc7.TTC7Protocol.doOall7 (TTC7Protocol.java:1311)
(pc 204)
at oracle.jdbc.ttc7.TTC7Protocol.executeFetch
(TTC7Protocol.java:661) (pc 44)
at oracle.jdbc.driver.OracleStatement.executeNonQuery
(OracleStatement.java:1320) (pc 326)
at oracle.jdbc.driver.OracleStatement.doExecuteOther
(OracleStatement.java:1232) (pc 193)
at oracle.jdbc.driver.OracleStatement.doExecuteWithBatch
(OracleStatement.java:1353) (pc 72)
at oracle.jdbc.driver.OracleStatement.doExecute
(OracleStatement.java:1760) (pc 35)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout
(OracleStatement.java:1807) (pc 91)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate
(OraclePreparedStatement.java:332) (pc 67)
at oracle.jdbc.driver.OraclePreparedStatement.execute
(OraclePreparedStatement.java:376) (pc 24)
at COM.formida.OSW.Coverages.LiveCoverageCompute.save
(LiveCoverageCompute.java:136) (pc 81)
at COM.formida.OSW.Coverages.CoverageThread.run
(CoverageThread.java:108) (pc 121)
Received on Fri Sep 29 2000 - 12:28:53 NZST