Скорость проведения документов

[Radistka]

SQL 2008 R2
1С 8.1.15.14
Самописка - 25Гб
комплексная 130 Гб
скриншот характеристик сервера во вложении

ну медленно проводились документы, но жить можно было. при 3 активных операторах реализация в 500строк за 3,5 минуты в комплексной проводилась. мы нагоняем учёт, перепроводим документы за прошлые месяцы. и стали замечать что на перепроведение тратится всё больше времени. раньше месяц перепроводился впринципе за выходные, а тут начали март перепроводить - за ночь 2 дня всего обрабатывает. думали что объёмы увеличились, но оно как бы не настолько. на том же серваке лежит ещё одна база, самописка, таблиц - копейки. один мощный справочник(порядка миллиона элементов в иерархии). стала замечать, что при добавлении хотя бы одного условия в запрос по этому справочнику, время запроса увеличивается в десяток раз, если с консоли выборку гнать, а если тот же самый запрос написать в обработке, то выполняется он...в общем я не дождалась.

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

[Dest]

Что касается той базы где реализация проводится. Делайте замер производительности и смотрите на чем тормозит.
А там, где мегосправочник, тоже запрос нужно смотреть. Может не оптимальный.

Обновление статистики делали?
Use NameDB
exec sys.sp_updatestats

>выгрузить - загрузить конечно вариант, но журнал регистрации терять не хотелось бы
Он и не потеряется. Он же хранится во внешнем файле. Кстати это помогает только при файловом варианте работы с 1с.

[Radistka]

Что касается той базы где реализация проводится. Делайте замер производительности и смотрите на чем тормозит.

на всём том, что касается выборок в запросах.. т.е. я подозреваю именно то в каком состоянии база находится.. только как это состояние определить и поправить

А там, где мегосправочник, тоже запрос нужно смотреть. Может не оптимальный.

ну как бы тут сложно ошибиться))

Код: (1C v8)

 |    ВЫБРАТЬ
|               ТрансфертТаблица.Консультант КАК Консультант
|       ИЗ
|               Документ.Трансферт.Таблица КАК ТрансфертТаблица
|       ГДЕ
|               ТрансфертТаблица.Ссылка.Дата < &Дата
|      
|       СГРУППИРОВАТЬ ПО
|               ТрансфертТаблица.Консультант

Обновление статистики делали?
Use NameDB
exec sys.sp_updatestats

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

[Radistka]

мм.. нарыла в интернетах про статистику, щас пошукаю, как админ с обеда вернётся, есть ли у нас на этих базах нечто подобное.

UPD  обновление статистики делается каждую ночь. на это дело уходит 3-4 часа, так что чаще - не вариант..

[Dest]

3-4 часа на обновление статистики ??!!!!!!!!!!
У нас база примерно 170 Гб, мы делаем не чаще раза в неделю, процесс занимает 15-20 минут не дольше. 
Я читал, что слишком часто делать обновление статистики тоже не желательно. Мы каждый день не делаем.

[Sla]

Скорей всего здесь серверные проблемы.

Попробовать бы на другой конфигурации система/железо.

Проблемы могут возникать как на i/o - дисках, так и на наличии lock'ов таблиц

Было бы неплохо посмотреть
1. план выполнения запросов
2. Проверить время сбора статистики после перезапуска сервера
3. Проверить наличие lock
4. Проверить наличие db-link, возможно, что (это ведь самописка) идет какая-то синхронизация с внешними базами (возможно, несуществующими). Поизучать вопрос логирования slow запросов
5. Проверка железа и качества i/o - диски, сеть.

[Radistka]

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

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

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

[Sla]

С переиндексацией понятно...

медленные запросы смотрели?
lock смотрели

подвисшие запросы? Может они накапливаются?

Я люблю рассказывать когда сделали на оракле курсор for update для сотни тысяч записей
Т.е. на тестовом сервере все "летало", а на боевом - падало в ступор

Кроме того, нужно проанализировать циклы запросов, возможно, что запросы повторяются в цикле, подумать о кешировании, возможно ли увеличить объем кеша для запросов, может постоянно своп идет?

[Radistka]

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

lock - что это? к чему относится?

"подвисшие запросы? Может они накапливаются?" - это как? в каком месте они подвисают, как это определить и изза чего это случается?

"подумать о кешировании, возможно ли увеличить объем кеша для запросов, может постоянно своп идет?"- место увеличивать нам есть куда, а вот где увеличивать и как понять что оно надо? кеш сам чистится? этот кеш относится к скулю или 1Ске?))