hi all
Пишу сюда, т.к. nntp на этой машине не доступен, а автор IBE здесь регулярно бывает :-)
Надеюсь на его пояснения по следующим фактам.
Трейс показывает, что в ИБЭ:
1. С момента аттача к БД до восстановления окон "предыдущего рабочего окружения" последовательно открывается и закрывается 17 транзакций; это всё понятно и хорошо;
2. После выполнения вот такой пары команд в Script Executive:
1.
create table ttt(id int);
commit;
- происходит:
2.1 открытие и немедленное закрытие (без единого оператора) транзакции TRA_22, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE (см аттач);
2.2. открытие загадочной TRA_23, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE, в которой ничего не происходит и которая остается активной до дисконнекта или следующего commit'a;
2.3 открытие TRA_24, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE, в которой делается один селект из RDB$RELATIONS, после чего она коммитится;
2.4 открытие TRA_25, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE, в которой опять делается один селект из RDB$RELATIONS и транзакция коммитится.
Обращаю внимание: транзакция TRA_23 остаётся всё это время активной в режиме READ_
WRITE .
Выяснилось далее, что:
а) если выполнить дисконнект от базы (а также реконнект), то эта транзакция будет отменена rollback'ом, хотя в ней ничего не менялось и не селектилось:
1.
2.
3.
4.
5.
2011-06-27T23:45:04.6090 (428:020DE01C) ROLLBACK_TRANSACTION
C:\1INSTALL\FIREBIRD\DATA\TEST3.FDB (ATT_3, SYSDBA:NONE, WIN1251, XNET:BALAHA)
C:\1INSTALL\FIREBIRD\IBExpert\IBExpert.exe:1244
(TRA_23, READ_COMMITTED | REC_VERSION | NOWAIT | READ_WRITE)
0 ms, 1 read(s), 1 write(s), 1 fetch(es), 1 mark(s)
б) если в том же окне ScriptExecutive сделать второй DDL:
- то в этой TRA_23 будет выполнено нечто:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Statement 101 :
-------------------------------------------------------------------------------
select cast( 1 as integer), cast(d.rdb$character_set_name as varchar( 64 )), cast(c.rdb$default_collate_name as varchar( 64 ))
from rdb$database d
left join rdb$character_sets c ON (d.rdb$character_set_name = c.rdb$character_set_name)
union
select cast( 2 as integer), cast(rdb$field_name as varcha...
11 records fetched
1 ms, 64 fetch(es), 2 mark(s)
Table Natural Index Update Insert Delete Backout Purge Expunge
***************************************************************************************************************
RDB$DATABASE 1 1
RDB$FIELDS 1
RDB$RELATION_FIELDS 7
RDB$RELATIONS 1
RDB$CHARACTER_SETS 2
- и затем она закроется COMMIT'ом.
Но затем опять повторяется странность: открывается ОДНА транзакция на DDL, в ней грохается таблица, транзакция коммитится, а дальше, после COMMIT'a, снова открываются ДВЕ транзакции - TRA_28, которая тут же закрывается, ничего не выполнив, а за ней - новая "загадка" - TRA_29, которая ничего не делает.
И всё бы ничего, да ведь все эти транзакции (TRA_23, TRA_29) висят в режиме READ_COMMITTED | REC_VERSION | NOWAIT | READ_
WRITE . И значит, перед отъездом домой закрывать надо не только результаты запросов в SQL Editor'e, но и выполненные с commit'ом скрипты в SE!
ВОПРОС_1. Открытие транзакций-"висяков" после commit'a в Script Executive - это бага или давно известная фича ?
ВОПРОС-2. Зачем на старте делать такое кол-во (17) мелких RW-транзакций, которые обращаются к rdb$-таблицам и ничего не меняют в базе ? почему нельзя это делать в RO-транзакциях ?
