Всем доброго дня,

FB2.5
есть скрипт обновления версии базы данных, запускается из delphi (firedac).
Хочется выполнять его в рамках одной транзакции дабы если что не так всё откатить назад.
В скрипте есть, к примеру добавление полей в таблицу, потом вставка записей в эту таблицу или создание хранимой процедуры использующих добавленное поле и выполнение этой хранимой процедуры итп
Есть ли возможность выполнить все эти действия в рамках одной транзакции, без промежуточных коммитов? Дабы при попытке внесения данных в таблицу с добавленным полем не вываливало исключение что такого поля нет итп Как добиться атомарности всего обновления?

Спасибо

Мимопроходящий,

есть ли тогда другая возможность добиться атомарности обновления?
Есть же какои то механизм работы через Delta файл при резервном копировании.

скажем искуственно инициировать работу через delta файл а потом в случае успеха слить его с базой или отбросить. Или при работе через delta файл операции с метаданными запрещены?

Бэкап перед обновлением.

это по любому

или, допустим, есть же тип транзакций который позволяет видеть изменения которые ещё не зафиксированы коммитом в других транзакциях. Если представить себе 2 таких транзакции. Одна делает изменение метаданных но не делает коммит, вторая позднее вносит данные в таблицу и в случае проблем обе делают роллбак в обратном порядке.

Dimitry Sibiryakov,

жалко, было бы удобно :/

интересно было бы почитать что то об этом

я подписан, но там чёрт ногу сломит. В кой хоть версии примерно такое было возможно? или всё дальше альфы не поднималось?

Dimitry Sibiryakov,

интересно было бы если бы разработчики тут ещё что то сказали. В чём возникли когда то проблемы, есть ли такое в планах итп.

т.е. только с порчей базы, по нормальному и не работало

Dimitry Sibiryakov,

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

Спасибо за информацию.

единственное по повору delta файла, когда работа ведётся через него, скорее всего обновление метаданных тоже невозможно? Что бы уж была полная картина.
Хотя конечно сомнительно что в delta файле хранятся и изменения в метаданных.
Интересно было бы почитать что то более подробное про механизм его работы.

тут пишут про эволюцию nbackup
В частности:
ibphoenixDelta file contains:
– Changed database pages
– Mapping table between delta and database

означает ли это что всётаки можно вносить изменения.
Надо попробовать.

т.е. если перед обновлением выдать команду
ALTER DATABASE BEGIN BACKUP
после чего всё начинает писаться в дельту
далее сделать обновление и если всё удачно выполнить
ALTER DATABASE END BACKUP
а если нет то что?
как отказаться от слияния с delta?

kdv,

если так делать то как потом разблокировать?
например сделал ALTER DATABASE BEGIN BACKUP
сделал изменения в данных
вырубил firebird
убрал в сторону delta файл
теперь при попытке соединиться вываливает
iSQLStatement failed, SQLSTATE = 08001
I/O error during "CreateFile (open)" operation for file "D:\MIKSRC\DB\APTM.FDB.delta"
-Error while trying to open file
-Das System kann die angegebene Datei nicht finden.

попробовать подсунуть delta нулевого размера (пустую)?

