Board index » delphi » Re: Statics ok?

Re: Statics ok?


2006-10-28 08:48:42 PM
delphi208
Hi Craig,
I read the article.
The IB size per table is changed or still the same?
"if a single database file (not to be confused with the size of the database
in total) exceeds 4 GB on Windows or 2 GB on unix, the database will be
corrupted. "
New releases are giving a message without corrupting IB database.
 
 

Re: Statics ok?

Mehmet F. Erten writes:
Quote
The IB size per table is changed or still the same?

"if a single database file (not to be confused with the size of the
database in total) exceeds 4 GB on Windows or 2 GB on unix, the
database will be corrupted. "
If you mean the size of the database file then no, it is not the same.
IB 6.5 and later uses 64 bit file I/O on any operating system that
supports it. That raises the file size limit to 18 terabytes.
--
Bill Todd (TeamB)
 

Re: Statics ok?

Hi,
I believe this was an issue with Interbase prior to version 6.5. Currently Interbase is only restricted to the OS's maximum file size limit.
Cheers,
Sol
"Mehmet F. Erten" <XXXX@XXXXX.COM>writes:
Quote
Hi Craig,

I read the article.
The IB size per table is changed or still the same?

"if a single database file (not to be confused with the size of the database
in total) exceeds 4 GB on Windows or 2 GB on unix, the database will be
corrupted. "

New releases are giving a message without corrupting IB database.


 

Re: Statics ok?

Mehmet F. Erten writes:
Quote
"if a single database file (not to be confused with the size of the
database in total) exceeds 4 GB on Windows or 2 GB on unix, the
database will be corrupted. "
Here is the full quote:
<quote>
If a single database file (not to be confused with the size of the
database in total) exceeds 4 GB on Windows or 2 GB on unix, the
database will be corrupted. IB 6.0.1.6 and 6.0.2.0 display an error
message instead of corrupting the database, and IB 6.5 and later allow
the use of larger files without errors or corruption.
</quote>
Seems pretty clear to me.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Borland newsgroup denizen Sergio González has a new CD of
Irish music out, and it is good: tinyurl.com/7hgfr
 

Re: Statics ok?

Bill Todd writes:
Quote
There are only three things that will cause the OIT (oldest
<interesting>transaction) to stop advancing.

1) A server crash while one or more transactions are active.
2) Rolling back a transaction that has made a large number of changes.
3) A transaction stuck in limbo. This can only happen if you are using
two phase commit to process transactions that include changes to more
than one database.
This is great info. So if you notice a large discrepency in the OAT
and the OIT I assume you need to find out why and fix it?
So, my question is. From the above reasons, I was trying to think of
how to debug and solve each problem. I was thinking of the following
but would appreciate input.
1) Server Crash - Would need to backup/restore here?
2) Large Xaction rollback - Not sure here. Back/Restore again?
3) Limbo - Not sure I understand this one. Does this mean a Xaction was
started and never Committed/RolledBack? If so, would a server restart
fix this?
--
 

Re: Statics ok?

Bob writes:
Quote
1) Server Crash - Would need to backup/restore here?
No. Just run a sweep.
Quote
2) Large Xaction rollback - Not sure here. Back/Restore again?
No. Run a sweep.
Quote
3) Limbo - Not sure I understand this one. Does this mean a Xaction
was started and never Committed/RolledBack? If so, would a server
restart fix this?
A transaction can only be left in limbo when you have a transaction
that includes changes to two or more databases on two or more servers.
When you commit such a transaction the server where the transaction was
started and is being committed sends a message to the other servers
asking if they are ready to commit. Each server sets the transaction
state to limbo and acknowleges the message. The committing server then
sends a message to all servers to commit the transaction. If one of the
servers crashes between the first and second message the transaction
will be left in limbo. To fix this you must use IBConsole or gfix to
commit or rollback the limbo transaction.
--
Bill Todd (TeamB)
 

Re: Statics ok?

Bill Todd writes:
Its interesting. I just checked my db and it had a OAT/OIT gap of
around 90k. This was just after we run a build that just injects our
system data into a cleanly built db. Its a large amount of data being
inserted. Its a single file database. The only conclusion as to why
this gap exists then would be from your 2nd reason (rolling back a
large number of changes). But as far as I know, there would have been
no rollbacks on this initial data injection phase (I will need to check
this). Is it possible to get this large gap after many INSERTs into
the DB as well?
--
 

Re: Statics ok?

Bob writes:
Quote
Is it possible to get this large gap after many INSERTs into
the DB as well?
Not that I am aware of. Normally the OIT = OAT - 1.
--
Bill Todd (TeamB)
 

Re: Statics ok?

Bill Todd writes:
Sorry to belabor this subject, but I am having trouble fully
understanding these transaction stats.
OAT/OIT I think I get, but I am struggling with the Next Active
Transaction number. A gap in the OAT/OIT you have pointed out quite
clearly the causes. But what if there is no gap in the OAT/OIT (or a
gap of 1), but the gap between the OAT and the Next Transaction is
large (100k or more)? This seems to me that I'd have active
uncommited/rolledback transactions as well?
This has been a {*word*81} to debug, but I am not entirely sure what to
look for.
--
 

Re: Statics ok?

