Замечания по выпуску


8.4 Глава 6. Компилятор SQL

Нужно изменить следующие разделы:

8.4.1 Реплицируемые сводные таблицы

Этот раздел должен содержать следующую информацию:

Реплицируемые сводные таблицы могут использоваться для обеспечения локального выполнения объединений. Например, если есть схема типа "звезда", в которой большая таблица фактов распределена по двенадцати узлам, объединения между таблицей фактов и таблицами ассоциаций будут более эффективны, если эти таблицы размещены совместно.

Если все эти таблицы размещены в одной группе узлов, для локально выполняемого объединения корректно может быть распределена только одна таблица ассоциации. Все другие таблицы ассоциаций нельзя будет использовать в локально выполняемом объединении, так как столбцы объединения таблицы фактов не будут соответствовать ключу разделения таблицы фактов.

Например, вы можете иметь таблицу фактов FACT (C1, C2, C3, ...), для разделения которой используется столбец C1, таблицу ассоциации DIM1 (C1, dim1a, dim1b, ...), для разделения которой используется столбец C1, таблицу ассоциации DIM2 (C2, dim2a, dim2b, ...), для разделения которой используется столбец C2, и т.д.

В этом примере можно увидеть, что объединение между таблицами FACT и DIM1 будет выполняться лучше всего, так как для предиката DIM1.C1 = FACT.C1 будет выполняться условие совместного размещения. Обе эти таблицы используют для разделения столбец C1.

Для объединения с DIM2 с предикатом WHERE DIM2.C2 = FACT.C2 не может использоваться локально выполняемое объединение, так как для разделения таблицы FACT используется столбец C1, а не C2.

В этом случае хорошим решением может быть репликация таблицы DIM2 в группу узлов таблицы фактов. При этом объединение может быть выполнено локально на каждом разделе.
Прим.:Реплицируемые сводные таблицы используются для репликации внутри одной базы данных. При репликации между базами данных используются регистрации и управляющие таблицы, а данные располагаются в различных базах данных и в различных операционных системах. Дополнительную информацию о репликации между базами данных смотрите в руководстве Replication Guide and Reference.

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

Реплицируемую сводную таблицу можно также создать в многоузловой группе узлов. Это та же группа узлов, в которой размещены таблицы большого объема. В этом случае копии исходной таблицы создаются на всех разделах этой группы узлов. В такой среде объединения между большой таблицей фактов и таблицами ассоциаций будут с большей вероятностью выполняться локально, и не будет выполняться передача данных исходной таблицы на все разделы.

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

После использования оператора REFRESH следует выполнить утилиту RUNSTATS для реплицируемой таблицы, так же как для любой другой таблицы.

Реплицируемые таблицы можно использовать прямо в запросе. Однако нельзя использовать с реплицируемой таблицей предикат NODENUMBER(), чтобы узнать данные таблицы на конкретном разделе.

Чтобы узнать, используется ли созданная реплицируемая сводная таблица для запроса, в котором указана исходная таблица, можно использовать средство EXPLAIN. Сначала убедитесь, что существуют таблицы EXPLAIN. Затем создайте план объяснения для интересующего вас оператора SELECT. Наконец, используйте утилиту db2exfmt для форматирования выходных данных EXPLAIN.

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

8.4.2 Концепции доступа к данным и оптимизация

Изменен раздел "Обращение к нескольким индексам" в разделе "Принципы просмотра индексов".

Перед примечанием в конце этого раздела добавьте следующую информацию:

Чтобы реализовать возможности улучшения производительности от использования динамических битовых образов при просмотре нескольких индексов, может понадобиться изменение значений параметра конфигурации базы данных sortheap (размер кучи сортировки) и параметра конфигурации менеджера баз данных sheapthres (порог кучи сортировки).

Если в плане доступа используются динамические битовые образы, требуется дополнительный объем кучи сортировки. Если заданное значение sheapthres относительно близко к значению sortheap (то есть для одновременных запросов они различаются менее чем в два или три раза), для работы с динамическими битовыми образами будет использоваться гораздо меньше памяти, чем предполагал оптимизатор.

Чтобы исправить эту ситуацию, увеличьте значение sheapthres по отношению к значению sortheap.

Изменен раздел "Стратегии поиска для объединения типа "звезда"" в разделе "Терминология предикатов".

В конце этого раздела добавьте следующую информацию:

Для динамических битовых образов, создаваемых и используемых в технологии объединения типа "звезда", используется память кучи сортировки. Дополнительную информацию о параметре конфигурации базы данных sortheap (размер кучи сортировки) смотрите в главе 13, "Конфигурирование DB2" книги Руководство администратора: Производительность.


[ Начало страницы | Страница назад | Страница вперед | Содержание | Индекс ]