[kim-aa]

Grub,

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

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

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


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

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


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

[Grub]

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

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

[kim-aa]

При формировании отчетов, база зависает и в консоли администрирования 1С видно, что затык идет из-за блокировок(видно кто "держит" базу и расспросив "виновника", выясняем что он формирует отчет). »

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

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

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


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

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


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

Перевод базы, работающую всю свою жизнь на одной СУБД, на другую СУБД чреват большими проблемами »

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

нет не путаюсь. »

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

Встречал где-то в литературе, что надо выносить тяжелые отчеты за пределы базы(на другой сервер), чтобы повысить производительность и записи и отчетов. В microsoft BOL есть инфа про выделение под логи транзакций отдельного LUN'a, под tempdb и под саму базу »

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

И, кажется, даже на тех же курсах упоминалось про вынесение отчетов на другой сервер. »

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