gfix -sweep localhost/port:path/dbname - делает "реконнект" при срубании через mon$attach / Firebird, InterBase

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gfix -sweep localhost/port:path/dbname - делает "реконнект" при срубании через mon$attach

5 сообщений из 5, страница 1 из 1

gfix -sweep localhost/port:path/dbname - делает "реконнект" при срубании через mon$attach

#38557818

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

Ффух... Воспроизвёл наконец-то. Заодно еще и какая-то непонятка с сообщением 'connection shutdown' при удалении аттача через курсор (where current of ...) - см ниже.

Исходная база - пустая, page_size=4096, fw = OFF.
DDL:

fil4sweep.sql

Код: 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.

recreate table t(id int primary key, s01 varchar(36) , s02 varchar(36) , s03 varchar(36) );
commit;
create index t_s01 on t(s01);
create index t_s02 on t(s02);
create index t_s03 on t(s03);
commit;
set term ^;
execute block as
begin
  begin
    execute statement 'create sequence g';
    when any do begin end
  end
end^
set term ;^
alter sequence g restart with 0;
commit;

-- 1'000'000 ==> 352 Mb
-- 5'000'000 ==> 1700Mb, ~7 min
set stat on;
set term ^;
execute block as
  declare n int = 5000000;
begin
  while (n>0) do
    insert into t(id, s01, s02, s03)
    values( :n +iif( mod(:n,1000)=0, 0*gen_id(g,1000), 0),
            uuid_to_char(gen_uuid()),
            uuid_to_char(gen_uuid()),
            uuid_to_char(gen_uuid())
          ) returning :n-1 into n;
end^
set term ;^

set echo on;

commit;
select count(*) from t;
delete from t;
commit;
set echo off;
show version;
show database;
set echo on;
shell sleep 5; -- можно оставить, сборщик всё равно почти ничего не успеет убрать :-)
exit;

Запускать скрипт строго из консоли , т.е. чтобы он по завершении НЕ остался в isql и, таким обр., не дал потоку GC собрать мусорные версии:

Код: plaintext

isql localhost/3333:тратата -i fil4sweep.sql

Отложить куда-нить получившуюся базу (её размер будет около 1.7 Гб, скрипт на моей тачке выполнялся около 7 минут).

Далее создаем подкаталог logs, а также файлик для сборка бактрасс в неинтерактивном режиме:

gdb_backtrace_batch.script

Код: plaintext

1.
2.
3.

thread apply all bt full
quit
yes

Затем создаем вспомогательный скрипт для отрубания коннекта от gfix'a (его использование - см ниже основной скрипт, gfixtest.sh):

gfixkill_eb.sql

Код: 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.

set list on;
select * from mon$database;
commit;
set term ^;
execute block returns(dts_before timestamp, deleted_attach_id int , dts_after timestamp) as
begin
  dts_before=cast('now' as timestamp);
  deleted_attach_id=-1; -- if remains to this value then no gfix attachment was found
  for
    select mon$attachment_id
    from mon$attachments
    where mon$remote_process containing 'gfix'
  into
    deleted_attach_id
  as cursor
    tcur
  do
    delete from mon$attachments where current of tcur;
  dts_after=cast('now' as timestamp);
  suspend;
end^
set term ;^
set stat off;
set echo on;
show database;
commit;
exit;

Далее обнуляем (для читабельности) firebird.log и, наконец, запускаем вот этот "основной скрипт" (в том же каталоге, что и файл gdb_backtrace_batch.script):

gfixtest.sh

Код: plaintext

clear
fbhome=/opt/fb30trnk
fbport=3333
fbname=firebird
dbname=/var/db/fb30/gfixtest30.fdb

gdb_batch_file=./gdb_backtrace_batch.script
delay=20
sign=15

i=1
killall -9 gfix 2>/dev/null
echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) sweep starting:
set -x
###################################################
$fbhome/bin/gfix -sweep localhost/$fbport:$dbname &
###################################################
set +x

