powered by simpleCommunicator - 2.0.56     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Informix [игнор отключен] [закрыт для гостей] / Ещё раз про update statistics
15 сообщений из 15, страница 1 из 1
Ещё раз про update statistics
    #36008680
Leonid Vorontsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Приветствую!

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

1. MEDIUM для всех таблиц (сколько таблиц - столько и таких команд);
2. HIGH для первых колонок всех индексов (сколько таких колонок - столько и команд);
3. LOW для составных индексов.

Думаю, возражений ни у кого нет? Но сейчас встал вопрос о быстродействии этого скрипта. Более подробное рассмотрение показало, что львиная доля времени уходит на "HIGH для первичных ключей"! А теперь, внимание, вопрос. А нужна ли вообще первичным ключам HIGH статистика, если и так известно, что все значения в колонке уникальны?
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36008822
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid VorontsovА теперь, внимание, вопрос. А нужна ли вообще первичным ключам HIGH статистика, если и так известно, что все значения в колонке уникальны?
для предикатов с > < нужна, правда если первичный ключ serial то такие предикаты бессмысленны, но опять же с оговоркой бывают paging запросы по serial-м с > <.

Короче на таблицы с кол-вм записей > 100 тыс, я обычно собираю статистику по 5% записей.
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36008867
zaiets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сделайте не HIGH и посмотрите на планы запросов.

Мы тут все типа умные и можем советовать кто как делает.
Если нужна статистика по поводу уникальности - достаточно даже только лов статистики по всем индексным полям.
К сожалению сервер думает очень часто не так как мы(иногда логику оптимизатора тяжело понять).
Нужно пробовать и сравнивать.

То что приемлимо для одного случая, не обязательно приемлемо для другого случая.
Есть БД вообще без статистики и жалоб на работу нет.
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36009014
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
zaietsСделайте не HIGH и посмотрите на планы запросов.
Мы тут все типа умные и можем советовать кто как делает.
Если нужна статистика по поводу уникальности - достаточно даже только лов статистики по всем индексным полям.
К сожалению сервер думает очень часто не так как мы(иногда логику оптимизатора тяжело понять).
Нужно пробовать и сравнивать.
То что приемлимо для одного случая, не обязательно приемлемо для другого случая.
Есть БД вообще без статистики и жалоб на работу нет.
Полностью поддерживаю.
По своему опыту при наличии врменнЫх ограничений на сбор статистики или больших объемах БД
использовал следующее:
- ежедневный сбор статистики только по тем таблицам, у которых сильно изменлось количество строк (в моем случае, я делал только для таблиц, у которых разница составляла не менее 10%).
Соответствующий запрос - update_stat_need_only.sql
- раз в неделю, в выходной, когда нет рабочей нагрузки (или даже в месяц, если другое не требовалось) делал стандартную процедуру
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36009036
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Vorontsov1. MEDIUM для всех таблиц (сколько таблиц - столько и таких команд);
2. HIGH для первых колонок всех индексов (сколько таких колонок - столько и команд);
3. LOW для составных индексов.
Думаю, возражений ни у кого нет?
Есть :)
1. MEDIUM для всех столбцов, кроме являющихся первыми в индексах
2. правильно
3. Зачем "LOW для составных индексов" если уже сделан "MEDIUM для всех таблиц" ?
К тому же, для разных версий и рекомендации Информикса по этой процедуре несколько отличались.
Например, FAQ 2007 года говорил следующее:
1. Run UPDATE STATISTICS LOW on all tables in the database and drop distributions
2. Run UPDATE STATISTICS MEDIUM on all columns which are in an index, but are not the first column of any index.
3. Run UPDATE STATISTICS HIGH on all columns which are the first column in an index.
4. Run UPDATE STATISTICS on all stored procedures.

Leonid VorontsovА нужна ли вообще первичным ключам HIGH статистика, если и так известно, что все значения в колонке уникальны?
Они то уникальны, но их распределение может быть не однородным.
При отсутствии распределений оптимизатор на предикат > и < будет брать вероятность 0.33, а это очень много для больших таблиц.
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36009520
Фотография Тан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Vorontsov
2. HIGH для первых колонок всех индексов (сколько таких колонок - столько и команд);

у меня возражение: я считаю, надо сделать сколько таблиц - столько команд
update statistics high for table t(f1,f2,f3)
будет один проход вместо трех, если ресурсы позволят

если я правильно поняла, сейчас у вас столько операторов, сколько у таблицы индексов
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36020642
Алексан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТанLeonid Vorontsov
2. HIGH для первых колонок всех индексов (сколько таких колонок - столько и команд);

у меня возражение: я считаю, надо сделать сколько таблиц - столько команд
update statistics high for table t(f1,f2,f3)
будет один проход вместо трех, если ресурсы позволят

если я правильно поняла, сейчас у вас столько операторов, сколько у таблицы индексовСогласен с Тан, по одной команде на каждый столбец пускали в 7-ке, а в 9-ке, начиная с какого-то-младшего-релиза 9.30, было введено усовершенствование, заключающееся в том, что если написать одну команду для всех столбцов, то сервер, если ему хватает памяти, выполняет лишь одно сканирование, читая все указанные столбцы за раз, что, конечно, быстрее. Подробнее можно узнать, если поставить SET EXPLAIN ON перед выполнением команды UPDATE STATISTICS - сервер запишет детали в файл.
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36020807
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Полезный материал на данную тему:

1. Get the most out of Informix Dynamic Server optimizer through UPDATE STATISTICS -
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0803changappa/?S_TACT=105AGY82&S_CMP=GENSITE

2. Understanding and Tuning Update Statistics - http://www.ibm.com/developerworks/db2/zones/informix/library/techarticle/miller/0203miller.html

