База работает быстрее после выгрузки и загрузки .dt в MSSQL 2005 #395245

База работает быстрее после выгрузки и загрузки .dt в  MSSQL 2005, хотел бы узнать, что происходит при загрузке dt на платформе 1С в MSSQL 2005 кроме реиндексации и дефрагментации, на базе регулярно каждую ночь провожу реиндексацию и дефрагментацию, но скорость работы запросов возрастает только после выгрузки и загрузки баз из dt

Странно... После какого периода использования происходит прирост производительности после перезагрузки базы? Какой эффективный размер базы? Конкретный пример на чем виден прирост и как он оценивается? Пробовали ли перезапускать сервер предприятия, сервер БД и был ли при этом прирост производительности? Кроме реиндексации и дефрагментации стоит еще производить обновление статистики.

база занимает 35 гигабайт, проводить выгрузку загрцзку приходится минимум один раз в месяц, для замера скорости работы использовались запросы , применяющиеся в отчетных формах данной базы , в запросах задействованны остатки, маленкий запрос проходит 40 секунд , после выгрузки загрузки мгновенно

сервер 1с предприятия перезапускал, вообще перегружал полностью сервер, роста производительности не было

размер файлов *.ldf и *.mdf каков?

Надо еще делать престройку индексов. При перезагрузки dtони выстраиваются заново.

Хм... Падение производительности какое-то нереальное. Даже трудно предположить причину. Насколько быстро пополняется база? Чтобы попробовал сделать я: 1) посмотрел в профайлере текст эталонного запроса 2) проанализировал план его выполнения до и после перезагрузки

обновление статистики не проводил, надо попробовать , нужно наверное найти скрипт размер мдф на текущий момент (вчера загрузил из дт) 35гиг лдф - 2гига

Если в запросе задействованы остатки, проблема может быть в таблицах итогов. Может, они жутко распухают у вас при жестоких правках задним числом. Правда, мне сложно представить, как это может вызвать падение производительности на порядки. Можно поподробнее про эталонный запрос? Он по актуальным итогам или за прошлые периоды? скрипт не нужно, в MSSQL 2005 это можно интерактивно настроить в Maintenance Plans.

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

Итоги за прошлый месяц рассчитаны?

да

сейчас выложу запросы они элементарные на мой взгляд

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

точно не могу сказать , пока исследуем только запросы при проведении документов , точнее сказать что тормозит таблица остатков конкретного регистра , регистр один из самыз больших , такая тенденция наблюдается что тормозит проведение запроса на конкретную дату за период последних 3 месяцев , если перейти на 4 месяц назад то работает быстро , пока не понятно почему именно тормозят остатки по тем 3 месяцям , есть подозрения что это конкретный случай

Если итоги за этот период расчитаны, то в принципе это вариант в пользу гипотезы о большом количестве записей в таблице итогов из-за перепроведений задним числом(старые периоды упакованы, т.к. там не было перепроведений после последней перезагрузки базы). Но такие тормоза могут быть только при ОЧЕНЬ большом количестве "лишних" записей и выборке без использования индексов. Так что было бы любопытно всё-таки взглянуть на запрос и подробное описание структуры этого регистра.

эм... а как ты дефрагментацию _данных_ внутри базы делаешь? она происходит при выгрузке/загрузке или бекап-ресторе (что, кстати, быстрее)

Не думаю, что фрагментация базы в течение месяца способна снизить производительность в десятки раз.

может :) файл он когда растет, внутри него таблицы и все новые данные подрад и вперемешку пишутся.... соответственно, на старые данные обращение замедлятся не будет, а с новыми - будет фигня

Кстати, возможно я ошибаюсь, но при бэкап/рестроре дефрагментации, ИМХО, не происходит.

Очень странно. Был свидетелем работы немаленьких баз, где дефрагментация не производилась годами. А будучи проведенной, не повышала производительность сколь либо заметно, не говоря уже о десятках раз :)

зависит от спецфики работы... если в базе только 3 вида документов и 3 регистра активно используются - то влияние фрагментации внути базы невелико, а если УПП со всеми подсистемами активно юзается - то тут .опа и происходит

Т.е. ВЫ ЛИЧНО были свидетелями проблем именно такого рода? Когда именно фрагментация данных базы MS SQL катастрофически сказывалась на производительсти?

в 7.7 на ПУБе регулярно такое происходит... на ТиСе на том же сервере - нифига... мое мнение - что именно из-за фрагментации данных, и большого количества постоянно используемых таблиц в ПУБе...

Т.е. именно ПРОВЕДЕННАЯ СРЕДСТВАМИ MS SQL дефрагментация базы ПУБа в разы (хотя бы) повышала производительность?

ВЫБРАТЬ ИЗ Документ.РегистрацияОплаты.СуммыОплаты КАК ДокОплата       абоненты) при выборе большого документа с количеством строк больше 100 и период например 12.11.2008 проходит около 40 сек ,

узнать бы полный список операций который происходит при загрузке базы из дт , можно было пробовать , вот еще момент , если просто загрузить дт в рабочую базу прирост производительности меньше чем если полностью убить базу на сервере, создать и загрузить в нее дт

бекап, убивание, создание и рестор... насчет «в разы» не скажу, но на глаз заметно...

СуммыОплаты, как я понял, это табличная часть? Использование временных таблиц здесь, ИМХО, излишне. Можно смело использовать обычный подзапрос. Оптимизатор запросов MSSQL эффективно решает такие ситуации, вы его только ограничиваете. Но это так, попутно. Можно подробную структуру регистра РасчетыСАбонентами, с порядком измерений и описанием типов? Хм... Я бы сказал, что здесь дело скорее не во внутренней фрагментации, а в обычной файловой. Это, кстати, может объяснить и

да это табличная часть , сейчас структуру выгружу

Большая? Если да, то попробуйте всё-таки ради интереса заменить временную таблицу на подзапрос.

ок попробую

да 17 милионов записей уже

Я имел в виду в одном документе :)

хм у меня в голове регистр )))