[comp.databases] sybase server 4.0e vs 4.01

mike@glisten.UUCP (Michael Wendel) (07/20/90)

We are running a wide area network of Sun systems across North America
connecting over 28 locations together using Sybase. There are 8 regional
locations each running a Sybase server on a SUN 4/280 system with
many Sun 386i and Sparcstation clients at each location (on an ethernet).

In addition there are remote locations with a Point to Point connection
to the nearest region. All the regions are tied together with dedicated
Point to Point lines. Our application handles distribution of data among
the regions and the individual Sybase servers. There are over 125 Sun 386i
clients and over 150 Sparcstation clients on the network.

The end user application is written using c++, sunview and Sybase DB library,
with over 200 stored procedures. The current version of Sybase used in
development and production is 4.0e (a major enhancement release [bug fix])
to the 4.0 release. We installed 4.0e in February.

Since 4.0e was installed, and due to growth in the use of the application,
we have been experiencing 3 major types of problems with the Sybase server.

Ther first problem is "infected process". This is where the sybase server
is managing many connections from clients and it somehow loses track of
the resources used by the connection. Sometimes we can kill it, and sometimes
we have to halt the server and restart it (breaking all user connections).
Usually other flakey problems occur if the infected process is killed and the
server left running (no halt and restart).

The second problem appears to be Server corruption of some sort with regard
to stored procedures. From time to time, we will start to get errors from
the server where SQL code that normally works, won't. We have determined
that reloading ALL the stored procedures corrects this problem. On a few
occasions, the server complains that the stored procedure is bad. Usually,
the error received indicates somthing unrleated, pointing at application 
error.

The third problem is the receipt of extraneous, premature EOF from the
server during an SQL request. The application sees it as a normal completion
of the SQL request and goes merrily about its business with incomplete data.
Examination of the Sybase error log, shows that the error occured. We
no have to monitor the log continuously to catch this condition.

Sybase is looking into these problems, and its a slow process. They are
difficult to catch, and when they occur, our production environment 
requires that we recover immediately. So we can't keep the problem online
for anyone to monitor very long.

Now after this long description of the problems and environment, this is what
I would like to find out:

1. Has anyone on the net seen these same problems? If so, have they been
   resolved and how?
2. Possibly migrating to 4.01, the latest release, will fix our problem.
   Has anyone done the migration to 4.01 from 4.0e? If so, what was involved?
3. Can I run 4.01 of the server and use the 4.0e application front ends?
   dwb, dblib, isql, and so on. We found that a fix applied in 4.0e dblib
   did not get into 4.01 dblib, so we need to stay with 4.0e dblib in the
   front end (client application).

Any help or advice would be appreciated. Thanks in advance.

========================================================================== 
Michael L. Wendel     (602) 464-5744                              /\ 
General Logistics International, Inc.                           /\\/ 
1201 S. Alma School Rd., Suite 7550, Mesa, AZ 85210             \//\ 
..!asuvax!glisten!mike  or attmail!mwendel                  GLI   \/ 

francois@welch.jhu.edu (Francois Schiettecatte) (07/21/90)

This is a message for Michael L. Wendel of GLI

I would be grateful if you would send any extra info you may have/
are going to get on the three problems you are experiencing. We have/are
experiencing the EOF problem and I think we have found out why we are getting
it. If I can have an e-mail address I will post that onto you, the person
who found out why is out right now.

Francois

e-mail francois@welchlab.welch.jhu.edu