Добрый день!
Имеется следующая конфигурация:
Бух 2.0 практически типовая(дописан 1 документ)
Платформа 8.2.13.213
8 пользователей
SQL 2005 на отдельном сервере
Сервер 1С на отдельном сервере
2 рабочих процесса на 1С сервере
Сервера не "задыхаются", вроде все нормально в плане ресурсов.
На SQL каждое утро выполняются задания, рекомендованные в базе знаний крупных внедрений сайта 1С.
Вроде все описал достаточно подробно.

Проблема заключается в том, что отчет "Карточка счета" с отбором по одному контрагенту формируется в общей сложности около 10 секунд, что сильно раздражает бухгалтерию. ОСВ, кстати, с таким же отбором по контрагенту формируется меньше 2х секунд.

В качестве лечения проблемы немного поубивали фоновые задания по обновлению индекса полнотекстового поиска, перенесли SQL на отдельный сервер, добавили еще 1 рабочий процесс в сервер 1С и ребутим агент кластера каждую ночь. В сумме все эти движения дали выигрыш буквально в 1-2 секунды.
Намедни через ТЖ отловили, что около 8 секунд выполняются запросы на стороне SQL.
Ах да, на файловой версии базы этот же отчет формируется за 2 секунды.

Теперь, собственно, вопросы:
1. Правильно ли мы определили, что узкое место в SQL?
2. Если да, то что можно с ним сделать, чтобы хотя бы ополовинить время выполнения запроса?
3. Может ли помочь обновление платформы на грядущую 8.2.14?
4. Почему вообще такая глупость происходит - у супер-пупер СУБД производительность в несколько раз меньше, чем у встроенного файлового 1Совского решения?

Спасибо большое за адекватные ответы.

"4. Почему вообще такая глупость происходит - у супер-пупер СУБД производительность в несколько раз меньше, чем у встроенного файлового 1Совского решения? " - гораздо интереснее другое - откуда такая глупость что серверная СУБД должна быть быстрее?

(1) на уровне отчета как правило быстрее

(2)показывай пруфлинк

4. sql медленнее. но работает и не ломает базу.
отчет или нет тут не при чем - локальное получение данных быстрее по умолчанию чем обратиться к серверу... задействовать его механизмы... дождаться ответа... вернуть результат

2(0)
"1. Правильно ли мы определили, что узкое место в SQL?
2. Если да, то что можно с ним сделать, чтобы хотя бы ополовинить время выполнения запроса? "

скорее всего да...
сама  "8.2.14" не спасет и ничего не ускорит, но у нее в настройках ТЖ есть такая опция, как показывать план выполняемого СКЛ-запроса... вот она вам может сильно помочь.

В принципе можно и без нее, но тогда все разбивается на два этапа: а) поймать ваш запрос В ТЖ, б)потом уже попытаться его выполнить в СКЛ или посмотреть планы. у СКЛ-я же есть уже крутилки которые могут вам помочь ускорить выполнение запроса.

по крайней мере в ДБ2 они точно есть, а стало быть и у МС должны быть

"крутилки SQL" в гугле не находятся :)
Подскажи поконкретнее, что именно искать надо?

забавные бывают порой одинэсники

(0) Уверен что 10 сек. стоят затраченных усилий?

(6) для начала профайлером ловим запрос в скуле, потом в студии смотрим план запроса.

Обновление статистики, дефрагментация индексов.

(10) а это точно выполнение запроса а не передача полученных данных по сети? карточка счета бывает очень большой.

(0) "На SQL каждое утро выполняются задания, рекомендованные в базе знаний крупных внедрений сайта 1С."
какие точно ?

(0) В отладчике именно выполнение запроса выполняется 10 секунд?

Надо смотреть запрос.
А то будет как в
v8: Очень много записей в справочнике или регистре сведений
(пост 146, 149)

Не нашел, как на этом форуме отвечать на конкретные посты, поэтому отвечу по порядку:
1. Мое руководство уверенно, что эти 10 секунд стоят того.
2. А что даст этот план запроса? Я у Гилева пробежался по статье про план запроса, но сути не понял. Отчет то типовой, лезть в 1Сный код и исправлять там что то не буду, или можно сам SQL "заточить" под выполнение конкретного запроса?
3. В карточке счета буквально пара-тройка записей.
4. Вот такие задания:    
Обновление статистик
   Очистка процедурного КЭШа
   Дефрагментация индексов
   Реиндексация таблиц базы данных
5. Это я посмотрел через замер производительности. Конкретно вот эта строка из общего модуля:
ПроцессорВывода.Вывести(ПроцессорКомпоновки, Истина);
выполняется 6-9 секунд.
6. Эммм... Запрос типовой(Отчет "Карточка счета"), вносить изменения в эти типовые механизмы ну оооочень не хочется - у нас конфа почти не настроенная.

