Добавлено: Ср Фев 08, 2012 11:00 am Заголовок сообщения: Медленно начинает работать станд. хранимая продцедура
Есть такой сабж с именем ap_rep_wiz3. Вызывается он при расчете аммортизации ОС (определение остатка). После нескольких расчетов по разным счетам/группам наступает момент, когда расчет из 100 объектов занимает 3-4 часа. При этом время выполнения данной продцедуры с обычных <=1сек увеличивается до 10-15сек. Помогает только полный рестарт сервера. Каких либо закономерностей не выявил.
Куда копнуть?
Добавлено: Ср Фев 08, 2012 11:11 am Заголовок сообщения: Re: Медленно начинает работать станд. хранимая продцедура
irBis писал(а):
Помогает только полный рестарт сервера. Каких либо закономерностей не выявил.
Куда копнуть?
1. Данных мало. Объем базы - каков? (подозреваю, что весьма незначительный)
2. Поможет базовый курс основ администрирования БД, в частности - индексы и статистика. Иногда статистику нужно обновлять
3. Смотреть на план исполнения запросов для выявления причин тормозов.
Если помогает рестарт сервера, значит, копать надо в сторону памяти и кеша. Посмотрите, что происходит при запуске процедуры, когда она тормозит. В первую очередь количество перекомпиляций и cache hit ratio.
А вообще второй камент AllexL - очень правильный.
Советов может быть очень много... Но для этого надо многое знать: какой сиквел-сервер, какая операционка, сколько памяти, сколько памяти выделено под сиквел и т.д. Ну и естественно - как собственно в вашей базе работает эта хранимая процедура, какие индексы есть и используются, как часто обновляется статистика. Да даже такая банальная штука, как фрагментация файлов БД
1) почти 8Гб
2) реиндексация еженочно, про статистику первый раз слышу
3) Как и чем просмотреть план?
скрипт запустил на тестовой БД, шуршит уже минут 10
1. Это довольно много для акцентовской базы. Какая винда, сиквел-сервер, железо?
2. Индексация еженощно - это хорошо если не вдаваться в подробности. В том же джобе добавьте статистику. И отключите автообновление статистики - для такого размера базы это уже зло.
3. Дык в SSMS...
10 минут для скрипта с селектами??? Очень много. Смотрите результурующую строку и пытайтесь оптимизировать.
Посмотрел хранимку... она запускается по sp_executesql и каждый раз перекомпилируется...
У... старье... СКЛ сервер имею ввиду. Все обновления стоят? Почему сиквелу так маол памяти дали???? Винде (если там больше ничего не вертится) достаточно 1,5-2 гига. Остальное - сиквелу. И попробуйте задать Lock pages in memory. Правда, не помню, есть ли это в 2000 сиквеле.
После СП4 еще были апдейты, серьезно влияющие на быстродействие. Давно дело было, не вспомню. Поищите.
Минимум памяти поставьте 6 гиг, максимум - пару терабайт Использование памяти смотреть не таск манагером, он врет... Там есть специфика в использовании памяти ядра. В 2000 сиквеле не помогу в этом вопросе. Не помню софтину, что-то из сисинтернала.
Цитата:
Lock pages in memory
- гугль. у меня нет под рукой сервера 2000. Может этой галочки и нет в 2000.
Цитата:
Где вкл/выкл статистику?
8:45 для "update statistics journal with fullscan"
В свойствах БД.
И еще - сколько активных юзеров? Дедлоки бывают?
ЗЫ. А в качестве эксперимента не пробовали делать то же самое на более поздней версии сиквела? В 2008R2 бесплатный понимает базу до 10 гиг, а триальный можно поставить на 180 дней.
Как это не удивительно, но "update statistics journal with fullscan" помогло. Посмотрим, как долго будет длиться эффект. Ща еще и в джоб пропишу. Гранд мерси за скрипт.
Как это не удивительно, но "update statistics journal with fullscan" помогло. Посмотрим, как долго будет длиться эффект. Ща еще и в джоб пропишу. Гранд мерси за скрипт.
Эффект будет длиться, пока она (статистика) не перестанет быть актуальной.
Индексировать ещенощно - бессмысленное издевательство, достаточно обновить статистику для всех журнальных таблиц , связанных с Documents:
Тогда понятно почему больше памяти не ест... не умеет адресовать
Цитата:
Эффект будет длиться, пока она (статистика) не перестанет быть актуальной.
Индексировать ещенощно - бессмысленное издевательство, достаточно обновить статистику для всех журнальных таблиц , связанных с Documents:
Если бы зависело от статистики, то перезагрузка сервера бы не помогла, т.к. статистика - это БД. Видимо, в процессе апдейта статистики освобождается что-то из памяти.
Индексипровать еженощно - не издевательство. Если ресурсы сервера и бизнес-процессы позволяют и не охота заморачиваться, то это спасает. Хотя по правильному конечно надо написать скрипт, который проверит дефрагментацию каждого индекса каждой таблицы и в случае дефрагментации, скажем, больше 5% процентов сделает ребилд. Первый вариант может занимать часы, второй - минуты. Но второй требует знаний, которых у вопрошающего, видимо, нет . Скрипт у меня есть, но выкладывать лениво
Да, ребилд индексов DOCUMENTS, JOURNAL, JRN_MISC, JRN_CRC и (может быть ...PARAMS) - это по сути ребилд всей базы, т.к. все остальное - капля в море.
Тогда понятно почему больше памяти не ест...
не умеет адресовать
А как же AWE?
kris писал(а):
Индексировать еженощно - не издевательство. Если ресурсы сервера и бизнес-процессы позволяют и не охота заморачиваться, то это спасает.
Издевательство, издевательство. Из пушки по воробьям палить.
Базы - какого размера? А куда потом помещаются индексы, и что становится со страницами, где размещались старые индексы?
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах