Comments 26
Сочуствую боли.
Но даже при наличии тестовой зоны проверить можно не все, а вот резервный сервер с заначенным бекапом это план «Б», который просто быть обязан.
Но даже при наличии тестовой зоны проверить можно не все, а вот резервный сервер с заначенным бекапом это план «Б», который просто быть обязан.
Вывод — только типовое железо.
Владельцы супердомов, екзадат и прочей очень дорогой фигни смотрят на вас с небольшим неодобрением.
Я правильно понял, что ошибка с XMLTYPE не проявлялась в тестовой зоне на suse и 12.2.0.1?
Все верно, в тестовой зоне проблем не было ни с ОС, ни с СУБД
А в итоге вы уже нашли глючные записи XMLTYPE?
грубо получается размер записи проблемной таблицы всего 430 байт. (4Gb / 10000000)
что могли засунуть в данное поле чтобы так сломать базу, или ошибка не связана с валидностью XML?
У нас тоже используется этот тип, но сами данные в таблицах лежат в простом CLOB
кастинг к XMLType делаем уже в рантайме
select extractValue(XMLType(value),…
и возможно когда-то тоже будет миграция на 12.
грубо получается размер записи проблемной таблицы всего 430 байт. (4Gb / 10000000)
что могли засунуть в данное поле чтобы так сломать базу, или ошибка не связана с валидностью XML?
У нас тоже используется этот тип, но сами данные в таблицах лежат в простом CLOB
кастинг к XMLType делаем уже в рантайме
select extractValue(XMLType(value),…
и возможно когда-то тоже будет миграция на 12.
Вопрос немного сформулирован некорректно.
Глючные записи мы нашли, они были в двух таблицах, где хранились данные XML TYPE в LOBs значениях. Во время подготовки к апгрейду надо осуществить сборку XDB, в этот момент и происходит повреждение данных с типом XML TYPE.
По мне у вас два варианта:
1. Развернуть полноценный тестовый стенд (железо в том числе0, на котором либо все пройдет успешно, либо выскочит тот самый bug.
2. Если нет возможности развернуть полноценный стенд, провести тестовый апгрейд на том, что есть, но в в этом варианте, даже в случае успешного обновления, надо быть готовым, что на проде выскочит bug.
Решением в обоих случаях является описанный в статье вариант — бэкап таблиц с XML type, которые вы накатите после апгрейда, заменив поврежденные таблицы.
А еще к вашему апгрейду может и патч выпустят:)
Глючные записи мы нашли, они были в двух таблицах, где хранились данные XML TYPE в LOBs значениях. Во время подготовки к апгрейду надо осуществить сборку XDB, в этот момент и происходит повреждение данных с типом XML TYPE.
По мне у вас два варианта:
1. Развернуть полноценный тестовый стенд (железо в том числе0, на котором либо все пройдет успешно, либо выскочит тот самый bug.
2. Если нет возможности развернуть полноценный стенд, провести тестовый апгрейд на том, что есть, но в в этом варианте, даже в случае успешного обновления, надо быть готовым, что на проде выскочит bug.
Решением в обоих случаях является описанный в статье вариант — бэкап таблиц с XML type, которые вы накатите после апгрейда, заменив поврежденные таблицы.
А еще к вашему апгрейду может и патч выпустят:)
Можно поинтересоваться, отчего в региональном ОС, при очевидно платной поддержке Оракла используется относительо экзотическая железяка без поддержки?
(Тут собстно поддержка железяки и её админство никакую роль в описанной проблеме играет, но может же и на её стороне фуцкап произойти).
Чем собстно выбор хпукса был/есть объёснён?
Спасибо.
(Тут собстно поддержка железяки и её админство никакую роль в описанной проблеме играет, но может же и на её стороне фуцкап произойти).
Чем собстно выбор хпукса был/есть объёснён?
Спасибо.
Хороший вопрос, техподдержка на железо присутствовала, на 5 лет вроде раньше HP предоставлял.
У нас она в 2015г закончилась. Пока думали закупать/не закупать новую, ударил кризис, HP разделился на HPE и HP Inc, изменилась политика, цена ТП взлетела до небес. На случай фуцкапа держим контакты HP спецов, готовых прийти на помощь)).
Чем был обусловлен выбор HPUX-а останется в истории, т.к. было это 8 лет назад, и когда я пришел в компанию, все уже было установлено, при этом людей, которых участвовали в закупе железа и софта, уже нет.
У нас она в 2015г закончилась. Пока думали закупать/не закупать новую, ударил кризис, HP разделился на HPE и HP Inc, изменилась политика, цена ТП взлетела до небес. На случай фуцкапа держим контакты HP спецов, готовых прийти на помощь)).
Чем был обусловлен выбор HPUX-а останется в истории, т.к. было это 8 лет назад, и когда я пришел в компанию, все уже было установлено, при этом людей, которых участвовали в закупе железа и софта, уже нет.
Судя по сведению задачи к получению данных из таблицы до повреждений, правильно ли я понимаю, что можно было бы вообще все данные выгрузить в файл, пересоздать таблицы и снова загрузить назад? Прошу не пинать ногами — знаю что это долго. Интересует сама возможность -получится или нет.
У меня пару вопросов сразу возникло:
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
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
1. Техподдержка Oracle у нас осуществляется поставщиком биллинга, у них в свою очередь договор с Oracle по ASFU. Как я отметил в статье, обновлением занимался командированный к нам DBA, непосредственно, он же взаимодействовал с Oracle. Мы спрашивали с DBA, он с Oracle, не могу ответить на вопросы, т.к. полагались на большой опыт DBA в обновлениях.
2. Опять-таки DBA контактировал и c коллегами и с ТП Oracle, у него имелись свои каналы скорой помощи. За канал RuOUG спасибо, не знал про него.
3. Скорее всего из-за того, что поздно обновлялись, взяли последнюю актуальную с надеждой что содержит в себе последние обновления.
2. Опять-таки DBA контактировал и c коллегами и с ТП Oracle, у него имелись свои каналы скорой помощи. За канал RuOUG спасибо, не знал про него.
3. Скорее всего из-за того, что поздно обновлялись, взяли последнюю актуальную с надеждой что содержит в себе последние обновления.
1. Техподдержка Oracle у нас осуществляется поставщиком биллинга, у них в свою очередь договор с Oracle по ASFU. Как я отметил в статье, обновлением занимался командированный к нам DBA, непосредственно, он же взаимодействовал с Oracle. Мы спрашивали с DBA, он с Oracle, не могу ответить на вопросы, т.к. полагались на большой опыт DBA в обновлениях.
2. Опять-таки DBA контактировал и c коллегами и с ТП Oracle, у него имелись свои каналы скорой помощи. За канал RuOUG спасибо, не знал про него.
3. Скорее всего из-за того, что поздно обновлялись, взяли последнюю актуальную с надеждой что содержит в себе последние обновления.
4. Вот за что Хабр полезен, так это то, что в комментарий полезной информации не меньше, чем в статье. Вы правы, ошибся версией, подправил, на серверах стояла 10-ая. 11-ые стояли на клиентских рабочих станциях, и с ними как раз проблем не было. Проблему с версиями в ходе тестирования обнаружили, и были готовы к ней. Наш косяк в том, что тестовые сервера приложений развернули с допустимыми клиентскими версиями, и упустили, что на некоторых production as стоит 10 версия
2. Опять-таки DBA контактировал и c коллегами и с ТП Oracle, у него имелись свои каналы скорой помощи. За канал RuOUG спасибо, не знал про него.
3. Скорее всего из-за того, что поздно обновлялись, взяли последнюю актуальную с надеждой что содержит в себе последние обновления.
4. Вот за что Хабр полезен, так это то, что в комментарий полезной информации не меньше, чем в статье. Вы правы, ошибся версией, подправил, на серверах стояла 10-ая. 11-ые стояли на клиентских рабочих станциях, и с ними как раз проблем не было. Проблему с версиями в ходе тестирования обнаружили, и были готовы к ней. Наш косяк в том, что тестовые сервера приложений развернули с допустимыми клиентскими версиями, и упустили, что на некоторых production as стоит 10 версия
Хорошо, что есть бэкап. Я сталкивался с ORA — 00600. Это просто «праздник» какой то. Это было в 2011/12. Смутно помню, так же у меня формировались в запросах xml и я использовал XMLType и XMLElement они ложились в CLOB(хранимые процедуры). Ломалось все это при выводе отчетов через приложение. Oracle выдавал именно ORA-600. С коллегами шутили, что «неет только не ORA-600». Спрашивал на форуме sql.ru, ответа не получил. И тогда была такая ситуация, что нужно было переходить на Oracle 11.0.2 с 10g. Как поправил? — не помню, использовал dbms_lob или что то еще, но тоже кажется не получалось. Как выяснили это связано с большим объемом данных. Как то обошли это, методом «тыка». ).
Oracle выдавал именно ORA-600.
Спрашивал на форуме sql.ru, ответа не получил.
ORA-600 это критическая ошибка. На support.oracle.com есть специальные траблшутеры для этой ошибки, которые позволяют найти номер патча для решения конкретной проблемы. Если траблшутер не помогает, то надо открывать саппорт реквест, а не на sql.ru отераться.
надо открывать саппорт реквест, а не на sql.ru отераться.одно другому не мешает, поэтому желательно сделать и то, и другое, т.к. с техподдержкой есть шанс прождать пару месяцев в ожидании патча даже для critical SR или не решить свою проблему вообще, а спецы на форуме есть с уровнем гораздо выше средней у техподдержки
Спасибо за совет, в тот момент не знал о траблшутерах. Да и как всегда нужно было решить проблему вот прям сейчас и срочно.
Как понимаю, такие вещи, как Integrity позволяет создавать изолированные окружения и гибко настраивать их ресурсы. Знаю, некоторые создают на одной такой физической машине как production, так и тестовые среды. Если уж купили такую вещь, то странно не использовать ее возможности.
Чем дольше работаю DBA, тем больше убеждаюсь, что Oracle — дорогая игрушка, не прощающая ошибок. В идеале стоило бы заначить третий сервер, на котором и разворачивать standby, а бывший primary оставить в замороженном состоянии на случай вот таких вот факапов.
Благо, в моей компании со стандартными x86 серверами и виртуалками особого дефицита нет.
Благо, в моей компании со стандартными x86 серверами и виртуалками особого дефицита нет.
не прощающая ошибокнаоборот, с ним надо очень хорошо постараться, чтобы профакапить данные. Он как раз оооочень многое прощает как админам, так и разработчикам :)
Местами прощает, а местами наоборот. Профакапил апгрейд СУБД до новой версии — и живи как хочешь. Без данных, без всего. А Flashback Database только в Enterprise Edition, а на Flashback Query в SE далеко не уехать в случае чего. Разумеется, при правильно подготовленном плане апгрейда можно всего избежать, а при полном тестировании нового и старого функционала с привлечением программистов — тем более, вот только таких профессионалов мне слишком мало встречалось пока. Может просто пока слишком молодой ещё…
Профакапил апгрейд СУБД до новой версии — и живи как хочешь. Без данных, без всего.Это как так надо постараться, чтобы данные потерять при апгрейде? Это ж надо еще умудриться не сделать ни холодного, ни горячего бэкапа, не иметь стендбая, да еще и поменять compatibity…
Sign up to leave a comment.
Опыт обновления Oracle 11.2.0.4 до 12c