Конфигурирование сервера Oracle для сверхбольших баз данных

       

Структурный анализ конфигурации


На самом высоком уровне абстракции определение требований к системе является простым делом, поскольку все мы желаем трех вещей: производительности, надежности и низкой стоимости. Однако когда мы преобразуем эти общезначимые цели во что-то конкретное, мы сталкиваемся с решениями, основанными на компромиссах. Для понимания возникших конфликтов, Вы должны сделать две вещи: (1) понять Ваши цели и (2) разобраться в Ваших технологиях. Весь фокус заключается в поиске верной микстуры из скорости, надежности и стоимости, которая удовлетворит специфичные нужды Вашего бизнеса. Это означает что решение, верное для Вас, не всегда будет подходящим для Вашего соседа.

Архитектурные ограничения приходят к нам из двух источников: (1) это экономические ограничения и (2) это технологические ограничения. Экономические ограничения Вам должны быть ясны очень хорошо, и я уверен, Вы не желаете иметь с ними дело. Однако, даже если вообразить, что Вы можете приобрести любое оборудование и программное обеспечение, какое только пожелаете, Вы все равно столкнетесь с ограничениями технологическими.

Предположим, к примеру, что Вы имеете OLTP-приложение и Вы оптимизировали дисковую конфигурацию Вашего сервера Oracle для достижения максимальной производительности при случайном вводе/выводе в ущерб производительности последовательного доступа к данным. Такое решение может выглядеть вполне разумным, поскольку доступ к файлам OLTP-базы данных в подавляющем большинстве основан на операциях чтения с использованием хорошо определенных индексов или хэш-структур, а также произвольных (scattered) операциях записи.

Однако первый же опыт реорганизации индекса на дисковом массиве, оптимизированном исключительно для доступа в условиях высокого параллелизма, потребует на 300–500 процентов больше времени, чем это могло бы занять в другой дисковой конфигурации. Ваше бескомпромиссное решение об оптимизации OLTPпроизводительности напрямую снизит доступность Вашей системы вследствие увеличения продолжительности недоступности индекса во время его реорганизации.

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

  • Производительность

  • Скорость случайного чтения
  • Скорость случайной записи
  • Скорость последовательного чтения
  • Скорость последовательной записи
  • Влияние параллелизма
  • Доступность

    • Частота отказов
    • Продолжительность простоя
    • Снижение производительности при отказах
    • Стоимость

      • Стоимость приобретения
      • Стоимость обслуживания

        В статье мы оценим несколько инструментов и техник в контексте этих категорий. Их описание дано в последующих разделах.



        Содержание раздела