С уважением,
Вадим.
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36021596
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АлексанСогласен с Тан, по одной команде на каждый столбец пускали в 7-ке, а в 9-ке, начиная с какого-то-младшего-релиза 9.30, было введено усовершенствование, заключающееся в том, что если написать одну команду для всех столбцов, то сервер, если ему хватает памяти, выполняет лишь одно сканирование, читая все указанные столбцы за раз, что, конечно, быстрее.
В принципе, все правильно.
Но хочу заметить, что для относительно небольших таблиц, которые целиком будут в буферном пуле, выигрыш будет небольшим, а для больших таблиц просто не будет хватать ресурсов и сканирование и обработка все равно будут идти по столбцам.
Когда-то давно, когда в 9.3 это появилось, проверил, заметного прироста не увидел, плюнул и скрипты менять не стал. Возможно сейчас кто то проверит и покажет существенный прирост производительности ?
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36021649
Leonid Vorontsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> 1. MEDIUM для всех таблиц
Во-первых, очень sorry - не просто medium, а medium distributions only. Ну, очепятка, с кем не бывает. Дальше, после общения с суппортом, прочтения всех линков по теме и ознакомившись с http://onlinedomus.net/pmwiki.php?n=IxScripts.Updstats, сделал-таки по-другому, а именно:
1. MEDIUM DISTRIBUTIONS ONLY для всех колонок, которые не являются первыми в индексах (сколько таблиц - столько и команд с перечислением всех таких колонок);
2. HIGH DISTRIBUTIONS ONLY для всех колонок, которые являются первыми в индексах (сколько таблиц - столько и команд с перечислением всех таких колонок);
3. LOW для всех любым способом проиндексированных колонок - тоже по одной команде на каждую таблицу.
Так вот, выйгрыш по времени составил порядка 8% :-(, так что, и непонятно, стоила ли игра свеч...
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36021708
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid VorontsovТак вот, выйгрыш по времени составил порядка 8% :-(, так что, и непонятно, стоила ли игра свеч...
выигрыш по сравнению с чем ?
- весь новый скрипт по сравнению со старым ?
- только HIGH ("львиная доля времени уходит на "HIGH для первичных ключей") ?
- использование одной команды на таблицу с перечислением столбцов вместо множества команд на каждую таблицу ?

А 8%...так как изначально никаких конкретных целей не ставилось, то и результат непонятен.
Если, например, взять 4 часа (240 мин) на весь US, то 8% составит почти 20 минут. Вроде прилично.
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36021764
Leonid Vorontsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я имел в виду, что весь новый скрипт выполняется чуть-чуть быстрее, чем весь старый. То есть, если старый выполнялся около 16 часв, то новый - около 15. Ну, а задача и стояла расплывчато - ускорить. Хотелось бы, конечно, в разы...
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36023827
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid VorontsovЯ имел в виду, что весь новый скрипт выполняется чуть-чуть быстрее, чем весь старый. То есть, если старый выполнялся около 16 часв, то новый - около 15. Ну, а задача и стояла расплывчато - ускорить. Хотелось бы, конечно, в разы...
А почему бы не попробовать предложенный мной способ (только изменяемые на определенный процент таблицы или только те, которые активно апдейтятся без существенного изменения кол-ва строк, т.е. просто по списку) ?
А также поиграться с medium (кстати. сколько занимает первый шаг в абсолютном исчислении ?)
И какой общий размер БД ? А то 16 часов как то многовато....
Может сортировки можно ускорить - там, обычно, есть несколько возможностей.
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36025465
Leonid Vorontsov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> почему не попробовать только изменяемые на определенный процент таблицы?
Обычно так и делалось. И будет делаться впредь. Но сейчас задача специфическая. Планируется поэтапно сливать базы департаментов в одну централизованную. То есть на каждом этапе сильно меняться будут практически все таблицы. И хотелось, чтобы в промежутках между этапами статстика была в порядке.
...
Рейтинг: 0 / 0
Ещё раз про update statistics
    #36041535
Алексан
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vasilisВ принципе, все правильно.
Но хочу заметить, что для относительно небольших таблиц, которые целиком будут в буферном пуле, выигрыш будет небольшим, а для больших таблиц просто не будет хватать ресурсов и сканирование и обработка все равно будут идти по столбцам... Память тоже, конечо, стоит настроить - поставить PDQPRIORITY или хотя бы DBUPSPACE (см. здесь , раздел "Переменные окружения") . Мой опыт показывает, что ускорение есть, и заметное. Обусловлено оно тем, что уменьшается число сканирований - представьте, что вместо 20 сканирований на 20 столбцов можно получить только 10 сканирований (памяти не так много, поэтому за одно сканирование распределение строится только для двух столбцов)! И чем больше таблица при этом, тем заметнее разница.
Если же память для сортировок вовсе не настраивать, то по-умолчанию используются 15 мегабайт, чего, начиная с некоторого размера таблицы, хватает только на один столбец. В результате приходим к тому, что если таблица небольшая, то и ускорение назначительно, а если достаточно большая, то всё работает по-старому (потому что памяти для сортировки не хватает).
Я рекомендую попробовать на одной большой таблице без каких-либо скриптов - установите SET EXPLAIN, PDQ-параметры достаточно большими, попросите построить только распределение (distributions only), иначе сервер сначала по индексам гулять будет, и посмотрите что получится... В sqexplain.out Вы увидите, сколько данных сервер собирается сортировать и сколько памяти использует, и сможете подстроиться.
...
Рейтинг: 0 / 0
15 сообщений из 15, страница 1 из 1
Форумы / Informix [игнор отключен] [закрыт для гостей] / Ещё раз про update statistics
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]