Про сторонние я и спрашивал выше. Стандартных пакетов нету. Сторонние — палка о двух концах. С одной стороны не тратим время на разработку, с другой — в случае проблем можем не получить support.
На счёт «встроенной» джавы — это несколько общая фраза. Взаимодействие Оракла (в частности мы говорим сейчас о PL/SQL Engine) и JVM может быть реализовано несколькимим методами и я этого не отрицал, обратите внимание. Лучше сравните производительность, это будет действительно интересно.
Ну и если мы вспомним версии «начиная с 8», то могу напомнить что особенно на старых версиях поддержка джавы не включалась в стандартную установку. При добавлении оной, словарь и набор системных объектов уверичивался на приблизительно 30 000 объёктов! Если не верите, можете проверить на вашей базе, сделайте что-то типа:
SELECT count(*)
FROM user_objects
WHERE object_name NOT LIKE 'SYS_%' AND
object_name NOT LIKE 'CREATE$%' AND
object_name NOT LIKE 'JAVA$%' AND
object_name NOT LIKE 'LOADLOB%' AND
object_type LIKE 'JAVA %'
И да, ракетной науки нету, так попробуйте. В большинстве случаев эквивалентный код будет работать не быстрее (а за счёт переключения контекста — ещё и медленнее), на то уже много статей написано, повторятся не буду.
Хм, но это Oracle Java, а не Oracle Database.
Конечно, джава код можно встраивать в PL/SQL… но производительность двух методов ещё стоит сравнить. Вообще добавление поддержки джавы достаточно ресурсоёмкое…
А не сложно будет уточнить что вы имели в виду? Какой-то из стандартных пакетов PL/SQL умеет работать с чистым json? Можно название для того чтобы мог полистать документацию? Т.к. я что-то пока не нашёл ничего в стандартной поставке.
Видел java-библиотеки прикрученные к PL/SQL… причём, похоже не «родные». Типа того же PL/JSON. Или стороннего DBMS_JSON.
Я что-то пропустил или не там ищу?
1) С патчем — ситуацию и вопрос понял, но не могу ничего сказать. Вариантов, как применить патч на отдельную базу я не видел, да и, думаю, не увижу, т.к. Оракл наоборот выставляет это преимуществом, что не нужно патчить базы по отдельности — меньше работы по администрированию. Тем более что в случае PDB мы по сути имеем один инстанс, один набор служебных процессов, памяти итд, который шарится… Едва ли тут получится иметь индивидуальный набор бинарников под каждую базу. Хотя ваше беспокойство по поводу того, что патч может поламать базы не причастные к той, в которой была сама проблема — понимаю и согласен… но таков подход CDB. Если для вас это совсем неприменимо, то старую арзитектуру без Multitenant никто не отменял — вы всё ещё можете пользоваться 12с и создавать отдельные инстансы на каждую базу. Это лишь инструмент. Использовать ли — вопрос.
С другой стороны, представьте картину когда у вас условно есть какой-то сервер, на котором стоит операционка, а на нём ряд ПО крутиться. Вы ведь не просите поставить патч на операционную систему, чтобы он применился только для одного ПО, но не применился для другого. Надеюсь, аналогия понятна. Так и здесь. Можно долго развивать эту тему.
PS: по поводу mv — обратите внимание в тексте — говорилось снова таки — если вам надо. Я исходил из того, что CDB содержащая в себе много PDB-шек, наверняка поглощает почти все ресурсы сервера, и вторая CDB на том же сервере уже может и не поднятся — не хватит той же оперативки. Потому прийдётся перетащить на «соседний» сервер. Впрочем, учитывая повсеместное использование NAS, то, очень даже возможно, что и не прийдётся ничего никуда переносить.
Ну и так случилось, на моей практике что часто апгрейд до новой версии оракла происходил спустя столь много лет от предыдущей, что вместе с ораклом менялось и железо :) Которое, подчас, оказывалось ещё и в другом датацентре (хотя, конечно, наверняка это будет не mv, а другие варианты передачи + архивирование итд).
Но песня была в первую очередь совсем не о том, так что можете проигнорировать мой пассаж по mv.
Хоть и с большим запозданием, но отвечу на это (сейчас ковыряю новые фичи 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: Надеюсь найду времени дописать ещё результаты изысканий в отдельные посты на хабре.
Понятно. Спасибо. Значит буду сам искать информацию. Как Вам книга, кстати? Она сугубо теоретическая или ест ьприближение к практическому использованию?
Интересные вещи рассказываете. Которые, впрочем, только подтверждают что скопировав игровую механику в аппликейшн Андроида/иОС от претензий по интеллектуальной собственности тоже не отделаться — не всё так просто. Кстати, знакомый этот сейчас в США живёт, в АпплСтор какого региона он apply-ил свою софту не знаю.
Кстати, у истории всё-таки есть happy-end. Знакомый от отказа не отчаился, а движок использовал для создания 3-мерных крестиков-ноликов на поверхности кубика. Эту игрушку уже приняли в эппл стор. Активно она не пошла, но несколько сотен долларов за продажу «платной версии» (бесплатная была, кажется, только с гранью на 3 элемента, а полная — с настраиваемой гранью или что-то такое)… Не мега-деньги, конечно, но для первого аппликейшна в эппл сторе, мне кажется, достойно.
За Андроид маркет не скажу, а под iOS (приложение ориентировано было под айФон), знакомый когда-то давно разработал свой движок и на нём сделал «большой» кубик рубик ( грань не из 3 кубиков, а настраиваемая, скажем, из 10 итд элементов). Так вот приложение не приняли в AppleStore по причине возможного нарушения патентных прав по отношению к оригинальному кубику-рубику. Возможно, вы, конечно, имели в виду законадательство страны, но не стоит забывать про правила самих упомянутых компаний(эппл / Гугл и их маркетов).
model очень богат разнообразным функционалом. в том числе в нём конструкция iterate, которая позволила бы организовать цикл. Reference model я бы использовал чтобы задать исходные условия задачи, основную модель с dimension (x,y) measure (val) — дал бы на основное поле. Потом задаём набор правил по которым будем решать задачу и итерируем пока не закроем всё поле. Как ие правила зададите — зависит только от вас. Я бы не делал чистый перебор, ибо это неэффективно (то что ваш метод не решил поле большее чем 5*5 в разумные сроки на приемлимом компьютере это доказывает). Кстати, oracle xe использует только одно ядро (это тоже одно из ограничений лицензии).
listagg (или stragg, как её знают по Кайтовскому исполнению) можно было бы действительно сделать самостоятельно, неспортивности не вижу… но можно попробовать обойти и его отсутсвие другими методами.
В целом — было бы лишних пару часиков — попробовал бы реализовать на model и выдать ответ, но увы, сегодня этого времени нету, потому пока только дал наводку вам на ключевые слова. Вот ещё где можно подробнее почитать про то что оно такое, хотя, конечно линк не оригинален :) docs.oracle.com/cd/B19306_01/server.102/b14223/sqlmodel.htm
Конечно, в любом случае будет перебор (даже когда вы сами решаете «аналитически» — это тоже в некоторой мере перебор). Просто не стоит делать чистый brute-force. Можно итеративно пробегать что можно заполнить хотя-бы на уровне каждой строки-колонки (учитывая задание и уже заполненные ячейки — как мы делаем при «аналитическом» поиске), а потом уже добить результат брут-форсом. Хотя, как я уже сказал, спортивный интерес это понизит, т.к. этот sql уже не настолько «sql» как в вашем решении.
А 12-ка, да. 29-го июня. С 30-го уже скачал и установил себе на виртуалку. Но писать статьи о новых фичах руки почти не доходят. Надеюсь что скоро исправлюсь.
Хм. Мсье действительно знает толк, но, учитывая, что мы говорим о oracle-sql, я бы напомнил, что даже в 10-ке есть итерации и я бы решал эту задачу посредством конструкции MODEL (если бы вообще решал её в SQL, конечно). Думаю что получилось бы эффективнее и не так нагруженно по использованию памяти. Конечно, model нельзя назвать совсем чистым sql-ем, но для этой задачи, на мой взгляд, очень даже подходит.
Но метод написанный автором красив.
PS: И, кстати, 12-ка не на подходе, она уже здесь, уже 2 месяца как.
Ага. Вижу, спасибо. К своему стыду, вынужден признать что с 11-кой я как-то до сих пор плотно не поработал. Все проекты были до сих пор либо на 9-ке либо на 10-ке. Пару раз переводил проекты на 11-ку, но прямо как карма — после этого обычно оперативно оказывался на других проектах :) А сейчас как то захотелось плотно сесть за what's new. Потому может не совсем new эта фича :)
Ну, вообще то, не так уж сложно. У меня была бумажная с русским переводом даже…
Но я предпочитаю английскую версию (ну очень как то меня напрягает читать техническую литературу на русском в последнее время), потому пришлось найти оригинал. На английском, в бумажном виде, у нас, конечно, сложнее найти.
Эххх… ностальгия. Как много всего знакомого подняли в теме. А USR 14400 как зацепил!!! Эххх!!! Подумать только 19 лет уже прошло с момента первого «connect 14400...» (эт у меня...).
Ну книга Кайта — это, конечно, классика. Но всё таки больше рассматриваются вопросы проектирования приложения и кода. А та книга, что я упомянул (http://www.amazon.com/books/dp/1590596366) — вся посвящена именно принципам работы CBO. Пошагово, кусочек за кусочком, как оракл считает cardinality, selectivity… cost с разными методами доступа, вплоть до формул расчёта коста для разных индексов (b-tree, bitmap), для разного вида предикатов, наборов предикатов итд итп. После её прочтения у меня очень сильно изменился уровень понимания процесса оптимизации запроса. Не поленюсь ещё раз написать, что крайне её рекомендую для прочтения тем, кто заинтересован данной темой.
Да, для раскрытия view — вполне можно сделать самому (хотя изобретение новых велосипедов...). А вот для VPD — я себе сложно представляю как сделать универсальную замену.
Ну и если мы вспомним версии «начиная с 8», то могу напомнить что особенно на старых версиях поддержка джавы не включалась в стандартную установку. При добавлении оной, словарь и набор системных объектов уверичивался на приблизительно 30 000 объёктов! Если не верите, можете проверить на вашей базе, сделайте что-то типа:
SELECT count(*)
FROM user_objects
WHERE object_name NOT LIKE 'SYS_%' AND
object_name NOT LIKE 'CREATE$%' AND
object_name NOT LIKE 'JAVA$%' AND
object_name NOT LIKE 'LOADLOB%' AND
object_type LIKE 'JAVA %'
И да, ракетной науки нету, так попробуйте. В большинстве случаев эквивалентный код будет работать не быстрее (а за счёт переключения контекста — ещё и медленнее), на то уже много статей написано, повторятся не буду.
Конечно, джава код можно встраивать в PL/SQL… но производительность двух методов ещё стоит сравнить. Вообще добавление поддержки джавы достаточно ресурсоёмкое…
Видел java-библиотеки прикрученные к PL/SQL… причём, похоже не «родные». Типа того же PL/JSON. Или стороннего DBMS_JSON.
Я что-то пропустил или не там ищу?
С другой стороны, представьте картину когда у вас условно есть какой-то сервер, на котором стоит операционка, а на нём ряд ПО крутиться. Вы ведь не просите поставить патч на операционную систему, чтобы он применился только для одного ПО, но не применился для другого. Надеюсь, аналогия понятна. Так и здесь. Можно долго развивать эту тему.
PS: по поводу mv — обратите внимание в тексте — говорилось снова таки — если вам надо. Я исходил из того, что CDB содержащая в себе много PDB-шек, наверняка поглощает почти все ресурсы сервера, и вторая CDB на том же сервере уже может и не поднятся — не хватит той же оперативки. Потому прийдётся перетащить на «соседний» сервер. Впрочем, учитывая повсеместное использование NAS, то, очень даже возможно, что и не прийдётся ничего никуда переносить.
Ну и так случилось, на моей практике что часто апгрейд до новой версии оракла происходил спустя столь много лет от предыдущей, что вместе с ораклом менялось и железо :) Которое, подчас, оказывалось ещё и в другом датацентре (хотя, конечно, наверняка это будет не mv, а другие варианты передачи + архивирование итд).
Но песня была в первую очередь совсем не о том, так что можете проигнорировать мой пассаж по mv.
— У вас должно быть два инстанса, у каждого своя 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: Надеюсь найду времени дописать ещё результаты изысканий в отдельные посты на хабре.
Кстати, у истории всё-таки есть happy-end. Знакомый от отказа не отчаился, а движок использовал для создания 3-мерных крестиков-ноликов на поверхности кубика. Эту игрушку уже приняли в эппл стор. Активно она не пошла, но несколько сотен долларов за продажу «платной версии» (бесплатная была, кажется, только с гранью на 3 элемента, а полная — с настраиваемой гранью или что-то такое)… Не мега-деньги, конечно, но для первого аппликейшна в эппл сторе, мне кажется, достойно.
listagg (или stragg, как её знают по Кайтовскому исполнению) можно было бы действительно сделать самостоятельно, неспортивности не вижу… но можно попробовать обойти и его отсутсвие другими методами.
В целом — было бы лишних пару часиков — попробовал бы реализовать на model и выдать ответ, но увы, сегодня этого времени нету, потому пока только дал наводку вам на ключевые слова. Вот ещё где можно подробнее почитать про то что оно такое, хотя, конечно линк не оригинален :)
docs.oracle.com/cd/B19306_01/server.102/b14223/sqlmodel.htm
Конечно, в любом случае будет перебор (даже когда вы сами решаете «аналитически» — это тоже в некоторой мере перебор). Просто не стоит делать чистый brute-force. Можно итеративно пробегать что можно заполнить хотя-бы на уровне каждой строки-колонки (учитывая задание и уже заполненные ячейки — как мы делаем при «аналитическом» поиске), а потом уже добить результат брут-форсом. Хотя, как я уже сказал, спортивный интерес это понизит, т.к. этот sql уже не настолько «sql» как в вашем решении.
А 12-ка, да. 29-го июня. С 30-го уже скачал и установил себе на виртуалку. Но писать статьи о новых фичах руки почти не доходят. Надеюсь что скоро исправлюсь.
Но метод написанный автором красив.
PS: И, кстати, 12-ка не на подходе, она уже здесь, уже 2 месяца как.
Но я предпочитаю английскую версию (ну очень как то меня напрягает читать техническую литературу на русском в последнее время), потому пришлось найти оригинал. На английском, в бумажном виде, у нас, конечно, сложнее найти.