[Из песочницы] Опыт обновления Oracle 11.2.0.4 до 12c
Всех приветствую. Я представитель отдела по развитию биллинговых систем, в региональном операторе связи. Хочу поделиться опытом обновления Oracle до версии 12c (12.2.0.1)
(Почему-то многие путают процесс апгрейда с миграцией, вот здесь доходчиво расписано когда и в каких случаях употреблять то или иное значение). Все мероприятия происходили в прошлом году.
Организационные мероприятия
С начала года начали организационные подготовительные работы, в первую очередь необходимо было развернуть тестовую зону. Нет, тестовая зона у нас имелась, только Oracle в ней развернут под SUSE. А в промышленной среде Oracle у нас установлен на серверах с платформой IA-64, и HP-UX в качестве ОС, а развертывание HP-UX в виртуальной среде оказалось тем еще квестом — HP-UX в качестве гостевой ОС поддерживает только одна VM — Integrity Virtual Machines, которая должна быть установлена на сервере с той же архитектурой. В итоге решили проводить работы на production standby-db-сервере.
Вторым шагом была настройка ОС HP-UX (согласно рекомендациям Oracle). Принимая во внимание, что у нас нет ни «тестовой зоны», ни ТП на HP-UX, начали искать специалиста по HP-UX, который бы взялся за эту работу с учетом рисков. Среди знакомых специалистов таковых не оказалось, начали обзванивать менеджеров HP. Конечно же диалог с менеджером сводился к приобретению техподдержки, иначе и говорить не о чем.
Последний раз мы проводили расчет стоимости за техническую поддержку HP (аппаратного и программного обеспечения) лет 5 назад. Ради интереса запросил провести оценку стоимости ТП. За ту стоимость, что нам предоставили, можно развернуть небольшой ЦОД, и плюс техподдержку на все на 3 года, поэтому вопрос о ее приобретении отпал.
Пробовали рассмотреть варианты с техподдержкой только на софт, с ограниченной ТП на время работ, искали у системных интеграторов, залежавшийся б/у сервер на Itanium, в качестве тестовой зоны, но все безрезультатно.
В итоге откликнулся специалист от поставщика биллинга, за что ему большое спасибо.
Настройки ОС были проведены, как указано выше, на standby-db-сервере. Сам Oracle обновили на тестовой зоне под RHEL 6.5. Обошлось все без проблем. Воодушевленные результатом мы запланировали обновление в промышленной зоне в ночь с 24 по 25 октября, с учетом, что к началу следующего рабочего дня, все должно было заработать (по нашему идеальному плану).
Подготовка к процессу обновления
Начали подготовку днем 24 октября, совместно с командированным к нам DBA.
Были выставлены требуемые параметры, настроили внеочередные backup-ы, очистили некоторые «тяжелые» таблицы. Следом остановка сервисов, бизнес-процессов, job-ов и тд. В общем, подготовка заняла почти весь день, сам же процесс обновления начался около 12 ночи и завершился в 4 утра. После начали запускать все в обратном порядке, время около 6 утра, мы уже мысленно находились дома, готовые отойти ко сну, но не тут-то было. Все сервисы запустились, кроме сервера приложений. Выяснили, что его служба отказывалась стартовать из-за того, что версия Oracle Client (11.2.0.1) была ниже серверной, пришлось обновлять все сервера, где клиентская часть была ниже допустимой версии. Обновили — заработало.
Оказалось это была лишь малая из проблем. Во время проверки работоспособности бизнес-процессов. обнаружили, что функциональность сервера профилей абонентов нарушена. При обращении к определённым данным выскакивала ошибка ORA-00600[qmcxdGetQNameInfo2], которая, по сути, и являлась корнем проблемы. Открыли service request (SR) в support Oracle в статусе «Severity 2», параллельно искали возможные пути решения проблемы. Ситуация накалялась тем, что мы не могли ни регистрировать абонентов, ни обслуживать: система обслуживания абонентов (SBMS), при регистрации абонента не могла создать профиль, CRM также не функционировал.
К вечеру нагрузка спала, и ситуация нормализовалась. Кроме того, у нас появился вариант решения проблемы. Мы выяснили, что ошибки возникают только при обращении к полям типа XML TYPE. При этом сам компонент XDB (Oracle XML DB) был валидным. Было решено попробовать выставить параметр COMPATIBLE в значение 12.2, который находился в это время ещё в значении 11.2, так как в Database Upgrade Guide по версии 12.2 говорится: Do not make this change until you are ready to upgrade, because a downgrade back to an earlier compatibility level is not possible after you raise the COMPATIBLE initialization parameter value. т.е. после выставления этого параметра в соответствующее значение возврат на прежнюю версию становится невозможным. Но в другом документе Oracle (Doc ID 1292089.1) есть следующее замечание: …after the upgradeoperation, you must set the database compatibility to at least 12.1.0.1. If the compatibility is less than 12.1.0.1 then an error is raised when you try to use Oracle XML DB. Таким образом мы решили попробовать исправить ситуацию, пожертвовав возможностью downgrade. Но, как выяснилось, данное решение не принесло результата. После этого мы отложили решение проблемы до утра, так как отсутствие сна сказывалось, и соображать с каждым часом было труднее. Кроме того, нужно было дожидаться ответа от саппорта Oracle.
Решение главной проблемы (BUG 26814058)
Утром 26 октября мы получили ответ от Oracle, который определил проблему как: unpublished BUG 26814058 — SELECT FROM TABLE WITH XMLTYPE FAILS WITH ORA-600 [QMCXDGETQNAMEINFO2], который классифицируется как «Code/Hardware Bug» в статусе 11. Bug относительно свежий (зарегистрирован 16 сентября), причём ещё на предыдущей версии (12.1). Ни патча, ни workaround для него не существовало на тот момент (возможно и на текущий). Статус 11 говорит о том, что ведётся работа над патчем, но при этом никаких точных сроков выпуска патча от Oracle не получить, даже если они его выпустят через пару дней. Подняли уровень нашего SR до «Severity 1», но надежды на быстрое решение от Oracle не было. Нужно было принимать решение — возвращаться на 11 версию или пытаться фиксить то, что есть.
Второй день без обслуживания абонентов сказывался, поэтому приняли решение дождаться ночи и откатываться на 11 версию, задействовав standby-db-сервер, так как вернуться при помощи штатной процедуры downgrade мы уже не могли из-за параметра COMPATIBLE. Посовещавшись и проанализировав таблицы выяснилось, что не работала значительная часть сервисов, но все они были завязаны на сервер профилей (GUP). Более того, удалось локализовать проблему до двух проблемных таблиц. Особую сложность представляла одна из них, так как в ней было более 10 млн. записей (около 4Гб). Ошибка возникала как при попытке обработать данные полей типа XML TYPE, так и при попытке экспорта данных таблиц. Операция «createtable… as select…» проходила, но результата не давала, данные в новой таблицы тоже оказались повреждёнными.
Решили попробовать извлечь данные со standby-db-сервера посредством DATA PUMP, который находился в состоянии «ДО обновления». Но оказалось, что данные там тоже повреждены. Дело в том, что при подготовке к обновлению в одном из шагов была осуществлена пересборка XDB в соответствии с рекомендациями Oracle. Предположительно, данные в столбцах XML TYPE повреждаются в результате именно этой операции, которая, кстати, происходит и непосредственно при миграции на Oracle 12.2, так как начиная с 12 версии компонент XDB становится обязательным и переустановить его уже невозможно. Однако инструкция по обновлению требует, чтобы все компоненты БД были валидными в момент обновления, в противном случае их следует переустановить.Таким образом к концу рабочего дня проблема свелась к поиску возможности извлечения неповреждённых данных таблиц.
Заключение
В самый критический момент, когда мы перепробовали все варианты и ничего не помогло, нас выручил backup со standby-db-сервера, который коллега сделал перед самым началом обновления 24 октября. Удалось, посредством RMAN, частично (только требуемые табличные пространства) восстановить standby DB на момент «до пересборки XDB» и извлечь необходимые данные. После этого, с помощью DATA PUMP, экспортировали проблемные таблицы со standby на main-db-сервер. Данная операция была завершена примерно в 2 часа ночи 27 октября. После этого функциональность GUP-сервера была восстановлена. Несмотря на то, что данные в восстановленной таблице устарели по времени, таблица была актуальна, так как все попытки обработать повреждённые данные оканчивались неудачей. Т.е. фактически БД находилась в состоянии read-only и данные в ней не менялись с момента «ДО обновления».
При наличии тестовой зоны, возможно, мы бы выявили эту проблему, на этапе подготовки к обновлению, но, поскольку Oracle классифицировал BUG как «Code/Hardware Bug», требовалось совпадение не только по версиям Oracle и пользовательским данным, но и по платформе и версии OС, что не являлось возможным.
Не забывайте делать backup, всем удачи.
