Доброй вечер.
Объясняю ситуацию. Имеем БАЗУ на DB2 9.7
так вот структура таблицы (многим здесь знакома)
имеет много таблиц + одна таблица в которой собирается информация помесячно
немного статистики
Начало реорганизации 25.12.2014 23:46 Общее время
Окончание реорганизации 26.12.2014 6:58 7:11:54
Начало реорганизации 04.01.2015 23:44
Окончание реорганизации 05.01.2015 8:43 8:59:09
Начало реорганизации 02.02.2015 22:14
Окончание реорганизации 03.02.2015 8:06 9:51:51
Начало реорганизации 03.03.2015 20:17
Окончание реорганизации 04.03.2015 6:55 10:38:45
При детальном анализе выяснили, что реорганизация таблицы
ХХХХХХ.PAY
составляет :
25.12.2014 2:06:57
04.01.2015 2:28:16
02.02.2015 3:08:53
03.03.2015 3:24:43
Объем базы:
25.12.2014 - 146 гб
04.01.2015 - 160 гб
02.02.2015 - 177 гб
03.03.2015 - 183 гб
Объем таблиц в байтах по состоянию на 03.03.2015:
PAY 106758144

записей 293 000 000.

1.Сразу оговорюсь по окончании реорганизации делаю ещё раз копию
и потом перегружаю 2 сферы они установленны на других сервера.
есть у кого нибудь варианты моя мысль пока что запуск реорганизации в 1 потоке таблицу PAY а во 2 потоке все остальные таблицы.

2.Тут уже обсуждали я сейчас делаю следующие процедуры
04.03.2015 20:16:41,47 Runstats for all tables
04.03.2015 21:20:30,72 Reorgchk for all tables
04.03.2015 22:24:59,90 Reorg for all tables
05.03.2015 6:34:48,82 ...done...
вот сомнения в процедуре Reorgchk
она обязательна каждый день или нет ?


p.s. Сервер 2008 R2 24 ядра озу 131 гб,
HDD на дисковом массиве
скорость копирования в момент резерного копирования базы от 400 мб/сек до 300 мб/сек
в общем базу в 190 гб сохраняю за 15 мин
пул буферов на DB2 - 3 000 000.

Mark Barinstein2. А как вы пользуетесь результатами reorgchk с скрипте? Если у вас после этого идет "reorg for all tables", то непонятно, зачем это.
Обычная процедура для каждой таблицы, это
- reorgchk (опционально со сбором статистики если есть подозрения, что она не свежая)
- если на предыдущем шаге выяснилось, что это вообще надо:
-- reorg
-- runstats

Альтернативно можно все эти задачи - и по реоргу, и по ранстату, вынести на автомат...

Я так понял последовательность должна быть такая
если я хочу тупо реорганизовать и собрать всю статистику
по всем таблицам
я правельно вас понял?

REORG *.* ALLOW NO ACCESS RESETDICTIONARY;
REORG INDEXES ALL FOR TABLE *.* ALLOW NO ACCESS;
runstats on table *.* with distribution and detailed indexes all;

Mark BarinsteinChumakov_JAЯ так понял последовательность должна быть такая
если я хочу тупо реорганизовать и собрать всю статистику
по всем таблицам
я правельно вас понял?

REORG *.* ALLOW NO ACCESS RESETDICTIONARY;
REORG INDEXES ALL FOR TABLE *.* ALLOW NO ACCESS;
runstats on table *.* with distribution and detailed indexes all;
Бессмысленно делать reorg indexes после offline reorg таблицы. При offline reorg индексы в конце и так перестраиваются.

Тоесть я так понимаю
для полной реорганизации БД мне нужно

REORG *.* ALLOW NO ACCESS RESETDICTIONARY;

runstats on table *.* with distribution and detailed indexes all

И ВСЕ ?

если ето так
простите за ламерский вопрос где это документально прописанно
особенно это
авторПри offline reorg индексы в конце и так перестраиваются.

В продолжении темы
у меня все таблицы находятся в одном табличном пространстве
при этом одна таблица
занимает объем суммы всех остальных таблиц
сейчас её объем 514 000 000 записей

вопрос : есть резон создать ещё одно табличное пространство и перенести туда эту таблицу ?