A large gap between the OAT and next transaction means that you have at
least one transaction that has been active for a long time and during
that period many other transactions have been started. Open the
performance monitor, click the Transactions tab, then click the column
header of the Elapsed Time column until you have the transactions
sorted in descending order by elapsed time and you can see how long the
oldest transactions have been active. Long running transactions are an
application design issue.
--
Bill Todd (TeamB)
 

Re: Statics ok?

Bill Todd writes:
Quote
A large gap between the OAT and next transaction means that you have
at least one transaction that has been active for a long time and
during that period many other transactions have been started. Open the
performance monitor, click the Transactions tab, then click the column
header of the Elapsed Time column until you have the transactions
sorted in descending order by elapsed time and you can see how long
the oldest transactions have been active. Long running transactions
are an application design issue.
Ok, so I need to do some bug hunting :)
One more question (promise). How do you properly end a transaction? I
ask this because I wrote a sample test that just executes 1000 selects
over two tables (using IBX). This will increase the OAT/NT gap by
~1000 each time I execute the loop. Now, if I remove the
StartTransaction/Commit then the NT only increments by one each time I
execute the loop, as the OAT stays the same. I am missing something.
IBDatabase1.Connected:= true;
for k:= 1 to 1000 do
begin
IBTransaction1.StartTransaction;
if Odd(k) then
ibQry.SQL.Text:= 'select * from TABLE1'
else
ibQry.SQL.Text:= 'select * from TABLE2';
ibQry.Open;
ibQry.Last;
ibQry.Close;
IBTransaction1.Commit;
end;
IBDatabase1.Connected:= false;
--
 

Re: Statics ok?

Bob writes:
Quote

One more question (promise). How do you properly end a transaction?
Call Commit or Rollback.
Quote
I
ask this because I wrote a sample test that just executes 1000 selects
over two tables (using IBX). This will increase the OAT/NT gap by
~1000 each time I execute the loop. Now, if I remove the
StartTransaction/Commit then the NT only increments by one each time I
execute the loop, as the OAT stays the same. I am missing something.

IBDatabase1.Connected:= true;
for k:= 1 to 1000 do
begin
IBTransaction1.StartTransaction;
if Odd(k) then
ibQry.SQL.Text:= 'select * from TABLE1'
else
ibQry.SQL.Text:= 'select * from TABLE2';

ibQry.Open;
ibQry.Last;
ibQry.Close;
IBTransaction1.Commit;
end;
IBDatabase1.Connected:= false;
That does not make sense to me. The OAT should advance each time a
transaction is commited and a new on started.
--
Bill Todd (TeamB)
 

Re: Statics ok?

Bob writes:
Quote
IBTransaction1.StartTransaction;
if Odd(k) then
ibQry.SQL.Text:= 'select * from TABLE1'
else
ibQry.SQL.Text:= 'select * from TABLE2';

ibQry.Open;
ibQry.Last;
ibQry.Close;
IBTransaction1.Commit;
Always use a try/finally around the transaction when you don't intend
to rollback:
IBTransaction1.StartTransaction;
try
if Odd(k) then
ibQry.SQL.Text:= 'select * from TABLE1'
else
ibQry.SQL.Text:= 'select * from TABLE2';
ibQry.Open;
ibQry.Last;
ibQry.Close;
finally
IBTransaction1.Commit;
end;
Without it you will fail to commit if your code raises an exception
between the start and commit.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Borland newsgroup denizen Sergio González has a new CD of
Irish music out, and it is good: tinyurl.com/7hgfr
 

Re: Statics ok?

Van den Wouwer Danny writes:
Quote
Following code is better I believe
No, that is wrong. The code you posted does a rollback whenever there
is an exception, which is very likely almost exactly the same behavior
as the original code (since DefaultAction defaults to rollback).
But since the code hasn't changed anything in the DB, there is nothing
to roll back. And even if the code had changed something in the DB you
still might not want a rollback (at this point it is up to the developer
to determine if you want to keep all successful changes or make the
changes atomic).
In short, you should only rollback when you have a really good reason
to do so, not as a routine coding pattern.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Want to help make Delphi and InterBase better? Use QC!
qc.borland.com -- Vote for important issues
 

Re: Statics ok?

Following code is better I believe
try
...
IBtran.Commit;
except
IBtran.Rollback;
raise;
end
Van den Wouwer Danny
Peopleware NV
Craig Stuntz [TeamB] writes:
Quote
Bob writes:

>IBTransaction1.StartTransaction;
>if Odd(k) then
>ibQry.SQL.Text:= 'select * from TABLE1'
>else
>ibQry.SQL.Text:= 'select * from TABLE2';
>
>ibQry.Open;
>ibQry.Last;
>ibQry.Close;
>IBTransaction1.Commit;

Always use a try/finally around the transaction when you don't intend
to rollback:

IBTransaction1.StartTransaction;
try
if Odd(k) then
ibQry.SQL.Text:= 'select * from TABLE1'
else
ibQry.SQL.Text:= 'select * from TABLE2';

ibQry.Open;
ibQry.Last;
ibQry.Close;
finally
IBTransaction1.Commit;
end;

Without it you will fail to commit if your code raises an exception
between the start and commit.