Опыт обновления 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 обновили на тестовой зоне под SUSE. Обошлось все без проблем. Воодушевленные результатом мы запланировали обновление в промышленной зоне в ночь с 24 по 25 октября, с учетом, что к началу следующего рабочего дня, все должно было заработать (по нашему идеальному плану).

Подготовка к процессу обновления


Начали подготовку днем 24 октября, совместно с командированным к нам DBA.
Были выставлены требуемые параметры, настроили внеочередные backup-ы, очистили некоторые «тяжелые» таблицы. Следом остановка сервисов, бизнес-процессов, job-ов и тд. В общем, подготовка заняла почти весь день, сам же процесс обновления начался около 12 ночи и завершился в 4 утра. После начали запускать все в обратном порядке, время около 6 утра, мы уже мысленно находились дома, готовые отойти ко сну, но не тут-то было. Все сервисы запустились, кроме сервера приложений. Выяснили, что его служба отказывалась стартовать из-за того, что версия Oracle Client (10) была ниже серверной, пришлось обновлять все сервера, где клиентская часть была ниже допустимой версии. Обновили — заработало.

Оказалось это была лишь малая из проблем. Во время проверки работоспособности бизнес-процессов. обнаружили, что функциональность сервера профилей абонентов нарушена. При обращении к определённым данным выскакивала ошибка 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, так и при попытке экспорта данных таблиц. Операция «create table… 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, всем удачи.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 26
  • +1
    Сочуствую боли.
    Но даже при наличии тестовой зоны проверить можно не все, а вот резервный сервер с заначенным бекапом это план «Б», который просто быть обязан.
    • +1
      Вывод — только типовое железо.
      • 0
        Владельцы супердомов, екзадат и прочей очень дорогой фигни смотрят на вас с небольшим неодобрением.
        • 0
          Я правильно понял, что ошибка с XMLTYPE не проявлялась в тестовой зоне на suse и 12.2.0.1?
          • 0
            Все верно, в тестовой зоне проблем не было ни с ОС, ни с СУБД
            • 0
              А в итоге вы уже нашли глючные записи XMLTYPE?
              грубо получается размер записи проблемной таблицы всего 430 байт. (4Gb / 10000000)
              что могли засунуть в данное поле чтобы так сломать базу, или ошибка не связана с валидностью XML?

              У нас тоже используется этот тип, но сами данные в таблицах лежат в простом CLOB
              кастинг к XMLType делаем уже в рантайме
              select extractValue(XMLType(value),…

              и возможно когда-то тоже будет миграция на 12.
              • +1
                Вопрос немного сформулирован некорректно.
                Глючные записи мы нашли, они были в двух таблицах, где хранились данные XML TYPE в LOBs значениях. Во время подготовки к апгрейду надо осуществить сборку XDB, в этот момент и происходит повреждение данных с типом XML TYPE.
                По мне у вас два варианта:
                1. Развернуть полноценный тестовый стенд (железо в том числе0, на котором либо все пройдет успешно, либо выскочит тот самый bug.
                2. Если нет возможности развернуть полноценный стенд, провести тестовый апгрейд на том, что есть, но в в этом варианте, даже в случае успешного обновления, надо быть готовым, что на проде выскочит bug.
                Решением в обоих случаях является описанный в статье вариант — бэкап таблиц с XML type, которые вы накатите после апгрейда, заменив поврежденные таблицы.
                А еще к вашему апгрейду может и патч выпустят:)
        • +3
          Можно поинтересоваться, отчего в региональном ОС, при очевидно платной поддержке Оракла используется относительо экзотическая железяка без поддержки?
          (Тут собстно поддержка железяки и её админство никакую роль в описанной проблеме играет, но может же и на её стороне фуцкап произойти).
          Чем собстно выбор хпукса был/есть объёснён?
          Спасибо.
          • 0
            Хороший вопрос, техподдержка на железо присутствовала, на 5 лет вроде раньше HP предоставлял.
            У нас она в 2015г закончилась. Пока думали закупать/не закупать новую, ударил кризис, HP разделился на HPE и HP Inc, изменилась политика, цена ТП взлетела до небес. На случай фуцкапа держим контакты HP спецов, готовых прийти на помощь)).
            Чем был обусловлен выбор HPUX-а останется в истории, т.к. было это 8 лет назад, и когда я пришел в компанию, все уже было установлено, при этом людей, которых участвовали в закупе железа и софта, уже нет.
            • 0
              Жесть. «людей, которых участвовали в закупе железа и софта, уже нет.» — скоропостижно скончались?
              Не страшно работать в такой конторе?
          • 0
            Судя по сведению задачи к получению данных из таблицы до повреждений, правильно ли я понимаю, что можно было бы вообще все данные выгрузить в файл, пересоздать таблицы и снова загрузить назад? Прошу не пинать ногами — знаю что это долго. Интересует сама возможность -получится или нет.
            • +2
              У меня пару вопросов сразу возникло:
              1. Почему сразу не создали SR c severity 1 + 24*7, а еще лучше сразу звонком в российскую тех.поддержку?
              2. Почему не обратились ни на sql.ru, ни в телеграмм канал RuOUG? Там полно высококлассных спецов, которые зачастую помогают решить сложнейшие проблемы и намного быстрее, чем техподдержка
              3. Почему выбрали 12.2, а не гораздо более стабильную 12.1.0.2?
              4. Как же вы так тестировали, что упустили даже проблему с версией клиента, да и быстрее было бы просто установить SQLNET.ALLOWED_LOGON_VERSION_CLIENT. Кстати, может вы ошиблись с версией ораклового клиента, т.к. дефолтно на 12.2 стоит 11:
              docs.oracle.com/en/database/oracle/oracle-database/12.2/netrf/parameters-for-the-sqlnet-ora-file.html#GUID-B2908ADF-0973-44A9-9B34-587A3D605BED
              • 0
                1. Техподдержка Oracle у нас осуществляется поставщиком биллинга, у них в свою очередь договор с Oracle по ASFU. Как я отметил в статье, обновлением занимался командированный к нам DBA, непосредственно, он же взаимодействовал с Oracle. Мы спрашивали с DBA, он с Oracle, не могу ответить на вопросы, т.к. полагались на большой опыт DBA в обновлениях.
                2. Опять-таки DBA контактировал и c коллегами и с ТП Oracle, у него имелись свои каналы скорой помощи. За канал RuOUG спасибо, не знал про него.
                3. Скорее всего из-за того, что поздно обновлялись, взяли последнюю актуальную с надеждой что содержит в себе последние обновления.
                • 0
                  1. Техподдержка Oracle у нас осуществляется поставщиком биллинга, у них в свою очередь договор с Oracle по ASFU. Как я отметил в статье, обновлением занимался командированный к нам DBA, непосредственно, он же взаимодействовал с Oracle. Мы спрашивали с DBA, он с Oracle, не могу ответить на вопросы, т.к. полагались на большой опыт DBA в обновлениях.
                  2. Опять-таки DBA контактировал и c коллегами и с ТП Oracle, у него имелись свои каналы скорой помощи. За канал RuOUG спасибо, не знал про него.
                  3. Скорее всего из-за того, что поздно обновлялись, взяли последнюю актуальную с надеждой что содержит в себе последние обновления.
                  4. Вот за что Хабр полезен, так это то, что в комментарий полезной информации не меньше, чем в статье. Вы правы, ошибся версией, подправил, на серверах стояла 10-ая. 11-ые стояли на клиентских рабочих станциях, и с ними как раз проблем не было. Проблему с версиями в ходе тестирования обнаружили, и были готовы к ней. Наш косяк в том, что тестовые сервера приложений развернули с допустимыми клиентскими версиями, и упустили, что на некоторых production as стоит 10 версия
                  • +1
                    взяли последнюю актуальную с надеждой что содержит в себе последние обновления.
                    не забывайте, что помимо исправлений, она содержит в себе и очень много нововведений, из-за которых очень повышается риск на новые доселе невиданные баги.
                    • 0
                      Будем иметь в виду, благодарю!
              • 0
                Хорошо, что есть бэкап. Я сталкивался с ORA — 00600. Это просто «праздник» какой то. Это было в 2011/12. Смутно помню, так же у меня формировались в запросах xml и я использовал XMLType и XMLElement они ложились в CLOB(хранимые процедуры). Ломалось все это при выводе отчетов через приложение. Oracle выдавал именно ORA-600. С коллегами шутили, что «неет только не ORA-600». Спрашивал на форуме sql.ru, ответа не получил. И тогда была такая ситуация, что нужно было переходить на Oracle 11.0.2 с 10g. Как поправил? — не помню, использовал dbms_lob или что то еще, но тоже кажется не получалось. Как выяснили это связано с большим объемом данных. Как то обошли это, методом «тыка». ).
                • +1
                  Oracle выдавал именно ORA-600.
                  Спрашивал на форуме sql.ru, ответа не получил.

                  ORA-600 это критическая ошибка. На support.oracle.com есть специальные траблшутеры для этой ошибки, которые позволяют найти номер патча для решения конкретной проблемы. Если траблшутер не помогает, то надо открывать саппорт реквест, а не на sql.ru отераться.

                  • 0
                    надо открывать саппорт реквест, а не на sql.ru отераться.
                    одно другому не мешает, поэтому желательно сделать и то, и другое, т.к. с техподдержкой есть шанс прождать пару месяцев в ожидании патча даже для critical SR или не решить свою проблему вообще, а спецы на форуме есть с уровнем гораздо выше средней у техподдержки
                    • 0
                      Спасибо за совет, в тот момент не знал о траблшутерах. Да и как всегда нужно было решить проблему вот прям сейчас и срочно.
                  • 0
                    Как понимаю, такие вещи, как Integrity позволяет создавать изолированные окружения и гибко настраивать их ресурсы. Знаю, некоторые создают на одной такой физической машине как production, так и тестовые среды. Если уж купили такую вещь, то странно не использовать ее возможности.
                    • 0
                      Переконфигурирование, насколько помню, требует перезагрузки. Т.е. минимум 2 перезагрузки иметь. Да и боевой ящик может не иметь ресурсов x2. Нищеброды, сэр.
                    • 0
                      Чем дольше работаю DBA, тем больше убеждаюсь, что Oracle — дорогая игрушка, не прощающая ошибок. В идеале стоило бы заначить третий сервер, на котором и разворачивать standby, а бывший primary оставить в замороженном состоянии на случай вот таких вот факапов.
                      Благо, в моей компании со стандартными x86 серверами и виртуалками особого дефицита нет.
                      • 0
                        не прощающая ошибок
                        наоборот, с ним надо очень хорошо постараться, чтобы профакапить данные. Он как раз оооочень многое прощает как админам, так и разработчикам :)
                        • 0
                          Местами прощает, а местами наоборот. Профакапил апгрейд СУБД до новой версии — и живи как хочешь. Без данных, без всего. А Flashback Database только в Enterprise Edition, а на Flashback Query в SE далеко не уехать в случае чего. Разумеется, при правильно подготовленном плане апгрейда можно всего избежать, а при полном тестировании нового и старого функционала с привлечением программистов — тем более, вот только таких профессионалов мне слишком мало встречалось пока. Может просто пока слишком молодой ещё…
                      • 0
                        Профакапил апгрейд СУБД до новой версии — и живи как хочешь. Без данных, без всего.
                        Это как так надо постараться, чтобы данные потерять при апгрейде? Это ж надо еще умудриться не сделать ни холодного, ни горячего бэкапа, не иметь стендбая, да еще и поменять compatibity…

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.