We have had our database server crash twice within the last couple days with
full DrWatson's. As I am assuming the engine being fairly stable I am
looking towards external influences contributing to the crash.

We do use a proxy database connection to another database (Oracle) that is
currently on a different machine (although we also got different crashes
when we were running on the same machine). I would like to know if we could
"isolate" the proxy connections so that driver-related crashes do not crash
the entire server. Is starting up a second "middle-man" ASA server to
handle the proxy connections a good idea, or would a proxy table between two
ASA database servers crash if one end goes down?

How can we do this in such a way so that this database stays up? I would
rathar avoid the "restart engine every morning at 2am" solution that has
been offered by others...

Erik

Do you really know if the crashes are directly attributable
to the use of proxy tables?

How have you figured that out and what version are you
using there? Also different platforms implement ODBC
differently so knowing the platform may be very germane.

Normally CIS /OMNI is supposed to be able to handle
normal ODBC errors, so it theoretically should be impossible
for any normal error condition to cause a crash. A bug in
an ODBC driver may be something else altogether but
do we know that is the case?

Unfortunately, if there is a crash pattern, knowing the exact
circumstances is probably going to be necessary to come
up with such a workaround.

I do see the ASE XPServer model in your reasoning and I
am not detracting you for that, but I don't see an easy way
of approximating that without some loss of functionally and
possibly a lot of overhead that may be unnecessarily be
added to an already trouble server.


HTH


"Erik Anderson" <erikba (AT) teamworkgroup (DOT) com> wrote

I don't have any hard evidence, these crashes are occurring onsite and it is
rathar difficult to get detailed tracking information from such a distance.
However, there is a lot of circumstantial evidence pointing to the proxy
database drivers.

The only information that I have been able to recover from the previous
DrWatson is that it *may* have occurred during a transient network outage.
Most of the servers we have had the engine on the last couple months have
been Windows XP systems, the current one (a user's workstation) is only
crashing a couple times per month. We have been regularly upgrading our
version of ASA8 and reloading the database.

I have in my ODBC development experience ran into many drivers that would
crash your application if you didn't look at them right. Turning on
"server-side cursors" with the MS SQL Server driver, for instance, will
instantly DrWatson your application.

The Oracle driver we are using is also the third "brand" of driver, as the
previous two have shown nasty incompatabilities or were otherwise unusable
to us in a production setting.

I will check out that XPServer, but I will also continue looking into
creating an ASA database that simply imports/exports proxy tables between
the oracle database and the actual ASA database.

"Nick Elson" <no_spam_nicelson (AT) sybase (DOT) com> wrote

Sorry Eric,

I didn't mean to mislead you there.

The XPServer is technology unique to ASE. That won't help
you with ASA. Your suggestion of forming two tiers of ASA
servers, as a workaround, somewhat reflects the way ASE
uses the XPServer architecture. You won't be able to leverage
XPS unless you are using ASE to begin with.

If you haven't done so yet, gather up all your Dr. Watsons
from the various sites and get someone in support to
review those. You may have a pattern that my be
worth further investigation. If nothing else, a confirmation
of the pattern may be able to be

If there is no pattern (and if there is nothing in the system/event
logs that tell you more) you may ***just be hitting a wall***.

Typically temporary disk space is ***the biggest wall***.
CIS/OMNI can aggravate this, because the optimizer must
(sometimes) build larger interim result sets (especially when
joining tables across two or more systems) than you may
be expecting from the same query to just ASA alone.

Turning on CIS_OPTION=6 and tracing when the crashes
occur, you may find a usage pattern worth looking into.

Good luck

Nick



"Erik Anderson" <erikba (AT) teamworkgroup (DOT) com> wrote

Here's a question related to this whole mess...

I am thinking of having two ASA databases running on different servers (not
just different databases) on the same machine.

I am expecting one of the servers to occasionally "jam". Symptoms: client
connection requests appear to have client freeze, cannot shutdown service,
must reboot machine to clear.

If I have a second ASA server which has proxy connections to a "jammed"
server, would the second ASA server jam as well? Is it possible to isolate
this condition to only one of the servers?

"Nick Elson" <no_spam_nicelson (AT) sybase (DOT) com> wrote

I cannot say for certain. It is still a pretty generic kind of question
since we still don't know why the first server is jamming/crashing.
Generically it should be ~more~ stable but there is no reason
to believe that the main server should have been unstable in the
first place.

It might positively impact the stability of the second server but
it may not. I would definitely look into ***increasing threads***
on the main server and then cranking up the NT/W2K/XP
Perfmon to capture any patterns.




"Erik Anderson" <erikba (AT) teamworkgroup (DOT) com> wrote