Репликация SQL на который смотрит АОС

[Индра]

> Для отчётов используется ODBC и отчёты делаются напрямую с SQL сервера, в экселевских файлах, используя DSN. Актуальность данных нужна максимум с отставанием в пол часа. База работает в основном 10х5 но бывает и 10х7 в зависимости от времени года и загруженности предприятия.

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

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

[Alexius]

На сколько я понял используется MS SQL и репликация транзакций. На память при таком раскладе не удастся изменить структуру копии БД вслед за оригиналом, все равно придется делать полный снимок (или полный бэкап) и поверх него уже пойдут транзакции. Для минимизации перерыва в работе могу предложить только использовать две копии, т.е. одна используется для доступа к отчетам и как резерв, а вторая для восстановления репликации после изменения структуры основной БД :
1. Копия 1 - работает как отчетная, Копия 2 - в запасе
2. Внесены изменения в структуру данных основной БД
3. Копия 2 - создаем репликацию с основной БД, Копия 1 продолжает работать
4. Как только на Копии 2 восстановилась БД и заработала репликация - перенастраиваем отчеты на Копию 2, а Копию 1 - выводим в резерв
5. см. п. 5, только Копия 1 и 2 меняются местами

PS 1. Задачу создания горячей резервной копии БД я решал через бэкап/восстановление полное/транзакций.
PS 2. Оперативная отчетность всегда делалась на основном сервере, проблемы с производительностью решались там-же.
PS 3. "Генеральская" отчетность делалась на копии БД, создаваемой ночью, ей высокая оперативность не требовалась. В крайнем случае БД развертывалась руками посредине дня.

[Владимир Максимов]

То, что Вы так хотели услышать, но никто внятно не произнес

Цитата:

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

Вопрос в том как поддерживать актуализированную копию БД при одноранговой репликации? т.к. в основную базу через интерфейс АХ вносятся новые столбцы в таблицы, а они то и не реплицируются. Репликация перестаёт функционировать, потому что структура таблиц не соответствуют друг другу.

Никак. При помощи репликации - это невозможно "в принципе". По нескольким причинам

1. Часть информации, которую надо "реплицировать" в случае изменения структуры данных физически отстуствует в базе данных. Это само приложение Axapta с описанием структуры таблиц.

Т.е. даже если Вы сможете модифицировать структуру в копии базы данных, то при этом "сломаете" уже копию собственно приложения Axapta.

2. Если речь идте об MS SQL, то физически репликация реализуется через триггера, которые "вешаются" на соответствующие таблицы. Но запуск синхронизации в Axapta при изменении структуры таблицы автоматически отключит все триггера. Т.е. по сути, выключит репликацию.

======================================================

Если Вы хотите оставить репликацию, как способ синхронизации баз, то в случае изменения структуры таблиц Вам придется сделать следующее:

1. Отключить (остановить) репликацию
2. Вручную накатить изменения в первой копии Axapta
3. Вручную накатить изменения во второй копии Axapta
4. Заново настроить репликацию (запустить процесс создания триггеров)

======================================================

PS: "Что-то в консерватории надо подправить" (с). У Вас методологическая ошибка. Неправильно организован сам процесс. Впрочем, о разных вариантах Вам уже рассказали.

[gl00mie]

Цитата:

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

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

Немного о поддерживаемых способах репликации написано в заметке Transactional Replication with AX 2009

Цитата:

Сообщение от S.Kuskov

Способ. Настроить оба AOSa на одно и тоже приложение (папку Application). И при изменении приложения через один из AOSов запускать обновление словаря и синхронизацию на другом AOSe.

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

Цитата:

Сообщение от Владимир Максимов

Если речь идте об MS SQL, то физически репликация реализуется через триггера, которые "вешаются" на соответствующие таблицы. Но запуск синхронизации в Axapta при изменении структуры таблицы автоматически отключит все триггера. Т.е. по сути, выключит репликацию.

Не знаю, как на счет триггеров, но убиение на синхронизации тех же индексов, которых нет в приложении, но которые DBA создали в базе, вполне можно обойти за счет того, что возвращать ядру Аксапты из СУБД не всю информацию о метаданных базы.

Цитата:

Сообщение от Индра

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

+1. Вообще, если отчеты создаются прямыми SQL-запросами и не переписываются каждый раз, когда меняется схема данных рабочей базы (мало ли, нафиг в отчетах нужны все новые столбцы?), то непонятно, зачем нужно реплицировать базу 1-в-1. В моем случае отчетность строится в кубах, туда периодически забираются данные из нужных транзакционных/справочных таблиц, на последних просто везде включено поле modifiedDataTime и сделаны индексы по нему, за счет чего можно быстро выбрать измененные и новые данные. Каждую ночь выгружаются изменения за день (это занимает буквально минут 10-15 при базе на порядок больше упомянутых 50-и гигов), на выходных идет полная перекачка. Если нужны данные максимум получасовой давности, так можно и перекачку запускать раз в полчаса - и выкачивать только те столбцы только тех таблиц, которые реально используются в отчетах, а не все подряд. При настроенных индексах все это проходить будет достаточно быстро.

[AndyD]

Цитата:

Сообщение от Владимир Максимов

2. Если речь идте об MS SQL, то физически репликация реализуется через триггера, которые "вешаются" на соответствующие таблицы. Но запуск синхронизации в Axapta при изменении структуры таблицы автоматически отключит все триггера. Т.е. по сути, выключит репликацию.

Это точно не про MS SQL
В нем репликация транзакций делается по журналу транзакций (с помощью Log Reader Agent).

[AndyD]

Цитата:

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

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

А какая версия SQL сервера у вас используется?
В 2008-м ALTER TABLE умеет реплицироваться точно. Судя по документации, 2005-й тоже
Другой вопрос, а использует ли DAX4 эту команду для изменения метаданных?

Насчет размера базы и восстановления из бэкапа.
Можно включить на базе режим восстановления FULL и использовать Log Shipping - все зависит от объема изменений, но, думаю, раз в десять-пятнадцить минут актуализировать данные можно будет. Как минус - на момент заливки бэкапа база будет недоступна

Также, если у вас используется Enterprise версия SQL, то можно настроить зеркалирование и создать Database snapshot.
Если зеркалирование делается в синхронном режиме, то на втором сервере всегда будут актуальные данные.
Достучаться до них можно будет через Snapshot, но так как он показывает срез данных на момент своего создания (которое выполняется очень быстро), то придется периодически его пересоздавать

[Индра]

Также, если у вас используется Enterprise версия SQL, то можно настроить зеркалирование и создать Database snapshot.
Если зеркалирование делается в синхронном режиме, то на втором сервере всегда будут актуальные данные.
Достучаться до них можно будет через Snapshot

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

[AndyD]

Зеркальная база находится в статусе оффлайн до тех пор, пока основная находится в рабочем режиме или ей (основной) не сделали Failover. С этого момента она переходит в рабочий режим и к ней можно обращаться

Что бы к ней все-таки получить доступ в то время, когда она находится в оффлайне, можно воспользоваться снапшотами базы (Database Snapshot) с помощью команды

Create a database snapshot
CREATE DATABASE database_snapshot_name 
    ON 
    (
        NAME = logical_file_name,
        FILENAME = 'os_file_name' 
    ) [ ,...n ] 
    AS SNAPSHOT OF source_database_name

Дальше можно будет обращаться к базе database_snapshot_name - в ней будут находится отзеркалированные данные.
Но, повторюсь, данные будут видны на момент времени создания снимка

Также, этот режим доступен только для энтерпрайз версии сиквела