fbpid=$(ps aux|grep /opt/fb30trnk/bin/firebird|grep -v grep|awk '{print $2}')
gfixpid=$(ps aux|grep $fbhome/bin/gfix|grep -v "defunct\|grep"|awk '{print $2}')
echo +++++++++++++++++++++++++++++++++++
echo alive \"gfix -sweep\" process: $gfixpid, firebird process: $fbpid
echo +++++++++++++++++++++++++++++++++++
ps $gfixpid
echo gather initial stacktrace of running gfix...
gdb -q -x $gdb_batch_file $fbhome/bin/gfix $gfixpid 1>logs/gfix_started_$(date +'%y%m%d_%H%M%S').gdb.txt 2>&1
gdb -q -x $gdb_batch_file $fbhome/bin/$fbname $fbpid 1>logs/firebird_when_gfix_started_$(date +'%y%m%d_%H%M%S').gdb.txt 2>&1
echo done:
ls -l logs/*.gdb.txt
while :
do
  gfixpid=$(ps aux|grep $fbhome/bin/gfix|grep -v "defunct\|grep"|awk '{print $2}')
  echo . . . . . . . . . . .  iter N $i . . . . . . . . . . . . . .
  echo before isql: alive gfix process: \>\>\> $gfixpid \<\<\<
  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) now wait $delay seconds before killing it...
  sleep $delay
  echo ....................................................................
  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) attempt to detach gfix process...

  set -x
  $fbhome/bin/isql localhost/$fbport:$dbname -i gfixkill_eb.sql
  set +x

  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) result of attempt $i to detach gfix: check that there is NO alive gfix pid:
  # again!
  gfixpid=$(ps aux|grep $fbhome/bin/gfix|grep -v "defunct\|grep"|awk '{print $2}')
  if [ -n "$gfixpid" ]; then
    echo after isql: alive gfix process: \>\>\> $gfixpid \<\<\<
    echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) starting gather stacktrace for gfix and firebird processes.
    gdb4gfixlog=logs/gfix_alive_$(date +'%y%m%d_%H%M%S').gdb.txt
    gdb4fblog=logs/firebird_when_gfix_alive_$(date +'%y%m%d_%H%M%S').gdb.txt
    set -x
    gdb -q -x $gdb_batch_file $fbhome/bin/gfix $gfixpid 1>$gdb4gfixlog 2>&1
    gdb -q -x $gdb_batch_file $fbhome/bin/$fbname $fbpid 1>$gdb4fblog 2>&1
    set +x
    echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) finish gathered stacktrace for gfix and firebird processes:
    ls -l $gdb4gfixlog $gdb4fblog
  else
    echo NO gfix process found. Bye!..
    exit
  fi
  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) finish iter $i
  i=$((i+1))
done

Этот скрипт:
0) грохнет все gfix'ы, если они сейчас есть;
1) затем:
1.1) запустит в фоновом режиме gfix -sweep (см. вызов с '&' в хвосте команды),
1.2) определит pid'ы процессов gfix & firebird, после чего
1.3) соберёт бактрассы с них, сложив их в файлы 'logs/gfix_started_*.txt' и 'logs/firebird_when_gfix_started_*.txt'
2) подождёт 20 сек, после чего запустит isql со скриптом gfixkill_eb.sql. Этот скрипт должен определить номер аттача от процесса 'gfix' и удалить его в mon$attachments. "На гор а " он выдаст номер этого удалённого аттача.
3) проверит после завершения п. 2), нет ли сейчас живого процесса 'gfix':

Код: plaintext

1.
2.
3.

  # again!
  gfixpid=$(ps aux|grep $fbhome/bin/gfix|grep -v "defunct\|grep"|awk '{print $2}')
  if [ -n "$gfixpid" ]; then
    . . .

4) если п. 3 вернул непустой gfixpid, то собирает снова бактрассы по процессам gfix & firebird, сложив их в файлы с именами 'logs/gfix_alive_*.txt' и 'logs/firebird_when_gfix_*.txt';
5) иначе скрипт завершается.

В итоге, вот что получилось при запуске этого скрипта:

Код: 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.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.

2014-02-11 21:40:32.8544 sweep starting:
++ set +x
++ /opt/fb30trnk/bin/gfix -sweep localhost/3333:/var/db/fb30/gfixtest30.fdb
+++++++++++++++++++++++++++++++++++
alive "gfix -sweep" process: 19202, firebird process: 19106
+++++++++++++++++++++++++++++++++++
  PID TTY      STAT   TIME COMMAND
19202 pts/3    Sl+    0:00 /opt/fb30trnk/bin/gfix -sweep localhost/3333:/var/db/fb30/gfixtest30.fdb
gather initial stacktrace of running gfix...
done:
-rw-r--r-- 1 root root 69775 Feb 11 21:40 logs/firebird_when_gfix_started_140211_214033.gdb.txt
-rw-r--r-- 1 root root 35451 Feb 11 21:40 logs/gfix_started_140211_214032.gdb.txt

 . . . . . . . . . . . iter N 1 . . . . . . . . . . . . . . 
before isql: alive gfix process: >>>  19202  <<<
2014-02-11 21:40:36.6369 now wait 20 seconds before killing it...
....................................................................
2014-02-11 21:40:56.6407 attempt to detach gfix process...
++ /opt/fb30trnk/bin/isql localhost/3333:/var/db/fb30/gfixtest30.fdb -i gfixkill_eb.sql

MON$DATABASE_NAME               /var/db/fb30/gfixtest30.fdb
MON$PAGE_SIZE                   4096
MON$ODS_MAJOR                   12
MON$ODS_MINOR                   0
MON$OLDEST_TRANSACTION          35
MON$OLDEST_ACTIVE               36
MON$OLDEST_SNAPSHOT             36
MON$NEXT_TRANSACTION            37
MON$PAGE_BUFFERS                16000
MON$SQL_DIALECT                 3
MON$SHUTDOWN_MODE               0
MON$SWEEP_INTERVAL              20000
MON$READ_ONLY                   0
MON$FORCED_WRITES               0
MON$RESERVE_SPACE               1
MON$CREATION_DATE               2014-02-11 00:17:49.9510
MON$PAGES                       435968
MON$STAT_ID                     1
MON$BACKUP_STATE                0
MON$CRYPT_PAGE                  0
MON$OWNER                       SYSDBA                                                                                  



DTS_BEFORE                      2014-02-11 21:40:57.2690
 DELETED_ATTACH_ID               17 
DTS_AFTER                       2014-02-11 21:40:57.7720


show database;
Database: localhost/3333:/var/db/fb30/gfixtest30.fdb
        Owner: SYSDBA
PAGE_SIZE 4096
Number of DB pages allocated = 435968
Sweep interval = 20000
Forced Writes are OFF
Transaction - oldest = 37
Transaction - oldest active = 38
Transaction - oldest snapshot = 38
Transaction - Next = 42
ODS = 12.0
Default Character set: NONE
commit;
exit;
++ set +x
2014-02-11 21:40:57.9066 result of attempt 1 to detach gfix: check that there is NO alive gfix pid:
 after isql: alive gfix process: >>> 19202 <<< 
2014-02-11 21:40:57.9206 starting gather stacktrace for gfix and firebird processes.
++ gdb -q -x ./gdb_backtrace_batch.script /opt/fb30trnk/bin/gfix 19202
++ gdb -q -x ./gdb_backtrace_batch.script /opt/fb30trnk/bin/firebird 19106
++ set +x
2014-02-11 21:41:03.3570 finish gathered stacktrace for gfix and firebird processes:
-rw-r--r-- 1 root root 73142 Feb 11 21:41 logs/firebird_when_gfix_alive_140211_214057.gdb.txt
-rw-r--r-- 1 root root 35978 Feb 11 21:41 logs/gfix_alive_140211_214057.gdb.txt
2014-02-11 21:41:03.3610 finish iter 1

 . . . . . . . . . . . iter N 2 . . . . . . . . . . . . . . 
before isql: alive gfix process: >>>  19202  <<<
2014-02-11 21:41:03.3751 now wait 20 seconds before killing it...
....................................................................
2014-02-11 21:41:23.3786 attempt to detach gfix process...
++ /opt/fb30trnk/bin/isql localhost/3333:/var/db/fb30/gfixtest30.fdb -i gfixkill_eb.sql

MON$DATABASE_NAME               /var/db/fb30/gfixtest30.fdb
MON$PAGE_SIZE                   4096
MON$ODS_MAJOR                   12
MON$ODS_MINOR                   0
MON$OLDEST_TRANSACTION          42
MON$OLDEST_ACTIVE               43
MON$OLDEST_SNAPSHOT             43
MON$NEXT_TRANSACTION            44
MON$PAGE_BUFFERS                16000
MON$SQL_DIALECT                 3
MON$SHUTDOWN_MODE               0
MON$SWEEP_INTERVAL              20000
MON$READ_ONLY                   0
MON$FORCED_WRITES               0
MON$RESERVE_SPACE               1
MON$CREATION_DATE               2014-02-11 00:17:49.9510
MON$PAGES                       435968
MON$STAT_ID                     1
MON$BACKUP_STATE                0
MON$CRYPT_PAGE                  0
MON$OWNER                       SYSDBA                                                                                  



DTS_BEFORE                      2014-02-11 21:41:23.4670
 DELETED_ATTACH_ID               20 
DTS_AFTER                       2014-02-11 21:41:23.6700


show database;
Database: localhost/3333:/var/db/fb30/gfixtest30.fdb
        Owner: SYSDBA
 connection shutdown   -- ?! 
PAGE_SIZE 4096
Number of DB pages allocated = 435968
Sweep interval = 20000
Forced Writes are OFF
Transaction - oldest = 44
Transaction - oldest active = 45
Transaction - oldest snapshot = 45
Transaction - Next = 48
ODS = 12.0
Default Character set: NONE
commit;
exit;
++ set +x
2014-02-11 21:41:24.5699 result of attempt 2 to detach gfix: check that there is NO alive gfix pid:
 NO gfix process found. Bye!..

И вот что появилось при его выполнении в firebird.log'e:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

oel64   Tue Feb 11 21:40:32 2014
        Sweep is started by SYSDBA
        Database "/var/db/fb30/gfixtest30.fdb"
        OIT 31, OAT 32, OST 32, Next 34


oel64   Tue Feb 11 21:40:57 2014
        Error during sweep:
        connection shutdown


oel64   Tue Feb 11 21:40:57 2014
        Sweep is started by SYSDBA
        Database "/var/db/fb30/gfixtest30.fdb"
        OIT 37, OAT 38, OST 38, Next 40


oel64   Tue Feb 11 21:41:23 2014
        Error during sweep:
        connection shutdown

При первой попытке его срубить он делает "переконнект" (меняет аттач_ид с 17 на 20 - см выше, лог .shell-скрипта)! Только вторая попытка грохнуть этот gfix становится успешной.

И это еще не всё.
Если посмотреть на лог вывода .shell-скрипта, то на ВТОРОЙ итерации ('iter N 2') видим, что вызов 'show database' внутри gfixkill_eb.sql сопровождается каким-то загадочным 'connection shutdown'. Откудова он вылез ?

В аттаче - все 4 бактрассы (две для firebird и две для gfix): первая пара - когда был только старт gfix'a, вторая - когда обнаружилось, что gfix не отрубился командой delete from mon$attachments.

...

Рейтинг:

0 / 0

11.02.2014, 21:58:26

| Ответить | Цитировать | Написать

gfix -sweep localhost/port:path/dbname - делает "реконнект" при срубании через mon$attach

#38558059

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

ТаблоидПри первой попытке его срубить он делает "переконнект" (меняет аттач_ид с 17 на 20 - см выше, лог .shell-скрипта)! Только вторая попытка грохнуть этот gfix становится успешной.Забыл вчера трейс натравить на весь этот спектакль.
Всё подтверждается.

Вот он (свип) стартует:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

2014-02-12T09:04:44.5630 (32351:0x7f6c357bd1e0) SWEEP_START
	/var/db/fb30/gfixtest30.fdb (ATT_ 17,  SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb30trnk/bin/gfix:32707

Transaction counters:
	Oldest interesting         31
	Oldest active              32
	Oldest snapshot            32
	Next transaction           34

2014-02-12T09:04:44.5630 (32351:0x7f6c357bd1e0) START_TRANSACTION
	/var/db/fb30/gfixtest30.fdb (ATT_17, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb30trnk/bin/gfix:32707
		(TRA_35, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)

2014-02-12T09:04:44.5630 (32351:0x7f6c357bd1e0) SWEEP_PROGRESS
	/var/db/fb30/gfixtest30.fdb (ATT_17, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb30trnk/bin/gfix:32707
. . .

Вот стартует (через 20 сек) isql, который будет срубать свип, и появляется служебный коннект ATT_6721, проверяющий права юзера isql:

Код: 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.

2014-02-12T09:05:08.6070 (32351:0x7f6c357bbd60) ATTACH_DATABASE
        /opt/fb30trnk/security3.fdb (ATT_6721, SYSDBA:NONE, NONE, <internal>)

2014-02-12T09:05:08.6100 (32351:0x7f6c357bbd60) START_TRANSACTION
        /opt/fb30trnk/security3.fdb (ATT_6721, SYSDBA:NONE, NONE, <internal>)
                (TRA_24816, CONCURRENCY | WAIT | READ_ONLY)

2014-02-12T09:05:08.6100 (32351:0x7f6c357bbd60) ROLLBACK_TRANSACTION
        /opt/fb30trnk/security3.fdb (ATT_6721, SYSDBA:NONE, NONE, <internal>)
                (TRA_24816, CONCURRENCY | WAIT | READ_ONLY)
      0 ms, 1 write(s), 1 fetch(es), 1 mark(s)

2014-02-12T09:05:08.6210 (32351:0x7f6c357be468) TRACE_INIT
        SESSION_1


2014-02-12T09:05:08.6210 (32351:0x7f6c357be468) ATTACH_DATABASE
        /var/db/fb30/gfixtest30.fdb (ATT_19, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:32754

2014-02-12T09:05:08.6230 (32351:0x7f6c357be468) START_TRANSACTION
        /var/db/fb30/gfixtest30.fdb (ATT_19, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:32754
                (TRA_36, CONCURRENCY | WAIT | READ_WRITE)

2014-02-12T09:05:08.9820 (32351:0x7f6c357be468) EXECUTE_STATEMENT_FINISH
        /var/db/fb30/gfixtest30.fdb (ATT_19, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30trnk/bin/isql:32754
                (TRA_36, CONCURRENCY | WAIT | READ_WRITE)

Statement 23:
-------------------------------------------------------------------------------
select * from mon$database

Вот gfix срубается isql'ем, выполняющим execute block:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.

2014-02-12T09:05:10.9450 (32351:0x7f6c357bd1e0) SWEEP_FAILED
	/var/db/fb30/gfixtest30.fdb (ATT_ 17 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb30trnk/bin/gfix:32707
  26382 ms, 1772827 read(s), 17 write(s), 14786944 fetch(es), 3581945 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$PAGES                             586                                                                      
. . .
T                                                                                                        583627

Далее gfix делает commit, выдаёт shutdown-мессагу и отсоединяется :

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

2014-02-12T09:05:10.9450 (32351:0x7f6c357bd1e0) COMMIT_TRANSACTION
	/var/db/fb30/gfixtest30.fdb (ATT_17, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb30trnk/bin/gfix:32707
		(TRA_35, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)
      0 ms

2014-02-12T09:05:10.9450 (32351:0x7f6c357bd1e0) ERROR AT JProvider::attachDatabase
	/var/db/fb30/gfixtest30.fdb (ATT_17, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb30trnk/bin/gfix:32707
335544856 : connection shutdown

2014-02-12T09:05:10.9450 (32351:0x7f6c357bd1e0)  DETACH_DATABASE 
	/var/db/fb30/gfixtest30.fdb (ATT_ 17 , SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb30trnk/bin/gfix:32707

А вот затем происходит нечто:
1) кто-то "системный" пытается пролезть в базу и получает по лбу ошибкой... "No such file or directory" (!!):

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.

2014-02-12T09:05:10.9580 (32707:0x7fe57a853db8) TRACE_INIT
	SESSION_1  
	

2014-02-12T09:05:10.9580 (32707:0x7fe57a853db8) FAILED ATTACH_DATABASE
	localhost/3333:/var/db/fb30/gfixtest30.fdb ( ATT_0 , SYSDBA, NONE,  <internal> )

2014-02-12T09:05:10.9580 (32707:0x7fe57a853db8) ERROR AT JProvider::attachDatabase
	localhost/3333:/var/db/fb30/gfixtest30.fdb (ATT_0, SYSDBA, NONE, <internal>)
335544344 : I/O error during "open" operation for file "localhost/3333:/var/db/fb30/gfixtest30.fdb"
335544734 : Error while trying to open file
        2 : No such file or directory

2014-02-12T09:05:10.9580 (32707:0x7fe57a853db8) TRACE_FINI
	SESSION_1

2) внутренний аттач #6721, проверявший права коннекта от isql, снова стартует и тут же завершает транзакцию - так, как обычно происходит при новом коннекте к базе:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.

2014-02-12T09:05:10.9620 (32351:0x7f6c357bbd60) START_TRANSACTION
	/opt/fb30trnk/security3.fdb (ATT_6721, SYSDBA:NONE, NONE, <internal>)
		(TRA_24817, CONCURRENCY | WAIT | READ_ONLY)

2014-02-12T09:05:10.9620 (32351:0x7f6c357bbd60) ROLLBACK_TRANSACTION
	/opt/fb30trnk/security3.fdb (ATT_6721, SYSDBA:NONE, NONE, <internal>)
		(TRA_24817, CONCURRENCY | WAIT | READ_ONLY)
      0 ms, 1 write(s), 1 fetch(es), 1 mark(s)

3) "из ниоткуда" появляется опять gfix, с тем же pid'ом, и устанавливает новый коннект (att_20):

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.

2014-02-12T09:05:10.9710 (32351:0x7f6c357bd1e0) TRACE_INIT
	SESSION_1  
	

2014-02-12T09:05:10.9710 (32351:0x7f6c357bd1e0) ATTACH_DATABASE
	/var/db/fb30/gfixtest30.fdb (ATT_20, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb30trnk/bin/gfix:32707

2014-02-12T09:05:10.9710 (32351:0x7f6c357bd1e0) SWEEP_START
	/var/db/fb30/gfixtest30.fdb (ATT_20, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb30trnk/bin/gfix:32707

Transaction counters:
	Oldest interesting         36
	Oldest active              37
	Oldest snapshot            37
	Next transaction           38

2014-02-12T09:05:10.9710 (32351:0x7f6c357bd1e0) START_TRANSACTION
	/var/db/fb30/gfixtest30.fdb (ATT_20, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb30trnk/bin/gfix:32707
		(TRA_39, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)

В общем, хотелось бы комментов по всему этому: откудова там лезет "no such file", отчего "реконнект" от gfix'a выперся...
Полный текст спектакля см в аттаче (трейс и вывод .sh-скрипта).

...

Рейтинг:

0 / 0

12.02.2014, 09:35:28

| Ответить | Цитировать | Написать

gfix -sweep localhost/port:path/dbname - делает "реконнект" при срубании через mon$attach

#38558244

hvlad

Участник

Сообщения: 13 125

Рейтинг: 0 / 0

Таблоид,

на 2.5 пробовал ?

...

Рейтинг:

0 / 0

12.02.2014, 11:56:41

| Ответить | Цитировать | Написать

gfix -sweep localhost/port:path/dbname - делает "реконнект" при срубании через mon$attach

#38558395

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

hvlad,

на LI-V2.5.3.26737 такого нету: отрубание gfix'a через mon$ идёт корректно

.sh output

Код: plaintext

$ ./gfixtest.sh
check settings:
fbhome=/opt/fb25, fbport=3253, fbname=fbserver
dbname=/var/db/fb30/gfixtest25.fdb

check changed parameters in firebird.conf:
------------------------------------------
BugcheckAbort = 1
ExternalFileAccess = Restrict /var/db/fb30
FileSystemCacheThreshold = 1000000
RemoteServicePort = 3253
TempBlockSize = 67108864
TempCacheLimit = 1073741824
TempDirectories = /dev/shm;/tmp
------------------------------------------
2014-02-12 13:13:42.7151 sweep starting:
++ set +x
++ /opt/fb25/bin/gfix -sweep localhost/3253:/var/db/fb30/gfixtest25.fdb
+++++++++++++++++++++++++++++++++++
alive "gfix -sweep" process: 5253, firebird process: 32351
+++++++++++++++++++++++++++++++++++
  PID TTY      STAT   TIME COMMAND
 5253 pts/5    Sl+    0:00 /opt/fb25/bin/gfix -sweep localhost/3253:/var/db/fb30/gfixtest25.fdb
gather initial stacktrace of running gfix...
done:
-rw-r--r-- 1 root root  2943 Feb 12 13:13 logs/firebird_when_gfix_started_140212_131343.gdb.txt
-rw-r--r-- 1 root root 21037 Feb 12 13:13 logs/gfix_started_140212_131342.gdb.txt

. . . . . . . . . . . iter N 1 . . . . . . . . . . . . . .
before isql: alive gfix process: >>> 5253 <<<
2014-02-12 13:13:44.0749 now wait 15 seconds before killing it...
....................................................................
2014-02-12 13:13:59.0784 attempt to detach gfix process...
++ /opt/fb25/bin/isql localhost/3253:/var/db/fb30/gfixtest25.fdb -n -i gfixkill_eb.sql

MON$DATABASE_NAME               /var/db/fb30/gfixtest25.fdb
MON$PAGE_SIZE                   4096
MON$ODS_MAJOR                   11
MON$ODS_MINOR                   2
MON$OLDEST_TRANSACTION          60
MON$OLDEST_ACTIVE               61
MON$OLDEST_SNAPSHOT             61
MON$NEXT_TRANSACTION            61
MON$PAGE_BUFFERS                2048
MON$SQL_DIALECT                 3
MON$SHUTDOWN_MODE               0
MON$SWEEP_INTERVAL              20000
MON$READ_ONLY                   0
MON$FORCED_WRITES               0
MON$RESERVE_SPACE               1
MON$CREATION_DATE               2014-02-11 17:49:52.1020
MON$PAGES                       417664
MON$STAT_ID                     1
MON$BACKUP_STATE                0



DTS_BEFORE                      2014-02-12 13:13:59.0970
DELETED_ATTACH_ID               7
DTS_AFTER                       2014-02-12 13:13:59.0970


show database;
Database: localhost/3253:/var/db/fb30/gfixtest25.fdb
        Owner: SYSDBA
connection shutdown
PAGE_SIZE 4096
Number of DB pages allocated = 417664
Sweep interval = 20000
Forced Writes are OFF
Transaction - oldest = 61
Transaction - oldest active = 62
Transaction - oldest snapshot = 62
Transaction - Next = 64
ODS = 11.2
Default Character set: NONE
commit;
exit;
++ set +x
2014-02-12 13:13:59.1070 result of attempt 1 to detach gfix: check that there is NO alive gfix pid:
NO gfix process found. Bye!..

firebird.log:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.

oel64 (Server)  Wed Feb 12 13:13:42 2014
        Sweep is started by SYSDBA
        Database "/var/db/fb30/gfixtest25.fdb"
        OIT 57, OAT 58, OST 58, Next 59


oel64 (Server)  Wed Feb 12 13:13:59 2014
        Error during sweep:
        connection shutdown

Фрагмент трейса для коннекта от gfix, когда его отрубают через mon$attach:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

2014-02-12T13:13:59.0990 (4961:0x7fe2e0cfca90) SWEEP_FAILED
	/var/db/fb30/gfixtest25.fdb (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb25/bin/gfix:5253
  16369 ms, 1965428 read(s), 288182 write(s), 7861326 fetch(es), 1884786 mark(s)

2014-02-12T13:13:59.0990 (4961:0x7fe2e0cfca90) COMMIT_TRANSACTION
	/var/db/fb30/gfixtest25.fdb (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb25/bin/gfix:5253
		(TRA_60, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)
      0 ms

2014-02-12T13:13:59.0990 (4961:0x7fe2e0cfca90) ERROR AT jrd8_attach_database
	/var/db/fb30/gfixtest25.fdb (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb25/bin/gfix:5253
335544856 : connection shutdown

2014-02-12T13:13:59.0990 (4961:0x7fe2e0cfca90) DETACH_DATABASE
	/var/db/fb30/gfixtest25.fdb (ATT_7, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
	/opt/fb25/bin/gfix:5253

- не содержит далее никаких "переконнектов". Полный трейс и бактрассы (кто знает, вдруг тоже нужны) - в аттаче.

...

Рейтинг:

0 / 0

12.02.2014, 13:23:06

| Ответить | Цитировать | Написать

gfix -sweep localhost/port:path/dbname - делает "реконнект" при срубании через mon$attach

#38560319

Таблоид

Участник

Сообщения: 9 702

Рейтинг: 0 / 0

В общем, http://tracker.firebirdsql.org/browse/CORE-4337
А то забудется ещё, кто его знает...

...

Рейтинг:

0 / 0

13.02.2014, 19:27:38

| Ответить | Цитировать | Написать

5 сообщений из 5, страница 1 из 1

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=40&fpage=103&tid=1563891]:	0ms
get settings:	8ms
get forum list:	10ms
check forum access:	2ms
check topic access:	2ms
track hit:	284ms
get topic data:	6ms
get forum data:	2ms
get page messages:	24ms
get tp. blocked users:	1ms
others:	202ms

total:	541ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы