ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Понимание результатов fb_lock_print
25 сообщений из 119, страница 2 из 5
  2  все
Понимание результатов fb_lock_print
    #38115189
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоидя всё равно НЕ получу никакой инфы о номере транзакции / коннекта, который не даёт добавить строку в detail-таблицу?для NOWAIT транзакции есс-но не получишь, ибо не сможешь в ЛТ найти ожидающий коннект. Для WAIT - номер коннекта найдешь при желании.Хорошо, вот пример с WAIT.
Новая база, таблица t(id int, f01 int);
В таблицу добавлена единственная строка: id=1, f01=1, после чего выполнен quit.
Затем:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
 connect #1 
C:\MIX\firebird\fb25>isql 192.168.0.60:test -n
Database:  192.168.0.60:test
SQL> update t set f01=-1 where id=1;
SQL> select current_connection,current_transaction from rdb$database;

CURRENT_CONNECTION CURRENT_TRANSACTION
================== ===================
                 6                  24

 connect #2 
C:\MIX\firebird\fb25>isql 192.168.0.60:test -n
Database:  192.168.0.60:test
SQL> update t set f01=-2 where id=1; -- висяк.

В этот момент была снята ЛТ:
Код: plaintext
fb_lock_print -a -d test
-- см аттач.
Допустим, надо понять, кто не даёт второму коннекту проапдейтить строку.

В лок-таблице ищем строку с pending: NNNNN, где NNNNN > 0.
Такой блок - один (в данной ситуации):
Код: plaintext
1.
2.
3.
4.
5.
OWNER BLOCK 215480
        Owner id: 132684431762415, type: 1, pending:  216240 
        Process id:  30893 (Alive), thread id: 140166742538000
        Flags: 0x06             scan wait infn      
        Requests (84):  forward: 228144, backward: 216240
        Blocks: *empty*

Если теперь поискать строку вида 'BLOCK 216240", то мы выходим на вот это:
Код: plaintext
1.
2.
3.
4.
5.
REQUEST BLOCK  216240 
        Owner: 215480, Lock: 214264, State: 0, Mode: 3, Flags: 0x82
        AST: 0x(nil), argument: 0x(nil)
        lrq_own_requests:       forward: 215492, backward: 229296
        lrq_lbl_requests:       forward: 214240, backward: 214144
        lrq_own_blocks  : *empty*
(других таких блоков нету).
То, что в этом блоке записано "Owner: 215480", подсказывает очевидное: мы нашли нечто, что хотел заблокировать зависший коннект с id=215480. А хотел он залочить объект с id = 214264.

Ищем далее строку "BLOCK 214264" и находим её тут:
Код: plaintext
1.
2.
3.
4.
5.
6.
LOCK BLOCK  214264 
        Series: 4, Parent: 213184, State: 6, size: 8 length: 4 data: 24
        Key: 000024, Flags: 0x00, Pending request count:      1
        Hash que (4):   forward: 214776, backward: 213824
        Requests (2):   forward: 214144, backward: 216240
                Request 214144, Owner: 212936, State: 6 (6), Flags: 0x00
                Request 216240, Owner: 215480, State: 0 (3), Flags: 0x82
Видим, что её получил в exclusive-распоражение некто "Request 214144, Owner: 212936 , State: 6 (6)".

Отлично. Ищем теперь строку "OWNER BLOCK 212936".
Находим этот блок в самом начале ЛТ:
Код: plaintext
1.
2.
3.
4.
5.
6.
OWNER BLOCK  212936 
        Owner id: 132684431762346, type: 1, pending:      0
        Process id:  30893 (Alive), thread id: 140166742538000
        Flags: 0x00                               
        Requests (83):  forward: 213120, backward: 224048
        Blocks: *empty*
- видим, что он сам уже ничего не ждёт (pending: 0), но... дальше-то что ?
Номер коннекта (который равен 6 - см выше), номер транзакции - в где они тут ?

С другой стороны, в mon$statements видим (с третьего окна):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SQL> select * from mon$statements where mon$attachment_id<>current_connection;

