ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
25 сообщений из 31, страница 1 из 2
  1  все
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38403893
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
По материалам этого топега, выношу в отдельную тему.
Извиняюсь, что делаю копипаст большого поста, но так лучше будет понять, о чём шла речь.

dimitrпопрошу на кошках вменяемого размера пример, твой миллиард никто в здравом уме заливать не будетну так там не миллиард апдейтов было, а гораздо меньше. Просто ему тяжко было обновлять два индекса, КМК, вот он и застрял с откатами на такое время.

Кому интересно - залейте у себя 200-300 млн записей в такую же таблицу:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
SQL> show table t;
ID                              INTEGER Nullable
S01                             VARCHAR(8) Nullable
S02                             VARCHAR(8) Nullable
SQL> show index;
T_ID INDEX ON T(ID)
T_S01 INDEX ON T(S01)
T_S02 INDEX ON T(S02)
- это не 80 Гб будет, а всего лишь 20. Время заливки будет 1-2 часа, вряд ли больше.

Затем делаем следующее (с предварительно запущенным трейсом):

session #1
isql 192.168.99.44/3330:t10e9 -n | mtee /t isql_log.txt
12:34:43.311 Database: 192.168.99.44/3330:t10e9
12:34:43.311 SQL> set plan on; set stat on; update t set s01=s02, s02=s01;

12:36:12.592 PLAN (T NATURAL)

session #2
запускаем shell-скрипт, который в цикле будет запрашивать мон-таблицы, с интервалом 10 сек. Запрос этот приведен выше в этом топеге, впрочем - вот, еще раз:
 
askmon.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.
47.
48.
49.
set autoddl off;
set list off;
set blob on;
set width mon_user 20;
set width remote_process 30;
set width sql_txt 50;
set width remote_ip 15;
set width rn 3;
commit;
    select
      current_time dts
      -- mon$attachments:
      ,cast(row_number()over(order by mon$attachment_id) as char(3)) rn
      ,a.mon$remote_address remote_IP
      ,a.mon$attachment_id attach_id
      ,a.mon$user mon_user
      ,a.mon$stat_id       stat_id
      ,a.mon$server_pid    server_PID
      ,a.mon$remote_pid    remote_PID
      -- mon$memory_usage:
      ,u.mon$memory_used used_memory
      ,u.mon$memory_allocated alloc_by_OS
      -- mon$io_stats:
      ,i.mon$page_reads reads
      ,i.mon$page_writes writes
      ,i.mon$page_fetches fetches
      ,i.mon$page_marks marks
      -- mon$record_stats:
      ,r.mon$record_seq_reads seq_reads
      ,r.mon$record_idx_reads idx_reads
      ,r.mon$record_inserts ins_cnt
      ,r.mon$record_updates upd_cnt
      ,r.mon$record_deletes del_cnt
      ,r.mon$record_backouts bk_outs
      ,r.mon$record_purges purges
      ,r.mon$record_expunges expunges
      -- aux info:
      ,right(a.mon$remote_process,30) remote_process
      -- mon$statements:
      --,left(cast(s.mon$sql_text as varchar(32760)),50) sql_txt
    from mon$attachments a
    --left join mon$statements s on a.mon$attachment_id = s.mon$attachment_id
    left join mon$memory_usage u on a.mon$stat_id=u.mon$stat_id
    left join mon$io_stats i on a.mon$stat_id=i.mon$stat_id
    left join mon$record_stats r on a.mon$stat_id=r.mon$stat_id
    where
    --a.mon$state=1 and
    a.mon$attachment_id<>current_connection
    --order by a.mon$attachment_id
;
 
askmon.sh
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
# askmon.sh
delay=10

fdb=t10e9
#/var/db/fb30/t3e8.fdb
fbport=3330
fbhome=/opt/fb30/bin
log=./logs/mon30_$(date +'%Y%m%d_%H%M%S').log
rm -f $log
while :
do
  echo -----------------------------------------------------------------------------------
  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) - starting quering mon tables
  $fbhome/isql localhost/$fbport:$fdb -user sysdba -pas masterke -pag 999 -n -m -i askmon30.sql | sed -e "s/ \{1,\}$//" >>$log
  # -o askmon.log
  # cat askmon.tmp | sed -e "s/ \{1,\}$//" >>askmon.log
  ls -la $log
  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) - done. Now take some sleep. . .
  #ls -la /tmp/core.*
  sleep $delay
done



Дальше даём поработать минут 10, больше не нужно.

session #3
шатдауним базу, с логированием моментов времени:
 
db_shutdown.sh
Код: plaintext
1.
2.
3.
4.
dbname=localhost/3330:t10e9
echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) starting shutdown. . .
gfix -shut full -force 0 $dbname -user sysdba -pas masterke
echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) finish shutdown.
gstat -h $dbname -user sysdba -pas masterke | grep -i attributes
Код: plaintext
1.
2.
2013-09-22 12:43:23.4028 starting shutdown. . .
2013-09-22  12:43:32 .0325 finish shutdown.
        Attributes              full shutdown
Итак, управление в ось из gfix -shut вернулось через 32-23 = 9 секунд.

А теперь смотрим в isql-окно. У мну в нём показано вот это:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Statement failed, SQLSTATE = HY000
database t10e9 shutdown
 12:48:56 .889 Current memory = 1154286256236196432
12:48:56.889 Delta memory = 1154286255133019200
12:48:56.889 Max memory = 19364495713684464
12:48:56.889 Elapsed time= 764.32 sec
12:48:56.889 Buffers = 4510032
12:48:56.889 Reads = 1154047425988526046
12:48:56.889 Writes -4216675458143171601
12:48:56.889 Fetches = 50392920015175064
12:48:56.889 SQL>
А еще смотрим в лог скрипта, запрашивавшего мон-таблицы, и обращаем внимание на моменты времени, когда он запускал isql и возвращался из него. Но только на те моменты, которые уже после шатдауна ( 12:43:32 ) были:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
2013-09-22 12:43:32.9232 - starting quering mon tables
-rw-r--r--. 1 root root 52164 Sep 22 12:43 ./logs/mon30_20130922_123440.log
2013-09-22 12:43:59.0390 - done. Now take some sleep. . .
-----------------------------------------------------------------------------------
2013-09-22 12:44:09.0683 - starting quering mon tables
-rw-r--r--. 1 root root 52416 Sep 22 12:44 ./logs/mon30_20130922_123440.log
2013-09-22 12:44:34.4666 - done. Now take some sleep. . .
-----------------------------------------------------------------------------------
2013-09-22 12:44:44.4707 - starting quering mon tables
-rw-r--r--. 1 root root 52668 Sep 22 12:45 ./logs/mon30_20130922_123440.log
2013-09-22 12:45:02.5571 - done. Now take some sleep. . .
-----------------------------------------------------------------------------------
2013-09-22 12:45:12.5611 - starting quering mon tables
-rw-r--r--. 1 root root 52920 Sep 22 12:45 ./logs/mon30_20130922_123440.log
2013-09-22 12:45:30.5999 - done. Now take some sleep. . .
-----------------------------------------------------------------------------------
2013-09-22 12:45:40.6045 - starting quering mon tables
-rw-r--r--. 1 root root 53172 Sep 22 12:46 ./logs/mon30_20130922_123440.log
2013-09-22 12:46:09.7788 - done. Now take some sleep. . .
(т.е. видим, что облом на тему 'database shutdown' isql получает почему-то не сразу, а через 15-20 секунд, а то и больше).

Ну, и наконец - данные трейса.
Вот старт DMl-стейтмента:
 
