Разбивка таблиц на разделы

Оценить
(1 голос)

Таблицы могут быть разбиты на разделы, что позволяет выполнять обработку запросов в параллельном режиме, а также сократить конкуренцию при блокировках. В процессе разбивки создается несколько цепочек страниц для таблицы, что весьма существенно повышает производительность операций вставки и параллельной обработки запросов, и при этом допускается также параллельная загрузка и dbcc. Ранние версии ASE допускали возможность разбивки только heap-таблиц (с динамически распределяемой памятью), однако начииая с ASE 11.5, вы можете создавать кластерные индексы в разделенных таблицах. Вы можете решиться на разбивку таблицы по следующим причинам:

•             чтобы создать многочисленные точки вставки для Ьеар-таблицы

•             чтобы распределить табличные операции ввода/вывода по нескольким устройствам

•             чтобы ускорить операции загрузки БД

•             чтобы повысить производительность параллельных запросов (каждый рабочий процесс при сканировании способен считывать отдельный раздел)

Разбивка не гарантирует повышение производительности; для разбивки должны быть отобраны правильные таблицы, и разбиты они должны быть корректно. Чтобы указать "подходящие кандидатуры" для разбивки, следуйте следующим советам:

•             Используйте sp_sysmon для нахождения Ьеар-таблиц с конфликтом при блокировках на последней странице. При разбивке Ьеар-таблиц создается множество точек вставки, в результате чего может поддерживаться больше параллельных операций вставки.

•             Ищите таблицы с низкой (менее 90%) частотой попаданий в кэш. Если данные уже находятся в кэше, то разбивка таблицы может не привести к повышению производительности (хотя некоторые запросы могут получить преимущества от использования многочисленных потоков).

Запросы, сканирующие менее 20 страниц таблицы данных, не будут выполняться в параллельном режиме. Если вы разрешаете параллельную обработку запросов, то остановитесь на разбивке таблиц только-для-чтения (или преимущественного чтения) в том случае, если приходится считывать более 20 страниц данных в одном запросе.

Разбивка может привести к проблемам в производительности, если ее реализация и мониторииг производятся некорректно. Разбивка таблиц с частыми операциями вставки может в результате привести к перекосу (отклонению), или неравномерно заполненным разделам, в таблицах с кластерными индексами. Даже небольшое количество отклонений может привести к неожиданному ухудшению производительности. Неар-таблицы обычно не являются объектами отклонения.

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

вы предоставляете достаточный объем пространства для построения обычных индексных конструкций.

Ниже приводятся некоторые практические соображения, относящиеся к организации разделов:

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

•             Каждый раздел всегда должен храниться на своем собственном устройстве, а устройства должны быть разбросаны (распределены) по как можно большему количеству дисков. Оптимизатор не принимает во внимание размещение раздела, а размещение большого количества разделов таблицы на одном шпинделе скорее может привести к проблемам ввода/вывода, чем к его облегчению, в частности в ситуациях, связанных с параллельной обработкой.

•             Разделы повышают параллелизм операций ввода/вывода за счет потребления большего количества ресурсов ЦП. Следовательно, добавление разделов будет полезным до тех пор, пока не произойдет перегруз ЦП.

Системные базы данных
Параллельная обработка
Adaptive Server IQ with Multiplex
Индексирование
Ввод/вывод и кэши

Добавить комментарий


Защитный код
Обновить