Оптимизация Навижн средствами MS SQL

[konrad_imported]

Добрый день, коллеги!

Хотелось бы знать мнение уважаемой конфы по следующим вопросам:

1. Кто-нибудь настраивал Fill Factor таблиц, как описано в "Tuning Navision for better performance", и отразилось ли это как-то на реальной производительности?
2. С какой частотой у вас производся перестроение индексов и какими методами - INDEXDEFRAG либо DBREINDEX ?
3. Каким образом делаете обновление статистики - на автомате или ночным заданием? И делаете ли обновление статистики сразу после перестроения индексов?
4.Какими методами пользуетесь для оптимизации SIFT-таблиц?

[Vadik]

Цитата:

Сообщение от konrad

1. Кто-нибудь настраивал Fill Factor таблиц, как описано в "Tuning Navision for better performance", и отразилось ли это как-то на реальной производительности?
2. С какой частотой у вас производся перестроение индексов и какими методами - INDEXDEFRAG либо DBREINDEX ?
3. Каким образом делаете обновление статистики - на автомате или ночным заданием? И делаете ли обновление статистики сразу после перестроения индексов?
4. Какими методами пользуетесь для оптимизации SIFT-таблиц?

Что-то молчат местные гуру Navision, встряну..

1) рекомендованные значения FILLFACTOR довольно .. интересные .. Если все настолько плохо с блокировками, то тут ни 50%, ни даже 10% на мой взгляд не спасут, а ввод-вывод гарантированно будет более тяжелым
2) достаточно редко. Вернее, перестройку индексов саму по себе делать смысла не вижу, так как maintenаnce plan настроен. Что касается того, DBREINDEX или INDEXDEFRAG, разницы нет никакой за исключением того, что INDEXDEFRAG можно в течение рабочего дня сделать (хотя это imho дурной тон - проводить регламентные работы в БД в рабочее время)
3) не вижу необходимости делать обновление статистики после перестройки индекса. Индекс сам по себе содержит статистику (см. sysindexes.statblob). Т.е. перестроенный индекс гарантированно имеет самую свежую статистику. Что касается обновления статистики безотносительно перестройки индексов - есть нюансы, см. http://www.sql.ru/forum/actualthread.aspx?...=sp+updatestats. Пока не вылезало, но стоит иметь в виду
4) ?

[konrad_imported]

После продолжительных экспериментов пришел к выводу, что от обслуживания по maintenаnce plan надо отказаться. Написал свой скрипт, который и запускаю по расписанию, раз в неделю. Использую DBCC DBREINDEX, а после обновление статистики с FullScan. А после обслуживания по maintenаnce plan (еженедельное перестроение индексов без изменения FullFactor, стоит по умолчанию = 0) наблюдалось некоторое замедление выполнения учетных операций. Через пару дней скорость восстанавливалась. Получалось, что перестроение через maintenаnce plan в моем случае ухудшает ситуацию, что само по себе не совсем понятно.
Сейчас склоняюсь к мысли выборочно уменьшить FF у ряда таблиц, в первую очередь у "условно пустых" - всевозможных журналов (типа 81, 14820). Процентов так до 50. Посмотрю, что получится.

Под оптимизацией SIFT-таблиц имел ввиду следующее. По идее таблицы, созданные для индексов со свойством MaintainSIFTIndex, при оптимизации требуют удаления строк с нулевыми суммами. Т.е, как мне представляется, оптимизировать их средствами SQL не представляется возможным. Пока видится только один способ - средствами Навижн, т.е фактически в ручную. Вот и думаю - а как народ справляется?