12:33:12
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
2013-09-22T 12:33:12 .1680 (29443:0x7f2e1f68ffb0) EXECUTE_STATEMENT_START
	t10e9 (ATT_550, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:12616
		(TRA_1044, CONCURRENCY | WAIT | READ_WRITE)

Statement 21:
-------------------------------------------------------------------------------
update t set s01=s02, s02=s01
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)
(время отличается от isql'ного потому, что isql был запущен с виндовой машины, а она с этим сервером не синхронизирована)

Вот я gfix'ом сказал базе "спать!":
 
12:43:25
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
2013-09-22T12:43:25.2050 (29443:0x7f2e1f691fe0) TRACE_INIT
	SESSION_8  
	

2013-09-22T12:43:25.2050 (29443:0x7f2e1f691fe0) FAILED ATTACH_DATABASE
	t10e9 (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
	/opt/fb30/bin/gfix:12685

2013-09-22T12:43:25.2050 (29443:0x7f2e1f691fe0) ERROR AT JProvider::attachDatabase
	t10e9 (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
	/opt/fb30/bin/gfix:12685
335544528 : database t10e9 shutdown

2013-09-22T12:43:25.2050 (29443:0x7f2e1f691fe0) TRACE_FINI
	SESSION_8

А вот завершение DML-откатов:
 
12:45:56
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
2013-09-22T12:45:56.4850 (29443:0x7f2e1f68ffb0) FAILED EXECUTE_STATEMENT_FINISH
	t10e9 (ATT_550, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:12616
		(TRA_1044, CONCURRENCY | WAIT | READ_WRITE)

Statement 21:
-------------------------------------------------------------------------------
update t set s01=s02, s02=s01
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)
0 records fetched
 764316 ms, 449133 read(s), 5051 write(s), 4766218 fetch(es), 1046385 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$INDICES                                       6                                                            
T                                  115812              115811                        115811


ИТОГО: gfix -shut вернул управление, но движок после этого еще 2.5 минуты продолжал запись откатов.

И еще раз повторю. Для воспроизведения сего не надо иметь таблицу в 1 млрд записей. Сделайте 200-300 млн, навесьте 2-3 индекса и запустите апдейт, включающий эти индексные поля. Дайте ему промолотить 10 минут.

ЗЫ. Делал на LI-T3.0.0.30661
...
Рейтинг: 0 / 0
22.09.2013, 14:35:35
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38403952
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitr, http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=982489&msg=14868979 проверь (на FW = ON), оно может тебя удивить...Нет, никакого удивления. Всё то же самое.
Дал промолотить ~10 минут, затем ткнул в шатдаун-скрипт, получил сразу же :
Код: plaintext
1.
2.
2013-09-22  14:48:36 .3060 starting shutdown. . .
2013-09-22  [b]14:48 :37[/b].2729 finish shutdown.
        Attributes               force write , full shutdown

- а в DML-сеансе была всё та же тишина:
Код: plaintext
1.
2.
3.
4.
C:\1Install\fb30>isql 192.168.99.44/3330:t10e9 -n | mtee /t isql_log2.txt
14:38:18.264 Database:  192.168.99.44/3330:t10e9
14:38:18.264 SQL> set plan on; set stat on; update t set s01=s02, s02=s01;

14:38:24.874 PLAN (T NATURAL)

И только через 20 с лишним минут после шатдауна в окне isql'я вылезло:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
Statement failed, SQLSTATE = HY000
database t10e9 shutdown
 15:13 :51.514 Current memory = 1154286256236196432
15:13:51.514 Delta memory = 1154286255132992032
15:13:51.514 Max memory = 19364495713684464
15:13:51.514 Elapsed time= 2126.70 sec
15:13:51.514 Buffers = 4510032
15:13:51.514 Reads = 1154047425988526043
15:13:51.514 Writes -3207869833101915157
15:13:51.514 Fetches = 50392920015172348

Trace: шатдаун в 14:48, отвал стейтмента - в 15:10.
 
Код: 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.
2013-09-22T14:35:24.6860 (29443:0x7f2e1f68ffb0) EXECUTE_STATEMENT_START
	t10e9 (ATT_600, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:13452
		(TRA_1106, CONCURRENCY | WAIT | READ_WRITE)

Statement 36:
-------------------------------------------------------------------------------
update t set s01=s02, s02=s01

<...>

2013-09-22T 14:48 :36.9950 (29443:0x7f2e1f68ef98) ERROR AT JProvider::attachDatabase
	t10e9 (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
	/opt/fb30/bin/gfix:13584
335544528 : database t10e9 shutdown

<...>

2013-09-22T 15:10 :51.3830 (29443:0x7f2e1f68ffb0) FAILED EXECUTE_STATEMENT_FINISH
	t10e9 (ATT_600, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:13452
		(TRA_1106, CONCURRENCY | WAIT | READ_WRITE)

Statement 36:
-------------------------------------------------------------------------------
update t set s01=s02, s02=s01
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)
0 records fetched
2126696 ms, 395545 read(s), 164662 write(s), 4194918 fetch(es), 919917 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
RDB$INDICES                                       6                                                            
T                                  101954              101954                        101954                    

2013-09-22T15:10:51.3830 (29443:0x7f2e1f68ffb0) ERROR AT JStatement::execute
	t10e9 (ATT_600, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:13452
335544528 : database t10e9 shutdown

ЗЫ. Теорема доказана ?
...
Рейтинг: 0 / 0
22.09.2013, 15:35:41
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38403954
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
спасибо, буду разбираться. Отпишусь потом в этой теме.
...
Рейтинг: 0 / 0
22.09.2013, 15:37:17
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38403992
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

если не сложно, проверь еще на SC или CS. Пока мне видится, что это проблема исключительно суперсервера.
...
Рейтинг: 0 / 0
22.09.2013, 16:31:59
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38403996
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
OK, отпишусь тогда сюда.
Только какой кеш коннекта выставить ?
...
Рейтинг: 0 / 0
22.09.2013, 16:35:39
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38404013
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrпроверь еще на SC или CS. Пока мне видится, что это проблема исключительно суперсервера.SC - синхронный. Вижу уже, что gfix -shut "не отдаёт" управление оси, пока отмотка назад не завершится. Статистики нет пока, там DML молотил почти 15 минут при FW = ON. Но и так вижу, что всё по-другому.
...
Рейтинг: 0 / 0
22.09.2013, 17:09:23
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38404015
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
очень хорошо, спасибо
...
Рейтинг: 0 / 0
22.09.2013, 17:16:25
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38404021
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
ТаблоидСтатистики нет пока...но теперь она есть.
Код: plaintext
1.
2.
2013-09-22  16:56:57 .2624 starting shutdown. . .
2013-09-22  17:19:40. 7068 finish shutdown.
        Attributes              force write, full shutdown

Trace:
1) старт DML, 16:40:16
2) облом DML, 17: 19:27 , и только после него -
3) шатдаун базы, 17: 19:40
 
Код: 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.
2013-09-22T16:40:16.8670 (14506:0x7f6fbfedb058) EXECUTE_STATEMENT_START
	t10e9 (ATT_626, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:4580
		(TRA_1154, CONCURRENCY | WAIT | READ_WRITE)

Statement 25:
-------------------------------------------------------------------------------
update t set s01=s02, s02=s01

<...>

2013-09-22T17:19:27.1120 (14506:0x7f6fbfedb058) FAILED EXECUTE_STATEMENT_FINISH
	t10e9 (ATT_626, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:4580
		(TRA_1154, CONCURRENCY | WAIT | READ_WRITE)

Statement 25:
-------------------------------------------------------------------------------
update t set s01=s02, s02=s01
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (T NATURAL)
0 records fetched
2350244 ms, 581887 read(s), 368434 write(s), 3811990 fetch(es), 835845 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                   92637               92636                         92636                    

2013-09-22T17:19:27.1120 (14506:0x7f6fbfedb058) ERROR AT JStatement::execute
	t10e9 (ATT_626, SYSDBA:NONE, NONE, TCPv4:192.168.0.201)
	C:\1Install\fb30\isql.exe:4580
335544528 : database t10e9 shutdown

<...>
2013-09-22T17:19:40.6250 (14506:0x7f6fbfedb058) TRACE_INIT
	SESSION_1  
	

2013-09-22T17:19:40.6250 (14506:0x7f6fbfedb058) FAILED ATTACH_DATABASE
	t10e9 (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
	/opt/fb30/bin/gfix:14990

2013-09-22T17:19:40.6250 (14506:0x7f6fbfedb058) ERROR AT JProvider::attachDatabase
	t10e9 (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
	/opt/fb30/bin/gfix:14990
335544528 : database t10e9 shutdown

2013-09-22T17:19:40.6250 (14506:0x7f6fbfedb058) TRACE_FINI
	SESSION_1  
	

2013-09-22T17:19:40.6330 (14506:0x7f6fbfedb058) TRACE_INIT
	SESSION_1  
	

2013-09-22T17:19:40.6330 (14506:0x7f6fbfedb058) FAILED ATTACH_DATABASE
	t10e9 (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
	/opt/fb30/bin/isql:15088

2013-09-22T17:19:40.6330 (14506:0x7f6fbfedb058) ERROR AT JProvider::attachDatabase
	t10e9 (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
	/opt/fb30/bin/isql:15088
335544528 : database t10e9 shutdown

2013-09-22T17:19:40.6330 (14506:0x7f6fbfedb058) TRACE_FINI
	SESSION_1
В общем, на SC - всё пучком.
...
Рейтинг: 0 / 0
22.09.2013, 17:32:12
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38404034
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Только вот что вижу на SC: запрос к мониторным (а может, и ко всем остальным) таблицам остается БЕЗ всякого отклика, как только база получила команду "ложись!" и движок выполняет отмотку назад DML-изменений. Сообщение, что база в шатдауне, появляется только в момент окончательного завершения отмотки, до этого - просто ничего не выводится (в последнем примере - все 20 минут):
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
2013-09-22 16:52:40.3253 - starting quering mon tables
-rw-r--r--. 1 root root 31656 Sep 22 16:56 ./logs/mon30_20130922_164031.log
2013-09-22 16:56:58.6297 - done. Now take some sleep. . .
-----------------------------------------------------------------------------------
2013-09-22  16:57 :08.6335 - starting quering mon tables
-rw-r--r--. 1 root root 31908 Sep 22 17:19 ./logs/mon30_20130922_164031.log
// вот здесь не было никакого отклика около 20 минут:
2013-09-22  17:19 :29.0201 - done. Now take some sleep. . .
-----------------------------------------------------------------------------------
2013-09-22 17:19:39.0261 - starting quering mon tables
-rw-r--r--. 1 root root 32160 Sep 22 17:19 ./logs/mon30_20130922_164031.log
2013-09-22 17:19:40.7171 - done. Now take some sleep. . .
...
Рейтинг: 0 / 0
22.09.2013, 17:49:04
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38464276
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
"Продолжаем разговор" (С)
Тут письмо счастья пришло: "Resolved: ( CORE-4236 )"

2 dimitr: я правильно понимаю, что теперь шатдаун на SS должен быть таким же синхронным, как и на SC ?
...
Рейтинг: 0 / 0
13.11.2013, 23:56:55
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38464319
miwaonline
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miwaonline
Участник
Таблоид"Продолжаем разговор" (С)
Тут письмо счастья пришло: "Resolved: ( CORE-4236 )"

2 dimitr: я правильно понимаю, что теперь шатдаун на SS должен быть таким же синхронным, как и на SC ?
Я, конечно, не ДЕ, но в трекере вроде написано, что

However, this does not work as expected in SuperServer, reporting a successful shutdown while other connections may be still modifying the database file. This situation is possible under high load.

Так что разработчики от тебя перестраховались
...
Рейтинг: 0 / 0
14.11.2013, 00:41:58
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38464425
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
miwaonlineв трекере вроде написано, что <...>я именно эту фразу ("this does not work as expected") и прочитал как "вначале было плохо, но теперь стало хорошо" (тикет ведь стал 'Resolved'). Но сомнения остались: а может, "under high load" всё равно трабл останется ?..
...
Рейтинг: 0 / 0
14.11.2013, 08:06:17
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38464432
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидя правильно понимаю, что теперь шатдаун на SS должен быть таким же синхронным, как и на SC ?
по крайней мере, я на это надеюсь :-)
...
Рейтинг: 0 / 0
14.11.2013, 08:21:53
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38465481
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrТаблоидя правильно понимаю, что теперь шатдаун на SS должен быть таким же синхронным, как и на SC ?по крайней мере, я на это надеюсь :-)Проверил на примере отсюда , а также на базе idx_under_load при молотьбе 350 коннектами - вроде бы всё пучком.
При работе в арх-ре SuperServer шатдаун базы стал действительно синхронным. Возврата в ось нет до тех пор, пока не прекратятся все "отмотки взад" сделанных коннектами изменений.

Код: 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.
 окно-1: 
Thu Nov 14 17:48:59 2013: Database:  localhost/3330:t10e9
Thu Nov 14 17:49:16 2013: SQL> set plan on; set stat on; update t set s01=s02, s02=s01; -- обновление индексных полей
Thu Nov 14 17:49:16 2013: PLAN (T NATURAL)

 окно-2: 
$ supertee -n -t db_shutdown_$(date +'%Y%m%d_%H%M%S').log ./db_shutdown.sh t10e9
2013-11-14  17:58:44 .7088 starting shutdown. . .

 окно-1: 
Thu Nov 14 18:00:30 2013: Statement failed, SQLSTATE = HY000
Thu Nov 14 18:00:30 2013: database t10e9 shutdown
Thu Nov 14 18:00:30 2013: Current memory = 140661851183776
Thu Nov 14 18:00:30 2013: Delta memory = 140661780938432
Thu Nov 14 18:00:30 2013: Max memory = 0
Thu Nov 14 18:00:30 2013: Elapsed time= 673.48 sec
Thu Nov 14 18:00:30 2013: Cpu = 0.00 sec
Thu Nov 14 18:00:30 2013: Buffers = 0
Thu Nov 14 18:00:30 2013: Reads = -33
Thu Nov 14 18:00:30 2013: Writes = -1
Thu Nov 14  18:00:30  2013: Fetches = 140661851181088

 окно-2: 
2013-11-14  18:00:42 .4900 finish shutdown.
        Attributes              full shutdown
Иппон.

PS. LI-T3.0.0.30728

PPS. В трейсе "реверс" изменений, происходящих в связи со срубанием при шатдауне выполняющегося стейтмента, не виден. Я забыл: это так и должно быть ?
 
trace when gfix -shut full issued
Код: 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.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
214.
215.
216.
217.
218.
219.
220.
221.
Trace session ID 3 started
2013-11-14T17:58:51.6200 (22790:0x7fabe1a819d8) TRACE_INIT
        SESSION_3


2013-11-14T17:58:51.6200 (22790:0x7fabe1a819d8) ATTACH_DATABASE
        /opt/fb30/security3.fdb (ATT_24929, SYSDBA:NONE, NONE, <internal>)

2013-11-14T17:58:52.7140 (22790:0x7fabe1a819d8) START_TRANSACTION
        /opt/fb30/security3.fdb (ATT_24929, SYSDBA:NONE, NONE, <internal>)
                (TRA_41842, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)

2013-11-14T17:58:52.7170 (22790:0x7fabe1a819d8) PREPARE_STATEMENT
        /opt/fb30/security3.fdb (ATT_24929, SYSDBA:NONE, NONE, <internal>)
                (TRA_41842, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)

Statement 21:
-------------------------------------------------------------------------------
SELECT PLG$VERIFIER, PLG$SALT FROM PLG$SRP WHERE PLG$USER_NAME = ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (PLG$SRP INDEX (RDB$PRIMARY2))
      2 ms

2013-11-14T17:58:52.7170 (22790:0x7fabe1a819d8) EXECUTE_STATEMENT_START
        /opt/fb30/security3.fdb (ATT_24929, SYSDBA:NONE, NONE, <internal>)
                (TRA_41842, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)

Statement 21:
-------------------------------------------------------------------------------
SELECT PLG$VERIFIER, PLG$SALT FROM PLG$SRP WHERE PLG$USER_NAME = ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (PLG$SRP INDEX (RDB$PRIMARY2))

param0 = varchar(93), "SYSDBA                                                                       ..."


2013-11-14T17:58:52.7170 (22790:0x7fabe1a819d8) EXECUTE_STATEMENT_FINISH
        /opt/fb30/security3.fdb (ATT_24929, SYSDBA:NONE, NONE, <internal>)
                (TRA_41842, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)

Statement 21:
-------------------------------------------------------------------------------
SELECT PLG$VERIFIER, PLG$SALT FROM PLG$SRP WHERE PLG$USER_NAME = ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (PLG$SRP INDEX (RDB$PRIMARY2))

param0 = varchar(93), "SYSDBA                                                                       ..."

0 records fetched
      0 ms, 1 read(s), 4 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
PLG$SRP                                           1

2013-11-14T17:58:52.7170 (22790:0x7fabe1a819d8) FREE_STATEMENT
        /opt/fb30/security3.fdb (ATT_24929, SYSDBA:NONE, NONE, <internal>)

Statement 21:
-------------------------------------------------------------------------------
SELECT PLG$VERIFIER, PLG$SALT FROM PLG$SRP WHERE PLG$USER_NAME = ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (PLG$SRP INDEX (RDB$PRIMARY2))

2013-11-14T17:58:52.7170 (22790:0x7fabe1a819d8) ROLLBACK_TRANSACTION
        /opt/fb30/security3.fdb (ATT_24929, SYSDBA:NONE, NONE, <internal>)
                (TRA_41842, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)
      0 ms

2013-11-14T17:58:52.7170 (22790:0x7fabe1a819d8) DETACH_DATABASE
        /opt/fb30/security3.fdb (ATT_24929, SYSDBA:NONE, NONE, <internal>)

2013-11-14T17:58:52.7170 (22790:0x7fabe1a819d8) TRACE_FINI
        SESSION_3


2013-11-14T18:00:30.3350 (22790:0x7fabe1a819d8) TRACE_INIT
        SESSION_3


2013-11-14T18:00:30.3350 (22790:0x7fabe1a819d8) ERROR AT JStatement::execute
        t10e9 (ATT_712, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30/bin/isql:31618
335544528 : database t10e9 shutdown

2013-11-14T18:00:30.3350 (22790:0x7fabe1a819d8) ROLLBACK_TRANSACTION
        t10e9 (ATT_712, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30/bin/isql:31618
                (TRA_1259, CONCURRENCY | WAIT | READ_WRITE)
      0 ms

2013-11-14T18:00:30.3350 (22790:0x7fabe1a819d8) DETACH_DATABASE
        t10e9 (ATT_712, SYSDBA:NONE, NONE, TCPv4:127.0.0.1)
        /opt/fb30/bin/isql:31618

2013-11-14T18:00:30.3350 (22790:0x7fabe1a819d8) TRACE_FINI
        SESSION_3


2013-11-14T18:00:30.7390 (22790:0x7fabe1a819d8) TRACE_INIT
        SESSION_3


2013-11-14T18:00:30.7390 (22790:0x7fabe1a819d8) FAILED ATTACH_DATABASE
        t10e9.fdb (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
        /opt/fb30/bin/gfix:31934

2013-11-14T18:00:30.7390 (22790:0x7fabe1a819d8) ERROR AT JProvider::attachDatabase
        t10e9.fdb (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
        /opt/fb30/bin/gfix:31934
335544528 : database t10e9.fdb shutdown

2013-11-14T18:00:30.7390 (22790:0x7fabe1a819d8) TRACE_FINI
        SESSION_3


2013-11-14T18:00:32.1100 (31934:0x7fd2af1de058) TRACE_INIT
        SESSION_3


2013-11-14T18:00:32.1100 (31934:0x7fd2af1de058) FAILED ATTACH_DATABASE
        t10e9.fdb (ATT_0, SYSDBA, NONE, <internal>)

2013-11-14T18:00:32.1100 (31934:0x7fd2af1de058) ERROR AT JProvider::attachDatabase
        t10e9.fdb (ATT_0, SYSDBA, NONE, <internal>)
335544835 : Target shutdown mode is invalid for database "/var/db/fb30/t10e9.fdb"

2013-11-14T18:00:32.1100 (31934:0x7fd2af1de058) TRACE_FINI
        SESSION_3


2013-11-14T18:00:32.1250 (22790:0x7fabe1a819d8) TRACE_INIT
        SESSION_3


2013-11-14T18:00:32.1250 (22790:0x7fabe1a819d8) ATTACH_DATABASE
        /opt/fb30/security3.fdb (ATT_24931, SYSDBA:NONE, NONE, <internal>)

2013-11-14T18:00:42.4150 (22790:0x7fabe1a819d8) START_TRANSACTION
        /opt/fb30/security3.fdb (ATT_24931, SYSDBA:NONE, NONE, <internal>)
                (TRA_41843, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)

2013-11-14T18:00:42.4190 (22790:0x7fabe1a819d8) PREPARE_STATEMENT
        /opt/fb30/security3.fdb (ATT_24931, SYSDBA:NONE, NONE, <internal>)
                (TRA_41843, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)

Statement 21:
-------------------------------------------------------------------------------
SELECT PLG$VERIFIER, PLG$SALT FROM PLG$SRP WHERE PLG$USER_NAME = ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (PLG$SRP INDEX (RDB$PRIMARY2))
      2 ms

2013-11-14T18:00:42.4190 (22790:0x7fabe1a819d8) EXECUTE_STATEMENT_START
        /opt/fb30/security3.fdb (ATT_24931, SYSDBA:NONE, NONE, <internal>)
                (TRA_41843, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)

Statement 21:
-------------------------------------------------------------------------------
SELECT PLG$VERIFIER, PLG$SALT FROM PLG$SRP WHERE PLG$USER_NAME = ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (PLG$SRP INDEX (RDB$PRIMARY2))

param0 = varchar(93), "SYSDBA                                                                       ..."


2013-11-14T18:00:42.4190 (22790:0x7fabe1a819d8) EXECUTE_STATEMENT_FINISH
        /opt/fb30/security3.fdb (ATT_24931, SYSDBA:NONE, NONE, <internal>)
                (TRA_41843, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)

Statement 21:
-------------------------------------------------------------------------------
SELECT PLG$VERIFIER, PLG$SALT FROM PLG$SRP WHERE PLG$USER_NAME = ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (PLG$SRP INDEX (RDB$PRIMARY2))

param0 = varchar(93), "SYSDBA                                                                       ..."

0 records fetched
      0 ms, 1 read(s), 4 fetch(es)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
PLG$SRP                                           1

2013-11-14T18:00:42.4190 (22790:0x7fabe1a819d8) FREE_STATEMENT
        /opt/fb30/security3.fdb (ATT_24931, SYSDBA:NONE, NONE, <internal>)

Statement 21:
-------------------------------------------------------------------------------
SELECT PLG$VERIFIER, PLG$SALT FROM PLG$SRP WHERE PLG$USER_NAME = ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (PLG$SRP INDEX (RDB$PRIMARY2))

2013-11-14T18:00:42.4190 (22790:0x7fabe1a819d8) ROLLBACK_TRANSACTION
        /opt/fb30/security3.fdb (ATT_24931, SYSDBA:NONE, NONE, <internal>)
                (TRA_41843, READ_COMMITTED | REC_VERSION | WAIT | READ_ONLY)
      0 ms

2013-11-14T18:00:42.4190 (22790:0x7fabe1a819d8) DETACH_DATABASE
        /opt/fb30/security3.fdb (ATT_24931, SYSDBA:NONE, NONE, <internal>)

2013-11-14T18:00:42.4190 (22790:0x7fabe1a819d8) TRACE_FINI
        SESSION_3


2013-11-14T18:00:42.4700 (22790:0x7fabe1a819d8) TRACE_INIT
        SESSION_3


2013-11-14T18:00:42.4700 (22790:0x7fabe1a819d8) FAILED ATTACH_DATABASE
        t10e9.fdb (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
        /opt/fb30/bin/gfix:31934

2013-11-14T18:00:42.4700 (22790:0x7fabe1a819d8) ERROR AT JProvider::attachDatabase
        t10e9.fdb (ATT_0, SYSDBA, NONE, TCPv4:127.0.0.1)
        /opt/fb30/bin/gfix:31934
335544835 : Target shutdown mode is invalid for database "/var/db/fb30/t10e9.fdb"

2013-11-14T18:00:42.4700 (22790:0x7fabe1a819d8) TRACE_FINI
        SESSION_3
...
Рейтинг: 0 / 0
14.11.2013, 18:10:12
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38465504
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид В трейсе "реверс" изменений, происходящих в связи со срубанием при шатдауне выполняющегося стейтмента, не виден. Я забыл: это так и должно быть ?

А зачем это там видеть чтобы shutdown дольше шёл?
...
Рейтинг: 0 / 0
14.11.2013, 18:17:20
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38465517
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов ДенисТаблоид В трейсе "реверс" изменений, происходящих в связи со срубанием при шатдауне выполняющегося стейтмента, не виден. Я забыл: это так и должно быть ?А зачем это там видеть чтобы shutdown дольше шёл?Ну, для полноты картины как бэ...
Типа "вот, смотри: видишь, сколько мне пришлось отменять изменений из-за твоего шатдауна" (речь от лица ФБ :))

И не понял я, кстати! на сколько шатдаун будет дольше идти от того, что отмотка в трейсе покажется, пусть это будет даже для 500 коннектов ? Там же речь идёт о выводе в текст нескольких тысяч строк - копейки же.
...
Рейтинг: 0 / 0
14.11.2013, 18:23:05
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38465568
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоидвроде бы всё пучком
ну и замечательно

ТаблоидВ трейсе "реверс" изменений, происходящих в связи со срубанием при шатдауне выполняющегося стейтмента, не виден. Я забыл: это так и должно быть ?
трейс не показывает откаты сейвпойнтов, шатдаун это лишь частный случай
...
Рейтинг: 0 / 0
14.11.2013, 19:05:06
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38465929
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
Off. Интересно, а абракадабровцы в своем InterBase вообще такими проблемами заморачиваются? Тикетов подобного рода в QC практически нет.
...
Рейтинг: 0 / 0
15.11.2013, 07:44:18
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38466327
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DarkMaster
Участник
CyberMaxOff. Интересно, а абракадабровцы в своем InterBase вообще такими проблемами заморачиваются? Тикетов подобного рода в QC практически нет.

А у них Таблоида нету ;)
...
Рейтинг: 0 / 0
15.11.2013, 13:12:17
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38466371
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
CyberMaxOff. Интересно, а абракадабровцы в своем InterBase вообще такими проблемами заморачиваются? Тикетов подобного рода в QC практически нет.Сколько народу им пользуется, интербейсом этим ? если SQL-диалект этой СУБД не поддерживает даже derived-таблиц, то сильно подозреваю, что число её поклонников стремится к нулю.
...
Рейтинг: 0 / 0
15.11.2013, 13:37:09
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38466398
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

ну в interbase sql/psql диалект не развивали особо, зато кучу других плюшек сделали, которые обещаются только в тройке и то не все.
...
Рейтинг: 0 / 0
15.11.2013, 13:49:20
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38466435
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
Симонов Денис,

Например? Что будет в 3 и что не будет?
...
Рейтинг: 0 / 0
15.11.2013, 14:15:00
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38466453
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
CyberMax,

будет:

- SMP в супере
- шифрование БД
- шифрование трафика
- Linger Database
- хранение пользователей в самой БД

не будет (не видел нигде в планах на тройку):

- PITR
- журнал транзакций
- онлайн дамп

Я вообще плохо знаком с IB (сужу по инфе из ibase и различным презенташкам). Точнее тебе только kdv скажет.
...
Рейтинг: 0 / 0
15.11.2013, 14:29:03
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38466456
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Симонов Денисонлайн дампБлизкий аналог - nbackup
...
Рейтинг: 0 / 0
15.11.2013, 14:30:18
| Ответить | Цитировать | Написать  
gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
    #38466466
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
hvlad,

ну да. Но всё равно работают они по разному.
...
Рейтинг: 0 / 0
15.11.2013, 14:35:01
| Ответить | Цитировать | Написать  
25 сообщений из 31, страница 1 из 2
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gfix -shut, прерывающий bulk DML: возврат управления в ось - сразу или нет ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&fpage=109&tid=1564138]:
 0ms
get settings:
 9ms
get forum list:
 17ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 56ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 60ms
get tp. blocked users:
 1ms
others: 219ms
total:  385ms
созд. / загр.: 385ms
x
x
Закрыть


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