Оптимизация большого табличного пространства

Question

У нас есть очень большая таблица LARGEHISTORY, в которой миллионы записей. В настоящее время таблица использует 50 ГБ табличного пространства, а максимально допустимое табличное пространство в DB2 составляет 65 ГБ (DB2 v9.5.301.436). Стол растет очень быстро, и нам нужно что-то сделать очень быстро, чтобы преодолеть проблему.

База данных: DB2 v9.5.301.436

Решения, о которых мы уже думали:

1. Увеличьте размер табличного пространства, чего можно достичь, используя следующие два параметра:

   1. Изменить табличное пространство LARGEHISTORY от 65 ГБ до 2 ТБ

      Преимущество:

      • Для увеличения табличного пространства нужно выполнить всего несколько команд.

      Недостаток:

      • Нам нужно выполнить reorg, что потребует огромных простоев.

      • Увеличение табличного пространства не даст эффекта, если мы не сделаем реорганизацию

   2. Создайте новое отдельное (2 ТБ) табличное пространство и переместите таблицу LARGEHISTORY из старого в новое табличное пространство, используя процедуру или оператор вставки select

      Преимущество:

      • Для создания нового табличного пространства нужно выполнить всего несколько команд.

      • Таблица может быть безопасно перемещена в новое табличное пространство.

      Недостаток:

      • LARGEHISTORY должна быть переведена в автономный режим, чтобы гарантировать отсутствие транзакции до завершения миграции.

      • Копирование 50 ГБ данных может потребовать огромных простоев. Существует вероятность сбоя процедуры, поскольку она может не справиться с такими огромными данными.

      • Оператор вставки select может не работать для таких огромных данных.

      Примечание: последняя версия DB2 имеет функцию перемещения таблицы из старой в новую без простоя.

2. Архивирование или удаление старых данных

   Преимущество:

   • Может быть легко сделано с помощью запланированной работы.

   Недостаток:

   • Старые данные перейдут в автономный режим. Если потребуется получить отчет, нам потребуется ручное вмешательство.

   • Все существующие отчеты будут затронуты и потребуют изменения.

   • Нам потребуется часто выполнять reorg, чтобы оптимизировать таблицу и табличное пространство для повышения производительности.

3. Создайте новую таблицу в новом табличном пространстве и переименуйте старую таблицу в LARGEHISTORY_OLD

   Преимущество:

   • Мы можем легко вставить новые данные в новую таблицу очень быстро.

   Недостаток:

   • При извлечении нам нужно использовать объединение / объединение всех на старой и новой таблицах или создание нового представления.

   • Мы не можем обновить данные, используя представление (если не используется материализованное представление, которое является дорогим)

   • Все существующие отчеты будут затронуты и потребуют изменения.

Пожалуйста, дайте мне знать, если у вас есть лучший вариант. На данный момент мы рассматриваем вариант 1.1. С опцией 1.1 я не уверен, будет ли какое-либо влияние на код.

Answer 1

Используйте разбиение таблицы. Это требует простоя, однако это предотвратит будущие проблемы: http://www.ibm.com/developerworks/data/library/techarticle/dm-0605ahuja2/

Вы создаете раздел таблицы для каждого периода (месяц, семестр) и просто присоединяете и отключаете разделы.

Вы должны проверить лицензию (издание db2)

Answer 2

create table t1
(    ...
,    sales_date date not null 
         check ( sales_date between '2012-01-01' and '2012-12-31' )
) in tblspc1 index in inxspc1 long in longspc1;

create table t2
(    ...
,    sales_date date not null 
         check ( sales_date between '2013-01-01' and '2013-12-31' )
) in tblspc2 index in inxspc2 long in longspc2;

create table t3
(    ...
,    sales_date date not null 
         check ( sales_date between '2014-01-01' and '2014-12-31' )
) in tblspc3 index in inxspc3 long in longspc3;


create view LARGEHISTORY as (
    select ..., sales_date from t1
    union all 
    select ..., sales_date from t2
    union all 
    select ..., sales_date from t3
)

attach/detach partitions by recreate the view