Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ? / 25 сообщений из 35, страница 1 из 2
03.04.2014, 13:53:21
    #38604248
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
hi all

Код: 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.
SQL> recreate table t1(id int primary key, s01 varchar(4), s02 varchar(4));
SQL> create index t1_s01_s02 on t1(s01, s02);
SQL> create index t1_s02_s01 on t1(s02, s01);
SQL> commit;
SQL> insert into t1
CON> select row_number()over(), left(uuid_to_char( gen_uuid() ), 4), left(uuid_to_char( gen_uuid() ), 4)
CON> from rdb$types rows 5;
SQL> commit;

SQL> execute block returns(msg varchar(50), elapsed_ms int) as
CON>   declare n int = 100000;
CON>   declare t0 timestamp;
CON> begin
CON>   t0=cast('now' as timestamp);
CON>   msg='update in-place '||n||' times, table T1';
CON>   while (n>0) do update t1 set s01=s02, s02=s01 where id=1 returning :n-1 into n;
CON>   elapsed_ms = datediff(millisecond from t0 to cast('now' as timestamp));
CON>   suspend;
CON> end
CON> ^

MSG                             update in-place 100000 times, table T1
ELAPSED_MS                      2419


SQL> set term ;^
SQL> commit;
SQL> exit;

Других коннектов к базе нет.
Делаю теперь два раза gstat -r -t T1: до и после свипа.
Результат до свипа:
Код: 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.
Database "/var/db/fb30/tmpidxupd.fdb"
Database header page information:
        Flags                   0
        Generation              32
        System Change Number    0
        Page size               4096
        ODS version             12.0
        Oldest transaction      22
        Oldest active           23
        Oldest snapshot         23
        Next transaction        24
        Sequence number         0
        Next attachment ID      12
        Implementation          HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Apr 3, 2014 13:39:33
        Attributes

    Variable header data:
        Sweep interval:         20000
        *END*


Database file sequence:
File /var/db/fb30/tmpidxupd.fdb is the only file

Analyzing database pages ...
T1 (132)
    Primary pointer page: 183, Index root page: 187
    Total formats: 1, used formats: 1
    Average record length: 21.00, total records: 5
    Average version length: 21.00, total versions: 1, max versions: 1
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 20.00, compression ratio: 0.95
    Pointer pages: 1, data page slots: 1
    Data pages: 1, average fill: 6%
    Primary pages: 1, full pages: 0, swept pages: 0
    Fill distribution:
         0 - 19% = 1
        20 - 39% = 0
        40 - 59% = 0
        60 - 79% = 0
        80 - 99% = 0

    Index RDB$PRIMARY9 (0)
        Root page: 201, depth: 1, leaf buckets: 1, nodes: 5
        Average node length: 4.40, total dup: 0, max dup: 0
        Average key length: 3.00, compression ratio: 0.60
        Average prefix length: 0.60, average data length: 1.20
        Clustering factor: 1, ratio: 0.20
        Fill distribution:
             0 - 19% = 1
            20 - 39% = 0
            40 - 59% = 0
            60 - 79% = 0
            80 - 99% = 0

    Index T1_S01_S02 (1)
        Root page: 208, depth: 2, leaf buckets: 87, nodes: 50005
        Average node length: 3.02,  total dup: 50000, max dup: 50000 
        Average key length: 2.02, compression ratio: 4.96
        Average prefix length: 9.98, average data length: 0.02
        Clustering factor: 1, ratio: 0.00
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 0
            40 - 59% = 86
            60 - 79% = 1
            80 - 99% = 0

    Index T1_S02_S01 (2)
        Root page: 206, depth: 2, leaf buckets: 87, nodes: 50005
        Average node length: 3.02,  total dup: 50000, max dup: 50000 
        Average key length: 2.02, compression ratio: 4.96
        Average prefix length: 9.98, average data length: 0.02
        Clustering factor: 1, ratio: 0.00
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 0
            40 - 59% = 86
            60 - 79% = 1
            80 - 99% = 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.
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.
Database "/var/db/fb30/tmpidxupd.fdb"
Database header page information:
        Flags                   0
        Generation              35
        System Change Number    0
        Page size               4096
        ODS version             12.0
        Oldest transaction      25
        Oldest active           23
        Oldest snapshot         23
        Next transaction        26
        Sequence number         0
        Next attachment ID      18
        Implementation          HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Apr 3, 2014 13:39:33
        Attributes

    Variable header data:
        Sweep interval:         20000
        *END*


