Вынос тяжелых отчетов на другой сервер
 

Ребята, доброго времени суток!
Встречал где-то в литературе, что надо выносить тяжелые отчеты за пределы базы(на другой сервер), чтобы повысить производительность и записи и отчетов. В microsoft BOL есть инфа про выделение под логи транзакций отдельного LUN'a, под tempdb и под саму базу. Также на курсах 1С тоже говорилось про разнесение tempdb, логов транзакций и базы по разным дисковым массивам. И, кажется, даже на тех же курсах упоминалось про вынесение отчетов на другой сервер. Если кто тоже встречал информацию по сабжу, то дайте линк, плиз. У меня вот из головы просто вышибло, где я это встречал. А необходимо почитать как это правильно реализуется.

Grub,

Вы путаетесь. Вы смешиваете оптимизацию системы ввода-вывода и оптимизацию серверов по операциям.

Сервера, да и сами базы СУБД, при высокой нагрузке действительно лучше оптимизировать под конкретные операции.
Условно их групируют в три клана:

- Оптимизированные на запись многочисленных транзакций- OLTP
- Оптимизированные на массовое чтение - OLAP
- Оптимизированные на гиперкубы - DataWarehaus (обычно это уже агрегированная база)


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

Типа этого
http://www.sql.ru/forum/actualthread.aspx?tid=685538


Просто вынести отчеты на другой сервер приложений, имеет смысл если у вас трехуровневая система с отдельным сервером СУБД и отдельными серверами приложений и при этом вы точно знаете, что основной затык происходит при расчете в коде 1С, а не массовой выборке в MS SQL

kim-aa, нет не путаюсь. Суть в том, что база является и OLTP и OLAP одновременно. При формировании отчетов, база зависает и в консоли администрирования 1С видно, что затык идет из-за блокировок(видно кто "держит" базу и расспросив "виновника", выясняем что он формирует отчет).
Система у нас действительно трехуровневая, поэтому как одно из решений и рассматривается вынос отчетов на другой сервер.
За ссылку Спасибо. Сейчас посмотрю.

По ссылке. Так и не увидел решения. Шел разговор, но ничем не закончился. Я промахнулся когда в первом посте не указал СУБД. Перевод базы, работающую всю свою жизнь на одной СУБД, на другую СУБД чреват большими проблемами. Поэтому сузим круг информации. Интересует MS SQL.

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

Вариант А: Не хватает мощности сервера приложений (высока загрузка CPU & Mem).
Основным признаком является, то что MS SQL при этом простаивает и количество дисковых операций не велико (винчестер не визжит - грубо говоря). В данном случае имеет смысл создания отдельного сервера приложений ориентированного только на отчеты.

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


Вариант Б: Не хвататает мощности сервера MS SQL.
Основным признаком является интенсивные операции ввода вывода, при относительно низкой процессорной загрузке.
Тут два варианта:
- Покупка и настройка отдельного дискового хранилища.
- Покупка и настройка отдельного сервера СУБД + приложений ориентированного только на отчеты. Настройка асинхронной репликации между серверами.

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


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

А это никто и не рекомендовал.

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



Это пример оптимизации ввода-вывода внутри одного сервера. Возможно и рекомендовано всегда.


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