RE: [Info-ingres] Friday is coming ...
- From: Karl & Betty Schendel <schendel@xxxxxxxxxxxxxx>
- Date: Wed, 20 Jul 2005 16:29:52 -0400
At 6:09 AM +1000 7/21/2005, Paul White wrote:
>DDLs operate in a different dimension from DDLs. The resource required to
>complete are not just row, page or table level. They lock entire catalogs
>and databases. Schema changes can cause entire tables to be re-written.
>They are executed by the schema owner / dba / God (I mean the IT manager).
>There is a limit to the number of DDLs you can include in a single
>transaction. Some DDLS cannot be rolled back.
None of these are arguments for making DDL non-transactional.
Some are reasonable arguments for not indiscriminately interspersing
DDL randomly. Some of your statements are a bit hyperbolic, such as
the bit about locking entire catalogs and databases. (Entire catalogs
aren't locked unless lock escalation takes place. I can't think of any
DDL that locks an entire database. Schema changes won't rewrite entire
tables unless you make it do so.) It's true that some DDL will take
exclusive control locks on tables.
What DDL can't be rolled back? Modify on a temporary table is all
that I can think of. (and it's rolled back like any operation on a
temporary table -- the table is dropped.)
By the way, the DDL limit-per-transaction is eliminated in r3.
That was purely an implementation issue, as are some of the other
points raised.
>
>As a rule, I try to ensure DML statements are executed, well outside of
>"normal" transactions, when the system is quiet. I prefer to use temp
>session tables instead of real tables.
Nothing wrong with that. I still expect DDL to be subject to transaction
rules just like any other non-session-control SQL statement.
Karl
.
- Prev by Date: RE: [Info-ingres] Friday is coming ...
- Next by Date: RE: [Info-ingres] Friday is coming ...
- Previous by thread: RE: [Info-ingres] Friday is coming ...
- Next by thread: RE: [Info-ingres] Friday is coming ...
- Index(es):
Relevant Pages
|