Database file sequence:
File /var/db/fb30/tmpidxupd.fdb is the only file

Analyzing database pages ...
T1 (132)
    Primary pointer page: 183, Index root page: 187
    Total formats: 1, used formats: 1
    Average record length: 21.00, total records: 5
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 20.00, compression ratio: 0.95
    Pointer pages: 1, data page slots: 1
    Data pages: 1, average fill: 5%
    Primary pages: 1, full pages: 0, swept pages: 0
    Fill distribution:
         0 - 19% = 1
        20 - 39% = 0
        40 - 59% = 0
        60 - 79% = 0
        80 - 99% = 0

    Index RDB$PRIMARY9 (0)
        Root page: 201, depth: 1, leaf buckets: 1, nodes: 5
        Average node length: 4.40, total dup: 0, max dup: 0
        Average key length: 3.00, compression ratio: 0.60
        Average prefix length: 0.60, average data length: 1.20
        Clustering factor: 1, ratio: 0.20
        Fill distribution:
             0 - 19% = 1
            20 - 39% = 0
            40 - 59% = 0
            60 - 79% = 0
            80 - 99% = 0

    Index T1_S01_S02 (1)
        Root page: 208, depth: 2, leaf buckets: 87, nodes: 50005
        Average node length: 3.02,  total dup: 50000, max dup: 50000 
        Average key length: 2.02, compression ratio: 4.96
        Average prefix length: 9.98, average data length: 0.02
        Clustering factor: 1, ratio: 0.00
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 0
            40 - 59% = 86
            60 - 79% = 1
            80 - 99% = 0

    Index T1_S02_S01 (2)
        Root page: 206, depth: 2, leaf buckets: 87, nodes: 50005
        Average node length: 3.02,  total dup: 50000, max dup: 50000 
        Average key length: 2.02, compression ratio: 4.96
        Average prefix length: 9.98, average data length: 0.02
        Clustering factor: 1, ratio: 0.00
        Fill distribution:
             0 - 19% = 0
            20 - 39% = 0
            40 - 59% = 86
            60 - 79% = 1
            80 - 99% = 0

Почему для индексов остались прежние значения total dup & max dup ? Он же собрать должен был старые версии ключей, разве нет ?
...
Рейтинг: 0 / 0
03.04.2014, 13:59:17
    #38604257
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
ТаблоидОн же собрать должен был старые версии ключей, разве нет ?
Он может собрать только те ключи, которые есть в записях на диске. Если в индексе есть
"потерянные" ключи, он их собрать не может. Нет способа найти в индексе "все ключи,
принадлежащие данной записи".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.04.2014, 14:09:04
    #38604273
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Dimitry SibiryakovОн может собрать только те ключи, которые есть в записях на диске. Если в индексе есть "потерянные" ключи, он их собрать не может. Нет способа найти в индексе "все ключи,
принадлежащие данной записи".Гм... значит, чтобы гстат стал выдавать адекватное кол-во дубликатов, нужен только b/r ?.. :'(
...
Рейтинг: 0 / 0
03.04.2014, 14:11:12
    #38604278
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Таблоидзначит, чтобы гстат стал выдавать адекватное кол-во дубликатов, нужен только
b/r ?..
Нет, достаточно перестроить индекс с помощью alter index active.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.04.2014, 14:11:34
    #38604279
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Таблоид,

можно попробовать пересоздать индекс
...
Рейтинг: 0 / 0
03.04.2014, 14:13:53
    #38604283
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
тогда вопрос к dimitr'у: а оптимизатор в ФБ-3 учитывает как-то max dup & total dup ?
...
Рейтинг: 0 / 0
03.04.2014, 14:17:39
    #38604294
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Таблоид,

дык при подсчёте селективности должен
...
Рейтинг: 0 / 0
03.04.2014, 14:22:07
    #38604302
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Таблоидоптимизатор в ФБ-3 учитывает как-то max dup & total dup ?
В любом случае, такие дубликаты не возникают в мейнстриме. Они возможны только у
извращенцев, которые используют update in place или меняют значение проиндексированного
поля туда-сюда-обратно.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.04.2014, 14:41:58
    #38604335
