|
Executing a stored procedure makes the network database server stop. The procedure declares a FOR loop (cursor) where it iterates a proxy table. Running the procedure I get "communication error" as the network database service sometimes stops. However sometime I do get a successful run. the proxy table is located in a remote server (oracle), so it seems to be an issue with the communication between sybase/oracle. Transcript of console.log I. 12/12 13:59:07. TCPIP link started successfully I. 12/12 13:59:07. Now accepting requests I am able to do crash the db network service by running a sql towards the proxy table also. SELECT * FROM PROXY_ORACLE_TABLE; There's less than 50 rows (though there is a blob column).
Is there a db log which would give me more details to figure out what's causing this? Or does anyone have an idea of what the issue might be? |
|
If the possibility exists that the server is down. I would copy the rows into a temp table and work on that set. Even then it is possible that the server stops responding during the select. Hope This Helps It is the Sybase Network database server which stops while running this procedure. So a temporary table would not help. It fails while using the remote server proxy table. The remote server is running fine though.
(12 Dec '12, 07:09)
Kman
|
Use "Remote Data Access Debugging" aka setting the CIS_OPTION = 7 might help. In general, I agree with Thomas's suggestion to avoid (or more correctly: reduce the probability of) such situations.
The exception must be found in the Sybase DB Server as this is the one which stops. The remote server is running fine
Does the database server stop (e.g. by a crash), or is it only the connection that is dropped? Does the console log (dbsrv12 -o myLog.txt) show anything of interest?
I would doubt that a crashing (or hung up) database server would send a -85 error...
The server stops (crash), yes. No the console log does not show anything about why or even that it did stop. I've added a transcript to the question
I've set cis_rowset_size = 1, which seems to make it more stable, though it's too early to say for sure
Do you have a support contract? If so, we would be interested in investigating the remote server proxy crash. You can also auto-submit any outstanding collected dump files by using
dbsupport -sa.You might also want to try the latest 12.0.1 EBF if you haven't already done that.
FWIW, the above log excerpt shows 12.0.1.3817, which is the latest EBF, isn't it?
Ah, yes - that is correct Volker, thanks. Sorry about that.
We should definitely attempt to capture more details about the crashing behaviour.
Which Oracle ODBC driver are you using? Are you using the "iAnywhere Solutions" version included with SQL Anywhere or are you using Oracle's ODBC driver?
...and setting the CIS_OPTION = 7 seems still worthwhile, methinks...