ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / select ID from <T> for update with lock into :V - создает ли версию записи ?
27 сообщений из 27, показаны все 2 страниц
  все  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706298
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hi all

Intro. Из семинара по транзакциям, 04-jun-2014, msk:Moscow_05_Garbage_collection.pdf, page 14BACKOUT: удаляем только первичную версию и восстанавливаем предыдущую
Всё ниже показанное сделано на новых базах с page_size = 8192, FW = OFF.
DDL (таблица с 2 млн строк, индексное по полю 'x' имеет селективность = 0.01 и весьма хреновый фактор кластеризации = 0.66) :
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
====
set term ^;
execute block as begin
    begin
        execute statement 'drop sequence g';
    when any do begin end
    end
end
^set term ;^
commit;
create sequence g;
commit;

recreate table t(id int primary key, x int);
commit;
insert into t select gen_id(g,1), mod( gen_id(g,0), 100 ) from rdb$types, rdb$types, rdb$types rows 2000000;
commit;

create index t_x on t(x);
commit;
 
gstat -r -t T
Код: 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.
T (128)
    Primary pointer page: 174, Index root page: 175
    Total formats: 1, used formats: 1
    Average record length: 11.98, total records: 2000000
    Average version length: 9.00, total versions: 60000, max versions: 1
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 12.00, compression ratio: 1.00
    Pointer pages: 8, data page slots: 13246
    Data pages: 13246, average fill: 55%
    Primary pages: 13246, full pages: 0, swept pages: 0
    Fill distribution:
         0 - 19% = 1
        20 - 39% = 0
        40 - 59% = 13245
        60 - 79% = 0
        80 - 99% = 0

    Index RDB$PRIMARY1 (0)
        Root page: 8408, depth: 3, leaf buckets: 1467, nodes: 2000000
        Average node length: 5.92, total dup: 0, max dup: 0
        Average key length: 3.00, compression ratio: 1.33
        Average prefix length: 2.98, average data length: 1.00
        Clustering factor: 13246, ratio: 0.01
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 0
            40 - 59% = 1
            60 - 79% = 0
            80 - 99% = 1466

    Index T_X (1)
        Root page: 16061, depth: 3, leaf buckets: 1218, nodes: 2000000
        Average node length: 4.92, total dup: 1999900, max dup: 19999
        Average key length: 2.00, compression ratio: 1.20
        Average prefix length: 2.41, average data length: 0.00
        Clustering factor: 1324505, ratio: 0.66
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 1
            40 - 59% = 0
            60 - 79% = 0
            80 - 99% = 1217

Тестовый скрипт:
 
Код: 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.
rollback;
set transaction no wait no auto undo;
set term ^;
execute block returns( eng varchar(10), scanned int, locked_ok int, skipped int )
as
  declare cx cursor for ( select rdb$db_key as dbkey from t where x between 49 and 51 order by x);
  declare v_key char(8) character set octets;
  declare id int;
  declare x int;
begin
  scanned=0;
  locked_ok=0;
  skipped=0;
  eng=rdb$get_context('SYSTEM','ENGINE_VERSION');
  open cx;
  while (1=1) do begin
    fetch cx into v_key;
    if ( row_count = 0 ) then leave;
    scanned = scanned + 1;
    begin
        --update t set id=id where current of cx;
         select id, x from t where rdb$db_key = :v_key for update with lock into id, x; 

        locked_ok = locked_ok + 1;
    when any do
        begin
            if ( gdscode in ( 335544345, 335544878, 335544336,335544451 ) )
              then skipped = skipped +1;
            else
              exception;
        end
    end
  end
  close cx;
  suspend;
end
^
set term ;^

Запускаю его несколько раз на LI-V2.5.3.26788 и на LI-T3.0.0.31250. Оба ФБ - в режиме SuperServer, конкурирующих аттачей нет.

Конфиг 2.5:
Код: plaintext
1.
2.
3.
4.
DefaultDbCachePages = 524288
FileSystemCacheThreshold = 1000000
TempBlockSize = 104857600
TempCacheLimit = 1073741824

Конфиг 3.0:
Код: plaintext
1.
2.
3.
DefaultDbCachePages = 512K
FileSystemCacheThreshold = 65536K
TempCacheLimit = 1024M