тогда получаем:
iSQLStatement failed, SQLSTATE = 08001
I/O error during "ReadFile" operation for file "D:\MIKSRC\DB\APTM.FDB.delta"
-Error while trying to read from file
-Ende der Datei (EOF) erreicht.
-internal Firebird consistency check (Can't actualize alloc table)

получается надо слепить delta файл без изменений и его подсовывать

тут правда встаёт вопрос годится ли эта дельта для всех случаев позднее или нет.
Можно конечно сначала делать дельту пустую, потом вырубать сервер её откладывать в сторону потом опять пускать сервер, сливать с ней, опять переводить в backup режим, делать обновление и если надо опять выключать но подсовывать первую delta в которой нет изменений. Шас попробую

такой трюк помогает с базой соединиться
но при попытке выдать команду:
ALTER DATABASE END BACKUP
получаем:
This operation is not defined for system tables.
unsuccessful metadata update.
ALTER DATABASE failed.
Database is not in the physical backup mode.
------------------------------------------------
SQLCODE: -607
SQLSTATE: 42000
GDSCODE: 335544351

Останавливаем FB опять, подсовываем обратно вторую дельту (с изменениами) и
ALTER DATABASE END BACKUP
проходит без проблем

означало ли это сообщение что можно теперь эту (первую, без изменений) дельту просто выкинут и работать дальше? Почему тогда в последствии при подсовывании последней delta (с изменениями) команда ALTER DATABASE END BACKUP прошла нормально?
если выдать команду ALTER DATABASE END BACKUP когда база не находится в Backup режиме сообщение получаем точно такое же.

Получается надо почитать документацию по nbackup. И после этого немного подумать мозгом на
тему "чем твои телодвижения отличаются от "сделать бэкап перед операцией, восстановить его
при неудаче"".

это понятно, просто хотелось разобраться в принципе возможно такое или нет используя delta файл.
Сейчас попробовал все варианты, получается пока не подсунешь правильную (последнюю) delta ничего не получается. Где то в системных таблицах сохраняется или ID этой delta или что то подобное. Можно конечно копать в сторону подмены этого ID в системных таблицах, не факт правда что это получится и туда есть доступ.
По идее тут должно помочь решение когда delta утеряна, испорчена итп.
Есть такое?

короче можно так:
1. Переводим базу в режим резервного копирования (все изменения идут в delta файл) командой ALTER DATABASE BEGIN BACKUP
2. Делаем обновление итп всё что нужно
3. Если всё хорошо выходим из режима резервного копирования и сливаем дельту с базой командой ALTER DATABASE END BACKUP
4. Если по каким либо причинам надо откатить изменения
5. Останавливаем FB
6. Переносим delta файл в безопасное место (на всякий случай)
7. Запускаем FB
7. Запускаем nbackup.exe -F <база данных> это удалит ссылку на дельту в базе и разблокирует её.
Далее всё в обычном режиме, сейчас проверил, работает как задумано.
Побочных эффектов не замечено.
Было бы интересно узнать что конкретно делает nbackup с ключём -F и можно ли это сделать без nbackup напрямую запросами в FB.

п.с. конечно, правильно всё делать через резервную копию, никто не спорит. Но такое решение тоже работает. Опять же если у когото тупо убита delta это поможет вернуть базу в работу, хоть и с потерей данных из delta (не всегда потерянные данные так важны).

согласен, конечно сначала всех отсоединить, но это как бы понятно думаю было.
Кстати эксперементировал с FB 3
надо будет ещё с 2.5 проверить.

Только не говори, что в документации к nbackup это не написано...

да, есть, но как менять эти флаги запросами непонятно. В доке по FB они даже не упоминаются (по крайней мере я пока не нашел):
nbackupWithin the file, the state flag is changed from locked (nbak_state_stalled) to normal
(nbak_state_normal);

опять же nbackup -F работает на файловом уровне а не через сервер.

я же писал вверху что если просто удалить delta то потом с базой нельзя соединиться, и ошибку привёл. А чтобы выполнить ... end backup надо по меньшей мере сначала соединиться с базой. Для этого перевести её в normal режим. Или я что то недопонимаю? ALTER DATABASE END BACKUP снаружи ведь выполнить нельзя, даже параметра "файл базы данных" нет.

Dimitry Sibiryakov,

согласен, читаю сейчас.

Поправка - запускать FB перед запуском nbackup -F ненужно, он работает с файлом базы напрямую.

Прочитал, кстати, спасибо kdv за перевод.

Информации по изменению флага средствами FB так и не нашел. То что nbackup правит его на
файловом уровне, без участия FB ведь не значит что сам FB не может менять его тоже. Поэтому этот вопрос пока остаётся открытым.

Небольшое дополнение ко всей этой истории.
Дело в то что размер базы данных бывает очень большим, у некоторых клиентов исчисляется терабайтами. Люди которым приходится делать обновление у клиентов вынуждены работать по ночам и выходным (дабы не останавливать фирмы на время обновления). Резервная копия (инкрементная) к моменту начала обновления всегда уже существует, но что бы её накатить нужны часы, иногда ночи недостаточно. Поэтому давно витала идея как то эту проблему обойти. Если работать через дельту то откат можно произвести в течении минут, при этом на крайний случай конечно иметь резервную копию. Со спеца снимается временное давление и он сможет спокойно решить проблему и накатить обновление снова. Более того успеть обслужить нескольких клиентов.
Поэтому спасибо всем за советы и за критику. Хотелось бы ещё услышать аргументы против такого решения, где это может споткнуться. Например возможна ли ситуация при работе с дельтой когда что то может пойти не так как предполагается (с точки зрения обновления метаданных итп). То что нормальная резервная копия есть это как бы подразумевается.

Спасибо

проблема в том что клиенты очень разношерстные. Есть большие конторы а есть совсем маленькие шарашкины конторы. Если для больших заморачиваться с репликачией может и имеет смысл то с маленькими это только лишний гемморой и траты. Тут порой даже проблема тупо в дисковом пространстве встаёт, у клиента не оказывается под рукой достаточно дискового пространства что бы сделать резервную копию в процессе обновления и потом её использовать. Бызы порой здоровенные (даже у маленьких контор), тупо их копировать уже куча времени. Поэтому вариант с delta и муссируется. Мы не можем сказать клиенту "пока то и то не сделаешь обновление не получишь". Все они платят денюжку и конечная цель что бы и дальше её исправно и вовремя платили. Клиентов конечно предупреждают если видят проблемы но конечный выбор остаётся за клиентом. К тому же маленькие конторы не всегда могут позволить себе многочассовую поддержку при обновлении, дорогое железо и своих спецов. Поэтому приходится выкручиваться как можем. Пока получается.

другими словами останавливать FB необязательно? достаточно запустить nbackup -F .... при работаюшем FB не запуская gfix для shutdown и он отпустит deltа файл и переключится в режим normal?