ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
4 сообщений из 29, страница 2 из 2
  2  все
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
01.09.2014, 00:34
| Ответить | Цитировать | Написать  
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
01.09.2014, 00:49
| Ответить | Цитировать | Написать  
trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
    #38733830
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидКешировать в TreeSet'e надо только PK/UK-ключи мастера. Которые в бол-ве случаев есть int / bigint (т.е. макс. 8 байт).
расскажи это Жене Болтику :-)

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

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

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

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

ЗЫ. Как объяснить "артефакты" номер раз и два ?
...
Рейтинг: 0 / 0
01.09.2014, 12:18
| Ответить | Цитировать | Написать  
4 сообщений из 29, страница 2 из 2
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / trace: должны ли быть index reads родит. таблицы при работе в дочерней с FK-полем ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38733742&tid=1563367]:
 0ms
get settings:
 10ms
get forum list:
 20ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 199ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 36ms
get tp. blocked users:
 1ms
others: 239ms
total:  523ms
созд. / загр.: 523ms
x
x
Закрыть


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