hi all
Что-то не догоняю я, видимо... фундаментальное что-то... :(
0) ставим bugcheckabort =1, рестартуем ФБ
1) создаем базу:
C:\>isql -q
SQL> create database '192.168.0.220/3333:/var/db/fb30/tmp201405132122.fdb'; commit; exit;
2) делаем теперь два коннекта к ней:
1.
2.
3.
4.
5.
6.
7.
session #1
C:\>isql 192.168.0.220/3333:/var/db/fb30/tmp201405132122.fdb
Database: 192.168.0.220/3333:/var/db/fb30/tmp201405132122.fdb
session #2
C:\>isql 192.168.0.220/3333:/var/db/fb30/tmp201405132122.fdb
Database: 192.168.0.220/3333:/var/db/fb30/tmp201405132122.fdb
3) запускаем снимок лок-таблицы:
/opt/fb30trnk/bin/fb_lock_print -a -c -d /var/db/fb30/tmp201405132122.fdb >fblptmp01.txt
4) во любой сессии (я выбрал 2-ю) вводим на выполнение вот этот скриптик:
1.
2.
3.
4.
5.
6.
7.
-- file = 'fbcrash.sql'
set echo on;
recreate table t(id int primary key, x int, y int);
commit;
create index t_yx on t computed by( iif( ( select sum(y) from t tx where tx.x = t.x ) < 1000, id, -1 ) );
commit;
insert into t values( 1, 100, 300);
При этом получим в окне session #2:
1.
2.
Statement failed, SQLSTATE = 08006
Error reading data from the connection.
After line 5 in file fbcrash.sql
(ждать придется около 5...10 секунд: пока coredump не создастся - никакого сообщения не будет).
Повторяем теперь снятие лок-таблицы, несколько раз, интервал - любой.
Смотрим в её заголовок и видим:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
LOCK_HEADER BLOCK
Version: 146, Creation timestamp: 2014-05-13 21:22:46
Active owner: 0, Length: 1048576, Used: 95184
Enqs: 170, Converts: 13, Rejects: 40, Blocks: 0
Deadlock scans: 0, Deadlocks: 0, Scan interval: 10
Acquires: 254, Acquire blocks: 0, Spin count: 0
Mutex wait: 0.0%
Hash slots: 8191, Hash lengths (min/avg/max): 0/ 0/ 6
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (5): forward: 78376, backward: 81208
Free owners: *empty*
Free locks (9): forward: 80408, backward: 92320
Free requests (9): forward: 93744, backward: 94016
Хотя:
0) ФБ выполнил стопудово рестарт
firebird.log
1.
2.
3.
4.
5.
6.
7.
8.
oel64 Tue May 13 21:24:09 2014
Database: /var/db/fb30/tmp201405132122.fdb
unsuccessful metadata update
request depth exceeded. (Recursive definition?)
internal Firebird consistency check (error during savepoint backout (290), file: exe.cpp line: 1619)
oel64 Tue May 13 21:24:16 2014
/opt/fb30trnk/bin/fbguard: /opt/fb30trnk/bin/firebird terminated abnormally (-1)
- и я должен был бы получать в ответ на fb_lock_print швабру:
1.
2.
Unable to access lock table.
shmem_data->sh_mem_length_mapped is 0
1) потоков внутри процесса ФБ - как положено при отсутствии работы, три:
1.
2.
3.
4.
$ ps -FLC -p 32453
UID PID PPID LWP C NLWP SZ RSS PSR STIME TTY STAT TIME CMD
firebird 32453 32382 32453 0 3 52438 3144 9 21:24 ? Sl 0:00 /opt/fb30trnk/bin/firebird
firebird 32453 32382 32454 0 3 52438 3144 10 21:24 ? Sl 0:00 /opt/fb30trnk/bin/firebird
firebird 32453 32382 32455 0 3 52438 3144 0 21:24 ? Sl 0:00 /opt/fb30trnk/bin/firebird
2) ФБ действительно не держит сейчас никаких открытых файлов:
1.
2.
[root@oel64 21:35:56 fb30]$ ls -l /proc/32453/fd
total 0
lrwx------ 1 firebird firebird 64 May 13 21:24 0 -> socket:[5210199]
1) Что тогда есть в лок-таблице вот это:
1.
2.
Owners (5): forward: 78376, backward: 81208
Free owners: *empty*
- ?
2) Почему я НЕ получил сообщение вида
1.
2.
3.
Unable to access lock table.
shmem_data->sh_mem_length_mapped is 0
- ?