NickDee
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Dimitry SibiryakovТаблоидоптимизатор в ФБ-3 учитывает как-то max dup & total dup ?
В любом случае, такие дубликаты не возникают в мейнстриме. Они возможны только у
извращенцев, которые используют update in place или меняют значение проиндексированного
поля туда-сюда-обратно.

Предлагаю забить на извращенцев. А извращенцами считать всех, кто не руководствуется стереотипами DS :) При изменении количества и качества стереотипов DS можно пересматривать набор извращенцев. Таким образом у DS будет прямое влияние на количество извращенцев, и он сможет легко изменить их количество в ту или иную сторону просто изменив набор своих стереотипов :)
...
Рейтинг: 0 / 0
03.04.2014, 15:03:04
    #38604377
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
NickDeeА извращенцами считать всех, кто не руководствуется стереотипами DS :)
Ну-ну... Поведай нам, милое дитя: зачем ты изменяешь значение проиндексированного поля
несколько раз в одной транзакции? Не можешь решить какое значение - правильное?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.04.2014, 15:47:18
    #38604454
NickDee
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Dimitry SibiryakovNickDeeА извращенцами считать всех, кто не руководствуется стереотипами DS :)
Ну-ну... Поведай нам, милое дитя: зачем ты изменяешь значение проиндексированного поля
несколько раз в одной транзакции? Не можешь решить какое значение - правильное?..

В триггерах обслуживающих репликацию, при update записи:
Код: sql
1.
2.
update repl_data set editdatetime = current_timestamp, recordversion = gen_id(rec_version_id, 1)
where (tableid = :tableid) and (recordid = :recordid)


В табличке более миллиона записей. По recordversion есть индекс.
Вытягиваю только последние обновления таким запросом:
Код: sql
1.
select * from repl_data where recordversion > :lastrecordversion order by recordversion



Вот ты в натуре на собеседника вешаешь проекцию "ребёнок, которого нужно упрекнуть и научить". Не надо вешать её :)
...
Рейтинг: 0 / 0
03.04.2014, 16:07:39
    #38604484
DarkMaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Dimitry SibiryakovНу-ну... Поведай нам, милое дитя: зачем ты изменяешь значение проиндексированного поля
несколько раз в одной транзакции? Не можешь решить какое значение - правильное?..


Кстати, имеет место быть. В сложных триггерных цепочках что-то такое...

Триггер 1:
NEW.UPDATE_RULE=1;

Триггер 2:

if (NEW.UPDATE_RULE=1) then ....
else

Триггер 3:
NEW.UPDATE_RULE=2;

Триггер N:
NEW.UPDATE_RULE=1;
...
Рейтинг: 0 / 0
03.04.2014, 16:22:49
    #38604504
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
DarkMaster,

ты не путай. В триггере при присваивании NEW.UPDATE_RULE ничего не меняется (ни сами записи, ни индексы). И сколько бы ты раз их не переприсваивал на диск уйдёт только последнее значение, в отличии от многократных UPDATE одной и той же записи
...
Рейтинг: 0 / 0
03.04.2014, 16:36:47
    #38604526
DarkMaster
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Симонов Денис,

Гм, таки да , погорячился...
...
Рейтинг: 0 / 0
03.04.2014, 18:01:36
    #38604652
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
NickDeeВ триггерах обслуживающих репликацию, при update записи:
Во-первых, и в этом случае для получения update in place нужно чтобы запись с данным
tableid-recordid изменилась несколько раз за одну транзакцию . И вопрос остаётся
прежним - "зачем"?

Во-вторых, в данном случае полям присваиваются каждый раз новые значения и для получения
потерянных нод в индексе надо чтобы сервер рухнул, не завершив транзакцию.

И в-третьих, я никакую проекцию не вешаю, мне действительно интересен вопрос "зачем?"
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.04.2014, 19:15:21
    #38604745
NickDee
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Dimitry SibiryakovNickDeeВ триггерах обслуживающих репликацию, при update записи:
Во-первых, и в этом случае для получения update in place нужно чтобы запись с данным
tableid-recordid изменилась несколько раз за одну транзакцию . И вопрос остаётся
прежним - "зачем"?