MON$STATEMENT_ID                235
MON$ATTACHMENT_ID               8
MON$TRANSACTION_ID              26
 MON$STATE                       1 
MON$TIMESTAMP                   2013-01-18 12:24:46.4340
MON$SQL_TEXT                    0:4
 update t set f01=-2 where id=1 
MON$STAT_ID                     7

MON$STATEMENT_ID                35
MON$ATTACHMENT_ID               6
MON$TRANSACTION_ID              <null>
 MON$STATE                       0 
MON$TIMESTAMP                   <null>
MON$SQL_TEXT                    0:6
 update t set f01=-1 where id=1 
MON$STAT_ID                     10
По равенству ID'шников таблицы `t` можно понять, ес-сно, что тут и есть затык. Но это - примитивный запрос, в нём сразу видно, ЧТО будет меняться. В реальности такое редко бывает.

В общем, я так и не понял, как в ЛТ найти транзакцию-"держиморду", которая не даёт развиваться остальным. Что в wait-режиме, что без него.
...
Рейтинг: 0 / 0
18.01.2013, 12:58:18
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115309
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ищи лок с series = LCK_attachment, у которого будет всего один owner = 212936. Это LOCK BLOCK 214080. Его key равен номеру коннекта. С транзакцией сложнее, т.к. она напрямую с локом не связана. Если ожидание именно на записи, то смотри key у конфликтного лока 214264. Либо просто ищи все тр-ции данного овнера по вышесказанному алгоритму, только для series = LCK_tra.
...
Рейтинг: 0 / 0
18.01.2013, 13:29:19
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115339
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrищи лок с series = LCK_attachment, у которого будет всего один owner = 212936. Это LOCK BLOCK 214080. Его key равен номеру коннекта. С транзакцией сложнее, т.к. она напрямую с локом не связана. Если ожидание именно на записи, то смотри key у конфликтного лока 214264. Либо просто ищи все тр-ции данного овнера по вышесказанному алгоритму, только для series = LCK_tra.Нашёл, псип. Вот они, коннекты (6 и 8 для данного примера):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
LOCK BLOCK 214080
	 Series: 7 , Parent: 213184, State: 6, size: 8 length: 4 data: 0
	 Key: 000006 , Flags: 0x00, Pending request count:      0
	Hash que (3):	forward: 214904, backward:    420
	Requests (1):	forward: 214016, backward: 214016
		Request 214016, Owner: 212936, State: 6 (6), Flags: 0x00
...
LOCK BLOCK 227248
	 Series: 7 , Parent: 213184, State: 6, size: 8 length: 4 data: 0
	 Key: 000008 , Flags: 0x00, Pending request count:      0
	Hash que (1):	forward:    436, backward:    436
	Requests (1):	forward: 225392, backward: 225392
		Request 225392, Owner: 215480, State: 6 (6), Flags: 0x00

ЗЫ. Соответствие номеров серий их мнемоникам вытащу сюда, чтобы в дальнейшем не рыскать по сырцам.
Код: 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.
[root@firebird jrd]# tail --lines=+35 lck.h | cat -n
     1          LCK_database = 1,                       // Root of lock tree
     2          LCK_relation,                           // Individual relation lock
     3          LCK_bdb,                                        // Individual buffer block
     4          LCK_tra,                                        // Individual transaction lock
     5          LCK_rel_exist,                          // Relation existence lock
     6          LCK_idx_exist,                          // Index existence lock
     7          LCK_attachment,                         // Attachment lock
     8          LCK_shadow,                                     // Lock to synchronize addition of shadows
     9          LCK_sweep,                                      // Sweep lock for single sweeper
    10          LCK_retaining,                          // Youngest commit retaining transaction
    11          LCK_expression,                         // Expression index caching mechanism
    12          LCK_prc_exist,                          // Procedure existence lock
    13          LCK_update_shadow,                      // shadow update sync lock
    14          LCK_backup_alloc,           // Lock for page allocation table in backup spare file
    15          LCK_backup_database,        // Lock to protect writing to database file
    16          LCK_backup_end,                         // Lock to protect end_backup consistency
    17          LCK_rel_partners,                       // Relation partners lock
    18          LCK_page_space,                         // Page space ID lock
    19          LCK_dsql_cache,                         // DSQL cache lock
    20          LCK_monitor,                            // Lock to dump the monitoring data
    21          LCK_tt_exist,                           // TextType existence lock
    22          LCK_cancel,                                     // Cancellation lock
    23          LCK_btr_dont_gc,                        // Prevent removal of b-tree page from index
    24          LCK_shared_counter,                     // Database-wide shared counter
    25          LCK_rel_gc                                      // Allow garbage collection for relation
