Перенос доработок на Prod

[Ivanhoe]

Поменяем мега корпорацию на нормальный интернет-магазин или b2b с кучей проверок при создании заказов. Ну вот не понимают клиенты, почему нужен почти час простоя. Днем офис работает, по ночам склад.

[Vadik]

Цитата:

Сообщение от Ivanhoe

Поменяем мега корпорацию на нормальный интернет-магазин

Работал я в одном нормальном интернет магазине (>10K заказов в день). Так там не было синхронной интеграции сайта с AX. И у сайта интеграция (асинхронная) строилась так, что не требовала постоянной доступности AX и прочих внутренних приложений. Люди, которые все это строили, знали толк в извращениях интернет-торговле

Цитата:

или b2b с кучей проверок при создании заказов

Ну, B2B тоже в принципе не предполагает наличия людей, нажимающих кнопку на одной стороне и ждущих когда она "отожмется" на другой, так что за нормально сделанный B2B я спокоен

Цитата:

Если не нужна длинная синхронизация

Вот вы привязались к этой синхронизации. Over 90% всех изменений в схеме данных - это добавление полей и создание/изменение индексов. Эти изменения можно делать на выделенном AOS-е без остановки рабочих AOS-ов и при известной доле везения - без "нахлестов" с работающими пользователями. Не нравится / не получается - значит, Вам для полноценного релиза нужен полноценный простой (и совсем не долгий кстати)

Цитата:

А HA не так уж прям и часто в полный рост настраивают

Часто-часто, особенно мегакорпорпорации На самом деле если будете слишком сильно проталкивать схему с восстановлением model из бэкапа, наживете себе кровников в лице БД админов и они же Вас в случае чего сделают крайним - а оно Вам надо ? Импорт modelstore во временную схему делает в итоге то же самое, а переключение схем работает быстрее чем restore database

[Ivanhoe]

Цитата:

Сообщение от Vadik

Вот вы привязались к этой синхронизации. Over 90% всех изменений в схеме данных - это добавление полей и создание/изменение индексов. Эти изменения можно делать на выделенном AOS-е без остановки рабочих AOS-ов и при известной доле везения - без "нахлестов" с работающими пользователями. Не нравится / не получается - значит, Вам для полноценного релиза нужен полноценный простой (и совсем не долгий кстати)

А можно подробнее, как сделать синхронизацию таблицы SalesLine или CustInvoiceTrans на выделенном AOS при работающих пользователях?

[sukhanchik]

Цитата:

Сообщение от Ivanhoe

А можно подробнее, как сделать синхронизацию таблицы SalesLine или CustInvoiceTrans на выделенном AOS при работающих пользователях?

А сделать это не на выделенном AOS, а в БД, с опцией ONLINE у команды CREATE INDEX? (я говорю конечно же про SQL Server)
Ну т.е. запустили и оно себе работает. Понятное дело - ДБА должны выбрать момент запуска скрипта, но это уже второй вопрос - формально простоя не будет. А АХ уже при обновлении подумает, что этот индекс уже создан.

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

[trud]

Цитата:

Сообщение от sukhanchik

А сделать это не на выделенном AOS, а в БД, с опцией ONLINE у команды CREATE INDEX? (я говорю конечно же про SQL Server)
Ну т.е. запустили и оно себе работает. Понятное дело - ДБА должны выбрать момент запуска скрипта, но это уже второй вопрос - формально простоя не будет. А АХ уже при обновлении подумает, что этот индекс уже создан.

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

Цитата:

ONLINE = ON
В начале операции совмещаемая блокировка (S) удерживается на исходном объекте в течение очень короткого времени. В конце операции на источнике на короткое время удерживается совмещаемая блокировка (S), если создается некластеризованный индекс

[Alexius]

Цитата:

Сообщение от trud

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

В MS SQL 2014 появилась "разруливалка" подобных неприятностей:

Цитата:

...
Но разработчики пошли дальше и добавили ещё несколько полезных параметров для ONLINE операций, а именно параметр low_priority_lock_wait, который позволяет задать интервал ожидания, в случаи блокировки ресурса над которым мы выполняем операцию:

MAX_DURATION = time [MINUTES]

и какое решение необходимо принять по истечению этого интервала:

ABOUT_AFTER_WAIT = [NONE | SELF | BLOCKERS]

NONE - никаких действий (равносильно текущему поведению в SQL Server 2012)
SELF - мы прерываем нашу операцию
BLOCKERS - мы прерываем работу всех процессов, которые нам "мешают"
...

SQL Server 2014: ONLINE операции над отдельными секциями секционированных объектов

PS. Решение не идеальное, но все же ...

[Vadik]

Цитата:

Сообщение от Ivanhoe

А можно подробнее, как сделать синхронизацию таблицы SalesLine или CustInvoiceTrans на выделенном AOS при работающих пользователях?

А что конкретно синхронизуем? ALTER TABLE ADD COLUMN NOT NULL DEFAULT() на SQL 2012 (если мне не изменяет память) EE и выше делается влет (на уровне метаданных). Да, ценник на EE редакцию конский но так оно почти всегда бывает при хотелках enterprise уровня. С индексами - да, возни и накладок больше
Либо - плановая остановка на обслуживание