crazyzerg13кто-нибудь ещё может пояснить бред в отчете по продажам?
ситуация - выбираю отчет по продажам, если выбирать допустим с 1 числа месяца по 28 число данного месяца, отчёт делается примерно минут 15. при аналогичных параметрах, если выбрать не "с такого-то по такое число", а "за месяц" (по сути с 1 по 28 число этого месяца), то отчёт делается за полторы минуты. почему такая дикая разница по времени формирования?
Видимо в первом случае итоги считаются в процессе формирования отчета, а во втором берутся из таблицы итогов регистра. Это если речь про февраль невисокосного года. Кстати, итоги вообще рассчитаны?

crazyzerg13Совершенно идентичное время на обработку повторных запросов уходит. И на полторы минуты и на 20. По поводу отладчика - напрягу нашего 1С-ника. По стандартному виндовому монитору всё идентично - только загрузка одного ядра под 100% и все. Дисковые и сетевые нагрузки идентичны (т.е. практически никакие).
Вообще, меня постоянно напрягает то, что на sql-сервере никогда не используется более одного ядра процессора на обработку одного запроса. Это нормально ?

SQL - сервер может распараллеливать некоторые запросы, если ему разрешить. Но стоит ли это делать? Всё зависит от того, какой план выполнения SQL-запроса выберет оптимизатор. При некоторых обстоятельствах можно получить 100% загрузку не одного, а всех имеющихся в наличии процессорных ядер, что неизбежно приведет к замедлению работы всех пользователей.
При выборе плана выполнения запроса, оптимизатор руководствуется статистикой, которая по возможности должна отражать актуально состояние данных. Если статистика неактуальна, оптимизатору "клинит башню", и казалось бы простые запросы выполняются неоптимальным способом, создавая избыточную нагрузку на железо. Возможно это как раз ваш случай. Проверьте включен ли режим автоматического сбора статистики для вашей базы, а так же насколько она актуальна. Это можно посмотреть в ms sql management studio.
Ежедневный пересчет итогов может довольно сильно изменять распределение данных в таблицах итогов регистров, да и отложенное проведение "вбрасывает" в таблицы регистров немалые порции данных. При этом "отставание" статистики чем дальше, тем сильнее искажает картину распределения данных для оптимизатора.
Кроме того, на работу оптимизатора запроса могут влиять банальные "глюки", поэтому желательно время от времени устанавливать на сервер патчи с исправлениями ошибок.
Да, и присоединюсь к мнению предыдущего оратора: ежедневные регламентные процедуры - это слегка перебор. А уж симпл рекавери на боевом сервере - это вообще за гранью добра и зла.

The Dim!ЗарегалсяДа, и присоединюсь к мнению предыдущего оратора: ежедневные регламентные процедуры - это слегка перебор. А уж симпл рекавери на боевом сервере - это вообще за гранью добра и зла.

А чем Вы руководствуетесь, давая такой совет в такой формулировке, если можно - подробный ответ. Или это очередное ИМХО ?

Не совсем понял о какой из двух фраз идет речь. Если о симпл рекавери, то производитель СУБД дает аналогичную рекомендацию. Backup Under the Simple Recovery Model

The Dim! Такой подход, дает выявить большое количество проблем ДО того как они станут критичными.
Вы сейчас про ТиИ, или у вас проблемы выявлялись при пересчете итогов и реиндексации? Если второе, то симпл рекавери для вас опасно вдвойне т.к. это уже похоже на неисправность дисковой подсистемы сервера.

The Dim! Я бы добавил дефрагментацию базы раз в месяц.
Не подскажете, какой прирост производительности это дает? Или вы таким способом предлагаете экономить место на дисковом массиве?

The Dim! И где там написано, что Microsoft не рекомендует использовать простой режим восстановления для баз данных MS SQL?
У вас проблемы с пониманием первого абзаца в статье? Не думаю. Больше похоже на попытку развести полемику ради полемики.

The Dim! Для того, что бы от полного режима восстановления был толк("в случае чего") нужно хранить ВЕСЬ лог между полными бэкапами базы данных. Не весь файл лога, а весь лог .
Эээээ... Это вы о чем? Вы уверены, что в SQL сервере от MS есть некий неведомый "лог" транзакций, который не пишется в файлы между полными бэкапами?

AHDPОн намекает, что можно сделать несколько бекапов лога между полными бекапами и удалить один бекапов лога. Ну и про разностный бекап не забыть ;)

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

AHDPЗарегался,

Почему? Просто сверху накатить ещё и бекап лога.

Бекап чего накатить? При симпл рекавери?