Как можно выполнить запрос таким образом, чтобы это минимально отражалось на скорости работы других пользователей? Лабаю сложный аналитический отчёт на рабочей базе (не спрашивайте, так надо), и при выполнении сложного запроса сильно тормозится работа пользователей. Можно ли как-то снизить приоритет выполнения моего запроса? Пусть он работает дольше, но не тормозит работу пользователей. Реально такое?

в тестовой работать не учили?

(1) Лабаю сложный аналитический отчёт на рабочей базе (не спрашивайте, так надо)

А почему ты думаешь что именно SQL Server тормозит юзеров, а не rphost?

(3) хз, может и rphost. Но, судя по моим запросам, думаю, они действительно долго выполняются на sql сервере.

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

По идее наверно как-то можно с помощью ТНФ вынести выполнение своего отчета на отдельный сервер 1С в кластере.

PS Вопросы идиотские как и сам подход.

(5) (6) Сегодня - так. У меня нет выбора. ((

(7) работай ночами.

(0)
1. Понять каким местом система тормозит (память, IOPS, процессор. И добавить то чего не хватает.
2. Лабать сложный аналитический отчёт на другой базе или по ночам.

(0) В SQL есть панель отчетов стандартная. Там есть такой раздел "Транзакции, блокирующие работу" или как-то так. Еще там есть история. Если ваш запрос среди этих, тогда ищите в списке. Еще можно посмотреть ТОП-10 по среднему расходу по ЦП и по памяти, там можно посмотреть, входит ли он в топ-10. Если да, тогда искать способы оптимизации, возможно, структуру хранения. Но по факту никак не должно влиять, так как 1С для запросов вне транзакций, а равно для вывода в отчет использует грязное чтение, используя инструкцию WITH NO LOCK. У меня в свое время был мега отчет (правда, в нем были структурные ошибки), в нем было декартово произведение очень большое, но формирование отчета не влияло на работу других пользователей. Только сам формирующий мог минут по 10-15 ждать результата.

(10) У меня много запросов в пакете, много временных таблиц, много выборки. Расчётов и объединений не очень много.

Обычно для скуля не проблема выполнить большой запрос и отдать данные. А вот rphost надуется и лопнет (ну может и не лопнет, но у всех юзеров которые висят на нем случатся тормоза). Единственный вариант распределить загрузку в случае с 1С - с помощью ТНФ вынести нагрузку на отдельный рабочий сервер 1С.

(0) Если других вариантов нет и MS SQL крутится не на одноядерном процессоре, то можно попробовать поменять в свойствах SQL сервера в разделе "Дополнительно" параметр "максимальная степень параллелизма" с "0" на "2" и посмотреть на результат. У нас это значение равно число доступных ядер/4, полет нормальный. При 0 значении параметра изредка бывали случаи, когда пользователь своими настройками какого-нибудь мега отчета вгонял сервер в глубокую задумчивость.

(13) Спасибо! Сейчас гляну..

(11) В рамках пакета создаются и используются одни и те же временные таблицы. Там все сразу видно и профайлером и панелью мониторинга. А много выборки - это пальцем в небо.

(11) очищай ВТ через УДАЛИТЬ по ходу запроса, может они просто забивают кеш

В крайнем случаю репликация БД в базу для отчетов, ну или кластер серверов

Ну и оптимизируй запрос конечно, чем быстрее он отработает тем лучше всем )

(16) Сто процентов ошибка в архитектуре. Это изврат создавать базы для отчетов.

(16) В кэше не хранятся результаты запросов. В кэше хранятся ПЛАНЫ. А очистка только освобождает память.

(16) Очищаю.

Вообще сложный аналитический отчет и 1С это вещи несовместимые. Для этих целей используют OLAP.

Сложный аналитический отчет и 1С - вещи совместимые, если вместо ссылок выводить представления ссылок.

(0) Запрос для отчета не должен выполняться дольше нескольких секунд, вы в курсе этого?

(22) поддерживаю. если долго шпилится запрос - значит что-то не так с запросом. анализ плана выполнения запроса может подсказать очень многое.

(21) Вы щас какую-то банальщину сказали...

(24) Забейте, не важно.

Кстати, интересная тема - управления ресурсами скуля из 1С. Запросы действительно *могут* быть долгими и ресурсоемкими. Пусть это будет не отчет, а рег. задание. Тот же расчет себестоимости, например. ЕМНИП, в последних версиях платформы появилась возможность прикрепить юзера к рабочему процессу. А значит, теоретически можно задействовать Resource Governor для всех соединений этого процесса. Если разработчики платформы подсуетятся и добавят поддержку. А может, уже? Есть кто в теме? (Особенно к ежикам вопрос :)