...
Рейтинг: 0 / 0
18.01.2013, 13:39:00
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115554
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
ТаблоидСоответствие номеров серий их мнемоникам вытащу сюдаХм... а почему в этом списке нет краткосрочных блокировок (латчей ?), которые ставятся на страницы при их считывании ? (например, при получении gen_id, да и вообще при получении содержимого любой записи)
...
Рейтинг: 0 / 0
18.01.2013, 15:21:17
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115837
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
страничные локи - это LCK_bdb. Страничные латчи - это несколько другое и не относится к ЛМ.
...
Рейтинг: 0 / 0
18.01.2013, 18:18:26
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115925
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrстраничные локи - это LCK_bdb. Страничные латчи - это несколько другое и не относится к ЛМ.LCK_bdb - это блокировка, для которой Series = 3 (я выше вытряхнул из lck.h соотв-щее перечисление).
Тогда вышеприведенного примера и снимка ЛТ (файл выше в аттаче) получается 66(!) блокировок страниц:
Код: plaintext
1.
grep -i "series: 3" fb_lock_print_all_when_infinite_lock_waiting.txt  | wc -l
66

Если посмотреть на эти lock block'и, то увидим, только одна страница схвачена в режиме exclusive ( state=6 ), а все остальные - в режиме protected read (state=3):
Код: plaintext
1.
2.
3.
4.
5.
6.
bash-4.1$ grep -i "series: 3" lp_lck_dbd.txt | tail -5
        Series: 3, Parent: 213184, State: 3, size: 8 length: 8 data: 0
        Series: 3, Parent: 213184, State: 3, size: 8 length: 8 data: 0
        Series: 3, Parent: 213184, State: 3, size: 8 length: 8 data: 0
        Series: 3, Parent: 213184, State: 3, size: 8 length: 8 data: 0
        Series: 3, Parent: 213184,  State: 6 , size: 8 length: 8 data: 0

Про protected read догадываюсь: это блокировки метаданных, чтобы никто таблицу `t` не дропнул.
Но про последнюю, exclusive-блокировку:
Код: plaintext
1.
2.
3.
LOCK BLOCK 216304
        Series: 3, Parent: 213184, State: 6, size: 8 length: 8 data: 0
        Key:  0001:000170 , Flags: 0x00, Pending request count:      0
-- имею вопрос: страница базы номер 170, затолканная в hash-гнездо номер 1, сейчас заблокирована "вусмерть", т.е. её нельзя даже прочитать . Это так ?
...
Рейтинг: 0 / 0
18.01.2013, 19:26:30
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115931
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrСтраничные латчи - это несколько другое и не относится к ЛМ.Если так, то существует ли механизм определения времени, затрачиваемого на получение этих латчей, скажем, при выполнении какого-нибудь сверхтяжкого селекта ? Т.е. вот идёт селект, ему надо прочесть огромное число страниц базы (не говоря уже про число строк таблиц!). Он запрашивает латчи на чтение каждой страницы, затем "отпускает" страницу и идёт дальше. Сколько времени у него уходит на это - как определить ?
...
Рейтинг: 0 / 0
18.01.2013, 19:31:50
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115992
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидСколько времени у него уходит на это - как определить ?
никак. Но в твоем случае пофиг, ибо за латчи в SC/CS практически нет конкуренции. Они свои в каждом экземпляре кеша.
...
Рейтинг: 0 / 0
18.01.2013, 20:43:58
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38115993
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидимею вопрос: страница базы номер 170, затолканная в hash-гнездо номер 1, сейчас заблокирована "вусмерть", т.е. её нельзя даже прочитать . Это так ?
не так. Этот лок просто кеширован коннектом. Когда кто-либо еще будет брать эту страницу, лок отпустится по АСТу.
...
Рейтинг: 0 / 0
18.01.2013, 20:45:16
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38125996
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Очередной вопросик возник.
Создал базу, page_size = 16K, в ней - табличку:
Код: sql
1.
2.
3.
4.
create table t(id int, f01 int, f02 int);
insert into t values(1, 100, 111);
insert into t values(2, 200, 222);
commit;