2(15) "ПроцессорВывода.Вывести(ПроцессорКомпоновки, Истина); " - то есть все-таки вывод долгий а не выполнение запроса?

(15) Если не знаешь, что даст план запроса, то лучше не лезь. Позовите спеца по MSSQL, пусть он смотрит.

на всякий случай спрошу - версия sql и параметры сервера

(15) А что даст этот план запроса? Я у Гилева пробежался по статье про план запроса, но сути не понял.

Читай до просветления. Без этих знаний не быть тебе спецом.

Да как же тут отвечать на пост, блин!
1. Я не знаю, куда ложится нагрузка при выполнении этой строки. Если проблема в "долгом выводе", то кто виноват?
2. Насколько я понимаю план запроса "расскажет" о том, где можно оптимизировать запрос. Индексы там включить или ребилднуть чего. Но для этого нужно лезть в 1Совский код и править его, что трудновыполнимо.
3. SQL 2008 R2. Да, в самом я начале с версией я обманул. Парметры железные или софтверные?
4. Спасибо, капитан.

(20.3) версия SQL - может экспресс стоит :)

в скобки номер (20)

(0) Памяти на сервере SQL сколько? И какой SQL стоит - 32 или 64?

(21) Нет, точно "взрослый" :)
(22) Спасибо!
(23) Только в понедельник смогу ответить - сегодня главного SQLщика нет.

(24) смотреть сначала что на поверхности - параметры сервера sql, сеть между серверами, общая сеть, параметры рабочей станции

(25) какие на хрен параметры. если дело касается производительности конкретного запроса, смотрят план запроса в первую очередь.

8 пользователей
SQL 2005 на отдельном сервере

тут все по дефолту должно летать

(23) разрядность вообще пофигу.

(26) когда перестает работать телевизор сразу с паяльником лезешь или сначала автомат проверяешь ?
в типовой конфигурации я бы смотрел профайлер в последнюю очередь

(25)но ведь ОСВ по счету с отборами формируется быстро! Разве это не указывает, что общих проблем нет?
(26)допустим, я там увижу, что там 3 вложенных запроса и все они без индекса(ну или как правильнее сказать? в общем, не индексированная таблица используется), что тогда делать?

(28) крутить настройки, это и есть паяльник. а план запроса это тестер, который покажет тебе что и как.

(27) Если у него сервак х32  и настроен на потребление 1.7Гб озу - это может влиять.

2(20) "Я не знаю, куда ложится нагрузка при выполнении этой строки. Если проблема в "долгом выводе", то кто виноват? "

так почему же и отчего же ты до сих пор не настроил ТЖ чтобы это выяснить? Ведь там раскладывается каеждая операция и пишется длительность в милисекундах

"о для этого нужно лезть в 1Совский код и править его, что трудновыполнимо. " - безусловно не надо.

как для ДБ2 то самое главное что можно сделать для ускорения - это чтобы данные уже лежали не на диске, а в памяти.. то есть в буферпулах(кэш в терминах ИБМ). при чем там такой фокус - типа можно ничего не трогать и все делается автоматом, но автоматом ДБ2 экономная, и буферпул расширяет только постепенно. А можно взять и сказать: тетка, вот эти два буферпула пусть будут вот такими большими - и потом просто взять и сформиовать все что что можно один раз - и возможно в первый раз картачка будет строиться тоже 10 секунд, но уже во второй - 2 секунды.

(32)я настроил ТЖ, который пишет обращения к SQL, посмотрел его парсером, скачанным с инфостарта, нашел несколько SQL запросов, которые в общей сложности выполняются около 8 секунд. Запросы там гигантские, и, на мой мой непрофессиональный взгляд, не самые оптимальные.

(34) rls используется ?

(33)"первый раз" имеешь в виду, что каждый раз, когда пользователю нужно будет сформировать карточку первое формирование будет долгим, а потом быстрым?
Но пользователю же нужно эту карточку 1 раз только посмотреть, ей второй раз, тащемта, и не нужен уже.

(34) на мой мой непрофессиональный взгляд, не самые оптимальные.

Зачет!
1. Получи свой проблемный запрос в скомпилированном виде
2. Открываешь Microsoft SQL Server Management Studio                        
3. Вставляешь туда скомпиленый запрос
4. Нажимаешь кнопочку Include Actual Execution Plan
5. Жмешь кнопочку Execute

2(36) нет, первый раз после того как я скажу db2 start

сервер про пользователей вообще ничего не знает, он обслуживает одного пользователя - сервер 1С

(35) не знаю. Смогу сказать в понедельник.
(37) тогда встает другая проблема - у меня тяжелый запрос кончается ничем:
UNION SELECTT6._RecorderTRef AS RecorderTRef,T6._RecorderRRef AS RecorderRRef,T6._LineNo AS LineNo_FROM _AccRg453 T6 WITH(NOLOCK)INNER JOIN _AccRgED489
Очевидно, что после "INNER JOIN _AccRgED489" должны быть условия. Это скачанный парсер - лох или такая 1Совская фича?
(38) а SQLный аналог понятия "буферпул" не знаешь случайно?

