Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Новый топик    Ответить
 Rebuild индексов после реорганизации. Помогите!!!!  [new]
mataba
Member

Откуда:
Сообщений: 8
Доброго всем дня!

Имеем такую проблему, уже повторяется второй раз... Есть большая таблица (190 000 000 строк),
после реорганизации которой, происходит rebuid индексов.
Почему индексы помечаются как invalid?
Перестройка индексов занимает очень длительное время. Реорганизацию делаем с опцией read access.
Проконсультируйте, как правильно подойти к процессу реорганизации: делать ее 1 раз в неделю,
или несколько раз в неделю?
И с доступом для чтения или в монопольном режиме?
22 сен 17, 16:40    [20816851]     Ответить | Цитировать Сообщить модератору
 Re: Rebuild индексов после реорганизации. Помогите!!!!  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4640
mataba,

Добрый день.

Такой дизайн у offline реорганизации:
REORG INDEXES/TABLE command
A classic table reorganization (offline reorganization) rebuilds the indexes during the last phase of the reorganization.

По поводу того, когда надо делать, ответ может дать REORGCHK command. Вы ей пользуетесь?

Ответ на вопрос, в каком режиме делать, зависит от нескольких факторов: характер работы пользователей в вашей системе во время работы reorg, возможность / целесообразность применения inplace (online) reorg вместо offline и т.д.
24 сен 17, 13:01    [20818832]     Ответить | Цитировать Сообщить модератору
 Re: Rebuild индексов после реорганизации. Помогите!!!!  [new]
Chumakov_JA
Member

Откуда:
Сообщений: 203
Проблемма в том, что нас тут много. Которые не могут анализировать состояние таблиц перед реорганизацией
1. ПО которое дают разработчики для обновления БД, даже не пытается провести анализ. В нем тупо после каждого изменения стоит реорганизация таблиц а также сбор статистики. Контролировать что поменяли или не поменяли разработчики это значит взять на себя всю ответственность при обновлении а это вероятность 50/50.
2. Все сообщения на тех потдержку заканчиваются ответом "когда проводили последнюю реорганизацию?"
А все по одной причине их ПО работает на OpenJPA 2.1, и состояние индексов для них это все

Поэтому и хотим как то все это ускорить т.к. Ресурсы есть а вот скорости совсем удручают.
В данном случае у нас таблица 960 миллионов записей в ней 12 индексов все время реорганизации около 11-12 часов. При этом сервер примерно 2-3 часа реально читает и записывает данные и занят реорганизацией а остальное время он просто немного занят % на 5-10. В db2diag.log между этими сообщениями ничего нет.

mataba - простите за вмешательство в ваше сообщение.

p.s. Попробовал как то после сбоя когда reorgchk реально сказал что индексы дохлые
Запустить реорганизацию online но все оказалось печально
24 сен 17, 22:34    [20819432]     Ответить | Цитировать Сообщить модератору
 Re: Rebuild индексов после реорганизации. Помогите!!!!  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2514
Когда происходит реорганизация, строки меняют места - следовательно, rid'ы меняются - следовательно, индексы не могут не стать инвалидными. Я сомневаюсь, что какая-то другая СУБД справилась бы лучше.

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

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

Существует и "партишионирование для бедных": разбить таблицу на несколько, назначив на них constraint's, по которым строка попадает точно в одну, и объединить со view через union all.

то есть вместо table t создать
create table t1 (... constraint c1 check ...)
create table t2 (... constraint c2 check ...)
....
create table tn (... constraint cN check ...)
create view t as
select * from t1
union all
...
select * from tn.
и при попытке вставки insert into t ... строки
все constraints c1...cn, кроме одной, должны давать false

(Кстати, не все знают, что, в отличие от where, где не выбираются строки, для которых предикат даёт undefined, СУБД позволяет вставить строку, если результат предиката в check оказался undefined).

Добавить много-много ОЗУ, перейти с винчестеров на ССОД.

Сменить софт, найти тот, у которого разработчики более вменяемые.
25 сен 17, 11:03    [20819979]     Ответить | Цитировать Сообщить модератору
 Re: Rebuild индексов после реорганизации. Помогите!!!!  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4640
@Chumakov_JA

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

Если надо ускорить процесс, то это потребует, скорее всего, структурных изменений. Например, секционирование таблицы, чтобы реорганизовывать, скажем, только одну последнюю секцию. Или использование DPF, но это уже серьезная переделка.

Chumakov_JA
p.s. Попробовал как то после сбоя когда reorgchk реально сказал что индексы дохлые
Запустить реорганизацию online но все оказалось печально
Дохлые индексы? Это как? Вывод утилиты можете показать?
Что именно оказалось печальным?
25 сен 17, 11:18    [20820026]     Ответить | Цитировать Сообщить модератору
 Re: Rebuild индексов после реорганизации. Помогите!!!!  [new]
