|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
Народ, а расскажите что вы делаете, если надо произвести alter table (структуру или триггер) для "горячей" таблицы, к которой ежесекундно единицы и десятки запросов ? У нас приходится переходить в singe-user mode, что ухудшает показатели SLA. Сидим, чешем репу - то ли как-то залочить эту таблицу, то ли делать на другом сервере, и как-то потом транзакции накатывать... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2015, 20:37 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
вариант - отличный SET ENVIRONMENT FORCE_DDL_EXEC '1' ; ALTER ... но предназначен не для всех ALTER вариант - никуда-не-спешим while true; do dbaccess xxx < alter.sql; sleep 3; done и вешается на ночь. к утру обычно додалбливается вариант срочный onmode -jy;onmode -m; dbaccess xxx < alter.sql у нас прикладной уровень умеет сам реконнектиться и всё прокатывает - он не успевает приконнектится и dbaccess успевает занять таблицу ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2015, 22:12 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
Для in-place-alter можно предложить вариант с переходом в single-user-mode во время maintance-window (нерабочие часы). Отрабатывает за секунду и показатели SLA ухудшаются незначительно. Если in-place-alter неприменим, то можно запустить одновременно два скрипта. В первом происходит непосредственно ALTER таблицы, предварительно захватив ее в EXCLUSIVE mode и установив большое время ожидания получения блокировки. Если другие сессии обращаются к этой таблице через DIRTY-READ изоляцию, нужно установить переменную окружения IFX_DIRTY_WAIT. Во втором скрипте последовательно килляем сессии, которые используют partnum этой таблицы (фрагмента). Естественно, первая сессия тоже будет использовать этот partnum, поэтому ее нужно будет исключить из списка килляемых :). ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2015, 22:38 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
Выбегалло, нашел скрипт, которым пользовался сам. Там есть интересный "dirty trick", который не дает новым сессиям обратиться к таблице. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
На всякий случай напомню еще раз о переменной окружения IFX_DIRTY_WAIT. PS: onstat -g opn предназначен для техсаппорта и формат его вывода может меняться от версии к версии, поэтому задача распарсить его возлагается на вас :) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.12.2015, 23:50 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
Яковлев Павел вариант - отличный SET ENVIRONMENT FORCE_DDL_EXEC '1' ; ALTER ... но предназначен не для всех ALTER судя по документации, FORCE_DDL_EXEC годится только для ALTER FRAGMENT. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2015, 02:15 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
victor16Выбегалло, нашел скрипт, которым пользовался сам. Там есть интересный "dirty trick", который не дает новым сессиям обратиться к таблице. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
На всякий случай напомню еще раз о переменной окружения IFX_DIRTY_WAIT. PS: onstat -g opn предназначен для техсаппорта и формат его вывода может меняться от версии к версии, поэтому задача распарсить его возлагается на вас :) да, надо будет попробовать. Вот тут более подробное описание почему важно использовать IFX_DIRTY_WAIT http://informix-technology.blogspot.com/2006/10/when-exclusive-is-not-really-exclusive.html ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2015, 02:25 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
ВыбегаллоЯковлев Павел вариант - отличный SET ENVIRONMENT FORCE_DDL_EXEC '1' ; ALTER ... но предназначен не для всех ALTER судя по документации, FORCE_DDL_EXEC годится только для ALTER FRAGMENT. фраза "но предназначен не для всех ALTER" об этом и говорит ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2015, 21:38 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
victor16нашел скрипт, которым пользовался сам. Там есть интересный "dirty trick", который не дает новым сессиям обратиться к таблице. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
что будет при обломе сессии между GRANT и REVOKE ? Так и останется таблица в состоянии "prevent new sessions from getting holds on" ? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2015, 21:41 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
Яковлев Павелvictor16нашел скрипт, которым пользовался сам. Там есть интересный "dirty trick", который не дает новым сессиям обратиться к таблице. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
что будет при обломе сессии между GRANT и REVOKE ? Так и останется таблица в состоянии "prevent new sessions from getting holds on" ? Ответ очевиден - в теории транзакция должна откатиться. В реальности зависит от причин облома сессии и последующих действий админа. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2015, 22:14 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
Хм... perl вроде бы и устанавливает IFX_DIRTY_WAIT, но onstat -g env <session> его не видит. Причем если установить в шелле и запустить dbaccess, то IFX_DIRTY_WAIT виден. DBD::Informix правда старенький, 2003 года. Надо поставить новый, от 2015го, и попробовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 10:19 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
Если часто меняются поля - нужно по шее архитекторам давать за непродуманность. С теми же Alter In Place - тоже нужно периодически бороться. Для больших изменений(зависит от приложения) на время изменения таблицы - таблицу переименовывали, а приложению подсовывали минимально наполненную таблицу. В конце таблицы объединяли. Было даже создавали новую таблицу нужной структуры, переносили несколько дней(скорость и репликация иногда несовместимы) в нее данные, а по окончанию подсовывали конечный результат. Но, снова же, большие изменения - это отдельная тема и даже системы 7х24 хоть на какое-то время, да останавливают. Относительно триггеров - возможно использование SPL в триггерах поможет, хотя возможны свои демоны. По килянию сессий, кроме onstat -g opn иногда еще приходится смотреть и по onstat -g stm. Обычно делаем где-то так, как описал Павел. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 14:32 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
яфшуеіЕсли часто меняются поля - нужно по шее архитекторам давать за непродуманность. С теми же Alter In Place - тоже нужно периодически бороться. Система 15 лет живет и развивается. Компания покупает новые продукты, интегрирует их к себе, выводит из оборота старые. Какая непродуманность ? Это жизнь. С большими таблицами понятно, что без downtime не обойтись. Речь идет об изменениях выполняемых за секунды - минуты, но которые на нагруженной системе все равно не проходят без вывода ее в single-user mode. Хочется все же SLA улучшить. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.02.2016, 19:25 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
А что вам дают показатели SLA? Если вы боретесь за SLA, значит у SLA есть какая-то стоимость. Установка обновления - это изменение функционала по требованиям бизнеса, т.е. установка данного функционала должна принести какие-то дивиденты. На активно-используемой 7х24 системе пусть бизнеса и решают - ставить/не ставить, соизмерима ли срочность установки со стоимостью простоя. В любом случае - Single-User или иное принудительное освобождение ресурса - это ЗАПЛАНИРОВАННЫЙ простой определенного бизнес-сервиса(доли секунд, секунды,...). Технически, наверное, каждый раз по своему решается вопрос установки в зависимости от изменений. Но, как по мне, если у вас действительно нет окон, нужно как-то собирать изменения и устанавливать их вместе - SLA будет выше. Когда система развивается, это хорошо :) Вообще хорошо, когда все развивается ... |
|||
:
Нравится:
Не нравится:
|
|||
04.02.2016, 17:52 |
|
как бы так извернуться... alter table online ?
|
|||
---|---|---|---|
#18+
яфшуеіА что вам дают показатели SLA? Если вы боретесь за SLA, значит у SLA есть какая-то стоимость. Установка обновления - это изменение функционала по требованиям бизнеса, т.е. установка данного функционала должна принести какие-то дивиденты. На активно-используемой 7х24 системе пусть бизнеса и решают - ставить/не ставить, соизмерима ли срочность установки со стоимостью простоя. В любом случае - Single-User или иное принудительное освобождение ресурса - это ЗАПЛАНИРОВАННЫЙ простой определенного бизнес-сервиса(доли секунд, секунды,...). Технически, наверное, каждый раз по своему решается вопрос установки в зависимости от изменений. Но, как по мне, если у вас действительно нет окон, нужно как-то собирать изменения и устанавливать их вместе - SLA будет выше. Когда система развивается, это хорошо :) Вообще хорошо, когда все развивается ну естественно, накатываем релизы раз в месяц. Но хотелось бы вообще без downtime. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.02.2016, 23:02 |
|
|
start [/forum/topic.php?fid=44&fpage=4&tid=1606819]: |
0ms |
get settings: |
23ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
58ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
273ms |
get tp. blocked users: |
2ms |
others: | 2679ms |
total: | 3071ms |
0 / 0 |