Дальше отсоединился и выполнил b/r. Таблица с двумя записями, очевидно, влезла в одну страницу базы:
gstat -r
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
<...>
T (128)
    Primary pointer page: 141, Index root page: 142
    Average record length: 16.00, total records: 2
    Average version length: 10.00, total versions: 1, max versions: 1
    Data pages: 1, data page slots: 1, average fill: 1%
<...>

Затем запускаю два isql окошка и в каждом них делаю апдейты строк без lock conflict'ов:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
 session #1 
C:\1INSTALL\FIREBIRD\Data>isql -n localhost:C:\1INSTALL\FIREBIRD\Data\TT.FDB
Database:  localhost:C:\1INSTALL\FIREBIRD\Data\TT.FDB
SQL>  select current_connection,current_transaction from rdb$database;

CURRENT_CONNECTION CURRENT_TRANSACTION
================== ===================
                 3                   7

SQL>  update t set f01=-f02, f02=-f01 where id=1;

 session #2 
C:\1INSTALL\FIREBIRD\Data>isql localhost:C:\1INSTALL\FIREBIRD\Data\TT.FDB -n
Database:  localhost:C:\1INSTALL\FIREBIRD\Data\TT.FDB
SQL> select current_connection,current_transaction from rdb$database;

CURRENT_CONNECTION CURRENT_TRANSACTION
================== ===================
                 4                   8

SQL> update t set f01=-f02, f02=-f01 where id=2;
Теперь делаю снимок ЛТ:
Код: plaintext
fb_lock_print -c -a -d TT.FDB >fb_lp_two_connects_updated_two_diff_records.txt

Если я правильно понимаю, снимок ЛТ должен содержать множество lock block'ов с сериями = 3 (это LCK_bdb - Individual buffer block). Причём, та единственная страница базы, в которой живут две записи таблицы `T`, должна встречаться в двух lock block'ах - ведь два коннекта держут "свои" блокировки записей, которые живут на этой самой странице.
И в каждом из этих лок-блоков должны быть блокировки уровня shared write, что соответствует "state: 4".

Я не вижу в упор, где это в ЛТ (она в аттаче).
Ибо команда поиска:
Код: plaintext
type fb_lp_two_connects_updated_two_diff_records.txt | findstr /i /n /c:"series: 3" > series_3_rows.txt
- выдаёт 48 строк со "State: 3" (protected read) и одну (49-ю) строку с "State: 6" (exclusive).
 
findstr result
Код: 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.
1178:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1201:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1223:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1231:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1252:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1260:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1268:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1276:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1292:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1300:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1308:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1316:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1324:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1332:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1340:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1356:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1364:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1380:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1388:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1396:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1404:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1412:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1420:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1428:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1436:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1444:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1452:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1460:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1468:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1476:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1484:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1492:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1500:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1508:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1516:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1524:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1532:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1540:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1548:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1556:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1564:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1572:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1580:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1588:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1596:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1604:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1612:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1628:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1636:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1644:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1652:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1660:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1668:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1692:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1700:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1708:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1716:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1724:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1732:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1740:   Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
1748:   Series: 3, Parent:  18892, State: 6, size: 8 length: 8 data: 0
...
Рейтинг: 0 / 0
27.01.2013, 00:16:58
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126001
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоиддва коннекта держут "свои" блокировки записей

