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


#0 by marrior
База работает быстрее после выгрузки и загрузки .dt в  MSSQL 2005, хотел бы узнать, что происходит при загрузке dt на платформе 1С в MSSQL 2005 кроме реиндексации и дефрагментации, на базе регулярно каждую ночь провожу реиндексацию и дефрагментацию, но скорость работы запросов возрастает только после выгрузки и загрузки баз из dt
#1 by fisher
Странно... После какого периода использования происходит прирост производительности после перезагрузки базы? Какой эффективный размер базы? Конкретный пример на чем виден прирост и как он оценивается? Пробовали ли перезапускать сервер предприятия, сервер БД и был ли при этом прирост производительности? Кроме реиндексации и дефрагментации стоит еще производить обновление статистики.
#2 by marrior
база занимает 35 гигабайт, проводить выгрузку загрцзку приходится минимум один раз в месяц, для замера скорости работы использовались запросы , применяющиеся в отчетных формах данной базы , в запросах задействованны остатки, маленкий запрос проходит 40 секунд , после выгрузки загрузки мгновенно
#3 by marrior
сервер 1с предприятия перезапускал, вообще перегружал полностью сервер, роста производительности не было
#4 by Immortal
размер файлов *.ldf и *.mdf каков?
#5 by Черников
Надо еще делать престройку индексов. При перезагрузки dtони выстраиваются заново.
#6 by fisher
Хм... Падение производительности какое-то нереальное. Даже трудно предположить причину. Насколько быстро пополняется база? Чтобы попробовал сделать я: 1) посмотрел в профайлере текст эталонного запроса 2) проанализировал план его выполнения до и после перезагрузки
#7 by marrior
обновление статистики не проводил, надо попробовать , нужно наверное найти скрипт размер мдф на текущий момент (вчера загрузил из дт) 35гиг лдф - 2гига
#8 by fisher
Если в запросе задействованы остатки, проблема может быть в таблицах итогов. Может, они жутко распухают у вас при жестоких правках задним числом. Правда, мне сложно представить, как это может вызвать падение производительности на порядки. Можно поподробнее про эталонный запрос? Он по актуальным итогам или за прошлые периоды? скрипт не нужно, в MSSQL 2005 это можно интерактивно настроить в Maintenance Plans.
#9 by marrior
по актуальным итогам все проходит мгновенно , а вот по прошлому периоду например за прошлый период где то в середине месяца то тормозит жутко , ну понятно , что расчитвает заново, но так долго
#10 by fisher
Итоги за прошлый месяц рассчитаны?
#11 by marrior
да
#12 by marrior
сейчас выложу запросы они элементарные на мой взгляд
#13 by fisher
По ходу уточняющий вопрос: можно сказать, что жестокое замедление происходит только для запросов по некоторым регистрам, или это глобальная картина?
#14 by marrior
точно не могу сказать , пока исследуем только запросы при проведении документов , точнее сказать что тормозит таблица остатков конкретного регистра , регистр один из самыз больших , такая тенденция наблюдается что тормозит проведение запроса на конкретную дату за период последних 3 месяцев , если перейти на 4 месяц назад то работает быстро , пока не понятно почему именно тормозят остатки по тем 3 месяцям , есть подозрения что это конкретный случай
#15 by fisher
Если итоги за этот период расчитаны, то в принципе это вариант в пользу гипотезы о большом количестве записей в таблице итогов из-за перепроведений задним числом(старые периоды упакованы, т.к. там не было перепроведений после последней перезагрузки базы). Но такие тормоза могут быть только при ОЧЕНЬ большом количестве "лишних" записей и выборке без использования индексов. Так что было бы любопытно всё-таки взглянуть на запрос и подробное описание структуры этого регистра.
#16 by Fragster
эм... а как ты дефрагментацию _данных_ внутри базы делаешь? она происходит при выгрузке/загрузке или бекап-ресторе (что, кстати, быстрее)
#17 by fisher
Не думаю, что фрагментация базы в течение месяца способна снизить производительность в десятки раз.
#18 by Fragster
может :) файл он когда растет, внутри него таблицы и все новые данные подрад и вперемешку пишутся.... соответственно, на старые данные обращение замедлятся не будет, а с новыми - будет фигня
#19 by fisher
Кстати, возможно я ошибаюсь, но при бэкап/рестроре дефрагментации, ИМХО, не происходит.
#20 by fisher
Очень странно. Был свидетелем работы немаленьких баз, где дефрагментация не производилась годами. А будучи проведенной, не повышала производительность сколь либо заметно, не говоря уже о десятках раз :)
#21 by Fragster
зависит от спецфики работы... если в базе только 3 вида документов и 3 регистра активно используются - то влияние фрагментации внути базы невелико, а если УПП со всеми подсистемами активно юзается - то тут .опа и происходит
#22 by fisher
Т.е. ВЫ ЛИЧНО были свидетелями проблем именно такого рода? Когда именно фрагментация данных базы MS SQL катастрофически сказывалась на производительсти?
#23 by Fragster
в 7.7 на ПУБе регулярно такое происходит... на ТиСе на том же сервере - нифига... мое мнение - что именно из-за фрагментации данных, и большого количества постоянно используемых таблиц в ПУБе...
#24 by fisher
Т.е. именно ПРОВЕДЕННАЯ СРЕДСТВАМИ MS SQL дефрагментация базы ПУБа в разы (хотя бы) повышала производительность?
#25 by marrior
ВЫБРАТЬ ИЗ Документ.РегистрацияОплаты.СуммыОплаты КАК ДокОплата       абоненты) при выборе большого документа с количеством строк больше 100 и период например 12.11.2008 проходит около 40 сек ,
#26 by marrior
узнать бы полный список операций который происходит при загрузке базы из дт , можно было пробовать , вот еще момент , если просто загрузить дт в рабочую базу прирост производительности меньше чем если полностью убить базу на сервере, создать и загрузить в нее дт
#27 by Fragster
бекап, убивание, создание и рестор... насчет «в разы» не скажу, но на глаз заметно...
#28 by fisher
СуммыОплаты, как я понял, это табличная часть? Использование временных таблиц здесь, ИМХО, излишне. Можно смело использовать обычный подзапрос. Оптимизатор запросов MSSQL эффективно решает такие ситуации, вы его только ограничиваете. Но это так, попутно. Можно подробную структуру регистра РасчетыСАбонентами, с порядком измерений и описанием типов? Хм... Я бы сказал, что здесь дело скорее не во внутренней фрагментации, а в обычной файловой. Это, кстати, может объяснить и
#29 by marrior
да это табличная часть , сейчас структуру выгружу
#30 by fisher
Большая? Если да, то попробуйте всё-таки ради интереса заменить временную таблицу на подзапрос.
#31 by marrior
ок попробую
#32 by marrior
да 17 милионов записей уже
#33 by fisher
Я имел в виду в одном документе :)
#34 by marrior
хм у меня в голове регистр )))
Тэги: Админ
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С

Back to top