Родилась тут такая хотелка чтобы базу данных можно было переводить базу данных в shutdown из скрипта




Так было бы удобно накатывать скрипты без предварительного использования gfix или сервисов.
Хотелось бы выслушать мнения, если будут положительные запулю в трекер.

Пожалуй с режимами я переборщил. Если команду сократить до



и использовать при этом только FORCE и режим SINGLE

а для



режим NORMAL

dimitrчто делать с ранее закешированными этим коннектом объектами, незакоммиченными транзакциями и т.д.
то же самое что и при gfix -shut single -force 0
только своё соединение либо восстанавливать либо как то сохранять

Таблоидя после gfix -shut вызываю gstat -h | grep -i "attributes" и проверяю состояние.

дык ассинхронность шатдауна вроде правилась недавно, так что он не вернёт управление ОС пока не завершится. Тоже самое должно быть и с оператором.

ТаблоидИ если не так, то quit с выдачей errorlevel'a.
Как ты будешь это делать ?

А вот здесь действительно интересно. Вроде force должно быть всё равно, но даже если будет какая то ошибка, то скорее всего отображать её и просто рвать текущее соединение.

я имел ввиду вот такую ситуацию




dimitrкроме того, мне интересно, что делать при ошибке в скрипте обновления базы. Она останется в шатдауне? Кто и как будет ее возвращать в онлайн? Если все равно gfix-ом, то нафига козе баян?
если SHUTDOWN выполняется как gfix -shut single -force 0 то никто не помешает сделать вот так

dimitrвообще, если следовать внутренней реализации шатдауна и максимально соответствовать GFIX-у, то опция шатдауна должна быть у команды CONNECT. Но это означает, что это будет фича утилиты ISQL, а не языка SQL.
ну это было бы неплохо, пусть только и в ISQL

понял, бесперспективно.
Хотя в ISQL можно сделать отдельные команды (только не CONNECT), которые позволяли бы делать эти действия. А что касается других инструментов (типа IBEScript), то они если захотят реализуют у себя аналоги.

dimitr,

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



в начале скрипта позволяет сделать первую часть, но не гарантирует что посереди выполнения моего скрипта кто нибудь не влезет и не обломит его.
Сейчас для этого есть штатный механизм gfix -shut single -force 0, но для него требуется дополнительно перед накаткой скрипта подсоединяться к сервису. Кроме того после его накатки необходимо присоединиться ещё раз чтобы вернуть базу в ONLINE.

dimitrчто делать с ранее закешированными этим коннектом объектами, незакоммиченными транзакциями и т.д.

транзакции откатывать и сбрасывать кэш метаданных (если это возможно)

P.S. Идея возникла не на пустом месте, а из того как это реализовано в Oracle (хотя там это не для того чтобы накатывать обновления). Вот и подумалось, что у нас можно сделать примерно такое же. Ну про нюансы я конечно не подумал.

dimitrвариант с ССЗБ лично мне нравится больше :-)
Кстати да. На первый взгляд это ничем не грозит. Просто оператор ALTER DATABSAE SHUTDOWN не выполнится и бросит ошибку, а дальнейший скрипт если он не может выполнится не выполнится, т.е. будет вести себя так как будто этого оператора и не было.

NikolayV81так в оракле проще по причине того что любое изменение метаданных = commit
для FB пофиг, ибо даже если сделать также (SET AUTODDL ON), то всё равно для метаданных в ISQL стартуется отдельная транзакция.