Результаты трейса (показаны, начиная со второго запуска на каждом ФБ):
1) для 2.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.
PLAN (T ORDER T_X INDEX (T_X))
PLAN (T INDEX ())
1 records fetched
   1689 ms, 1285201 fetch(es), 259710 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   46570    
. . .
   2153 ms, 971712 fetch(es), 200931 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   26977  
. . .
   2153 ms, 971712 fetch(es), 200931 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   26977  
. . .
   1968 ms, 859600 fetch(es), 179910 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   19970
. . .
  2008 ms, 878130 fetch(es), 183384 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   21128   
. . .
   1991 ms, 852624 fetch(es), 178602 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   19534
2) для 3.0 :
 
Код: 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.
Select Expression
    -> Filter
        -> Table "T" as "CX T" Access By ID
            -> Index "T_X" Range Scan (lower bound: 1/1, upper bound: 1/1)
Select Expression
    -> Write Lock
        -> Singularity Check
            -> Filter
                -> Table "T" Access By ID
                    -> DBKEY
1 records fetched
   1403 ms, 1221896 fetch(es), 247848 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   42616                    
. . .
   1477 ms, 1177528 fetch(es), 239529 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   39843     
. . .
   1388 ms, 1178440 fetch(es), 239700 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   39900 
. . .
Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   39353                    
. . .
   1370 ms, 1177497 fetch(es), 239523 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   39841                    
. . .
   1403 ms, 1176072 fetch(es), 239256 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                   39752


Разное число фетчей... марок... разное время (в 2.5) при отсутствии, повторюсь, конкурирующих активностей на серваке.
Но главное - ненулевые backout'ы при отсутствии чего-либо, создававшего версии строк. Причём, их значения - тоже разные (особливо в 2.5).

Чем это всё можно оюъяснить ?
...
Рейтинг: 0 / 0
25.07.2014, 18:32
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706301
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
SELECT WITH LOCK естественно создает версию записи, ты опять школу проспал? :-)
...
Рейтинг: 0 / 0
25.07.2014, 18:34
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706314
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
dimitrSELECT WITH LOCK естественно создает версию записи, ты опять школу проспал? :-)гм... странно: пребывал в блаженной уверенности, что на семинаре из уст кого-то из Монстров Рока прозвучала фраза, что select for update НЕ создаёт версии... Впрочем может, поглючилось...

Но! Почему тогда нет бекверсий вот тута:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
recreate table td(id int primary key); commit;
create sequence gd; commit;
insert into td select gen_id(gd,1) from rdb$types,rdb$types; commit; -- ~50000 rows
select id from td where id between 25000 and 25010 for update with lock;
rollback;
select id from td where id between 25000 and 25010 for update with lock;
rollback;
select id from td where id between 25000 and 25010 for update with lock;
rollback;

trace:
 