Представь себе триггер, который меняет оперативный остаток.
Представь себе появление в БД десятков тысяч документов в одной транзакции (например импортом из 1С в конце дня), и соответственно с ненулевыми шансами на апдейт одной и той же записи в таблице остатков по товару.

Dimitry SibiryakovВо-вторых, в данном случае полям присваиваются каждый раз новые значения и для получения потерянных нод в индексе надо чтобы сервер рухнул, не завершив транзакцию.

Ну вот ты сам как думаешь, как будет правильно? Если бы это была твоя БД, которую ты поддерживаешь?
Какие для тебя потенциальные последствия как для пользователя БД? Деградация производительности? Вводящие в заблуждение цифры в статистике по индексам?
...
Рейтинг: 0 / 0
03.04.2014, 19:22:01
    #38604753
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
NickDeeПредставь себе триггер, который меняет оперативный остаток.
Не, хоть убей, не получается у меня представить проиндексированный оперативный остаток.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.04.2014, 19:22:02
    #38604754
Таблоид
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
NickDeeредставь себе появление в БД десятков тысяч документов в одной транзакции (например импортом из 1С в конце дня), и соответственно с ненулевыми шансами на апдейт одной и той же записи в таблице остатков по товару.Мну кажется, что после загрузки 10 тыс документов пересчет статистики по индексам - просто необходим, по-любому.
...
Рейтинг: 0 / 0
03.04.2014, 19:41:03
    #38604774
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
ТаблоидПочему для индексов остались прежние значения total dup & max dup ? Он же собрать должен был старые версии ключей, разве нет ?См сюда 15806327
...
Рейтинг: 0 / 0
03.04.2014, 19:56:45
    #38604785
NickDee
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Dimitry SibiryakovNickDeeПредставь себе триггер, который меняет оперативный остаток.
Не, хоть убей, не получается у меня представить проиндексированный оперативный остаток.

Это странно, обрати на это внимание :) Ведь я тебе выше описал триггер на репликацию. Этот триггер висит на таблице оперативных остатков, и меняет индексированное поле recordversion.
...
Рейтинг: 0 / 0
03.04.2014, 20:00:06
    #38604789
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
NickDeeВедь я тебе выше описал триггер на репликацию. Этот триггер висит на таблице
оперативных остатков, и меняет индексированное поле recordversion.

Ты реплицируешь хранимый агрегат вместо первички? Или, не дай бог, вместе с первичкой???
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.04.2014, 20:02:54
    #38604795
NickDee
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
ТаблоидМну кажется, что после загрузки 10 тыс документов пересчет статистики по индексам - просто необходим, по-любому.
Когда в таблице миллион записей и каждая запись обладает уникальным значением в поле F, то при обновлении значения в этом поле статистика не меняется, сколько бы раз оно не обновлялось. Если я правильно понимаю.
...
Рейтинг: 0 / 0
03.04.2014, 20:19:18
    #38604810
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
NickDee то при обновлении значения в этом поле статистика не меняется
вопрос, что считать статистикой. То, что использует оптимизатор - rdb$index.rdb$statistics это 1/(keys-dup), фиксируется только после создания индекса или set statistics.
если про gstat, то там идет просчет индекса в его текущем состоянии. А селективность можно посчитать в любой момент, самостоятельно, если знать кол-во ключей и кол-во повторов ключей.
...
Рейтинг: 0 / 0
03.04.2014, 20:37:02
    #38604823
NickDee
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Dimitry SibiryakovNickDeeВедь я тебе выше описал триггер на репликацию. Этот триггер висит на таблице
оперативных остатков, и меняет индексированное поле recordversion.

Ты реплицируешь хранимый агрегат вместо первички? Или, не дай бог, вместе с первичкой???

Хранимый агрегат я могу не реплицировать, но при этом буду реплицировать другие поля этой же таблицы. Это задаётся правилами синхронизации.
И зачем ты привязался к частному случаю? :)
...
Рейтинг: 0 / 0
03.04.2014, 20:41:50
    #38604829
NickDee
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
kdvNickDee то при обновлении значения в этом поле статистика не меняетсявопрос, что считать статистикой.
Имхо Таблоид говорит про set statistics.
...
Рейтинг: 0 / 0
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ? / 25 сообщений из 35, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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