Добрый день!

Ситуация в принципе ожидаемая, но тем не менее не ожидал такого значения времени исполнения.

1. FB 2.5 Имеем таблицу 20 млн записей. 6 полей.
2. Добавляем поле integer
3. Инициализируем поле значением.
выполнение этой операции заняло 3 часа. FW=OFF

Делаем после добавления поля backup/restore инициализация поля 96 секунд.

kdvbazilio77инициализация поля
имеется в виду update?

Вообще до и после таких операций надо gstat -r делать, а если только конкретная таблица, то и -t.
Но поскольку все это случается уже после того как - "мы сделали, а почему так получилось", то уже поздно.

С другой стороны, как-то я не очень верю, что update 20млн записей после рестора проходит за 1 мин 36 секунд.
Надо было наверное дополнить условия задачи.

Вся эта ситуация проявляется при процедуре обновления БД.
Наш сценарий обновления БД:

1. Резервное копирование средствами файловой системы
2. backup/restore
3. Прокручиваем кучу DDL и DML
4. backup/restore

Что происходит с этой таблицей.

1. Создается
2. Вставляется 20 млн записей из других таблиц
3. Создаются индексы
4. update всех записей по одному полю
5. возня удалили добавили, изменили довольно много
т.к между пунктом 1 и 6 куча ревизий с корректировкой данных в таблице
6. Добавили поле Integer
7. update

3 часа

если backup/restore

Statement executed in 96391 ms.
Updates: 17684077 Deletes: 0 Inserts: 0 Selects: 17684077.

[quot bazilio77]kdvпропущено...

если backup/restore

Statement executed in 96391 ms.
Updates: 17684077 Deletes: 0 Inserts: 0 Selects: 17684077.

если backup/restore перед добавлением поля то 110 секунд

Dimitry Sibiryakovbazilio775. возня удалили добавили, изменили довольно много т.к между пунктом 1 и 6 куча ревизий с
корректировкой данных в таблице
6. Добавили поле Integer

Сделать п.6 сразу после п.1 совсем не судьба?..


Нет не судьба. Т.к. скрипт инкрементальный делаем новую версию бд пишем как перевести бд из текущей версии в следующую,
разница между 1 и 6 несколько лет.
Просто у одного из клиентов нужно было обновить версию 2008 года.

Симонов Денисbazilio77,

проделай эту операцию с выключенной сборкой мусора
Не совсем понял это как?

Симонов Денисbazilio77,

isc_dpb_no_garbage_collect

Не помогает. Только хуже получается, лезут очень интересные ошибки:

CREATE SEQUENCE RCPREP_GEN;

alter table RCPREP
add concentrated BOOL default 0,
add RCPREP_ID ID;

update rcprep
set rcprep_id = gen_id(rcprep_gen, 1),
concentrated = iif(conc_pct <> 0, 1, 0);

Statement executed in 2500 ms.
Updates: 283446 Deletes: 0 Inserts: 0 Selects: 283446.

ALTER TABLE RCPREP
DROP CONSTRAINT RCPREP_PK,
ADD CONSTRAINT UNQ1_RCPREP UNIQUE (RCP_ID,RAW_ID);

ALTER TABLE RCPREP
ADD CONSTRAINT PK_RCPREP PRIMARY KEY (RCPREP_ID);

*** error ***
FAILED: The insert failed because a column definition includes validation constraints.Validation error for column RCPREP_ID, value "*** null ***".

Исходя из скрипта, такой ошибки не должно быть!
Убираем sc_dpb_no_garbage_collect все нормально.

При выполнении скрипта автокоммит после каждого выражения.

kdvbazilio77,

это сто лет как известная фишка, в первую очередь при "переиспользовании" значений ПК

" Possible scenario:

tx1: insert key 1
tx1: rollback
tx2: insert key 1

violation of PRIMARY or UNIQUE KEY constraint "

insert в tx2 не собирает мусор от tx1, а ПК видит ключи от всех транзакций.

Это хорошо. Но в сухом остатке получаем что пока только backup/restore в критичных точках большого
может его ускорить.

hvladbazilio77Но в сухом остатке получаем что пока только backup/restore в критичных точках большого
может его ускорить.Свип сделай перед "большим"
Свип из скрипта? "большой" значило большой скрипт.

hvladbazilio77Свип из скрипта?Ну бекап-рестор "из скрипта" тебя же не смущает ?

И я так и не понял - ты обратил внимание, что CORE-5110 исправлен в 2.5.6 ?

Вопрос про свип был - есть ли стандартные средства по его вызову из скрипта.
Расширить скрипт новым словом sweep_database не проблема..
Попробовал судя по всему свип не помогает, все равно update очень долго.


Сейчас проверил 2.5.7.27050 embedded c no_garbage_collect
The insert failed because a column definition includes validation constraints.
validation error for column RCPREP_ID, value "*** null ***".

hvlad,

Попробуй этот скрипт с no_garbage_collect, 2.5.7 не работает
Invalid insert or update value(s): object columns are constrained - no 2 table rows can have duplicate column values.
violation of PRIMARY or UNIQUE KEY constraint "PK2" on table "T".

проблема в delete

recreate table t (
id1 int not null,
id2 int,
constraint pk1 primary key (id1)
);
commit;

set term ^;

execute block as
declare i int = 0;
begin
while (i < 1000000) do
begin
insert into t (id1, id2) values (:i, :i + 200);
i = i + 1;
end
end
^

set term ;^

commit;

delete from t
where id1 < 10000;

alter table t add n int default -1 not null;
commit;

update t set n = id1;
commit;

alter table t drop constraint pk1;
commit;

alter table t add constraint pk2 primary key (n);
commit;

hvlad,



Но самое интересное что мой скрипт на моей базе выдает
validation error for column value "*** null ***"

Могу выслать бд и скрипт