Код: 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.
2014-07-25T18:48:28.0650 (27218:0x7fc322e848c8) START_TRANSACTION
	/var/db/fb25/tmp25.fdb (ATT_18, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2380
		(TRA_188, CONCURRENCY | WAIT | READ_WRITE)

2014-07-25T18:48:28.0760 (27218:0x7fc322e848c8) EXECUTE_STATEMENT_FINISH
	/var/db/fb25/tmp25.fdb (ATT_18, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2380
		(TRA_188, CONCURRENCY | WAIT | READ_WRITE)

Statement 347:
-------------------------------------------------------------------------------
select id from td where id between 25000 and 25010 for update with lock
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (TD INDEX (RDB$PRIMARY2))
11 records fetched
      0 ms, 69 fetch(es), 22 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
TD                                               11                                                            

2014-07-25T18:48:32.5540 (27218:0x7fc322e848c8) ROLLBACK_TRANSACTION
	/var/db/fb25/tmp25.fdb (ATT_18, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2380
		(TRA_188, CONCURRENCY | WAIT | READ_WRITE)
      0 ms, 4 write(s), 157 fetch(es), 35 mark(s)

2014-07-25T18:48:36.8440 (27218:0x7fc322e848c8) START_TRANSACTION
	/var/db/fb25/tmp25.fdb (ATT_18, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2380
		(TRA_189, CONCURRENCY | WAIT | READ_WRITE)

2014-07-25T18:48:36.8550 (27218:0x7fc322e848c8) EXECUTE_STATEMENT_FINISH
	/var/db/fb25/tmp25.fdb (ATT_18, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2380
		(TRA_189, CONCURRENCY | WAIT | READ_WRITE)

Statement 349:
-------------------------------------------------------------------------------
select id from td where id between 25000 and 25010 for update with lock
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (TD INDEX (RDB$PRIMARY2))
11 records fetched
      0 ms, 69 fetch(es), 22 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
TD                                               11                                                            

2014-07-25T18:48:42.0910 (27218:0x7fc322e848c8) ROLLBACK_TRANSACTION
	/var/db/fb25/tmp25.fdb (ATT_18, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2380
		(TRA_189, CONCURRENCY | WAIT | READ_WRITE)
      0 ms, 3 write(s), 155 fetch(es), 34 mark(s)

2014-07-25T18:48:44.9690 (27218:0x7fc322e848c8) START_TRANSACTION
	/var/db/fb25/tmp25.fdb (ATT_18, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2380
		(TRA_190, CONCURRENCY | WAIT | READ_WRITE)

2014-07-25T18:48:44.9800 (27218:0x7fc322e848c8) EXECUTE_STATEMENT_FINISH
	/var/db/fb25/tmp25.fdb (ATT_18, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2380
		(TRA_190, CONCURRENCY | WAIT | READ_WRITE)

Statement 350:
-------------------------------------------------------------------------------
select id from td where id between 25000 and 25010 for update with lock
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PLAN (TD INDEX (RDB$PRIMARY2))
11 records fetched
      0 ms, 69 fetch(es), 22 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
TD                                               11                                                            

2014-07-25T18:48:48.9930 (27218:0x7fc322e848c8) ROLLBACK_TRANSACTION
	/var/db/fb25/tmp25.fdb (ATT_18, SYSDBA:NONE, NONE, TCPv4:192.168.43.96)
	C:\MIX\firebird\fb25\bin\isql.exe:2380
		(TRA_190, CONCURRENCY | WAIT | READ_WRITE)
      0 ms, 3 write(s), 155 fetch(es), 34 mark(s)
...
Рейтинг: 0 / 0
25.07.2014, 18:52
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706333
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
Таблоидselect for update НЕ создаёт версии.
select for update не создает версии
select with lock - создает версии
with lock появился в 1.5.

for update, как и ранее, в соответствии с
http://www.firebirdsql.org/refdocs/langrefupd25-select.html#langrefupd25-with-lock
для with lock не является обязательным, и имеет только один эффект - помещение в пакет по 1 записи, вместо забивания пакета записями в обычных условиях.

Тут совсем подробно
http://www.firebirdsql.org/refdocs/langrefupd25-notes-withlock.html
и напомню
http://www.ibase.ru/devinfo/pslock.htm
...
Рейтинг: 0 / 0
25.07.2014, 19:13
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706340
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ТаблоидПочему тогда нет бекверсий вот тута:
Потому что они автооткатились. Стартуй странзакция с NO AUTO UNDO и будет тебе счастье.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.07.2014, 19:34
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706342
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Разобрался. Ненулевые backout'ы будут, если стартовать транзакцию _с_ кляузой no auto undo.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SQL> recreate table tx(id int); commit;
SQL> insert into tx values(1); commit;
SQL> out nul;
SQL> rollback; set transaction no wait; select id from tx for update with lock;
SQL> rollback; set transaction no wait; select id from tx for update with lock;
SQL> rollback; set transaction no wait; select id from tx for update with lock;
-- vs --
SQL> rollback; set transaction no wait no auto undo; select id from tx for update with lock;
SQL> rollback; set transaction no wait no auto undo; select id from tx for update with lock;
SQL> rollback; set transaction no wait no auto undo; select id from tx for update with lock;
SQL> out;

И это - удивляет как бэ...
...
Рейтинг: 0 / 0
25.07.2014, 19:38
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706343
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovТаблоидПочему тогда нет бекверсий вот тута:
Потому что они автооткатились. Стартуй странзакция с NO AUTO UNDO и будет тебе счастье.да, я уже это увидел, спс.
...
Рейтинг: 0 / 0
25.07.2014, 19:38
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706351
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Остался еще вопросик. Какими фазами Меркурия объясняются разные значения backout'ов (см стартовый пост), особливо в 2.5 ?
...
Рейтинг: 0 / 0
25.07.2014, 19:52
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706355
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидОба ФБ - в режиме SuperServer
может, фоновый сборщик мусора что-то успевает?
...
Рейтинг: 0 / 0
25.07.2014, 19:59
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706381
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvТаблоидОба ФБ - в режиме SuperServerможет, фоновый сборщик мусора что-то успевает?Он должен в таком случае успевать убрать всё, т.е. в трейсе я не должен видеть ни backout'ов, ни пугренов, ни экспунгов.

Ибо вот модифицир. скрипт:
 
Код: 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.
commit;
set transaction no wait no auto undo;
set term ^;
execute block returns( eng varchar(10), scanned int, locked_ok int, skipped int )
as
  declare cx cursor for ( select rdb$db_key as dbkey from t where x between 49 and 51 order by x);
  declare v_key char(8) character set octets;
  declare id int;
  declare x int;
begin
  scanned=0;
  locked_ok=0;
  skipped=0;
  eng=rdb$get_context('SYSTEM','ENGINE_VERSION');
  open cx;
  while (1=1) do begin
    fetch cx into v_key;
    if ( row_count = 0 ) then leave;
    scanned = scanned + 1;
    begin
        --update t set id=id where current of cx;
        select id, x from t where rdb$db_key = :v_key for update with lock into id, x;

        locked_ok = locked_ok + 1;
    when any do
        begin
            if ( gdscode in ( 335544345, 335544878, 335544336,335544451 ) )
              then skipped = skipped +1;
            else
              exception;
        end
    end
  end
  close cx;
  suspend;
end
^
set term ;^
commit;

-- дальше имитируем "другую активность":
select count(*) from rdb$types,rdb$types,rdb$types; 
commit;
И вот что я вижу в isql и в трейсе:
 
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.
33.
SQL> in oe;

ENG             SCANNED    LOCKED_OK      SKIPPED
========== ============ ============ ============
2.5.3             60000        60000            0


       COUNT
============
    11852352

SQL> in oe;

ENG             SCANNED    LOCKED_OK      SKIPPED
========== ============ ============ ============
2.5.3             60000        60000            0


       COUNT
============
    11852352

SQL> in oe;

ENG             SCANNED    LOCKED_OK      SKIPPED
========== ============ ============ ============
2.5.3             60000        60000            0


       COUNT
============
    11852352

SQL>
 
trace
Код: 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-07-25T 21:18:40. 0660 (332:0x7fda9a12d8c8) EXECUTE_STATEMENT_FINISH
. . .
PLAN (T ORDER T_X INDEX (T_X))
PLAN (T INDEX ())
1 records fetched
   1699 ms, 704360 fetch(es), 174760 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                             27380

. . .

2014-07-25T 21:18:56 .2540 (332:0x7fda9a12d8c8) EXECUTE_STATEMENT_FINISH
. . .
PLAN (T ORDER T_X INDEX (T_X))
PLAN (T INDEX ())
1 records fetched
   1643 ms, 746396 fetch(es), 188772 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                             34386

. . .

2014-07-25T 21:19:29 .5400  (332:0x7fda9a12d8c8) EXECUTE_STATEMENT_FINISH
. . .
    693 ms, 687602 fetch(es), 169174 mark(s)

Table                             Natural     Index    Update    Insert    Delete   Backout     Purge   Expunge
***************************************************************************************************************
T                                            120000                                             24587
Сколько времени ему (фоновому GC) надо на "уборку территории" ?
...
Рейтинг: 0 / 0
25.07.2014, 21:33
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706405
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидkdvможет, фоновый сборщик мусора что-то успевает?Он должен в таком случае успевать убрать всё, т.е. в трейсе я не должен видеть ни backout'ов, ни пугренов, ни экспунгов.С чего ты взял, что он должен всё успеть ?

ТаблоидСколько времени ему (фоновому GC) надо на "уборку территории" ?N, а может и M

PS Возьми мониторинг в руки и смотри за фоновым сборщиком
...
Рейтинг: 0 / 0
25.07.2014, 22:47
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706423
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
dimitrSELECT WITH LOCK естественно создает версию записи
А создаёт ли он новую версию записи если текущая версия уже создана текущей транзакцией?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
25.07.2014, 23:42
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706429
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Dimitry SibiryakovА создаёт ли он новую версию записи если текущая версия уже создана текущей транзакцией?
будет update-in-place
...
Рейтинг: 0 / 0
26.07.2014, 00:09
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38706538
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
dimitrбудет update-in-place
Может, записи, выбранные select с with lock, ещё и в undo log добавляются?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
26.07.2014, 14:00
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709094
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladВозьми мониторинг в руки и смотри за фоновым сборщикомПроверил. НЕ работает фоновый сборщик. Или, может, не должен работать - не знаю.

DDL :
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
set term ^;
execute block as begin
    begin
        execute statement 'drop sequence g';
    when any do begin end
    end
end
^set term ;^
commit;
create sequence g;
commit;

recreate table t(id int primary key, x int);
commit;
insert into t select gen_id(g,1), mod( gen_id(g,0), 100 ) from rdb$types, rdb$types, rdb$types rows 2000000;
commit;

create index t_x on t(x);
commit;
Скрипт, который будет несколько раз запускаться из основного run-скрипта:
 
file = `gc_test.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.
50.
select current_timestamp as dts, 'start EB. . .' as msg from rdb$database;
commit;
set transaction no wait no auto undo;
set term ^;
execute block returns( eng varchar(10), scanned int, locked_ok int, skipped int )
as
  declare cx cursor for ( select rdb$db_key as dbkey from t where x between 49 and 51 order by x);
  declare v_key char(8) character set octets;
  declare id int;
  declare x int;
begin
  scanned=0;
  locked_ok=0;
  skipped=0;
  eng=rdb$get_context('SYSTEM','ENGINE_VERSION');
  open cx;
  while (1=1) do begin
    fetch cx into v_key;
    if ( row_count = 0 ) then leave;
    scanned = scanned + 1;
    begin
        --update t set id=id where current of cx;
        select id, x from t where rdb$db_key = :v_key for update with lock into id, x;

        locked_ok = locked_ok + 1;
    when any do
        begin
            if ( gdscode in ( 335544345, 335544878, 335544336,335544451 ) )
              then skipped = skipped +1;
            else
              exception;
        end
    end
  end
  close cx;
  suspend;
end
^
set term ;^
commit;
select current_timestamp as dts, 'finish EB + commit' as msg from rdb$database;
-- emulate some activity
 -- GC should(?) start his job in separate thread since this point: 
out nul;
select count(*) from rdb$types,rdb$types,rdb$types; 
commit;
select count(*) from rdb$types,rdb$types,rdb$types; 
commit;
out;
select current_timestamp as dts, 'finish counts' as msg from rdb$database;
commit;

Запускаемый скрипт (file = `gc_run.sql`):
Код: plaintext
1.
2.
3.
4.
5.
in gc_test.sql;
in gc_test.sql;
in gc_test.sql;
in gc_test.sql;
in gc_test.sql;

Стартуем в окне-1 :
Код: plaintext
isql 192.168.0.220/3333:/var/db/fb30/tmp30.fdb -i gc_run.sql 1>gc_run.log 2>&1

Тут же стартуем в окне-2:
 
file = `askmon_7200.sh`
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
monsql=askmon_7200.sql
fbhome=/opt/fb30trnk
fbport=3333
fdb=/var/db/fb30/tmp30.fdb

log=./logs/mon30_$fdb_$(date +'%y%m%d_%H%M%S').log
err=./logs/mon30_$fdb_$(date +'%y%m%d_%H%M%S').err

rm -f $log
while :
do
  echo -----------------------------------------------------------------------------------
  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) - starting quering mon tables
  echo check result in $log, errors in $err
  echo $fbhome/bin/isql localhost/$fbport:$fdb -user sysdba -pas masterke -pag 999 -n i ...
  set -x
  $fbhome/bin/isql localhost/$fbport:$fdb -user sysdba -pas masterke -pag 999 -n -i $monsql 2>>$err | sed -e "s/ \{1,\}$//" >>$log
  set +x
  ls -la $log $err
  echo $(echo -n $(date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24) - done. Start next iter. . .
done
где скрипт `askmon_7200.sql` есть повтор 7200 раз вот этого:
 
`askmon_7200.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.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
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 sec 6; 
commit; 
    select     
      current_time dts     
      -- mon$attachments:     
      ,cast( datediff(second from timestamp '30.07.2014' to current_timestamp ) as char(10 ) ) sec     
      ,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$attachment_id<>current_connection 
      order by 
      iif( a.mon$user in ('Garbage Collector', 'Cache Writer'  )
          ,1 
          , iif( a.mon$remote_process containing 'gfix'
                ,2 
                ,iif( a.mon$remote_process containing 'nbackup'
                      or a.mon$remote_process containing 'gbak'
                     ,3 
                     ,1000+a.mon$attachment_id
                     )
                )
          )
    rows 7 
  ;
 shell sleep 1;      
set heading off;     
select substring(cast(current_timestamp as varchar(25)) from 12 for 12) dts,'iter #'||2 msg from rdb$database;     
commit;     
    select     
      current_time dts     
      -- mon$attachments:     
      ,cast( datediff(second from timestamp '30.07.2014' to current_timestamp ) as char(10 ) ) sec     
      ,a.mon$remote_address remote_IP     
. . . etc 7200 times . . .
(т.е. между каждым опросом mon-таблиц делается пауза 1 сек).

Лог вывода скрипта, который лочил строки, делал затем коммит и выполнял "другую активность" несколько раз:
 
`gc_run.log`
Код: 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.
                      DTS MSG           
========================= ============= 
2014-07-30 13:34:20.4070  start EB. . . 


ENG             SCANNED    LOCKED_OK      SKIPPED 
========== ============ ============ ============ 
3.0.0             60000        60000            0 


                      DTS MSG                
========================= ================== 
2014-07-30 13:34:21.2950  finish EB + commit 


                      DTS MSG           
========================= ============= 
2014-07-30 13:34:38.8480  finish counts 


                      DTS MSG           
========================= ============= 
2014-07-30 13:34:38.8510  start EB. . . 


ENG             SCANNED    LOCKED_OK      SKIPPED 
========== ============ ============ ============ 
3.0.0             60000        60000            0 


                      DTS MSG                
========================= ================== 
2014-07-30 13:34:39.5440  finish EB + commit 


                      DTS MSG           
========================= ============= 
2014-07-30 13:34:57.2390  finish counts 


                      DTS MSG           
========================= ============= 
2014-07-30 13:34:57.2420  start EB. . . 


ENG             SCANNED    LOCKED_OK      SKIPPED 
========== ============ ============ ============ 
3.0.0             60000        60000            0 


                      DTS MSG                
========================= ================== 
2014-07-30 13:34:57.9280  finish EB + commit 


                      DTS MSG           
========================= ============= 
2014-07-30 13:35:15.6080  finish counts 


                      DTS MSG           
========================= ============= 
2014-07-30 13:35:15.6100  start EB. . . 


ENG             SCANNED    LOCKED_OK      SKIPPED 
========== ============ ============ ============ 
3.0.0             60000        60000            0 


                      DTS MSG                
========================= ================== 
2014-07-30 13:35:16.3020  finish EB + commit 


                      DTS MSG           
========================= ============= 
2014-07-30 13:35:34.1480  finish counts 


                      DTS MSG           
========================= ============= 
2014-07-30 13:35:34.1510  start EB. . . 


ENG             SCANNED    LOCKED_OK      SKIPPED 
========== ============ ============ ============ 
3.0.0             60000        60000            0 


                      DTS MSG                
========================= ================== 
2014-07-30 13:35:34.8390  finish EB + commit 


                      DTS MSG           
========================= ============= 
2014-07-30 13:35:52.3550  finish counts

Промежутки времени между фразами "finish EB + commit" и "finish counts" - это время, когда выполнялась "другая активность", т.е. подсчет строк из большого источника данных (да еще два раза, для верности :)).

В аттаче - причёсанный лог опроса мониторинга. В котором русским по белому видно, что поток GC... ничего не делал (строки выделены жёлтым цветом). Вообще. И поток CW, кстати - тоже.

ЧЯДНТ ?
...
Рейтинг: 0 / 0
30.07.2014, 14:09
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709147
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry Sibiryakovdimitrбудет update-in-place
Может, записи, выбранные select с with lock, ещё и в undo log добавляются?А как же ты переписывал тот самый undo log, если задаёшь такие вопросы ???
...
Рейтинг: 0 / 0
30.07.2014, 15:03
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709151
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидПроверил. НЕ работает фоновый сборщик. Или, может, не должен работать - не знаю.Для SELECT WITH LOCK - не работает, согласен.
...
Рейтинг: 0 / 0
30.07.2014, 15:06
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709159
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидПроверил. НЕ работает фоновый сборщик. Или, может, не должен работать - не знаю.Для SELECT WITH LOCK - не работает, согласен.А должен ли был вообще ?
PS. Я проверю для update t set id=id, отпишусь тогда.
PPS. И еще тут бНОПНЯ: если в SS работает один аттач-молотилка, а в двух других потоках - GC & CW, то должна ли их активность отображаться в виде ненулевой загрузки разных cpu-ядер сервера ? Ибо я тут понаблюдал в top'e, и увидел загрузку только одного ядра...
...
Рейтинг: 0 / 0
30.07.2014, 15:13
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709165
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
hvladА как же ты переписывал тот самый undo log, если задаёшь такие вопросы ???

Во-первых, я его не переписывал, а только причёсывал.
Во-вторых, только нижний уровень, непосредственно работу самого лога, всё дерево вызовов и
высокоуровневой логики я не прослеживал.
Если бы я наткнулся на его заполнение при select, то пошёл бы в девел и резонно задал
вопрос "а назачем", поскольку backout "тяжелее" чем expunge.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
30.07.2014, 15:18
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709175
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry Sibiryakovя его не переписывал, а только причёсывал.0xFF. ты "тот самый" патчик по нынешним сырцам вышлешь, или чё там ? ;-)
...
Рейтинг: 0 / 0
30.07.2014, 15:23
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709179
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидhvladДля SELECT WITH LOCK - не работает, согласен.А должен ли был вообще ?Сходу - не вижу противопоказаний.

Таблоидесли в SS работает один аттач-молотилка, а в двух других потоках - GC & CW, то должна ли их активность отображаться в виде ненулевой загрузки разных cpu-ядер сервера ?Да, но только если эти потоки действительно грузят CPU, а не IO.
...
Рейтинг: 0 / 0
30.07.2014, 15:25
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709183
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоид0xFF. ты "тот самый" патчик по нынешним сырцам вышлешь, или чё там ? ;-)

Вышлю когда подрихтую под позднейшие изменения.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
30.07.2014, 15:27
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709184
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Dimitry SibiryakovВо-первых, я его не переписывал, а только причёсывал.Речь о том, что ты должен бы быть в состоянии посмотреть ответ в коде, а не задавать такие вопросы


Dimitry SibiryakovЕсли бы я наткнулся на его заполнение при select, то пошёл бы в девел и резонно задал
вопрос "а назачем", поскольку backout "тяжелее" чем expunge.Ну так возрадуйся, ибо любое создание версии протоколируется в анду-логе.
Ответ на свой "а назачем" найди сам, он на поверхности.
...
Рейтинг: 0 / 0
30.07.2014, 15:29
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709191
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladтолько если эти потоки действительно грузят CPU , а не IO.А чем они могут грузить ЦПУ, если всё, что они делают, это операции с базой ?
Вот если я буду делать в бесконечной тоске что-то типа:

Код: plaintext
1.
2.
3.
4.
5.
6.
update t set ... where <много-много-строк>;
commit;
update t set ... where <много-много-строк>;
commit;
update t set ... where <много-много-строк>;
commit;
. . .
- то должен ли увидеть загрузку трёх ядер ? Или тут что-то более хитрое надо сваять ?
...
Рейтинг: 0 / 0
30.07.2014, 15:34
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709227
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоиддолжен ли увидеть загрузку трёх ядер ?Два - увидишь.
...
Рейтинг: 0 / 0
30.07.2014, 16:11
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38709601
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Таблоидhvladпропущено...
Для SELECT WITH LOCK - не работает, согласен.А должен ли был вообще ?
PS. Я проверю для update t set id=id, отпишусь тогда.
PPS. И еще тут бНОПНЯ: если в SS работает один аттач-молотилка, а в двух других потоках - GC & CW, то должна ли их активность отображаться в виде ненулевой загрузки разных cpu-ядер сервера ? Ибо я тут понаблюдал в top'e, и увидел загрузку только одного ядра...В общем, когда меняем select with lock на холостой апдейт:
 
Код: 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.
select current_timestamp as dts, 'start EB. . .' as msg from rdb$database;
commit;
set transaction no wait no auto undo;
set term ^;
execute block returns( eng varchar(10), scanned int, locked_ok int, skipped int )
as
  declare cx cursor for ( select rdb$db_key as dbkey from t where x between 49 and 51 order by x);
  declare v_key char(8) character set octets;
  declare id int;
  declare x int;
begin
  scanned=0;
  locked_ok=0;
  skipped=0;
  eng=rdb$get_context('SYSTEM','ENGINE_VERSION');
  open cx;
  while (1=1) do begin
    fetch cx into v_key;
    if ( row_count = 0 ) then leave;
    scanned = scanned + 1;
    begin
         update t set id=id where current of cx; 
        --select id, x from t where rdb$db_key = :v_key for update with lock into id, x;

        locked_ok = locked_ok + 1;
    when any do
        begin
            if ( gdscode in ( 335544345, 335544878, 335544336,335544451 ) )
              then skipped = skipped +1;
            else
              exception;
        end
    end
  end
  close cx;
  suspend;
end
^
set term ;^
commit;
select current_timestamp as dts, 'finish EB + commit' as msg from rdb$database;
-- emulate some activity
out nul;
select count(*) from rdb$types,rdb$types,rdb$types; 
commit;
select count(*) from rdb$types,rdb$types,rdb$types; 
commit;
out;
select current_timestamp as dts, 'finish counts' as msg from rdb$database;
commit;
- то... ничего не меняется. Потоки GC & CW - бездельничают.
 
gc_run.log
Код: 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.
                      DTS MSG           
========================= ============= 
2014-07-31 00:40:56.1400  start EB. . . 


ENG             SCANNED    LOCKED_OK      SKIPPED 
========== ============ ============ ============ 
3.0.0             60000        60000            0 


                      DTS MSG                
========================= ================== 
2014-07-31 00:40:56.8250  finish EB + commit 


                      DTS MSG           
========================= ============= 
2014-07-31 00:41:14.3630  finish counts 


                      DTS MSG           
========================= ============= 
2014-07-31 00:41:14.3650  start EB. . . 


ENG             SCANNED    LOCKED_OK      SKIPPED 
========== ============ ============ ============ 
3.0.0             60000        60000            0 


                      DTS MSG                
========================= ================== 
2014-07-31 00:41:15.0250  finish EB + commit 


                      DTS MSG           
========================= ============= 
2014-07-31 00:41:32.5460  finish counts 


                      DTS MSG           
========================= ============= 
2014-07-31 00:41:32.5490  start EB. . . 


ENG             SCANNED    LOCKED_OK      SKIPPED 
========== ============ ============ ============ 
3.0.0             60000        60000            0 


                      DTS MSG                
========================= ================== 
2014-07-31 00:41:33.2040  finish EB + commit 


                      DTS MSG           
========================= ============= 
2014-07-31 00:41:50.7260  finish counts 


                      DTS MSG           
========================= ============= 
2014-07-31 00:41:50.7290  start EB. . . 


ENG             SCANNED    LOCKED_OK      SKIPPED 
========== ============ ============ ============ 
3.0.0             60000        60000            0 


                      DTS MSG                
========================= ================== 
2014-07-31 00:41:51.3820  finish EB + commit 


                      DTS MSG           
========================= ============= 
2014-07-31 00:42:08.9180  finish counts 


                      DTS MSG           
========================= ============= 
2014-07-31 00:42:08.9210  start EB. . . 


ENG             SCANNED    LOCKED_OK      SKIPPED 
========== ============ ============ ============ 
3.0.0             60000        60000            0 


                      DTS MSG                
========================= ================== 
2014-07-31 00:42:09.5780  finish EB + commit 


                      DTS MSG           
========================= ============= 
2014-07-31 00:42:27.1430  finish counts

В аттаче - причесанный эксельчик с данными опроса мониторинга для этого варианта.
...
Рейтинг: 0 / 0
31.07.2014, 00:59
| Ответить | Цитировать | Написать  
select ID from <T> for update with lock into :V - создает ли версию записи ?
    #38712882
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидВ общем, когда меняем select with lock на холостой апдейт:Я не воспроизводил твою "систему мониторинга", но вижу, что GC собирает мусор меньше чем за секунду после старта новой тр-ции, после EB.
Есс-но, ты не успеешь увидеть загрузку более чем одного ядра.
...
Рейтинг: 0 / 0
05.08.2014, 12:05
| Ответить | Цитировать | Написать  
27 сообщений из 27, показаны все 2 страниц
  все  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / select ID from <T> for update with lock into :V - создает ли версию записи ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=40&tid=1563418]:
 0ms
get settings:
 4ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 174ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 66ms
get tp. blocked users:
 2ms
others: 203ms
total:  482ms
созд. / загр.: 482ms
x
x
Закрыть


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