ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
25 сообщений из 35, страница 1 из 2
  1  все
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
    #38604248
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
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:53:21
| Ответить | Цитировать | Написать  
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
    #38604257
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
ТаблоидОн же собрать должен был старые версии ключей, разве нет ?
Он может собрать только те ключи, которые есть в записях на диске. Если в индексе есть
"потерянные" ключи, он их собрать не может. Нет способа найти в индексе "все ключи,
принадлежащие данной записи".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.04.2014, 13:59:17
| Ответить | Цитировать | Написать  
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
    #38604273
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Dimitry SibiryakovОн может собрать только те ключи, которые есть в записях на диске. Если в индексе есть "потерянные" ключи, он их собрать не может. Нет способа найти в индексе "все ключи,
принадлежащие данной записи".Гм... значит, чтобы гстат стал выдавать адекватное кол-во дубликатов, нужен только b/r ?.. :'(
...
Рейтинг: 0 / 0
03.04.2014, 14:09:04
| Ответить | Цитировать | Написать  
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
    #38604278
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоидзначит, чтобы гстат стал выдавать адекватное кол-во дубликатов, нужен только
b/r ?..
Нет, достаточно перестроить индекс с помощью alter index active.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.04.2014, 14:11:12
| Ответить | Цитировать | Написать  
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
    #38604279
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

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

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

Предлагаю забить на извращенцев. А извращенцами считать всех, кто не руководствуется стереотипами DS :) При изменении количества и качества стереотипов DS можно пересматривать набор извращенцев. Таким образом у DS будет прямое влияние на количество извращенцев, и он сможет легко изменить их количество в ту или иную сторону просто изменив набор своих стереотипов :)
...
Рейтинг: 0 / 0
03.04.2014, 14:41:58
| Ответить | Цитировать | Написать  
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
    #38604377
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
NickDeeА извращенцами считать всех, кто не руководствуется стереотипами DS :)
Ну-ну... Поведай нам, милое дитя: зачем ты изменяешь значение проиндексированного поля
несколько раз в одной транзакции? Не можешь решить какое значение - правильное?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
03.04.2014, 15:03:04
| Ответить | Цитировать | Написать  
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
    #38604454
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
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, 15:47:18
| Ответить | Цитировать | Написать  
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
    #38604484
Фотография DarkMaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DarkMaster
Участник
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:07:39
| Ответить | Цитировать | Написать  
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
    #38604504
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
DarkMaster,

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

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

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

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

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

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

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

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

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

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

Хранимый агрегат я могу не реплицировать, но при этом буду реплицировать другие поля этой же таблицы. Это задаётся правилами синхронизации.
И зачем ты привязался к частному случаю? :)
...
Рейтинг: 0 / 0
03.04.2014, 20:37:02
| Ответить | Цитировать | Написать  
gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
    #38604829
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NickDee
Участник
kdvNickDee то при обновлении значения в этом поле статистика не меняетсявопрос, что считать статистикой.
Имхо Таблоид говорит про set statistics.
...
Рейтинг: 0 / 0
03.04.2014, 20:41:50
| Ответить | Цитировать | Написать  
25 сообщений из 35, страница 1 из 2
  1  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gfix -sweep, выполняемый в монопольном коннекте, не выправляет total dup & max dup. Why ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38604302&tid=1563748]:
 0ms
get settings:
 5ms
get forum list:
 8ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 182ms
get topic data:
 5ms
get forum data:
 3ms
get page messages:
 37ms
get tp. blocked users:
 1ms
others: 200ms
total:  445ms
созд. / загр.: 445ms
x
x
Закрыть


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