Влияние RAID-технологии на работу оптимизаторов баз данных

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

Сложные оптимизаторы баз данных имеют информацию о том, сколько дисков доступно БД, и используют эту информацию при разрешении планов запросов. Некоторые оптимизаторы также используют информацию более низкого уровня, такую как время позиционирования головок и пропускная способность дисков.

При использовании RAID уровней 0, 3 или 5 не существует взаимооднозначного соответствия между физическими и логическими дисками. Другими словами, одно "дисковое устройство" массива RAID 0 или RAID 5 фактически задействует несколько физических дисков. Аналогичное утверждение справедливо и для дисковых массивов ТЗ и АЮОО, где LUNs скрывают фактическое размещение дисков, входящих в состав массивов. Оптимизаторы баз данных могут быть введены в заблуждение этой очевидной нехваткой устройств, предполагая, что пропускная способность дисков ограничена и может стать "узким местом". Результатом такого "заблуждения" могут оказаться не вполне оптимальные планы запросов и особенно в системах DSS.

Для СУБД не существует никакого способа, чтобы определить для всех RAID-устройств, которые существуют на сервере, топологию дисков, относящихся к этим устройствам. Иногда варианты, выбранные оптимизатором, являются важными для производительности ваших приложений, что особенно справедливо для приложений DSS, где эффективные планы запросов представляют собой один из ключевых факторов, определяющих время завершения запросов.

В таких случаях оптимизатору БД можно попытаться помочь. Каким образом? Далее приведены некоторые предложения применительно к средам DSS:

•             Используйте менеджер томов для того, чтобы создать несколько томов на RAID-устройствах или на LUNs вплоть до того же числа томов, сколько дисков относятся к данному логическому устройству. Например, если пять физических дисков проходят под некоторым LUN или содержатся в слое, можно было бы создать пять логических томов на этом устройстве. В противном случае оптимизатор БД мог бы прийти к неправильному выводу о том, что этот "единственный диск" станет "узким местом" и принять такой план, который минимизирует доступ к этому диску.

•             Не увлекайтесь количеством логических томов, которые вы можете создать на одном и том же физическом диске. Следует иметь в виду, что оптимизатор БД может предположить, что каждый логический том представляет собой отдельный физический диск.

•             Избегайте создания нескольких логических томов на одном и том же диске для одного и того же табличного пространства. Оптимизатор БД может предположить, что это табличное пространство фактически распределено между несколькими физическими дисками.

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

Достоинства и недостатки менеджеров томов
Изменения имен дисковых устройств
Автоматическое восстановление при обнаружении ошибок
Смешанные виды хранения данных
Рекомендации по размещению данных

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


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