Ничего они не держут. Заблокировали что нужно, сделали своё грязное дело и давно уже
блокировки отпустили так, что ты и глазом моргнуть не успел.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 00:26:45
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126002
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovНичего они не держут. Заблокировали что нужно, сделали своё грязное дело и давно уже
блокировки отпустили так, что ты и глазом моргнуть не успел.Это как это ?! а "кто" тогда мешает третьему коннекту проапдейтить эти же строки ?
...
Рейтинг: 0 / 0
27.01.2013, 00:28:22
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126008
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоида "кто" тогда мешает третьему коннекту проапдейтить эти же строки ?

Совесть. Он видит наличие незакоммиченных версий.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 00:46:40
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126019
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovОн видит наличие незакоммиченных версий.Этого мало. Он также должен видеть, живые ли соотв-щие транзакции.
Тогда получается, что составить картину типа "Кто чего сейчас держит заблокированным" практически нереально: надо пройтись по всем незакоммиченным версиям и попробовать "тихо" их залочить, чтобы понять, живы ли соотв-щие транзакции - владельцы блокировок, а затем "разлочить".
Этот процесс будет выполняться долго и всё загнётся. Я прав в своей догадке ?
...
Рейтинг: 0 / 0
27.01.2013, 00:57:59
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126028
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ТаблоидОн также должен видеть, живые ли соотв-щие транзакции.

А для этого у него есть TIP и возможность послать сигнал "есть кто живой" другой транзакции.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.01.2013, 01:09:36
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126049
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидПричём, та единственная страница базы, в которой живут две записи таблицы `T`, должна встречаться в двух lock block'ахНет, ибо страница - одна, значит и блокировка у неё тоже одна.
Вот request'ов может быть много. А lock - один.

Таблоидведь два коннекта держут "свои" блокировки записейНет никаких блокировок записей. НЕТ ИХ.

Таблоидблокировки уровня shared writeНет конечно.

События происходили примерно так:
1. первый коннект собирается читать страницу с данными и просит SR блокировку
- блокировка получена, можно читать страницу
2. первый коннект собирается менять страницу с данными и просит PW блокировку
- блокировка получена, можно менять страницу
- старая SR при этом отпускается
3. второй коннект собирается читать с данными и просит SR блокировку
- первый коннект получает сигнал и отпускает свою PW блокировку, при этом он пишет страницу на диск
- второй коннект получает SR блокировку и читает страницу с диска
4. второй коннект собирается менять страницу с данными и просит PW блокировку
...

Итого: у последнего писателя есть PW блокировка, у остальных - нет никаких блокировок
этой страницы.
...
Рейтинг: 0 / 0
27.01.2013, 02:16:44
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126051
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Чтобы ещё больше запутать Таблоида, уточню - то, что движок считает блокировками, на самом деле лишь запросы на блокировки. Т.е. в лок-менеджере им соответствуют REQUEST'ы.

