Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ? / 25 сообщений из 29, страница 1 из 2
31.08.2014, 16:35
    #38733598
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
Код: 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
31.08.2014, 16:48
    #38733601
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
Таблоид,

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

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

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

может и было. Но как сказал ДЕ оно относится к другому статменту. Вот когда ты создаёшь триггер before/after insert статистика по действиям внутри триггера будет относится к триггеру, а не к оператору insert. Так?
...
Рейтинг: 0 / 0
31.08.2014, 20:23
    #38733666
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
Симонов Денискак сказал ДЕ оно относится к другому статменту .К какому именно "другому" ?? Я ввожу ОДИН стейтмент!
Симонов ДенисВот когда ты создаёшь триггер 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
31.08.2014, 20:30
    #38733668
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
сейчас перепроверил - операции триггеров должны включаться в статистику "родителя". Надо проверять.
...
Рейтинг: 0 / 0
31.08.2014, 20:32
    #38733669
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
ТаблоидА стейтмент, прописанный в явно созданном TDETL_BIU - уже относится.

извиняюсь был не прав.
...
Рейтинг: 0 / 0
31.08.2014, 20:40
    #38733675
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
dimitrсейчас перепроверил - операции триггеров должны включаться в статистику "родителя". Надо проверять.А нельзя ли фикс (если он будет) сделать прежде всего для 3.0 (где есть mon$-новшества) и прислать мну в мыльце в виде патчика ? А то ну очень надо - ты же знаешь причину этой "пурги"! :-)
...
Рейтинг: 0 / 0
31.08.2014, 21:00
    #38733677
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
фикса не будет. Я зарапортовался, никакого check-триггера без каскада есс-но нет. FK проверяется при вставке в индекс, операции внутри индекса в табличную статистику никак не попадают (и не должны). Т.е. Денис выше все правильно написал.
...
Рейтинг: 0 / 0
31.08.2014, 21:07
    #38733679
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
dimitrFK проверяется при вставке в индекс, операции внутри индекса в табличную статистику никак не попадают ( и не должны ).Как именно проверяется FK, ведь в родит. таблицу надо слазить или нет ? И если обращения к ней таки есть (да еще и для каждой из 100500 млн добавляемых в деталь строк), то почему они не должны показываться ?
...
Рейтинг: 0 / 0
31.08.2014, 21:08
    #38733680
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
ТаблоидdimitrFK проверяется при вставке в индекс, операции внутри индекса в табличную статистику никак не попадают ( и не должны ).Как именно проверяется FK, ведь в родит. таблицу надо слазить или нет ? И если обращения к ней таки есть (да еще и для каждой из 100500 млн добавляемых в деталь строк), то почему они не должны показываться ?А, стоп. Пардон, я понял: ты говоришь о том, что в родит. ТАБЛИЦУ вообще нет обращений, есть только ходьба в её ИНДЕКС.
Ну так это же IR , нет разве ?
...
Рейтинг: 0 / 0
31.08.2014, 21:25
    #38733684
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
значит, так. Выборки из таблицы нет. Поиск в индексе есть. Обращение к таблице тоже есть, но довольно специфическое. Технически наверное его можно назвать индексным, хотя формально оно не относится ни к seq_reads ни к idx_reads. Я пока не знаю, как это будет правильнее показать в статистике. Буду думать.
...
Рейтинг: 0 / 0
31.08.2014, 22:25
    #38733710
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
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
31.08.2014, 22:40
    #38733715
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
ТаблоидПотому что заставляет ФБ делать больше фетчей при каскаде, чем при его
эмуляции
Каскадные операции тут ни при чём. Это расходы на поддержание ссылочной целостности,
которую твоя эмуляция не обеспечивает.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
31.08.2014, 22:45
    #38733717
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
Dimitry SibiryakovЭто расходы на поддержание ссылочной целостности, которую твоя эмуляция не обеспечивает."Расшифровку" бы получить, расходов этих. Что там за два фетча на каждую запись, чего они ради ?
...
Рейтинг: 0 / 0
31.08.2014, 22:52
    #38733720
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
Таблоид"Расшифровку" бы получить, расходов этих. Что там за два фетча на каждую запись, чего они ради ?
то самое "специфическое" чтение записи из таблицы, один фетч на PP и один на DP - все как обычно. Требуется чтобы сравнить поля связи мастера со слейвом (ключ индекса может "врать", ибо априори неточен).
...
Рейтинг: 0 / 0
31.08.2014, 22:59
    #38733722
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
dimitrТаблоид"Расшифровку" бы получить, расходов этих. Что там за два фетча на каждую запись, чего они ради ?то самое "специфическое" чтение записи из таблицы, один фетч на PP и один на DP - все как обычно. Требуется чтобы сравнить поля связи мастера со слейвом (ключ индекса может "врать", ибо априори неточен).А зачем на каждой обрабатываемой detail-строке дёргать запись мастера, почему нельзя закешировать после первого прочтения ? Разве она не блокируется на старте DML-стейтмента и до тех пор, пока он не завершится ?
...
Рейтинг: 0 / 0
31.08.2014, 23:05
    #38733726
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
ТаблоидА зачем на каждой обрабатываемой detail-строке дёргать запись мастера, почему нельзя закешировать после первого прочтения ?
а откуда сервер знает, что следующая деталь будет ссылаться на того же мастера? В общем случае это не так. Кроме того, записи мастера и так буферизируются страничным кешем.

ТаблоидРазве она не блокируется на старте DML-стейтмента и до тех пор, пока он не завершится ?
кто "она"? Какое-такое "блокирование"?
...
Рейтинг: 0 / 0
31.08.2014, 23:53
    #38733734
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
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
01.09.2014, 00:04
    #38733737
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
ТаблоидЭто вообще похоже на связь 1-1.
вполне легальная связь, которой пользуется куча народу

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

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

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

ТаблоидНапример, при добавлении в вышеприведенном скрипте в таблицу tdetl_casc 1 млн строк, второе окно, пытающееся удалить master-строку, получает по лбу
ибо при удалении мастера проверяется ссылочная целостность (наличие строк-деталей)
...
Рейтинг: 0 / 0
01.09.2014, 00:11
    #38733739
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
А, и еще тут вылезло, в схеме "каскады".
Исходные данные: в таблице 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
01.09.2014, 00:24
    #38733740
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
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
01.09.2014, 00:34
    #38733741
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
ТаблоидТут три раза повторяется значение "444555".
а если это будет три повторения из 100500 записей? Создание FK на табличке-миллиарднике. Давай-ка закешируй мастер.

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

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

ТаблоидЕсть "что-то", не позволяющее мну добавить в деталь новые строки, пока в соседнем окне идёт delete from tmain_casc where id = 1. Если это не блокирование master-записи, то что тогда ?
оно так и говорит - "не позволю!"?
...
Рейтинг: 0 / 0
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ? / 25 сообщений из 29, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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