Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
— upgrade-жены
Простите? :)
Простите? :)
On-line перемещение партиций таблиц (больше не надо останавливать Instance, все далает на лету).
не совсем верно. Партиции и до 12с можно было двигать без остановки Instance. Новый режим Online перемещения не деструктивен по отношение к запросам идущим по перемещаемой таблице. Раньше индексы инвалидировались, что приводило к остановке всех активных запросов над таблицей.
А вот для чего действительно приходится останавлиать инстанс — это для физического перемещения файлов. В 12с добавили Online перемещение файлов данных без остановки Instance и остановки операций над перемещаемыми блоками.
Спасибо за новости!
Название главной feature в Oracle Database 12c — «Multitenant», там не нужно в середине слова T заглавную писать.
Плюс рекомендую заглянуть на официальные страницы продукта с техническим уклоном (Oracle Technical Network):
Oracle Database 12c
Oracle Multitenant
Название главной feature в Oracle Database 12c — «Multitenant», там не нужно в середине слова T заглавную писать.
Плюс рекомендую заглянуть на официальные страницы продукта с техническим уклоном (Oracle Technical Network):
Oracle Database 12c
Oracle Multitenant
>Патч накатывается 1 раз на всё CDB — далее он реплицируется на все PDB автоматом.
>На все PDB пишется ТОЛЬКО 1 общий backup. Накатывается тоже 1 раз сразу на все.
Похоже на единую точку отказа.
>На все PDB пишется ТОЛЬКО 1 общий backup. Накатывается тоже 1 раз сразу на все.
Похоже на единую точку отказа.
Похоже, интересно, насколько это надежно при выходе из строя этой точки, либо при потере связи с интернетом (тем более, что их сервера в США стоят(пинги, задержки), хотя может и в Европе есть заркала). Это узкое место я считаю, хотя у них там все зазеркалировано на Exadata'ах, как они уверяют, что всё «супер надежно и супер устойчиво».
И еще — В прошлом году на конференции JavaOne они говорили, что стоимость владения таким облаком будет рассчитываться из размера БД (а не версии продукта и числа CPU, как раньше), т.е. по мере роста базы цена будет только расти… Ларри опять хочет взять всех за одно место )))
И еще — В прошлом году на конференции JavaOne они говорили, что стоимость владения таким облаком будет рассчитываться из размера БД (а не версии продукта и числа CPU, как раньше), т.е. по мере роста базы цена будет только расти… Ларри опять хочет взять всех за одно место )))
Ладно потеря связи, в США и Европе это маловероятно. Хуже ситуация, когда одной базе из ста нужен определенный патч, а тестировать, не сломает ли он что-нибудь в остальных, — можно повеситься.
Общий бэкап тоже так себе идея.
Про Ларри согласен. :)
Общий бэкап тоже так себе идея.
Про Ларри согласен. :)
Хоть и с большим запозданием, но отвечу на это (сейчас ковыряю новые фичи 12-ки активно). Когда нужно проапгрейдить только 1 PDB, оракл предлагает следующий выход (красиво на мой взгляд).
— У вас должно быть два инстанса, у каждого своя CDB-шка, соответсвенно.
— Из CDB-шки можно unplug-ить PDB-шки в одну команду, при этом сораняя информацию о ней в xml файл. Получается такой-себе moveable набор файлов. Переносим эти файлы поближе к новой CDB-шке (если конечно нужно переносить и она не находится «там же» (не обязательно на том же сервере, но, скажем, если у них один расшаренный NAS, то это уже что-то… ну это уже индивидуально — сами разберётесь где у вас файлы с данными лежат). Короче, здесь у нас максимум одна команда mv в юниксе, если надо и ждём пока move закончится.
— Дальше в ещё одну команду подключаем PDB-шку к новой CDB (на новой версии). listener-у же говорим что сервис уже живёт на другой CDB (ну или, если всё нормально настроено, то PMON сам скажет).
— В идеале — радуемся жизни. Апгрейд произошёл. Если после апгрейда поняли что на новом патче / версии всё плохо — производим обратную операцию (в идеале, если места достаточно, до последнего момента файлы с исходного размещения не удаляем (делаем cp, а не mv). Тогда откат будет происходить быстрее.
Ну, или, если короче и в языке SQL:
sqlplus CDB_ADMIN/pwd@CDB_OLD_VERSION as sysdba
ALTER PLUGGABLE DATABASE sales CLOSE IMMEDIATE; -- In RAC do the same on all instances
ALTER PLUGGABLE DATABASE sales UNPLUG INTO ‘/u01/pdbdb/sales_meta.xml’;
exit
cp /u01/pdbdb/* /u02/pdbdb/
connect CDB_ADMIN/pwd@CDB_NEW_VERSION as sysdba
CREATE PLUGGABLE DATABASE sales USING ‘/u02/pdbdb/sales_meta.xml’ source_file_name_convert=(‘/u01/pdbdb/’,’/u02/pdbdb/) NOCOPY;
— Nocopy — говорит о том, что файлы уже там, их копировать не надо (как в случае с созданием клона)
ALTER PLUGGABLE DATABASE sales OPEN;
На мой взгляд всё не так уж страшно и выглядит разумно. Т.к. если у вас на CDB-шке висит 10 независимых приложений (что подразумевает концепция CDB), надеяться что они все одновременно согласятся на апгрейд версии — по меньшей мере наивно.
PS: Надеюсь найду времени дописать ещё результаты изысканий в отдельные посты на хабре.
— У вас должно быть два инстанса, у каждого своя CDB-шка, соответсвенно.
— Из CDB-шки можно unplug-ить PDB-шки в одну команду, при этом сораняя информацию о ней в xml файл. Получается такой-себе moveable набор файлов. Переносим эти файлы поближе к новой CDB-шке (если конечно нужно переносить и она не находится «там же» (не обязательно на том же сервере, но, скажем, если у них один расшаренный NAS, то это уже что-то… ну это уже индивидуально — сами разберётесь где у вас файлы с данными лежат). Короче, здесь у нас максимум одна команда mv в юниксе, если надо и ждём пока move закончится.
— Дальше в ещё одну команду подключаем PDB-шку к новой CDB (на новой версии). listener-у же говорим что сервис уже живёт на другой CDB (ну или, если всё нормально настроено, то PMON сам скажет).
— В идеале — радуемся жизни. Апгрейд произошёл. Если после апгрейда поняли что на новом патче / версии всё плохо — производим обратную операцию (в идеале, если места достаточно, до последнего момента файлы с исходного размещения не удаляем (делаем cp, а не mv). Тогда откат будет происходить быстрее.
Ну, или, если короче и в языке SQL:
sqlplus CDB_ADMIN/pwd@CDB_OLD_VERSION as sysdba
ALTER PLUGGABLE DATABASE sales CLOSE IMMEDIATE; -- In RAC do the same on all instances
ALTER PLUGGABLE DATABASE sales UNPLUG INTO ‘/u01/pdbdb/sales_meta.xml’;
exit
cp /u01/pdbdb/* /u02/pdbdb/
connect CDB_ADMIN/pwd@CDB_NEW_VERSION as sysdba
CREATE PLUGGABLE DATABASE sales USING ‘/u02/pdbdb/sales_meta.xml’ source_file_name_convert=(‘/u01/pdbdb/’,’/u02/pdbdb/) NOCOPY;
— Nocopy — говорит о том, что файлы уже там, их копировать не надо (как в случае с созданием клона)
ALTER PLUGGABLE DATABASE sales OPEN;
На мой взгляд всё не так уж страшно и выглядит разумно. Т.к. если у вас на CDB-шке висит 10 независимых приложений (что подразумевает концепция CDB), надеяться что они все одновременно согласятся на апгрейд версии — по меньшей мере наивно.
PS: Надеюсь найду времени дописать ещё результаты изысканий в отдельные посты на хабре.
Спасибо за информацию.
Обращу внимание, что я писал не про апгрейд версии, а про установку патча; это разные сценарии. Апгрейд настолько серьезный шаг, что без тестирования всего не обойтись. И апгрейдим, как правило все базы, адаптируем приложения и т.д.
Патчи же бывают в основном двух категорий: закрывающие дырки безопасности и исправляющие баги. Баг часто проявляется на конкретном сценарии работы, то есть он вылезает на одной базе из ста. И патчить другие базы необходимости нет, а риск что-то сломать есть (так как в патче обычно собрана куча изменений). Поэтому нужно тестирование работы приложений с патчем. Патчи первой категории как правило нужно ставить везде, но желательно делать это не одновременно, а постепенно: пропатчили — протестировали — работает — переходим к следующей. Я предполагаю, что разработчики предусмотрели эти сценарии.
P.S. Зачем мувить куда-то продуктивную базу, я вообще не понял. Обычно их не очень-то потаскаешь при их размере. В правильном продуктиве есть бэкап, есть стендбай, есть тестовые базы с малым объемом данных.
Обращу внимание, что я писал не про апгрейд версии, а про установку патча; это разные сценарии. Апгрейд настолько серьезный шаг, что без тестирования всего не обойтись. И апгрейдим, как правило все базы, адаптируем приложения и т.д.
Патчи же бывают в основном двух категорий: закрывающие дырки безопасности и исправляющие баги. Баг часто проявляется на конкретном сценарии работы, то есть он вылезает на одной базе из ста. И патчить другие базы необходимости нет, а риск что-то сломать есть (так как в патче обычно собрана куча изменений). Поэтому нужно тестирование работы приложений с патчем. Патчи первой категории как правило нужно ставить везде, но желательно делать это не одновременно, а постепенно: пропатчили — протестировали — работает — переходим к следующей. Я предполагаю, что разработчики предусмотрели эти сценарии.
P.S. Зачем мувить куда-то продуктивную базу, я вообще не понял. Обычно их не очень-то потаскаешь при их размере. В правильном продуктиве есть бэкап, есть стендбай, есть тестовые базы с малым объемом данных.
1) С патчем — ситуацию и вопрос понял, но не могу ничего сказать. Вариантов, как применить патч на отдельную базу я не видел, да и, думаю, не увижу, т.к. Оракл наоборот выставляет это преимуществом, что не нужно патчить базы по отдельности — меньше работы по администрированию. Тем более что в случае PDB мы по сути имеем один инстанс, один набор служебных процессов, памяти итд, который шарится… Едва ли тут получится иметь индивидуальный набор бинарников под каждую базу. Хотя ваше беспокойство по поводу того, что патч может поламать базы не причастные к той, в которой была сама проблема — понимаю и согласен… но таков подход CDB. Если для вас это совсем неприменимо, то старую арзитектуру без Multitenant никто не отменял — вы всё ещё можете пользоваться 12с и создавать отдельные инстансы на каждую базу. Это лишь инструмент. Использовать ли — вопрос.
С другой стороны, представьте картину когда у вас условно есть какой-то сервер, на котором стоит операционка, а на нём ряд ПО крутиться. Вы ведь не просите поставить патч на операционную систему, чтобы он применился только для одного ПО, но не применился для другого. Надеюсь, аналогия понятна. Так и здесь. Можно долго развивать эту тему.
PS: по поводу mv — обратите внимание в тексте — говорилось снова таки — если вам надо. Я исходил из того, что CDB содержащая в себе много PDB-шек, наверняка поглощает почти все ресурсы сервера, и вторая CDB на том же сервере уже может и не поднятся — не хватит той же оперативки. Потому прийдётся перетащить на «соседний» сервер. Впрочем, учитывая повсеместное использование NAS, то, очень даже возможно, что и не прийдётся ничего никуда переносить.
Ну и так случилось, на моей практике что часто апгрейд до новой версии оракла происходил спустя столь много лет от предыдущей, что вместе с ораклом менялось и железо :) Которое, подчас, оказывалось ещё и в другом датацентре (хотя, конечно, наверняка это будет не mv, а другие варианты передачи + архивирование итд).
Но песня была в первую очередь совсем не о том, так что можете проигнорировать мой пассаж по mv.
С другой стороны, представьте картину когда у вас условно есть какой-то сервер, на котором стоит операционка, а на нём ряд ПО крутиться. Вы ведь не просите поставить патч на операционную систему, чтобы он применился только для одного ПО, но не применился для другого. Надеюсь, аналогия понятна. Так и здесь. Можно долго развивать эту тему.
PS: по поводу mv — обратите внимание в тексте — говорилось снова таки — если вам надо. Я исходил из того, что CDB содержащая в себе много PDB-шек, наверняка поглощает почти все ресурсы сервера, и вторая CDB на том же сервере уже может и не поднятся — не хватит той же оперативки. Потому прийдётся перетащить на «соседний» сервер. Впрочем, учитывая повсеместное использование NAS, то, очень даже возможно, что и не прийдётся ничего никуда переносить.
Ну и так случилось, на моей практике что часто апгрейд до новой версии оракла происходил спустя столь много лет от предыдущей, что вместе с ораклом менялось и железо :) Которое, подчас, оказывалось ещё и в другом датацентре (хотя, конечно, наверняка это будет не mv, а другие варианты передачи + архивирование итд).
Но песня была в первую очередь совсем не о том, так что можете проигнорировать мой пассаж по mv.
Хотя ведь можно и не уходить в облако, а просто обновить локальные базы и получить все «плюшки» новой версии, не потеряв уверенность во «владении ресурсом».
Я уже неплохо «пощупал» 12с и кое-что описал уже:
1. Про ток как устроены identity, как работают Inline pl/sql функции и когда исполняются default: orasql.org/2013/07/13/oracle-12c-behavior-tests-of-the-inline-functions-identities-and-defaults/
2. Про изменение varchar'ов: orasql.org/2013/07/13/oracle-12c-extended-varchars/
3. Про Латералы и Топы: orasql.org/2013/07/05/topn-2/
4. Еще про консистентность inline функций: orasql.org/2013/07/05/topn-2/
1. Про ток как устроены identity, как работают Inline pl/sql функции и когда исполняются default: orasql.org/2013/07/13/oracle-12c-behavior-tests-of-the-inline-functions-identities-and-defaults/
2. Про изменение varchar'ов: orasql.org/2013/07/13/oracle-12c-extended-varchars/
3. Про Латералы и Топы: orasql.org/2013/07/05/topn-2/
4. Еще про консистентность inline функций: orasql.org/2013/07/05/topn-2/
Может соберешь в один пост и выложишь? Было бы удобнее на много, чем ползать по куче ссылок. И да, было бы хорошо по-русски все написать ;-)
Мне не хватает времени даже в свою русскую версию блоrа выложить то же самое… Да и смысла особого собирать разные темы в одну кучу не вижу. Могу только посоветовать посмотреть список, который не поленился и собрал Стив Карам: www.oraclealchemist.com/news/install-oracle-12c-12-1/
Кстати, пара уточнений:
триггер не создается. более того, генерация происходит без переключений контекста прямо в sql engine.
Сам создает сиквенс, который (видимо) создает триггер Before Insert и дергает его.
триггер не создается. более того, генерация происходит без переключений контекста прямо в sql engine.
БД-шный тип VARCHAR расширили с 4000 char до 32000 char (как в PL/SQL)максимум — 32767 bytes, и не по умолчанию — для этого нужно сменить значение параметра MAX_STRING_SIZE на extended.
Про консистентность ссылкой ошибся — orasql.org/2013/07/03/oracle-12c-inconsistency-of-inline-functions/
В принципе, в блоге у Джонатана Льюиса в комментариях это я тоже выкладывал
В принципе, в блоге у Джонатана Льюиса в комментариях это я тоже выкладывал
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Краткий список нововведений в Oracle 12c