Есть две основные сущности - владельцы ресурсов (OWNER'ы) и собственно ресурсы, точнее их блокировки (LOCK'и). Владельцы делают запросы (REQUEST'ы) на владение ресурсами. Можно сказать, что владельцы и ресурсы связаны как M:N посредством запросов.

С точки зрения владельца его список запросов есть список ресурсов которыми он владеет или хочет овладеть.

С точки зрения ресурса, его список запросов можно разделить на две части:
- удовлетворённые запросы (их владельцы совместно владеют ресурсом), и
- ожидающие запросы (их владельцы хотят получить доступ, несовместимый с доступом первой группы)

Например, из твоего файла:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
LOCK BLOCK  22120
	Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
	Key: 0001:000143, Flags: 0x00, Pending request count:      0
	Hash que (1):	forward:   1500, backward:   1500
	Requests (2):	forward:  22068, backward:  31892
		Request  22068, Owner:  18744, State: 3 (3), Flags: 0x00
		Request  31892, Owner:  20992, State: 3 (3), Flags: 0x00
Это блокировка страницы (Series: 3) с номером 143.
Её состояние - PR (State: 3).
Ею владеют 2 владельца (18744, 20992)

А вот совсем другая блокировка
Код: plaintext
1.
2.
3.
4.
5.
6.
LOCK BLOCK  30476
	Series: 4, Parent:  18892, State: 6, size: 8 length: 4 data: 7
	Key: 000008, Flags: 0x00, Pending request count:      0
	Hash que (3):	forward:  30360, backward:  22584
	Requests (1):	forward:  30424, backward:  30424
		Request  30424, Owner:  20992, State: 6 (6), Flags: 0x00
Это блокировка транзакции (Series: 4) с номером 8.
Её состояние - EX (State: 6).
Ею безраздельно владеет владелец 20992


PS в предыдущем посте читать вместо SR и PW соответственно PR и EX
...
Рейтинг: 0 / 0
27.01.2013, 02:31:58
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126113
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
С учетом вот этой фразы:hvladчитать вместо SR и PW соответственно PR и EX- подправил тот текст и получаю:hvladСобытия происходили примерно так:
1. первый коннект собирается читать страницу с данными и просит SR Protected Read блокировку
- блокировка получена, можно читать страницу
2. первый коннект собирается менять страницу с данными и просит PW Exclusive блокировку
- блокировка получена, можно менять страницу
- старая SR при этом отпускается ВОПРОС-1. Первый коннект выдал команду UPDATE, смысл которой - поменять содержимое страницы. Да, понятно, что сначала надо найти эту страницу. Но почему нельзя после её нахождения сразу поставить exclusive-блокировку, без промежуточной PR ? И почему, кстати, нужна именно EX, разве Protected Write не будет достаточной ? (страница ведь обновляется целиком, никаких там "частичных записей" со 153-его по 234-й байт нету ==> никто не сможет прочитать её в "несогласованном" виде. Или не так ?)

И еще вопрос.hvlad
Код: plaintext
1.
2.
3.
4.
5.
6.
LOCK BLOCK  22120
	Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
	Key: 0001 :000143 , Flags: 0x00, Pending request count:      0
	Hash que (1):	forward:   1500, backward:   1500
	Requests (2):	forward:  22068, backward:  31892
		Request  22068, Owner:  18744, State: 3 (3), Flags: 0x00
		Request  31892, Owner:  20992, State: 3 (3), Flags: 0x00

Это блокировка страницы (Series: 3) с номером 143 .
Её состояние - PR (State: 3). Там еще десятки аналогичных лок-блоков:
 
Код: 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.
...
LOCK BLOCK  23860
        Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
        Key: 0001:0000 79 , Flags: 0x00, Pending request count:      0
        Hash que (1):   forward:    988, backward:    988
        Requests (2):   forward:  23808, backward:  30904
                Request  23808, Owner:  18744, State: 3 (3), Flags: 0x00
                Request  30904, Owner:  20992, State: 3 (3), Flags: 0x00

LOCK BLOCK  26180
        Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
        Key: 0001:0000 80 , Flags: 0x00, Pending request count:      0
        Hash que (1):   forward:    996, backward:    996
        Requests (2):   forward:  26128, backward:  29372
                Request  26128, Owner:  18744, State: 3 (3), Flags: 0x00
                Request  29372, Owner:  20992, State: 3 (3), Flags: 0x00

LOCK BLOCK  22700
        Series: 3, Parent:  18892, State: 3, size: 8 length: 8 data: 0
        Key: 0001:0000 81 , Flags: 0x00, Pending request count:      0
        Hash que (1):   forward:   1004, backward:   1004
        Requests (2):   forward:  22648, backward:  31528
                Request  22648, Owner:  18744, State: 3 (3), Flags: 0x00
                Request  31528, Owner:  20992, State: 3 (3), Flags: 0x00
...
Они отличаются только номерами внутри хеш-гнёзда ("0001:000NNN"), а еще ID'шниками forward/backward.
Все они в том же самом Protected Read, т.е. эти страницы (..., 79, 80, 81, ...) сейчас можно читать, но в них нельзя записывать.

ВОПРОС-2. Что это за страницы ? Как понять, к какому объекту базы они относятся ? В gstat'e по пользовательским таблицам нет инфы о номерах страниц, а rdb$-таблицы так вообще не отображаются никак.

hvlad3. второй коннект собирается читать с данными и просит Protected Read SR блокировку
- первый коннект получает сигнал и отпускает свою Exclusive PW блокировку, при этом он пишет страницу на диск
- второй коннект получает Protected Read SR блокировку и читает страницу с диска ВОПРОС-3. По каким правилам owner-"А", получивший сигнал "отпусти ресурс!" от owner'a-"Б", решает, можно ли это делать ? Или он делает это всегда, а уж owner-"Б" должен сам позаботиться о сохранности изменений owner'a-"A" ?
...
Рейтинг: 0 / 0
27.01.2013, 11:21:23
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126157
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид ВОПРОС-1. Первый коннект выдал команду UPDATE, смысл которой - поменять содержимое страницы. Да, понятно, что сначала надо найти эту страницу. Но почему нельзя после её нахождения сразу поставить exclusive-блокировку, без промежуточной PR ?
потому что update "изнутри" - это а-ля for select + update where current of. Нафига лочить страницу на запись, если предикат может оказаться ложным и мы запись не будем менять? Но иногда таки ставится сразу EX еще при чтении, если оптимизатор сочтет это более удачным. Это экономит конверсию лока.

ТаблоидИ почему, кстати, нужна именно EX, разве Protected Write не будет достаточной ?
в случае страничных блокировок монопенисуально, т.к. поведение читателей от этого никак не изменится

ТаблоидОни отличаются только номерами внутри хеш-гнёзда ("0001:000NNN")
0001 - это не хеш-гнездо, а номер page space

Таблоид ВОПРОС-2. Что это за страницы ? Как понять, к какому объекту базы они относятся ?
никак (без отладчика)

Таблоид ВОПРОС-3. По каким правилам owner-"А", получивший сигнал "отпусти ресурс!" от owner'a-"Б", решает, можно ли это делать ? Или он делает это всегда, а уж owner-"Б" должен сам позаботиться о сохранности изменений owner'a-"A" ?
всегда, при условии что owner A в данный момент не меняет страницу. Если меняет - то отпустит "как только так сразу". О сохранности заботится owner A, записывая измененную страницу на диск - читай ответ Влада внимательнее.
...
Рейтинг: 0 / 0
27.01.2013, 13:05:50
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126162
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидВ gstat'e по пользовательским таблицам нет инфы о номерах страниц
IBSurgeonViewer покажет. правда, не на "живой" базе.
...
Рейтинг: 0 / 0
27.01.2013, 13:14:25
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126168
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrНафига лочить страницу на запись, если предикат может оказаться ложным и мы запись не будем менять?Ну так мы всё равно её лочим, только в режиме protected read.

К тому же, предикат окажется ложным после получения protected read-блокировки только в случае, когда эта же запись подверглась модификации другой транзакцией
 
оно ?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
 connect #1 
SQL> select * from t;

          ID          F01          F02
============ ============ ============
           1         -111         -100
           2          200          222

SQL> delete from t where id=1;

 connect #2 
SQL> update t set f01=-f01 where id=1;

 connect #1 
SQL> commit;

 connect #2 
Statement failed, SQLSTATE = 40001
deadlock
-update conflicts with concurrent update
-concurrent transaction number is 12
Не так уж часто сиё бывает по сравнению с числом страниц, которые остаются неизменными после первоначального создания и многократных дальнейших их чтений.
Почему нельзя так:
1) запрашиваем страницу 123 в режиме protected write
2) получили, проверяем предикат
3) предикат не изменился ==> сразу же меняем содержимое, без затрат на повышение блокировки
4) предикат изменился ==> отвал.
Ы ?

