|
Home > Archive > SQL Anywhere database > July 2005 > symbol server lookup?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
symbol server lookup?
|
|
| Erik Anderson 2005-07-18, 1:23 pm |
| I am attempting to diagnose an ASA service failure that appears to occur on
a semi-daily basis, usually but not always outside of business hours (when
only scheduled events are running). I would appreciate it if I could have a
symbol lookup so that I could have a better idea what might be causing these
faults.
File: dbserv9.dll
Version: 9.0.2.2551
Address: 0x002aa8f5
| |
| Chris Keating \(iAnywhere Solutions\) 2005-07-18, 8:23 pm |
| You should engage technical support on this issue as this is an user
community forum.
"Erik Anderson" < erikba@teamworkgroup
.com> wrote in message
news:42dbf862$1@foru
ms-2-dub...
>I am attempting to diagnose an ASA service failure that appears to occur on
>a semi-daily basis, usually but not always outside of business hours (when
>only scheduled events are running). I would appreciate it if I could have
>a symbol lookup so that I could have a better idea what might be causing
>these faults.
>
> File: dbserv9.dll
> Version: 9.0.2.2551
> Address: 0x002aa8f5
>
| |
| Joshua Savill 2005-07-18, 8:23 pm |
| Erik,
I'm not sure what you mean by symbol lookup, but I have a feeling that one
of the events is causing the database server to crash. Is there any way you
can isolate which event is running when the database server crashes. Perhaps
using dbsrv9 -zr SQL -o output.txt will be able to determine the statement
or sequence of statements that causes the crash.
If you can determine the cause, I recommend looking through the EBF reports
to try and determine if this problem has been resolved in a later version of
ASA 9.0.2. There was a recent fix to ASA 9.0.2 where a stored procedure
could crash the database server. If it is still causing a problem, I
recommend opening up a case with technical support (1-800-8Sybase).
--
Joshua Savill
iAnywhere Solutions - Product Support Analyst
"Erik Anderson" < erikba@teamworkgroup
.com> wrote in message
news:42dbf862$1@foru
ms-2-dub...
>I am attempting to diagnose an ASA service failure that appears to occur on
>a semi-daily basis, usually but not always outside of business hours (when
>only scheduled events are running). I would appreciate it if I could have
>a symbol lookup so that I could have a better idea what might be causing
>these faults.
>
> File: dbserv9.dll
> Version: 9.0.2.2551
> Address: 0x002aa8f5
>
| |
| Erik Anderson 2005-07-18, 8:23 pm |
| Thank you for your response, not sure what either one of us can do to track
down this issue, looks like I'm gonna have to do a server version bump soon.
I hate doing that on a prod server, always feels like i'm stepping out
blindly...
"Joshua Savill" <jsavill@ianywhere.com> wrote in message
news:42dc0114$1@foru
ms-2-dub...
> Erik,
>
> I'm not sure what you mean by symbol lookup, but I have a feeling that one
> of the events is causing the database server to crash. Is there any way
> you can isolate which event is running when the database server crashes.
> Perhaps using dbsrv9 -zr SQL -o output.txt will be able to determine the
> statement or sequence of statements that causes the crash.
>
> If you can determine the cause, I recommend looking through the EBF
> reports to try and determine if this problem has been resolved in a later
> version of ASA 9.0.2. There was a recent fix to ASA 9.0.2 where a stored
> procedure could crash the database server. If it is still causing a
> problem, I recommend opening up a case with technical support
> (1-800-8Sybase).
>
> --
> Joshua Savill
> iAnywhere Solutions - Product Support Analyst
>
> "Erik Anderson" < erikba@teamworkgroup
.com> wrote in message
> news:42dbf862$1@foru
ms-2-dub...
>
>
| |
| Stephen Rice 2005-07-18, 8:23 pm |
| Erik Anderson wrote:
> Thank you for your response, not sure what either one of us can do to track
> down this issue, looks like I'm gonna have to do a server version bump soon.
> I hate doing that on a prod server, always feels like i'm stepping out
> blindly...
>
> "Joshua Savill" <jsavill@ianywhere.com> wrote in message
> news:42dc0114$1@foru
ms-2-dub...
>
>
>
I'd put some message statements into the events and make sure the server
is running with -o That will tell you what event was running
Nothing has been said yet that suggests we have fixed the problem you
are encountering so I wouldn't upgrade.
/steve
--
Stephen Rice
Technical Services Manager
iAnywhere Solutions
--- Please Post ---
Whitepapers, Tech Docs, Solved Cases, Bug Fixes and
"Report a bug" are all available on www.ianywhere.com
| |
| Erik Anderson 2005-07-19, 8:23 pm |
| I would like to confirm that when ASA faults, that when it comes up it
removes all transactions in the transaction log following the most recent
checkpoint?
"Stephen Rice" <NSsrice@ianywhere.com> wrote in message
news:42dc1963$1@foru
ms-1-dub...
> I'd put some message statements into the events and make sure the server
> is running with -o That will tell you what event was running
>
> Nothing has been said yet that suggests we have fixed the problem you are
> encountering so I wouldn't upgrade.
>
> /steve
>
> --
> Stephen Rice
> Technical Services Manager
> iAnywhere Solutions
>
> --- Please Post ---
> Whitepapers, Tech Docs, Solved Cases, Bug Fixes and
> "Report a bug" are all available on www.ianywhere.com
| |
| Joshua Savill 2005-07-19, 8:23 pm |
| When the database recovers after the server has crashed, it will rollback
all uncommitted transactions. Any committed transaction after the last
checkpoint should still remain in the database. Are you having problems with
this?
--
Joshua Savill
iAnywhere Solutions - Product Support Analyst
"Erik Anderson" < erikba@teamworkgroup
.com> wrote in message
news:42dd6863@forums
-1-dub...
>I would like to confirm that when ASA faults, that when it comes up it
>removes all transactions in the transaction log following the most recent
>checkpoint?
>
> "Stephen Rice" <NSsrice@ianywhere.com> wrote in message
> news:42dc1963$1@foru
ms-1-dub...
>
>
| |
| Erik Anderson 2005-07-19, 8:23 pm |
| I yanked the transaction log and asked for all transactions, including
uncommitted transactions. The last information I see is a CHECKPOINT
operation followed by a ROLLBACK_ALL macro. So either this happened right
after a checkpoint completed or the information has been wiped and the
transaction log is useless in figuring out what happened.
"Joshua Savill" <jsavill@ianywhere.com> wrote in message
news:42dd69d6$1@foru
ms-1-dub...
> When the database recovers after the server has crashed, it will rollback
> all uncommitted transactions. Any committed transaction after the last
> checkpoint should still remain in the database. Are you having problems
> with this?
>
> --
> Joshua Savill
> iAnywhere Solutions - Product Support Analyst
>
> "Erik Anderson" < erikba@teamworkgroup
.com> wrote in message
> news:42dd6863@forums
-1-dub...
>
>
| |
| Joshua Savill 2005-07-19, 8:23 pm |
| All committed transactions should remain in the database, even if the
database crashes.
--
Joshua Savill
iAnywhere Solutions - Product Support Analyst
"Erik Anderson" < erikba@teamworkgroup
.com> wrote in message
news:42dd6c4a@forums
-2-dub...
>I yanked the transaction log and asked for all transactions, including
>uncommitted transactions. The last information I see is a CHECKPOINT
>operation followed by a ROLLBACK_ALL macro. So either this happened right
>after a checkpoint completed or the information has been wiped and the
>transaction log is useless in figuring out what happened.
>
> "Joshua Savill" <jsavill@ianywhere.com> wrote in message
> news:42dd69d6$1@foru
ms-1-dub...
>
>
| |
| Joshua Savill 2005-07-19, 8:23 pm |
| The transaction log that you translated, had the database already gone
through a recovery with that transaction log? If so, then I would expect to
see a CHECKPOINT issued at the end of the database recovery process. This
would be why the last entry in the transaction log is a CHECKPOINT followed
by the ROLLBACK_ALL macro.
--
Joshua Savill
iAnywhere Solutions - Product Support Analyst
"Erik Anderson" < erikba@teamworkgroup
.com> wrote in message
news:42dd6c4a@forums
-2-dub...
>I yanked the transaction log and asked for all transactions, including
>uncommitted transactions. The last information I see is a CHECKPOINT
>operation followed by a ROLLBACK_ALL macro. So either this happened right
>after a checkpoint completed or the information has been wiped and the
>transaction log is useless in figuring out what happened.
>
> "Joshua Savill" <jsavill@ianywhere.com> wrote in message
> news:42dd69d6$1@foru
ms-1-dub...
>
>
|
|
|
|
|