точно не знаю, думаю - кэш...

(41) в любом случае спасибо за мысль. кое-что гуглится.

(40) нету аналога прямого, равно как и динамической настройки для лучшей производительности. Можно закреплять таблицы/индексы в кэше, но не более.

(40) так же очевидно что до UNION  должен быть запрос. скорей всего это ты так выдернул его. куском.

(43) это вы про PINTABLE?
"Инструкция DBCC PINTABLE не является необходимой, и была удалена для предотвращения дополнительных проблем. Синтаксис этой команды все еще работает, но не влияет на сервер."
http://msdn.microsoft.com/ru-ru/library/ms178015(v=sql.90).aspx

(44) там большущий запрос, я выложил только концовку. Могу целиком, если это принципиально.

(46) план этого запроса нужен. а не сам запрос.

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

(47)ок. Возвращайся в понедельник смотреть его.
(48) а это что и где?

Сейчас читаю по поводу памяти, отведенной SQL серверу - если поставить минимальный порог не динамически, а, к примеру, 1Гб - может ли это помочь закэшировать необходимые таблицы?

(49) для начала скажи как формируется отчет у пользователя с полными правами. если так же медленно, то я не прав.

(50)ты не прав :)

пардон)

(49) Нет смысла ставить минимум. Он всё равно сожрет больше :) Гига 4 хотя бы ему дайте.

2(53) он имеет в виду минимум задать сразу большой.

(54) да, именно так.
Физически на этом сервере памяти 4Гб, кроме SQL им никто не пользуется, в настройках памяти стоит от 0 до 2147483647Мб.

(49) нет - это не поможет. Если вы поставите минимум 1 гб памяти, sql server будет "зажимать" для себя этот гиг. Т.е. если ОС или какое-нибудь приложение затребует себе память - он этот гиг, даже если ему не сильно-то и нужно, не отдаст.
Причем, это не значит, что он его сразу себе возьмет. Если ему хватает 512 мб, он только их и возьмет. А вот если захавает больше 1 гига - то уже "не отпустит".

(56) Хренас с два.
Если SQL отработал - он все в кэш засосал и память хрен отдаст.

А если новую базу, типовую, этот же релиз, демку, развернуть на этом сервере и попробовать сформировать подобный отчет?

(0) Я бы для начала твой запрос скопировал бы и попробовал выполнить в консоли запросов, и посмотрел за какое время он тебе результат выплюнет... Может и не в запросе дело то, а в выводе данных

(57) >>Если SQL отработал - он все в кэш засосал и память хрен отдаст.
если min server memory не установлено?

(56) как я рассуждаю: "если у сервера стоит минимум 0, то он будет всегда стремится очищать(высвобождать память). Соответственно, если я формирую свой отчет, то он что то берет в кэш, а потом сразу отпускает, потому что нужно освобождать память. Если не нужно освобождать, то есть вероятность, что он оставит эту табличку в кэше и в следующий раз запрос будт формироваться быстрее".
(58) мысль! попробую.
(59) ТЖ мне полностью запрос на дает, profiler'ом сейчас не могу воспользоваться, но за идею спасибо.

(61) если это на сервере единственное приложение и ему не с кем бодаться за память - фиг он ее будет сам освобождать, с этим можете не париться.

2(61) запрос который в консоли выполнять можно выцепить отладчиком

(55) Наконец! Из чего можно сделать вывод, что сервак у вас, скорее всего х32 и SQL реально ест 1.7 Гб. Если база уже 5 гиг и больше, надо бы перейти на х64 и памяти SQL добавить.

(0) 10 сек. много - да вы зажрались :)))

(64) База весит всего 2.2 Гига

(64) с чего такие выводы?

(67)он же сказал "скорее всего" а не "сто процентов"
а так как ТС не сообщает потребляемую СКЛ-сервоом память, то возникла вот такая спекуляция.

(66) Потихоньку вытягиваем из партизана циферки...
Тогда смотрите счетчики производительности на SQL-сервере при выполнении запросов.

(68)4 гига более чем достаточно для данной нагрузки.

(64) Если база уже 5 гиг и больше, надо бы перейти на х64 и памяти SQL добавить

А как интересно раньше, когда не было х64 крутились на скуле, да и не только базы размерами по несколько сотен гигабайт?

2(70) это Интела не было х64, но была Альфа, и на ней был МС СКЛ сервер...

Проверил у себя на Буге КОРП карточку счета по счету 60 и отбор по контрагенту, делается 3 сек за любой месяц

p.s. База 20 гиг на PostgreSQL