"Nick Elson [Sybase iAnywhere]" <@@@@com@>
2010-07-16 15:27:25 UTC
On the concern about rollbacks, make sure you include
the "-r" switch.
It is not certain what you are actually measuring here but
the following observastions may help:
It may be possible your login_procedure is issuing
a commit here. Also it is not uncommon for ODBC
applications and database frameworks to commit
every new connections; due to some implementing
logic to guarantee an autocommit behaviour, others
to clean-up history on connections possibly coming
from a connection pool. [not certain if commits with no
work pending get logged but a scenario]
The "-d" switch changes the way dbtran reports stuff.
More importantly it changes the order of actions and
may be reording things in the way that is confusing
you. I would try removing that. This effect alone
could be sufficient to explain your observation. This
'out of sequence' behaviour is highlighted in the
warning added to the head of the output
-- WARNING: Chronological ordered
output must not be applied to a database
similar caveats apply when reading. Also, when
operations in logs (console or transaction) occur at
the same clock resolution time, outputs can sometimes
reorder them as an artifact due to any sorting mechanisms.
Rollbacks at the ends of transactions and logs,
are not always displayed in the dbtran output unless
you add the "-r" switch. [some rollbacks are just
implied and understood]
You never see disconnects with dbtran. So it is
all too easy to associate operations from reused
connection ids when that is not the case. Since
you clearly are looking at a disconnect boundary
this is a factor to be aware of when assesing the
last two points.
It is possible the commit is a side effect of the
last operation (when the server is running in
'unchained' mode) and not comming from the
connection itself. As such it could be a housekeeping
entry required to clean up the reused connection
if only to keep it 'recoverable' during a startup or
application of backup log in a recovery scenario.
No. Checkpoints are not tied to commits.
If your application crashes or disconnects, uncommited
operations should be rolled back and the log should
be able to reflect that rollback (see -r comments above).
Some operations autocommit (DDL statements, DML
operations executed by the server with chained mode
off, ....) and so there must be some commit logged
in that case. It may be possible that trigger or RI
logic may present a delay to the commit.
It is possible you are looking at a reporting problem
with dbtran. V7 is pretty old (assuming you are using
the last 7.0.4EBF, 7.0 is much older than that) and
there may have been some problem in that version.
All in all it sound pretty benign. I can not determine
if the report represents any sort of fatal issue with
logging.
Do keep in mind the entries in the log were put in
there by the version of software running at the
of those connections time, and so the issue could
be due to older bugs than the reported version of dbtran.
And, well, you asked, but do not say why this is a concern
for you. If you do not have any recovery, replication or
indication of another area having troubles, it may be there
is nothing wrong here. Is there anything behind this concern?
CONNECT
--> BEGIN TRANSACTION
----> UPDATE OR INSERT
---> COMMIT.
I looked at a log file that started a transaction, did 2 INSERTS and then
sat there for a long time (about 20 minutes). I then saw another
CONNECT coming from the same ID. After the CONNECT, all it
did was COMMIT and then it was done.
I have never seen this behavior before where a separate CONNECT
is issued to do the COMMIT on a prior transaction. Does this have
something to do with a checkpoint maybe? Is this what would happen
if you had an application that did not execute the COMMIT?
Some of our stuff turns off autocommit and I did see where
there was a path to exit the function prior to issuing a
COMMIT.
Does ASA do COMMITS on a checkpoint or after a
period of time?
the "-r" switch.
It is not certain what you are actually measuring here but
the following observastions may help:
It may be possible your login_procedure is issuing
a commit here. Also it is not uncommon for ODBC
applications and database frameworks to commit
every new connections; due to some implementing
logic to guarantee an autocommit behaviour, others
to clean-up history on connections possibly coming
from a connection pool. [not certain if commits with no
work pending get logged but a scenario]
The "-d" switch changes the way dbtran reports stuff.
More importantly it changes the order of actions and
may be reording things in the way that is confusing
you. I would try removing that. This effect alone
could be sufficient to explain your observation. This
'out of sequence' behaviour is highlighted in the
warning added to the head of the output
-- WARNING: Chronological ordered
output must not be applied to a database
similar caveats apply when reading. Also, when
operations in logs (console or transaction) occur at
the same clock resolution time, outputs can sometimes
reorder them as an artifact due to any sorting mechanisms.
Rollbacks at the ends of transactions and logs,
are not always displayed in the dbtran output unless
you add the "-r" switch. [some rollbacks are just
implied and understood]
You never see disconnects with dbtran. So it is
all too easy to associate operations from reused
connection ids when that is not the case. Since
you clearly are looking at a disconnect boundary
this is a factor to be aware of when assesing the
last two points.
It is possible the commit is a side effect of the
last operation (when the server is running in
'unchained' mode) and not comming from the
connection itself. As such it could be a housekeeping
entry required to clean up the reused connection
if only to keep it 'recoverable' during a startup or
application of backup log in a recovery scenario.
No. Checkpoints are not tied to commits.
If your application crashes or disconnects, uncommited
operations should be rolled back and the log should
be able to reflect that rollback (see -r comments above).
Some operations autocommit (DDL statements, DML
operations executed by the server with chained mode
off, ....) and so there must be some commit logged
in that case. It may be possible that trigger or RI
logic may present a delay to the commit.
It is possible you are looking at a reporting problem
with dbtran. V7 is pretty old (assuming you are using
the last 7.0.4EBF, 7.0 is much older than that) and
there may have been some problem in that version.
All in all it sound pretty benign. I can not determine
if the report represents any sort of fatal issue with
logging.
Do keep in mind the entries in the log were put in
there by the version of software running at the
of those connections time, and so the issue could
be due to older bugs than the reported version of dbtran.
And, well, you asked, but do not say why this is a concern
for you. If you do not have any recovery, replication or
indication of another area having troubles, it may be there
is nothing wrong here. Is there anything behind this concern?
We are using ASA 7 in Solaris and I have noticed something
kinda funny in the logfile pertaining to the sequence of
events.
When I do a dbtran -d on a logfile, I notice that the normal progression iskinda funny in the logfile pertaining to the sequence of
events.
CONNECT
--> BEGIN TRANSACTION
----> UPDATE OR INSERT
---> COMMIT.
I looked at a log file that started a transaction, did 2 INSERTS and then
sat there for a long time (about 20 minutes). I then saw another
CONNECT coming from the same ID. After the CONNECT, all it
did was COMMIT and then it was done.
I have never seen this behavior before where a separate CONNECT
is issued to do the COMMIT on a prior transaction. Does this have
something to do with a checkpoint maybe? Is this what would happen
if you had an application that did not execute the COMMIT?
Some of our stuff turns off autocommit and I did see where
there was a path to exit the function prior to issuing a
COMMIT.
Does ASA do COMMITS on a checkpoint or after a
period of time?