dimitr0001 - это не хеш-гнездо, а номер page spaceЧто это за "единица измерения", в где-то про неё написано ?
...
Рейтинг: 0 / 0
27.01.2013, 13:27:19
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126181
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидНу так мы всё равно её лочим, только в режиме protected read.
это не мешает остальным коннектам ее читать в этот момент, в отличие от

ТаблоидК тому же, предикат окажется ложным после получения protected read-блокировки только в случае, когда эта же запись подверглась модификации другой транзакцией
серверу глубоко фиолетово, какой именно у тебя предикат. Может там условие 1=0. Тоже лочить все страницы на запись?

ТаблоидПочему нельзя так
потому что фигню написал. Я не знаю что такое "предикат изменился".

ТаблоидЧто это за "единица измерения", в где-то про неё написано ?
оно тебе не надо. Это область со своей нумерацией страниц. В первом приближении это файл. Для основной базы это всегда 1, для GTT - ID экземпляра данных (временного файла).
...
Рейтинг: 0 / 0
27.01.2013, 13:52:30
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126182
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvIBSurgeonViewer покажет. правда, не на "живой" базе.Дык интересуют именно возможности анализа ЛТ живой базы, на которой юзера лбами сталкиваются :-)
Впрочем, любопытная штука, спасибо.
Только и по ней непонятка есть - см иллюстр.