Chumakov_JA
Member

Откуда:
Сообщений: 203
Mark Barinstein,

По первому пункту. У нас есть лицензия ESE но в тех задании строго прописанно WSE
Соответственно разработчики не могут использовать многораздельный таблицы.
А мы не можем перейти на многораздельный таблицы без одобрения которое нам не дали.
Для себя протестировали работу ПО я с многораздельными таблицами, производительность на 40% повысилась также реорганизовали только те части которые были последние. Все просто замечательно. Но увы ответ "не типовая схема"
По второму пункту. За день сервер выключали "случайно" раза три.
После этого reorgchk выдал что индексы непригодны ответ не сохранил.
Запустил реорганизацию online, но вечером нужна копия базы и вся реорганизация в пустую.
Да и пока шла сама реорганизация блокировки были ну очень часто. 2 дня доказывания что только полная реорганизация поможет и итог 11 часов ожидания и все просто стало летать.

p.s. Тут ещё один момент когда базу проэктировали разработчики все таблицы собрали в одно табличное пространство.
25 сен 17, 23:16    [20822148]     Ответить | Цитировать Сообщить модератору
 Re: Rebuild индексов после реорганизации. Помогите!!!!  [new]
Chumakov_JA
Member

Откуда:
Сообщений: 203
Victor Metelitsa,
http://www.sql.ru/forum/1264275/reorg-table-kak-svesti-k-minimumu-vremya-dlya-provedeniya-reorganizacii-tablic-i-indeksov
Там практически все ответы на Ваши предложения
25 сен 17, 23:19    [20822157]     Ответить | Цитировать Сообщить модератору
 Re: Rebuild индексов после реорганизации. Помогите!!!!  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2514
Chumakov_JA
Victor Metelitsa,
http://www.sql.ru/forum/1264275/reorg-table-kak-svesti-k-minimumu-vremya-dlya-provedeniya-reorganizacii-tablic-i-indeksov
Там практически все ответы на Ваши предложения

Чудес же не бывает.
26 сен 17, 09:23    [20822527]     Ответить | Цитировать Сообщить модератору
 Re: Rebuild индексов после реорганизации. Помогите!!!!  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2514
Chumakov_JA
Mark Barinstein,
Да и пока шла сама реорганизация блокировки были ну очень часто. 2 дня доказывания что только полная реорганизация поможет и итог 11 часов ожидания и все просто стало летать.

Почему "только полная реорганизация поможет" и в чём заключалось доказывание? Не в битых же индексах и не в том, что были тормоза, пока реорганизация шла?
26 сен 17, 09:26    [20822534]     Ответить | Цитировать Сообщить модератору
 Re: Rebuild индексов после реорганизации. Помогите!!!!  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4640
Chumakov_JA
По первому пункту. У нас есть лицензия ESE но в тех задании строго прописанно WSE
Соответственно разработчики не могут использовать многораздельный таблицы.

Table partitioning, начиная с 10.5, доступно в WSE.
Functionality in DB2 product editions and DB2 10.5 offerings.
26 сен 17, 14:30    [20823954]     Ответить | Цитировать Сообщить модератору
 Re: Rebuild индексов после реорганизации. Помогите!!!!  [new]
Chumakov_JA
Member

Откуда:
Сообщений: 203
Mark Barinstein,

Будем знать НО по ТЗ должно быть DB2 9.7.6 так вот для переноса таблиц в другое табличное пространство использовать команду move table (могу ошибаться) не получилось использовать. В 9.7.6 есть косяк если описание полей на русском языке.
Выход простой установить fix pack 10, так вот официально нельзя.
А вы про 10.5
А вот такой вариант в момент когда мне нужно провести реорганизацию таблицы
Я меняю параметры DB2 так чтобы все ресурсы были отданы только на реорганизацию
Вопрос какие параметры ускорят реорганизацию?
27 сен 17, 00:13    [20825466]     Ответить | Цитировать Сообщить модератору
 Re: Rebuild индексов после реорганизации. Помогите!!!!  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4640
Chumakov_JA,

Через неделю 9.7 снимается с поддержки. Вам, по-хорошему, все равно надо бы задуматься о миграции.
Reorg - операция не быстрая. Вы не ускорите кардинально ее изменением параметров.
Если есть возможность, попробуйте "вручную" переносить данные из этой таблицы в новую такую же с помощью load из курсора или параллельног insert select с активацией в начале транзакции not logged initially у цели. Но оба этих подхода имеют минусы, и в обоих случаях это пересоздание таблицы и связанных объектов.
27 сен 17, 08:34    [20825669]     Ответить | Цитировать Сообщить модератору
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить