Интернет-журнал «FORS» Архив номеров На Главную

Практический опыт миграции на Oracle Exadata хранилища данных крупной телекоммуникационной компании

к.ф.-м.н. Ю. Пудовченко,
Expert of Solution Laboratory of FORS Distribution

 

Источник: Статья представляет собой краткое изложение одноименой презентации автора, доложенной на семинаре Oracle DB Community Day, 29 августа 2013 г.

Справка:
Телекоммуникационная компания Orange Communications SA вышла на Швейцарский телекоммуникационный рынок в июне 1999. В настоящее время это третий по численности оператор в Швейцарии. Около 2.5 млн абонентов.

Оборудование: HP Superdome, VMAX, DMX3, Oracle 10.2.0.4 for Itanium.
Билинговая система Amdocs.
Для миграции предназначались BI- и DWH- базы данных, которые представляют собой срезы продуктива, общим объемом около 16ТБ.

Предпослыки к миграции:

Оборудование под BI- и DWH-БД заказчика проработало около 11 лет.В течение этих лет на этот сервер переносились и создавались на нем новые BI- и DWH-приложения заказчика. В результате к моменту миграции на 1 ядро стало приходиться до 5 одновременно работающих процессов. Сервер было загружен круглосуточно, все дни недели. Система хранения также была загружена всегда.

Проблемы заказчика сводились к нескольким очевидным моментам:

Данная модель сервера в настоящее время уже не выпускается. Оракл также ведет политику отказа от НР Itanium, что добавляет рисков. Поэтому добавление памяти и ядер в старую систему является бесперспективным. Учитывая вышеперечисленное заказчик принял решение уходить на новую платформу.

Цели, которые заказчик ставил перед новым решением:

Также было добавлено естественное ограничение: Обновление не должно требовать переписывания написанного ранее кода.

И компания ФОРС предложила Экзадату, потому что Экзадата:

Особенностью Экзадаты является то, что система хранения обходится заказчику 10К/ядро, тогда как полнофункциональная СУБД обходится 47.5К/ядро.
Но полная функциональность не является необходимой.
В большинстве случаев достаточно 1-2 ядер, чтобы обрабатывать подключения к БД.
Достаточно 1-2 ядер для выполнения процессов DataGuard, RAC. По статистике 80% операций в БД –это операции SELECT.
Зная это, Oracle вынес часть СУБД (SQL Engine) на систему хранения и назначил ей цену в 10К/ядро.

В результате около половины ядер в Экзадате способны выполнять только SELECT (система хранения), а другая половина &mgash; являются полнофункциональной СУБД.

Опции БД &mgash; Partitioning, RAC, Active Data Guard, OLAP, Real Application Testing, Label Security,R (Data Mining), Database Vault &mgash; в Экзадате платятся только за ядра БД.

Опции Diagnostic Pack + Tuning Pack в Экзадате тоже платятся только в расчете на ядра БД.

В результате, Экзадата обходится дешевле.

Мы проанализировали AWR заказчика и оценили технические характеристики Экзадаты, к которые бы соответствовали потребностям заказчика. По нашим оценкам получилось 1/4 Экзадаты с High Performance дисками.

Заказчик оказался способен дублировать ETL в 2 системы: старую и новую и смог эксплуатировать Exadata одновременно с старой системой. В результате его пользователи получили возможность работать с двумя системами одновременно и им было позволено выбирать между двумя системами.

Этот подход также позволил заказчику самому решить, когда отключить старую систему.

Таким образом, если бы в процессе миграции на Экзадате произошел катастрофический сбой с потерей всех данных, то у заказчика на этот период всегда был в запасе старый сервер с актуальной БД.

Особенности миграции:

  1. Особенности Заказчика и организации его технологического процесса:
  2. Требуется перенести на Экзадату две БД : BI (8,5T), ODS (6,5T). Версии исходных БД
  3. 10.2. Аппаратная платформа HP UX 11.31. Аппаратная платформа Экзадаты это Intel x86-64. СУБД версии 11.2.0.3.
  4. К перечисленным БД привязаны внешние системы заказчика – web-интерфейсы пользователей, рабочие места аналитиков, IBM DataStage и т.д., – которые оказались несовместимы с версией СУБД 11.2.
  5. Поэтому дополнительно возникла проблема миграции внешних систем на более свежие версии, чтобы они могли работать с СУБД 11.2.0.3 (версия СУБД на Экзадате на тот момент).
  6. Также у заказчика была потребность поднять на Экзадате не только производственные БД, но и сделать для них копии для тестирования и разработки.
  7. В исходных БД у заказчика было более 400 smallfile-табличных пространств.
  8. Предложения и действия Исполнителя:

Мы взяли новую Экзадату:

По другому надо было где-то найти дополнительный дисковый массив или место на массиве размером 10-14 ТБ). Мы не тратили время на выгрузку 10-14ТБ дампа при экспорте и не тратили время на чтение этих объемов при импорте. Таким образом, наши действия были предельно экономными как по ресурсам, так и по времени.

Хочется подчеркнуть, что в процессе импорта с помощью DataPump копируются только табличные данные, (примерно половина от объема файлов БД), и не копируются сегменты индексов и пустые блоки. А это означает, что DataPump генерирует минимальное количество операций I/O на исходной системе, потому что не сканируется весь датафайл. Т.е. ввод-вывод на исходной системе используется максимально экономно.

Как оказалось впоследствии, эта особенность стала краеугольным камнем всего процесса.

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

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

По сравнению к копированием датафалов с использованием RMAN, DataPump имеет некоторые преимущества:

Кроме того, положительным эффектом от DataPump является увеличение плотности данных в новой БД, что положительно сказывыется на производительности, а также исчезают chained rows и migrated rows.

DataPump позволяет гибко реорганизовывать данные, что позволило нам переложит таблицы в новые табличные пространства с помощью опции REMAP_TABLESPACE.

Миграция продолжалась около 3-х месяцев.

После миграции:

В общем, HCC показал себя с хорошей стороны. Отдельные таблицы, например, уменьшились с 1200Гб до 250Гб.Все индексы, построенные над этой таблицей, были удалены за исключением одного, который обеспечивал целостность primary key.

Объем баз уменьшился

Заказчик планирует идти дальше:

Ссылки:

  1. Dispena, Michele Savino “Migrating HP to Exadata” http://prezi.com/igfkkwjnveti/migrating-hp-to-exadata/?auth_key=a20c001386a671a0a2d6920244d1e9931422bd6f
  2. Ю. Пудовченко "Практический опыт миграции хранилища данных телекоммуникационной компании на Oracle Exadata" http://connect.fors.ru/p56371255/