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

[Alexius]

Цитата:

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

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

На основании вышеизложенного я не понимаю зачем нужно запускать АОС для копии при работающем основном. Если требуется перенести выполнение отчетов на другой сервер, то достаточно изменить настройки соединения. Для резервного восстановления работы при падении основного сервера БД, нужно просто отключить репликацию и перенастроить АОС либо выключить основной и поднять резервный. Все это проделывается руками или скриптами. В чем засада ?

[Marik]

Цитата:

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

На основании вышеизложенного я не понимаю зачем нужно запускать АОС для копии при работающем основном. Если требуется перенести выполнение отчетов на другой сервер, то достаточно изменить настройки соединения. Для резервного восстановления работы при падении основного сервера БД, нужно просто отключить репликацию и перенастроить АОС либо выключить основной и поднять резервный. Все это проделывается руками или скриптами. В чем засада ?

да в этом и нет засады. с этим то всё понятно. АОС запускать что бы внести столбцы в таблицы в резервной БД, но это двойная работа, и не возможность работы пользователей пока вносятся изменения.

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

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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

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

[AndyD]

Цитата:

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

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

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