aEremenko: Создание сервера отчетности

[Blog bot]

Источник: http://blogs.msdn.com/aeremenk/archi...5/3699503.aspx
==============

Не секрет, что для обеспечения дополнительных сервисов и более оптимального распределения нагрузки отчетность часто выносят на отдельный физический сервер.
Вариантов на Microsoft SQL Server может быть несколько:

• Еще одна инсталляция Microsoft Dynamics AX, настроенная на копию производственной базы данных;
• Использование Microsoft SQL 2005 Server Report Services (SRS);
• Использование Microsoft SQL Analysis Services (OLAP) в качестве сервиса для создания представлений и последующего экспорта в Microsoft Excel.

Рассмотрим первый способ, тем более что по лицензионному соглашению по Microsoft Dynamics AX можно создать 3 инсталляции, где только одна – производственная (оставшиеся 2 могут использоваться для разработки, тестирования, отчетности).
Копию производственной базы можно получить односторонней репликацией, например.
Для создания репликации требуется первичныйключ (primary key) по таблице; таким образом, для таблиц безпервичногоключа необходимо изменить один из уникальных индексов и установить его как основной в параметрах таблицы в Репозитарии прикладных объектов (AOT) Microsoft Dynamics AX. После чего процесс синхронизации изменит структуру этих таблиц; однако синхронизация может занять достаточно большое количество времени в зависимости от размера таблицы и имеющегося оборудования сервера базы данных.
Нужно понимать, что нет необходимости реплицировать данные всех таблиц на сервер отчетности, число основных таблиц не так велико.
В случае использования репликации рекомендуется непрерывная репликация транзакций (continuous transactional replication) с удаленным агентом распространителя (remote distributor). В этой конфигурации, нагрузкой для производственной базы данных будет только нагрузка на журнал транзакций. Важно, чтобы дисковая подсистема, где размещены файлы журнала транзакций, была достаточно производительна и изолирована от прочей нагрузки (никаких других файлов на том же дисковом массиве).
Наиболее важным изменением для базы данных Microsoft Dynamics AX при использовании репликации является невозможность удаления таблицы после публикации. Если в процессе создания модификаций или поднятия таковых в производственной базе данных, процесс синхронизации попытается пересоздать таблицу, синхронизация может закончиться неуспешно.
Для поддержки изменений структур таблиц необходимо исключить таблицы, используемые в публикации. Нет необходимости удаления всей публикации, достаточно удалить определенные статьи (таблицы) из публикации и добавить их обратно после процесса синхронизации и заново инициализировать снимок только для этих статей. Такое решение может быть достигнуто созданием соответствующего сценария (скрипта), но это ведет увеличению затрат на администрирование, так как необходимо выполнять сценарий при каждой синхронизации в Microsoft Dynamics AX.
Альтернативой односторонней репликации может быть механизм журналов доставки (log shipping), однако этот способ также имеет ряд ограничений. Пользователи будут вынуждены отсоединиться от базы данных в момент поднятия журнала, соответственно ограничивает их в возможности запускать отчеты. Для минимизации такого эффекта необходимо увеличивать интервал между поднятиями журналов, но это в свою очередь ведет к "устареванию" данных. Фактически этот способ годится только для клиентов, для которых приемлем запуск отчетов с данными, актуальными на "вечер вчерашнего дня".

В Microsoft SQL Server 2005 есть также возможность использовать зеркальное отображение данных (mirroring) для копирования данных на другой физический сервер, а затем предоставить доступ к данным посредством моментальных снимков (snapshots). Этот способ также имеет свои ограничения. Моментальный снимок представляет собой доступный только для чтения снимок состояния базы на момент создания самого снимка. При обновлении снимка, пользователи будут вынуждены прервать выполнения отчета и запустить его снова. Если же снимки не обновлять, то теряется актуальность данных.
Необходимо также помнить, что политика поддержки корпорации Майкрософт не распространяется на технологию зеркального отображения баз данных в SQL Server 2005.

Наиболее интересный и правильный путь – использование Microsoft SQL 2005 Server Report Services, но об этом в следующий раз…


Источник: http://blogs.msdn.com/aeremenk/archi...5/3699503.aspx

[belugin]

Про зеркалировние (диклеймер: по памяти, за что купил):
1. Оно какое-то сырое, включается полусекретным свитчем

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

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

[Vadik]

Цитата:

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

Про зеркалировние (диклеймер: по памяти, за что купил):
1. Оно какое-то сырое, включается полусекретным свитчем

database mirroring был по умолчанию отключен и не рекомендовался для включения на production до выхода SP1, а сейчас вовсю используется SP2

[Recoilme]

Цитата:

Для создания репликации требуется первичныйключ (primary key) по таблице

Пришлось в свое время отказаться от "родной" репликации т.к. далеко не у всех основных таблиц он есть (что не есть здорово в общем то), и не каждый заказчик даст добавить ключи на боевой БД для целей системы отчетности (репликации), справедливо опасаясь за производительность на каком ни-ть экзотическом запросе..

Поэтому мне кажется в статье незаслуженно не упомянут старый добрый способ настройки ДТС пакетов и переливки нужных таблиц по расписанию)

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