Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток. Подскажите, есть ли способ ускорить процесс сбора статистики и реорганизацию таблиц? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2012, 14:50 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Loofi, Здравствуйте. По статистике: Можно использовать (особенно для больших таблиц) в RUNSTATS предложения TABLESAMPLE для таблиц и SAMPLED DETAILED для индексов. См. описания этих опций по ссылке. По реорганизации: Можно использовать в REORG предложение CLEANUP ONLY. См. описание опции по ссылке. Если версия ESE, можете рассмотреть возможность использования MDC или table partitioning и реорганизовывать раздел таблицы, а не всю таблицу целиком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2012, 16:31 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Спасибо, попробую ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2012, 16:42 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Loofi, Можно также запускать обновление статистики и реорганизацию в окна минимальной активности пользователей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2012, 09:45 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Andron, не выйдет. Наши маньяки в субботу в 21:00 работать пытаются, не говоря уже про будние дни. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2012, 10:43 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
LoofiAndron, не выйдет. Наши маньяки в субботу в 21:00 работать пытаются, не говоря уже про будние дни. Можно создать скрипты по реорганизации и сбору статистики. Запускать через планировщик задач в ночное время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2012, 12:29 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
slix, так и делаю. Но таблицы большие, много времени уходит, в ночное время не укладываюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2012, 12:36 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Loofi, К ПО не относится, но если есть возможность, закупите более быстрое дисковое пространство. Ну и при таких раскладах, наверное, стоит подумать о разбиении базы. Тоже проблемы с растущими базами имеются. Хотим разделить на архивную и оперативную БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2012, 12:48 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
slix, дисковое пространство используем довольно-таки производительное, от netApp. А в чём суть технологии разделения на архивную и оперативную БД, если не затруднит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2012, 13:41 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Можно обойтись без скриптов: сделать AUTO_MAINT ON и AUTO_TBL_MAINT ON затем включить AUTO_RUNSTATS и AUTO_REORG. После этого достаточно будет определить окно самообслуживания в которое будут запускаться автоматические операции. Окно автоматического обслуживания проще всего определить в Центре управления > подкл к базе > контекстное меню на базе в левом окне > Конфигурировать автоматическое обслуживание > запускается мастер где устанавливаем необходимые параметры обслуживания. Подробнее см. Автоматическое обслуживание таблиц в DB2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2012, 13:47 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Andron, я понял. Но система - продакшн, почти 24*7. Автостатистика и автореорганизация в указаные промежутки времени игнорируют критичные таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2012, 15:19 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Loofi, А какая редакция DB2? На ESE можно подумать о разбиении таблицы на partition'ы и reorg'и по ним проводить индивидуально (на WSE можно до некоторой степени сэмулировать). Также (если доступна фича) добавить сжатие. Многие большие таблицы жмутся очень хорошо. Реоргам, как и сбору статистики, это сильно поможет (если в CPU не упрётся). Можно также поиграться с размерами страниц и тем, как записи в них пакуются (сжатие тут тоже сыграет свою положительную роль). BTW А как данные вообще меняются? Наверное вообще с этого надо начинать. Преимущественно добавляются или и добавляются, и удаляются (если да, то как, большими "блоками" или поодиночке); как часто апдейтятся (меняет ли это длину записи); как меняются индексируемые поля; можно ли выделить часть данных в таблице, используемую чаще других (отсюда вариант разбиения "текущие" данные - "архив"), и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2012, 12:11 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
CawaSPb, использую ese 9.7.4. В CPU не упрётся, ибо запас "прочности" имеется. Чтения больше чем записи, но и записи не мало. База сама не большая, 90 Гб. Есть проблемы с одной таблицей 13ГБ. Реорганизуется идёт 14 часов, потом столько же времени индексы реорганизует. В принципе, за выходные можно успеть все операции, но ползатели своей работой создают тупиковую ситуацию в ответственный момент. Соответственно, в понедельник вся база сияет лок вэйтами. Работа стоит — таблица реорганизуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2012, 14:05 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Loofi, Ну, варианты тогда: а) разбить на партишены и реорганизовывать их по отдельности. Весьма вероятно, что и реорга при таком раскладе потребуют не все. б) можно использовать такой хак как залоадить всю эту таблицу нафиг в другую, потом их подменить (есть ньюансы). В обоих случаях сжатие может сильно пойти на пользу. Я бы рекомендовал где-либо проверить, насколько таблица жмётся, и при необходимости опцию сжатия докупить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2012, 15:25 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
CawaSPb, вариант а) - мне не разрешат, вариант б) - как-то боязно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2012, 16:34 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
LoofiЕсть проблемы с одной таблицей 13ГБ. Реорганизуется идёт 14 часов, потом столько же времени индексы реорганизует. Как-то мягко говоря не быстро для 13-ти ГБ. А с нетапом точно все нормально ? На том же рейде, где база лежит паралельно никакой тяжелой нагрузки нет ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2012, 16:55 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
sysdummy1, дык в этой же системе ещё 3 базы:256Мб,100ГБ и 210Гб. С нэтаппом всё хорошо. Если остальную нагрузку снять, то таблица реорганизуется за 7 часов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2012, 18:06 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
LoofiCawaSPb, использую ese 9.7.4. В CPU не упрётся, ибо запас "прочности" имеется. Чтения больше чем записи, но и записи не мало. База сама не большая, 90 Гб. Есть проблемы с одной таблицей 13ГБ. Реорганизуется идёт 14 часов, потом столько же времени индексы реорганизует. В принципе, за выходные можно успеть все операции, но ползатели своей работой создают тупиковую ситуацию в ответственный момент. Соответственно, в понедельник вся база сияет лок вэйтами. Работа стоит — таблица реорганизуется. Насколько я понимаю, если табл. работает на select и insert реорганизация не есть жизненно необходимая операция, статистика важнее. А сколько выполняется обновление статистики? Может имеет смысл ограничиться только ею, а реорг оставить на новогодние праздники? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2012, 21:22 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
const64+, суть такова: есть упомянутая таблица и ещё 2 маленькие связанные с ней (на этих двух процесс реорганизации таблицы, реорганизации индексов и сбор статистики проходит за 30 минут. Если в выходные их не реорганизовать, то в понедельник лучше вообще на работу не приходить. Если таблица реорганизована - статистика собирается 9 минут, если нет - не знаю, ждал больше часа, не дождался вырубил. P.S. найдётся чудо, которое под бой курантов залепит тупиковую ситуацию при реорге. Не на этой базе, так на другой. У меня баз мнооого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2012, 22:39 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Интересная ситуация. Что 13, что 7 часов мне кажется многовато. Насколько я помню, у меня на SATA-дисках сопоставимое много быстрее. Недостаточно информации, чтобы понять, почему потребовался reorg. В зависимости от ситуации можно было бы подумать о * подборе правильных pctincrease и pctfree * кластерном индексе, чтобы по возможности поддерживать порядок * каком-то дополнительном индексе/индексах, с целью добиться index only access на критических запросах. Компрессия - это хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2012, 00:13 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Действительно, как-то странно... у меня есть табл. примерно такого объема - но для нее что реорг, что рунстатс выполняются минуты... Вы можете провести эксперимент: сделайте копию БД где-нибудь в другом месте (на других дисках) и посмотрите сколько там займет это времени. P.S. чтобы не мешали, можно перед реоргом либо QUIESCE сделать, ну, или, права отобрать у пользователей... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2012, 08:37 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Loofi, Можете показать для вашей проблемной таблицы вывод команды db2pd -db имя_базы -tcbstats |grep имя_таблицы ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2012, 12:17 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Andron, 0x000007F31FC130F8 2 6 n/a 2 6 R_COMPONENTS_VALUE DB2ADMIN Perm 3455523 0 0 0 0x000007F31FC130F8 R_COMPONENTS_VALUE DB2ADMIN 0 2053490 2053490 310 0 15291131 5599 355519 753 2816 391 41 0 0 0 - - как-то так ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2012, 12:55 |
|
||
|
Сбор статистики и реорганизация
|
|||
|---|---|---|---|
|
#18+
Inserts Updates Deletes 355519 753 2816 А сколько uptime базы с момента пред активации? Если достаточно большой то приведенная статистика по обновлениям данных говорит в пользу того что частая реорганизация таблицы не является сильно необходимой (кол-во insert по сравнению с update и delete достаточно большое). Насколько я понимаю именно большое число update и delete должно являтся поводом к частой реорганизации таблицы, а здесь не так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2012, 13:55 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=38031048&tid=1601578]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
59ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 179ms |

| 0 / 0 |
