Hello, nathanelrick!

Friday, March 2, 2012, 9:48:32 PM, you wrote:

n> no one have an idea about what is a

n> deadlock
n> Error: 16

n> ?

n> the isolation of the transaction was: isc_tpb_read_committed +
n> isc_tpb_no_rec_version + wait => normally no deadlock must appear ??

Maybe you have 2 wait transactions that locks each other.
Since you are using no_read_committed, it "locks" even
on reading, so, any reading in trigger, etc, can cause
real deadlock (since you said that you have "ddl is a little long").

>> i know the behavior of each, but i need to know the difference in speed / resource usage between each of them ...

no speed difference or resource usage between rec_version and
no_rec_version. And even more, I can say that only shapshot
(concurrency, consistency) transactions consume resources, and
resourses is the size of local copy of TIP for that transaction.

n> what is the most fastest isolation level ?

No one. When transaction works alone, none difference in speed, for
any isolation level. Versioning engine doesn't place any locks
somewhere in DB or memory.
But, when you start update and delete records, you produce
versions, and here is the main performance source - there more
versions transaction reads to understand what it can show
and what not to show, the slower reading will be.

For me no_rec_version itself is the worst case, nearly useless.
I even wonder why it exist - versioning engine designed not
to block readers.
And wait - also not good for most cases. It's again a versioning
engine, not designed to wait on locks.
So, I prefer application to know the problem exactly when
it happens, not to wait for unknown time and then ... oops!,
whe have lock conflict.

--
Dmitry Kuzmenko, www.ib-aid.com