powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
29 сообщений из 29, показаны все 2 страниц
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733598
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
SQL> recreate table tmain(id int primary key); commit;
SQL> recreate table tdetl(id int primary key, pid int references tmain); commit;
SQL> insert into tmain values(1);
SQL> commit;
SQL> create sequence g; commit;
SQL> insert into tdetl select gen_id(g,1), 1 from rdb$types,rdb$types; commit;

trace :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
2014-08-31T16:33:43.5000 (520:0223C08C) EXECUTE_STATEMENT_FINISH
        t0 (ATT_6, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        C:\1INSTALL\FIREBIRD\FB25SNAP\bin\isql.exe:1288
                (TRA_22, CONCURRENCY | WAIT | READ_WRITE)

Statement 135:
------------------------------------------------------------------------
insert into tdetl select gen_id(g,1), 1 from rdb$types,rdb$types
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN JOIN (RDB$TYPES NATURAL, RDB$TYPES NATURAL)
0 records fetched
   2845 ms, 4 read(s), 345 write(s), 944617 fetch(es), 212447 mark(s)

Table                             Natural     Index    Update    Insert
************************************************************************
RDB$INDICES                                       4
RDB$TYPES                           52212
RDB$RELATION_CONSTRAINTS                5
TDETL                                                             51984

Оевидно, что при вставке каждой строки в TDETL движок проверял наличие родительской записи в TMAIN.
В статистике на это намёков не видно (про вызовы "скрытого" check_NN триггера я уж не говорю).

Это так и должно быть ?
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733601
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

да. Тебе же 100 раз было сказано что в статистике отображаются индексированные чтения (чтения по индексу), а не чтение самого индекса.
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733603
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

как раз check-триггер и проверяет наличие записи в родителе. А статистику его вызова ты не видишь, ибо он не относится к твоему стейтменту (как и любой другой триггер или ХП).
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733610
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrкак раз check-триггер и проверяет наличие записи в родителе. А статистику его вызова ты не видишь, ибо он не относится к твоему стейтменту (как и любой другой триггер или ХП).Ну так что следует сделать (запустить), чтобы деятельность этого check-триггера вылезла в статистику ?

И вообще как-то туманно звучит: "не относится к твоему стейтменту". Он (этот check-триггер) работает ведь именно когда я дёргаю дочернюю таблицу, как и было показано выше.
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733612
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисда. Тебе же 100 раз было сказано что в статистике отображаются индексированные чтения (чтения по индексу), а не чтение самого индекса.Ты утверждаешь, что "чтений по индексу" таблицы TMAIN тут не было ?
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733621
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

может и было. Но как сказал ДЕ оно относится к другому статменту. Вот когда ты создаёшь триггер before/after insert статистика по действиям внутри триггера будет относится к триггеру, а не к оператору insert. Так?
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733666
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денискак сказал ДЕ оно относится к другому статменту .К какому именно "другому" ?? Я ввожу ОДИН стейтмент!
Симонов ДенисВот когда ты создаёшь триггер before/after insert статистика по действиям внутри триггера будет относится к триггеру, а не к оператору insert. Так?Если я выкину FK и добавлю триггер TDETL_BIU, эмулирующий FK-проверку:
Код: plaintext
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.
recreate table tmain(id int primary key); commit;
recreate table tdetl(id int primary key, pid int); commit; -- references tmain
insert into tmain values(1); commit;
set term ^;
execute block as begin
  begin execute statement 'create sequence g'; when any do begin end end
end
^
set term ;^
commit;
alter sequence g restart with 0;
create exception ex_no_parent_row 'attempt to insert/modify field with value which has no parent.'; 
commit;

set term ^;
create or alter trigger tdetl_biu for tdetl active before insert or update as
begin
  if (not exists(select * from tmain m where m.id = new.pid)) then 
    exception ex_no_parent_row;
end
^
set term ;^
commit;

insert into tdetl select gen_id(g,1), iif( gen_id(g,0) <= 4, 1, 2) from rdb$types rows 5; 
commit;
- то стопудово получу и его активность в трейсе, и статистику по тем таблицам, куда он лазит.
Код: plaintext
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.
2014-08-31T20:11:13.4560 (20014:0x7fa6802e93f8) EXECUTE_TRIGGER_START
        /var/db/fb25/oltp25.fdb (ATT_1679, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:25603
                (TRA_92564, CONCURRENCY | WAIT | READ_WRITE)
        TDETL_BIU FOR TDETL (BEFORE INSERT)

2014-08-31T20:11:13.4560 (20014:0x7fa6802e93f8) FAILED EXECUTE_TRIGGER_FINISH
        /var/db/fb25/oltp25.fdb (ATT_1679, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:25603
                (TRA_92564, CONCURRENCY | WAIT | READ_WRITE)
        TDETL_BIU FOR TDETL (BEFORE INSERT)
      0 ms, 6 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$EXCEPTIONS                                    1

2014-08-31T20:11:13.4560 (20014:0x7fa6802e93f8) FAILED EXECUTE_STATEMENT_FINISH
        /var/db/fb25/oltp25.fdb (ATT_1679, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:25603
                (TRA_92564, CONCURRENCY | WAIT | READ_WRITE)

Statement 3720:
-------------------------------------------------------------------------------
insert into tdetl select gen_id(g,1), iif( gen_id(g,0) <= 4, 1, 2) from rdb$types rows 5
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (RDB$TYPES NATURAL)
0 records fetched
      0 ms, 1 write(s), 121 fetch(es), 31 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$TYPES                               5
RDB$EXCEPTIONS                                    1
 TMAIN                                             4 
TDETL                                                                 4                   4

2014-08-31T20:11:13.4560 (20014:0x7fa6802e93f8) ERROR AT jrd8_execute
        /var/db/fb25/oltp25.fdb (ATT_1679, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb25sc/bin/isql:25603
335544517 : exception 158
335544382 : EX_NO_PARENT_ROW
335544382 : attempt to insert/modify field with value which has no parent.
335544842 : At trigger 'TDETL_BIU' line: 3, col: 63
Я в упор не понимаю, почему стейтмент, прописанный в "системном" триггере CHECK_NN, который делает что-то похожее на "if (not exists(select * from tmain m where m.id = new.pid)) then . . .", НЕ относится к вводимому insert'у. А стейтмент, прописанный в явно созданном TDETL_BIU - уже относится.
Напоминает "тут играем, а тут рыбу заворачивали".
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733668
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
сейчас перепроверил - операции триггеров должны включаться в статистику "родителя". Надо проверять.
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733669
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА стейтмент, прописанный в явно созданном TDETL_BIU - уже относится.

извиняюсь был не прав.
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733675
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrсейчас перепроверил - операции триггеров должны включаться в статистику "родителя". Надо проверять.А нельзя ли фикс (если он будет) сделать прежде всего для 3.0 (где есть mon$-новшества) и прислать мну в мыльце в виде патчика ? А то ну очень надо - ты же знаешь причину этой "пурги"! :-)
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733677
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
фикса не будет. Я зарапортовался, никакого check-триггера без каскада есс-но нет. FK проверяется при вставке в индекс, операции внутри индекса в табличную статистику никак не попадают (и не должны). Т.е. Денис выше все правильно написал.
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733679
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrFK проверяется при вставке в индекс, операции внутри индекса в табличную статистику никак не попадают ( и не должны ).Как именно проверяется FK, ведь в родит. таблицу надо слазить или нет ? И если обращения к ней таки есть (да еще и для каждой из 100500 млн добавляемых в деталь строк), то почему они не должны показываться ?
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733680
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидdimitrFK проверяется при вставке в индекс, операции внутри индекса в табличную статистику никак не попадают ( и не должны ).Как именно проверяется FK, ведь в родит. таблицу надо слазить или нет ? И если обращения к ней таки есть (да еще и для каждой из 100500 млн добавляемых в деталь строк), то почему они не должны показываться ?А, стоп. Пардон, я понял: ты говоришь о том, что в родит. ТАБЛИЦУ вообще нет обращений, есть только ходьба в её ИНДЕКС.
Ну так это же IR , нет разве ?
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733684
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
значит, так. Выборки из таблицы нет. Поиск в индексе есть. Обращение к таблице тоже есть, но довольно специфическое. Технически наверное его можно назвать индексным, хотя формально оно не относится ни к seq_reads ни к idx_reads. Я пока не знаю, как это будет правильнее показать в статистике. Буду думать.
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733710
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrВыборки из таблицы нет. Поиск в индексе есть. Обращение к таблице тоже есть, но довольно специфическое.ИМХО, оно какое-то уж слишком "спецфицьское". Потому что заставляет ФБ делать больше фетчей при каскаде, чем при его эмуляции (каждая строка детали требует там на 2 фетча больше - что при вставках в деталь, что при удалении в родителе.
А при удалении, кстати, идёт проигрыш каскада не только по фетчам, но и по времени.

DDL для каскада:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
recreate table tdetl_casc(id int primary key using index tdetl_casc_pk, pid int);
recreate table tmain_casc(id int primary key using index tmain_casc_pk);
alter table tdetl_casc add
    constraint tdetl_casc_fk foreign key (pid)
    references tmain_casc(id)
    on delete cascade
    on update cascade
    using index tdetl_pid;
commit;
insert into tmain_casc values(1);
commit;
DDL для "эмулятора" каскада:
Код: plaintext
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.
set term ^;
execute block as
begin
  begin
  execute statement 'drop trigger tmain_trig_ad';
  when any do begin end
  end
  begin
  execute statement 'drop trigger tdetl_trig_biu';
  when any do begin end
  end
end
^
set term ;^
commit;
recreate table tdetl_trig(id int primary key using index tdetl_trig_pk, pid int);
recreate table tmain_trig(id int primary key using index tmain_trig_pk);
commit;
recreate exception ex_no_parent 'no parent key found';

create index tdetl_trig_pid on tdetl_trig(pid);
commit;

set term ^;
create or alter trigger tdetl_trig_biu for tdetl_trig
active before insert or update position 0
as
begin
  if ( NOT exists(select * from tmain_trig m where m.id = new.pid) ) then
    exception ex_no_parent;
end
^

create or alter trigger tmain_trig_ad for tmain_trig
active after delete position 0
as
begin
  delete from tdetl_trig d where d.pid = old.id;
end
^
set term ;^
commit;

insert into tmain_trig values(1);
commit;

Делаем insert 1 млн строк в деталь таблицу схемы "каскад":
Код: plaintext
1.
2.
insert into tdetl_casc(id, pid) select row_number()over(), 1 
from rdb$types, rdb$types,(select 1 i from rdb$types rows 20) 
rows 1000000;
Trace:

1. Для схемы "каскад" :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Statement 742:
-------------------------------------------------------------------------------
insert into tdetl_casc(id, pid) select row_number()over(), 1 from rdb$types, rdb$types,(select 1 i from rdb$types rows
 20) rows 1000000
0 records fetched
  22031 ms, 4319 write(s),  17710987  fetch(es), 3043836 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$PAGES                                                             3
RDB$TYPES                         1295420
TDETL_CASC                                                      1000000

2. Для схемы "эмулятор каскада" :

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Statement 744:
-------------------------------------------------------------------------------
insert into tdetl_trig(id, pid) select row_number()over(), 1 from rdb$types, rdb$types,(select 1 i from rdb$types rows 20) rows 1000000
0 records fetched
  24107 ms, 4092 write(s),  15710989  fetch(es), 3043836 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$PAGES                                                             3
RDB$TYPES                         1295420
TDETL_TRIG                                                      1000000
TMAIN_TRIG                                  1000000

Теперь commit + удаляем родительскую строку, что повлечёт грохание 1 млн строк в детали в каждой схеме.
Trace:

1. Для схемы "каскад" :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
Statement 745:
-------------------------------------------------------------------------------
delete from tmain_casc where id=1
0 records fetched
    3021 ms ,  7001250  fetch(es), 1000001 mark(s)

Table                             Natural     Index    Update    Insert    Delete 
**********************************************************************************
TDETL_CASC                                  1000000                       1000000
TMAIN_CASC                                        1                             1

2. Для схемы "эмулятор каскада" :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
Statement 746:
-------------------------------------------------------------------------------
delete from tmain_trig where id=1
0 records fetched
    2640 ms ,  5000628  fetch(es), 1000001 mark(s)

Table                             Natural     Index    Update    Insert    Delete 
**********************************************************************************
TDETL_TRIG                                  1000000                       1000000
TMAIN_TRIG                                        1                             1

PS. LI-T3.0.0.31309 (впрочем, и на всех предыдущих билдах 3.0, а также на всех 2.5 - то же самое)
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733715
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидПотому что заставляет ФБ делать больше фетчей при каскаде, чем при его
эмуляции
Каскадные операции тут ни при чём. Это расходы на поддержание ссылочной целостности,
которую твоя эмуляция не обеспечивает.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733717
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovЭто расходы на поддержание ссылочной целостности, которую твоя эмуляция не обеспечивает."Расшифровку" бы получить, расходов этих. Что там за два фетча на каждую запись, чего они ради ?
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733720
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид"Расшифровку" бы получить, расходов этих. Что там за два фетча на каждую запись, чего они ради ?
то самое "специфическое" чтение записи из таблицы, один фетч на PP и один на DP - все как обычно. Требуется чтобы сравнить поля связи мастера со слейвом (ключ индекса может "врать", ибо априори неточен).
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733722
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоид"Расшифровку" бы получить, расходов этих. Что там за два фетча на каждую запись, чего они ради ?то самое "специфическое" чтение записи из таблицы, один фетч на PP и один на DP - все как обычно. Требуется чтобы сравнить поля связи мастера со слейвом (ключ индекса может "врать", ибо априори неточен).А зачем на каждой обрабатываемой detail-строке дёргать запись мастера, почему нельзя закешировать после первого прочтения ? Разве она не блокируется на старте DML-стейтмента и до тех пор, пока он не завершится ?
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733726
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА зачем на каждой обрабатываемой detail-строке дёргать запись мастера, почему нельзя закешировать после первого прочтения ?
а откуда сервер знает, что следующая деталь будет ссылаться на того же мастера? В общем случае это не так. Кроме того, записи мастера и так буферизируются страничным кешем.

ТаблоидРазве она не блокируется на старте DML-стейтмента и до тех пор, пока он не завершится ?
кто "она"? Какое-такое "блокирование"?
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733734
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидА зачем на каждой обрабатываемой detail-строке дёргать запись мастера, почему нельзя закешировать после первого прочтения ?а откуда сервер знает, что следующая деталь будет ссылаться на того же мастера? В общем случае это не так. Кроме того, записи мастера и так буферизируются страничным кешем.Вставка в деталь-таблицу записей с числом dictinct parent-ключей, равным числу dictinct ключей в мастере - это самый худший случай. Это вообще похоже на связь 1-1.
В бол-ве случаев в деталь-таблицу идут вставки, в select count(distinct parent_id) << select count(master.id). Не понимаю, почему бы не запоминать "где-то там в памяти" значения из master-таблицы, дабы вообще не лазить за ними на следующих повторах (в рамках этого же стейтмента).

dimitrТаблоидРазве она не блокируется на старте DML-стейтмента и до тех пор, пока он не завершится ?
кто "она"? Какое-такое "блокирование"?Запись master-таблицы. Она блокируется до тех пор, пока идёт вставка в detail.
Например, при добавлении в вышеприведенном скрипте в таблицу tdetl_casc 1 млн строк, второе окно, пытающееся удалить master-строку, получает по лбу:
Код: plaintext
1.
2.
3.
4.
5.
SQL> delete from tmain_casc where id=1;
Statement failed, SQLSTATE = 23000
violation of FOREIGN KEY constraint "TDETL_CASC_FK" on table "TDETL_CASC"
-Foreign key references are present for the record
-Problematic key value is ("ID" = 1)
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733737
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЭто вообще похоже на связь 1-1.
вполне легальная связь, которой пользуется куча народу

ТаблоидВ бол-ве случаев в деталь-таблицу идут вставки, в select count(distinct parent_id) << select count(master.id).
кто сказал, что они идут в порядке возрастания/убывания ключей мастера? И что вообще будет более одной вставки в деталь?

ТаблоидНе понимаю, почему бы не запоминать "где-то там в памяти" значения из master-таблицы, дабы вообще не лазить за ними на следующих повторах (в рамках этого же стейтмента).
"где-то там в памяти" = в страничном кеше. Хватит уже натягивать сову на глобус.

ТаблоидЗапись master-таблицы. Она блокируется до тех пор, пока идёт вставка в detail.
нет никакого блокирования

ТаблоидНапример, при добавлении в вышеприведенном скрипте в таблицу tdetl_casc 1 млн строк, второе окно, пытающееся удалить master-строку, получает по лбу
ибо при удалении мастера проверяется ссылочная целостность (наличие строк-деталей)
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733739
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А, и еще тут вылезло, в схеме "каскады".
Исходные данные: в таблице tmain_casc - одна строка, в подчинённой ей tdetl_casc - ноль:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SQL> select * from tmain_casc; commit;

          ID
============
           1

SQL> select  count(*) from tdetl_casc; commit;

                COUNT
=====================
                    0


Далее делаю так:

session #1 (в трейсе ниже - ATT_720). Запускаю вот этот скрипт (file = 'ins'):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
rollback; set transaction no wait;
set term ^;
execute block as
declare i int = 0;
declare n int = 1000000;
begin
  while (i < n ) do insert into tdetl_casc(id, pid) values( :i, 1 ) returning :i+1 into i;
end
^
set term ;^
rollback;

session #2 (в трейсе ниже - ATT_722). Запускаю в ней примерно через 5-7 сек вот это:
Код: plaintext
rollback; set transaction no wait; delete from tmain_casc where id=1;

И получаю... обломы в ОБЕИХ сессиях!
Вот трейс:
Код: plaintext
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.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
2014-09-01T00:06:20.8580 (27769:0x7f9ae1c6bf90) TRACE_INIT
        SESSION_4


2014-09-01T00:06:20.8600 (27769:0x7f9ae1c6bf90) EXECUTE_STATEMENT_START
        oltp30 ( ATT_720 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:31141
                (TRA_443449, CONCURRENCY | NOWAIT | READ_WRITE)

Statement 978:
-------------------------------------------------------------------------------
execute block as
declare i int = 0;
declare n int = 1000000;
begin
  while (i < n ) do insert into tdetl_casc(id, pid) values( :i, 1 ) returning :i+1 into i;
end


2014-09-01T00:06:27.9210 (27769:0x7f9ae1c69ec8) TRACE_INIT
        SESSION_4


2014-09-01T00:06:27.9360 (27769:0x7f9ae1c69ec8) EXECUTE_STATEMENT_START
        oltp30 ( ATT_722 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:31387
                (TRA_443451, CONCURRENCY | NOWAIT | READ_WRITE)

Statement 979:
-------------------------------------------------------------------------------
delete from tmain_casc where id=1

2014-09-01T00:06:29.0100 (27769:0x7f9ae1c69ec8)  FAILED  EXECUTE_STATEMENT_FINISH
        oltp30 ( ATT_722 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:31387
                (TRA_443451, CONCURRENCY | NOWAIT | READ_WRITE)

Statement 979:
-------------------------------------------------------------------------------
delete from tmain_casc where id=1
0 records fetched
   1073 ms, 839397 fetch(es), 2 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$INDICES                                       2
RDB$RELATION_CONSTRAINTS                          1
TMAIN_CASC                                        1                             1         1

2014-09-01T00:06:29.0100 (27769:0x7f9ae1c69ec8) ERROR AT JStatement::execute
        oltp30 (ATT_722, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:31387
335544466 : violation of FOREIGN KEY constraint "TDETL_CASC_FK" on table "TDETL_CASC"
335544839 : Foreign key references are present for the record
335545072 : Problematic key value is ("ID" = 1)

2014-09-01T00:06:31.1610 (27769:0x7f9ae1c6bf90)  FAILED  EXECUTE_STATEMENT_FINISH
        oltp30 ( ATT_720 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:31141
                (TRA_443449, CONCURRENCY | NOWAIT | READ_WRITE)

Statement 978:
-------------------------------------------------------------------------------
execute block as
declare i int = 0;
declare n int = 1000000;
begin
  while (i < n ) do insert into tdetl_casc(id, pid) values( :i, 1 ) returning :i+1 into i;
end

0 records fetched
  10301 ms, 3893 write(s), 11309314 fetch(es), 2656018 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$INDICES                                       2
RDB$RELATION_CONSTRAINTS                          1
TDETL_CASC                                                       375649              375649

2014-09-01T00:06:31.1610 (27769:0x7f9ae1c6bf90) ERROR AT JStatement::execute
        oltp30 (ATT_720, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:31141
335544466 : violation of FOREIGN KEY constraint "TDETL_CASC_FK" on table "TDETL_CASC"
335544838 : Foreign key reference target does not exist
335545072 : Problematic key value is ("PID" = 1)
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733740
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидВ бол-ве случаев в деталь-таблицу идут вставки, в select count(distinct parent_id) << select count(master.id).кто сказал, что они идут в порядке возрастания/убывания ключей мастера? И что вообще будет более одной вставки в деталь?Да пусть хоть в порядке винегрета, какая разница ?
Пусть последовательность вставки в detail такая:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
insert into detail(id, pid) values( gen_id(g,1), 123456);
insert into detail(id, pid) values( gen_id(g,1), 444555);
insert into detail(id, pid) values( gen_id(g,1), 321456);
insert into detail(id, pid) values( gen_id(g,1), 951357);
insert into detail(id, pid) values( gen_id(g,1), 444555);
insert into detail(id, pid) values( gen_id(g,1), 111111);
insert into detail(id, pid) values( gen_id(g,1), 444555);

Тут три раза повторяется значение "444555".
Движок сейчас три раза ходит в индекс master'a с поиском "444555" и, насколько я понимаю, таки шарит еще и в самом master'e, в его PP + DP, ибо:dimitrключ индекса может "врать", ибо априори неточенПочему нельзя, один раз сходив за ключиком "444555", добавить его куда-нить в структуру-аналог TreeSet'а, что бы прежде чем ходить за ним в следующие разы, проверить этот TreeSet ? И при наличии там этого ключа - сказать себе: "да, такой ключ уже БЫЛ прочитан из master'a, и его не надо заново фетчить!"

dimitrТаблоидНе понимаю, почему бы не запоминать "где-то там в памяти" значения из master-таблицы, дабы вообще не лазить за ними на следующих повторах (в рамках этого же стейтмента)."где-то там в памяти" = в страничном кеше.Что будет сохранено в страничном кеше - запись master'a ? Ну так от повторных фетчей (в индексе + PP + DP) это не избавляет!

dimitrТаблоидЗапись master-таблицы. Она блокируется до тех пор, пока идёт вставка в detail.нет никакого блокированияЕсть "что-то", не позволяющее мну добавить в деталь новые строки, пока в соседнем окне идёт delete from tmain_casc where id = 1. Если это не блокирование master-записи, то что тогда ?
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733741
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидТут три раза повторяется значение "444555".
а если это будет три повторения из 100500 записей? Создание FK на табличке-миллиарднике. Давай-ка закешируй мастер.

ТаблоидПочему нельзя, один раз сходив за ключиком "444555", добавить его куда-нить в структуру-аналог TreeSet'а, что бы прежде чем ходить за ним в следующие разы, проверить этот TreeSet ? И при наличии там этого ключа - сказать себе: "да, такой ключ уже БЫЛ прочитан из master'a, и его не надо заново фетчить!"
предлагаю проследовать в сад

ТаблоидЧто будет сохранено в страничном кеше - запись master'a ? Ну так от повторных фетчей (в индексе + PP + DP) это не избавляет!
похер. Что ты так привязался к этим фетчам? Они тебе жмут?

ТаблоидЕсть "что-то", не позволяющее мну добавить в деталь новые строки, пока в соседнем окне идёт delete from tmain_casc where id = 1. Если это не блокирование master-записи, то что тогда ?
оно так и говорит - "не позволю!"?
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733742
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА, и еще тут вылезло, в схеме "каскады".
Исходные данные: в таблице tmain_casc - одна строка, в подчинённой ей tdetl_casc - ноль:
. . .
session #2 (в трейсе ниже - ATT_722). Запускаю в ней примерно через 5-7 сек вот это:
Код: plaintext
rollback; set transaction no wait; delete from tmain_casc where id=1;

Бесовщина какая-то лезет!
Если переключиться БЫСТРО (из session #1 в session #2), то вторая сессия, запустившая удаление мастер-строки всё равно позже, чем первая, каким-то образом умудряется таки её удалить! И облом получает уже только session #1:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
session #1
SQL> in ins;

session #2 -- быстро(!) переходим сюда Alt-Tab'ом
SQL> rollback; set transaction no wait; delete from tmain_casc where id=1;

session #1
Statement failed, SQLSTATE = 23000
violation of FOREIGN KEY constraint "TDETL_CASC_FK" on table "TDETL_CASC"
-Foreign key reference target does not exist
-Problematic key value is ("PID" = 1)
After line 2 in file ins

session #2
SQL> _ -- смогла удалить строку в master'e, хотя стартовала стейтмент позже.

Trace:
::NB:: первая сессия успела к тому моменту добавить 33521 строк
Код: plaintext
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.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
Trace session ID 5 started
2014-09-01T00:25:40.0670 (27769:0x7f9ae1c61b90) TRACE_INIT
        SESSION_5


2014-09-01T00:25: 40.069 0 (27769:0x7f9ae1c61b90) EXECUTE_STATEMENT_START
        oltp30 (ATT_720, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:31141
                (TRA_443466, CONCURRENCY | NOWAIT | READ_WRITE)

Statement 984:
-------------------------------------------------------------------------------
execute block as
declare i int = 0;
declare n int = 1000000;
begin
  while (i < n ) do insert into tdetl_casc(id, pid) values( :i, 1 ) returning :i+1 into i;
end


2014-09-01T00:25: 40.671 0 (27769:0x7f9ae1c6bf90) TRACE_INIT
        SESSION_5


2014-09-01T00:25:40.6730 (27769:0x7f9ae1c6bf90) EXECUTE_STATEMENT_START
        oltp30 (ATT_722, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:31387
                (TRA_443468, CONCURRENCY | NOWAIT | READ_WRITE)

Statement 985:
-------------------------------------------------------------------------------
delete from tmain_casc where id=1

2014-09-01T00:25:40.9600 (27769:0x7f9ae1c61b90) FAILED EXECUTE_STATEMENT_FINISH
        oltp30 (ATT_720, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:31141
                (TRA_443466, CONCURRENCY | NOWAIT | READ_WRITE)

Statement 984:
-------------------------------------------------------------------------------
execute block as
declare i int = 0;
declare n int = 1000000;
begin
  while (i < n ) do insert into tdetl_casc(id, pid) values( :i, 1 ) returning :i+1 into i;
end

0 records fetched
    891 ms, 681 write(s), 1009179 fetch(es), 236992 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$INDICES                                       2                                                           
RDB$RELATION_CONSTRAINTS                          1                                                           
TDETL_CASC                                                        33521               33521                   

2014-09-01T00:25:40.9600 (27769:0x7f9ae1c61b90) ERROR AT JStatement::execute
        oltp30 (ATT_720, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:31141
335544466 : violation of FOREIGN KEY constraint "TDETL_CASC_FK" on table "TDETL_CASC"
335544838 : Foreign key reference target does not exist
335545072 : Problematic key value is ("PID" = 1)

2014-09-01T00:25:41.0130 (27769:0x7f9ae1c6bf90)  EXECUTE_STATEMENT_FINISH 
        oltp30 (ATT_722, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:31387
                (TRA_443468, CONCURRENCY | NOWAIT | READ_WRITE)

Statement 985:
-------------------------------------------------------------------------------
delete from tmain_casc where id=1
0 records fetched
    340 ms, 98643 fetch(es), 1 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
TMAIN_CASC                                        1                             1
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733749
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrТаблоидТут три раза повторяется значение "444555".а если это будет три повторения из 100500 записей ? Создание FK на табличке-миллиарднике. Давай-ка закешируй мастер.Кешировать в TreeSet'e надо только PK/UK-ключи мастера. Которые в бол-ве случаев есть int / bigint (т.е. макс. 8 байт).
Кстати, если речь пошла о расходе памяти: а как тогда ФБ создаёт битмапы для выборок в 100500 млрд строк, когда там PLAN INDEX ? В этих битмапах хранятся номера записей (rdb$db_key char(8) ?), и лимита никакого (по памяти) вроде бы нет.

dimitrЧто ты так привязался к этим фетчам? Они тебе жмут?Не они жмут, а неадекватно-огроменные IDX_READS, которые показывают новые mon$-счетчики на одной таблице. В одном известном тебе тесте.
Я начал ковыряться в коде и вижу: эта таблица (DOC_DATA) является родительской к двум другим (QDISTR & QSORNED, причём вторая связана с DOC_DATA не одним, а двумя полями).
Вспомнив, для чего вводил эти FK, решил грохнуть их к ЧМ: алгоритм и так не позволяет нарушать ссылки.

Запустил заново - и вижу, что статистика вообще не поменялась. Что с ними, что без них.
Но такого не может быть, раз есть какие-то "тайные затраты" на поддержание ссыл. целостности!
Вот такая история.
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733830
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидКешировать в TreeSet'e надо только PK/UK-ключи мастера. Которые в бол-ве случаев есть int / bigint (т.е. макс. 8 байт).
расскажи это Жене Болтику :-)

ТаблоидКстати, если речь пошла о расходе памяти: а как тогда ФБ создаёт битмапы для выборок в 100500 млрд строк, когда там PLAN INDEX ? В этих битмапах хранятся номера записей (rdb$db_key char(8) ?), и лимита никакого (по памяти) вроде бы нет.
RTFM sparse bitmap

dimitrЗапустил заново - и вижу, что статистика вообще не поменялась. Что с ними, что без них.
значит, не в них дело. А в кривых запросах или кривых данных.

dimitrНо такого не может быть, раз есть какие-то "тайные затраты" на поддержание ссыл. целостности!
ок, выведу я тебе "тайные" затраты. Но уже сейчас понятно, что оно ничего тебе не даст.
...
Рейтинг: 0 / 0
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733962
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrрасскажи это Жене Болтику :-)я плохо понимал его мысли, когда они тут появлялись.
Надеюсь, он меня тоже не поймёт, так что не буду тратить время попусту.
dimitrdimitrЗапустил заново - и вижу, что статистика вообще не поменялась. Что с ними, что без них.значит, не в них дело. А в кривых запросах или кривых данных.Да там запросы - "два притопа, три прихлопа". Через курсоры пришлось многие вещи делать, к сож-ю.
А насчет кривых данных - это ты про перекошенные распределения говоришь или что ? ибо данные генерятся рандомно из некоторых диапазонов, изначально они "равномерные".

dimitrок, выведу я тебе "тайные" затраты. Но уже сейчас понятно, что оно ничего тебе не даст.Это мы еще поглядим! :-)

ЗЫ. Как объяснить "артефакты" номер раз и два ?
...
Рейтинг: 0 / 0
29 сообщений из 29, показаны все 2 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]