db2replic,

db2replicосновные задачи - oltp, ввод-апгрейд данных.
постепенно растет кол-во отчетных запросов к бд (большие объемы выборки с сортировками-группировками)


Здесь задача понять, что в первую очередь нагружает систему и от чего хотим избавиться. В смешанной среде транзакции друг другу могут мешать:

а) блокировками
б) olap вымывает пулы и грузит диск
с) olap грузит память-проц (+диск) - сортировки, временные таблицы и пр.


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


При таком количестве таблиц репликация будет весьма тяжелой сама по себе. Тут опять вопрос - что, все 200 оперативные? Или 190 - статичные справочники и реально нужно реплицировать 10?

Если все 200, то тут уже использование второго сервера только MPP, при чем нужно будет продумать правильное разделение по партициям. А если у вас одна большая таблица с суррогатом типа счетчик - все, не вариант.

db2replic2 - сделать на отчетном сервере federated объекты на основной сервер.


И что это даст??? Запросы все равно будут отрабатывать на основном сервере. Если только сегментировать таблицу на оперативную-архивную часть и размазывать ее между 2-мя серверами (через view & instead of trigger) . Только тогда наоборот, скорее с основного на архивный будут никнеймы. Плюс еще нужно будет сделать процедуры по перезаливке.

db2replic3 - постоянный он-лайн инкрементный бэкап основного сервера с накатыванием обновлений на "отчетном"


Вариант с бэкапом прокатит только для загрузки варехауза или песочницы со вчерашними данными - типа каждое утро новый слепок для юзеров, вторая пока в restore-rollforward, в час Х их меняем.

db2replicглавный вопрос - что даст меньшую нагрузку на основной сервер?


Главный вопрос - что делать? Это покажет детальный анализ, я показал основные точки, куда пилить.

Действия:

Выявляем тяжелые запросы и анализируем их, если есть возможность - улучшаем. Строим/удаляем индексы, меняем уровень изоляции для olap на UR. Смотрим на пулы, перемещаем tbs между дисками и подкручиваем прочие ручки. Оптимизируем все, что можем. Может реально использовать summary, кластеризацию или MDT, если отклик для insert/update/delete будет приемлемым. Не хватает, думаем дальше. Если множество таблиц для отчетности достаточно статично и у самой системе отчетности можно поменять источник данных - тогда задумываемся о репликации части таблиц на второй сервер. Честно говоря, я плохо представляю OLAP прям весь такой оперативный.

У меня для sas/dwh 2 сценария используются: и регулярная песочница каждое утро и репликация определенного множества таблиц с небольшой задержкой. Итого 3 базы: Оперативная - Песочница - МиниРеплика. Для ряда старых приложений деление через никнеймы тоже сделано.

Andy

db2replicможет я не правильно понял, но по-моему,
сервер А ("OLAP") посылает серверу Б(OLTP) запрос, получает план, на основе плана делает
выборки только нужных данных, и уже сам делает финальные группировки-сортировки.


Нет. Никаких чужих "планов" он не смотрит. При создании никнеймов есть возможность сделать index definintion на никнейм (на однородные сервера db2 автоматом создаются существующие на источнике). Можно туда залить статистику, которую использует компилятор. Есть даже возможность кэширования - я уже не помню точно, но мы от нее отказались, надо наморщить ум почему. Что в итоге за запрос пойдет по никнейму - нужно смотреть в эксплейне, очень часто получаем безпредикативный full select.

db2replicВ этом случае с сервера OLTP снимается часть нагрузки с проца и ОП.
Также вместо множества агентов на обслуживание каждого из клиентов
(пользователей подсистемы отчетов), получаем обслуживание только клиента "OLAP-сервера".


С чего бы, ведь все данные лежат на сервере исходном. Из-за особенностей использования никнеймов вместо быстрого пересечения двух множеств локально, например, получим два full-select'а и их объединение на olap-server'е. Если таблицы маленькие, а запросы наоборот - да, реально можно получить выигрыш. Но это исключение, когда задача решена не теми средствами...

Если клиент использует никнейм - ему выделяется коннект на удаленный сервер. Количество коннектов останется прежним.

Еще раз - разберитесь, что конкретно не устраивает. Хотелки и их реализации должны быть адекватными. "Оперативный olap" - это явно неправильно понятая и также неправильно решенная задача.

Andy

Добавлю к сказанному Виктором (кстати, привет! 2:5020/1.21 :) )

Victor MetelitsaТяжёлая репликация или нет - дело, конечно, не в количестве таблиц.


скажем так - не только в количестве. Просто чем больше таблиц, тем сложнее поддерживать. И одному capture может быть тяжело.

Victor Metelitsa1. Когда включаем репликацию, размер логов увеличивается (увеличивается нагрузка на то место в дисковой подсистеме, где хранятся эти логи).


Увеличивается за счет того, что в лог пишется при апдейте строка целиком, а если включена опция capture before image - то, соответственно, и записывается исходная строка. Плюс потом Capture (при SQL-репликации) будет писать в stage-таблицы (1 или 2 записи, если включить режим передачи изменений как пару delete/insert). Может потребоваться увеличить размеры журналов. Плюс при массовых апдейтах - дисковое пространство.

Victor Metelitsa3. Программа "Capture" куда-то складывает полученные данные,


При Q-репликации, будет использоваться транспорт MQ. При SQL - исходная база.
Плюс свою нагрузку при SQL-репликации создадут подписчики.

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

Andy