ЗЫ. Этот вьювер развивается или нет ? там указан 2004-й год...
...
Рейтинг: 0 / 0
27.01.2013, 13:53:21
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126185
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидНу так мы всё равно её лочим, только в режиме protected read.Ты разницу между shared и exclusive понимаешь ? А то, что кроме тебя, эту страницу могут хотеть прочитать ещё 100500 коннектов - тоже понимаешь ?

ТаблоидК тому же, предикат окажется ложным после получения protected read-блокировки только в случае, когда эта же запись подверглась модификации другой транзакциейУ тебя всегда и везде доступ только по ПК ?
Вот откуда эта категоричность ?

ТаблоидНе так уж часто сиё бываетВ конкурентной среде записи могут меняться гораздо быстрее, чем ты себе можешь представить.

ТаблоидПочему нельзя такДмитрий выше написал, что так иногда делается.

ТаблоидЧто это за "единица измерения", в где-то про неё написано ?Это не есть инф-ция для конечного пользователя. Посему - кому надо, те и так знают.

PageSpace ввели для реализации GTT. В данный момент есть PageSpace = 1, в которой учитываются страницы основной БД, и все остальные PageSpace, в которых живут данные GTT.
...
Рейтинг: 0 / 0
27.01.2013, 14:02:27
| Ответить | Цитировать | Написать  
Понимание результатов fb_lock_print
    #38126190
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrэто не мешает остальным коннектам ее читать в этот момент, в отличие отhvladТаблоидНу так мы всё равно её лочим, только в режиме protected read.Ты разницу между shared и exclusive понимаешь ? А то, что кроме тебя, эту страницу могут хотеть прочитать ещё 100500 коннектов - тоже понимаешь ?я всё это понимаю. Поэтому про exclusive и не говорил ни разу. Наоборот, заменить её хотел на PW :-)
А спрашивал про protected write , которая запрещает другим писать, но НЕ запрещает читать.
hvladУ тебя всегда и везде доступ только по ПК ?
Вот откуда эта категоричность ?Нет, конечно. Но причём тут вид доступа ?

ЗЫ. Табличка в Книге про совместимость блокировок - пущай тут тоже будет.
...
Рейтинг: 0 / 0
27.01.2013, 14:15:48
| Ответить | Цитировать | Написать  
25 сообщений из 119, страница 2 из 5
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Понимание результатов fb_lock_print
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38126168&tid=1564097]:
 0ms
get settings:
 8ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 205ms
get topic data:
 7ms
get forum data:
 2ms
get page messages:
 42ms
get tp. blocked users:
 1ms
others: 195ms
total:  478ms
созд. / загр.: 478ms
x
x
Закрыть


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