dimitrТы смотрел на счетчик page writes на шагах 2 и 4?сорри, я там ошибся: делал вставку в таблицу t
3 , которая уже балы в этой базе, да еще и структура у неё та же самая оказалась :(
Сделал всё с самого начала. Странности всё-таки есть. Лезут.
Всех, кому интересно, прошу проверить у себя, на базе с page_size =
4096 , charset = none. ФБ 2.5, в архитектуре
SuperClassic .
Вот
DDL :
1.
2.
3.
4.
SQL> recreate table t(id int, s varchar(32760)); commit;
SQL> create index t_id on t(id); commit;
SQL> insert into t select gen_id(g,1), rpad('', 32760, uuid_to_char(gen_uuid())) from rdb$types,rdb$types rows 1000; commit;
SQL> quit;
Далее:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
Коннект-1.
Database: 192.168.0.201/3252:empty25
-- вычитываем в кеш:
SQL> out nul; select cast(right(s,10) as varchar(10)) rs,current_timestamp dts from t where id=1; out; set stat on;
-- проверяем, что на диск больше лезть не надо:
SQL> select cast(right(s,10) as varchar(10)) rs,current_timestamp dts from t where id = 1 ;
RS DTS
========== =========================
C7402EA022 2013-12-13 23:53:54.5810
Current memory = 1543088
Delta memory = 0
Max memory = 1581632
Elapsed time= 0.02 sec
Buffers = 256
Reads = 0 -- ОК, так и есть
Writes 0
Fetches = 19
Коннект-2.
C:\MIX\firebird\fb25>isql 192.168.0.201/3252:empty25 -n -c 256
Database: 192.168.0.201/3252:empty25
SQL> update t set s=null where id = 4 ;
Коннект-1.
SQL> select cast(right(s,10) as varchar(10)) rs,current_timestamp dts from t where id = 1;
RS DTS
========== =========================
C7402EA022 2013-12-13 23:54:10.8780
Current memory = 1543088
Delta memory = 0
Max memory = 1581632
Elapsed time= 0.01 sec
Buffers = 256
Reads = 1
Writes 0
Fetches = 19
Коннект-2.
SQL> rollback;
Коннект-1.
SQL> select cast(right(s,10) as varchar(10)) rs,current_timestamp dts from t where id=1;
RS DTS
========== =========================
C7402EA022 2013-12-13 23:54:20.6590
Current memory = 1543088
Delta memory = 0
Max memory = 1581632
Elapsed time= 0.01 sec
Buffers = 256
Reads = 1
Writes 0
Fetches = 19
И еще одно наблюдение. Несложный (но муторный) повтор для разных значений ID'шников привёл к следующим результатам:
коннект-1 будет реагировать статистикой
с reads=1 ...
1) ...
как для update t set s = null,
так и для rollback'a в коннекте-2, - но только при условии, что коннект-2 меняет записи
с id=2...5;
2) ...
только для rollback'a в коннекте-2, если этот коннект-2 меняет записи с
id=6...110
Если же коннект-2 меняет записи с id >= 111, то ни апдейт, ни роллбак НЕ будут отражены в reads коннекта-1 при перечитке записи.
Что касается счетчика writes, то он в коннекте-1 ВСЁ ВРЕМЯ был равен нулю.
Мутная вода.
Длина данных в каждой записи (32760 строка + 4 байта id'шник + 16 байт заголовок записи) в ВОСЕМЬ раз превышает размер страницы базы. Счетчик записей (writes) во всех замерах был равен НУЛЮ ==> никаких новых страниц там не выделялось.
Установка коннектом
-2 в записи с ID
=5 длинного varchar-поля в NULL никак не может отражаться на страницах, прочитанных коннектом
-1 для записи с ID
=1 .
Они же разделены как минимум 8*3 = 24 штуками других страниц!!
А про "эхо" от роллбака, идущее аж от 110-й страницы, я вообще молчу тихо об лёд...
dimitrВ первом случае наверняка изменяется pointer page (ибо твой апдейт приводит к выделению новой страницы), которую запросто может захотеть перечитать коннект 1.Нету там новой страницы. Я делал после первых трёх апдейтов нуллами вот это:
gstat EMPTY25.FDB -r -t T|findstr /i /c:"data pages"
- и получал всё время одно и то же:
Data pages: 192 , data page slots: 192 , average fill: 88%
dimitrВо втором случае он наверняка будет перечитывать измененную TIP.Как это достоверно определить ?
