Pull to refresh

Comments 19

Вероятно, кому-то пригодится, чтобы не повторять мои грабли.


То, что Oracle величает релизом, весь остальной мир называет бета-тест.
Количество ошибок для той сферы, для которой применяется Oracle DB, поражает своим количеством и критичностью.

Не хочу на вас наезжать, но пост не имеет смысла, ибо никто не ставит оракл не подождав хотя бы год после релиза.

upd: в продакшн разумеется, а для всего остального есть металинк. А все ошибки охватить в одном посте не получится.
В продакшн не ставят, конечно. Потому я и написал предисловие, т.к. из версии к версии одна и та же картина.
С другой стороны, если бы не ставили совсем, и не пробовали мигрировать свои проекты, то и к следующему релизу ситуация не поменялась бы.
И, кстати, бета тест-релизы были раньше. Приблизительно год назад, если память меня не подводит. Естественно не public.

С другой стороны, большинство статей по новым фичам что я видел, полны восторгов и описуют фичи, которые, похоже, люди не попробовали дальше примера из ораклового what's new. Или решили деликатно промолчать о том, что у них не получилось и какие workarounds они применили.
Потому что, например, с тем же PDB autostart не столкнуться сложно… но ни в одной статье про multitenant я этого не видел.
С другой стороны — не факт что это баг, а не «as designed» и это поведение изменят в R2 или ещё где-то.

Ну и в целом — спасибо за ваше мнение, у каждого оно, бесспорно, своё. Всем вкусам не угодить — для того и существуют разные хабы, а также введения, поясняющие о чём будет статья, чтобы незаинтересованные не тратили время. Вы меня убедили. что первый абзац я написал не зря, вместо того, чтобы переходить сразу к сути.

Но ваше мнения я тоже учту при размышлениях о тематике следующих статей.

С уважением.
Изложено немного сумбурно, но достаточно интересно.
Спасибо — было полезно.
Если не сложно, можно пояснить в чём сумбурность? Мало пояснений / комментариев?
Я действительно старался не заполнять заметку «водой», а описать по возможности кратко, основываясь на субъективных предпочтениях к подаче информации. Это доставляет неудобства?
Тема про PLSQL Developer — ИМХО — здесь лишняя.
Формат изложения «DBMS_METADATA and session sequence» и «Pagination, массивы и run-time расчёт количества строк для fetch» больше похож на заметки на полях.
Но в общем — как я уже сказал — полезно.
P.S.> Баги проверил — живёханьки, а вот local_listener dbca у меня на OEL прописал, но коллеги тоже сталкивались с отсутствием регистрации на листенере…
Согласен про сумбурность повествования, все как-то скомкано и скачками. Недавно только тестируете?
Прокомментирую некоторые вещи:
1. Знакомим PMON с локальным listener
У меня на oel проблем не было
Автозапуск PDB после перезагрузки
Принципиально наличие нескольких pdb, не означает, что их все надо открывать при старте. Хотя стоило бы им добавить в настройки отдельных pdb — стартовать вместе с cdb или нет.
Invisible columns
Ну лично я считаю, что показывать в sql*plus'овском describe их надо, но дополнительно показывать флаг «невидимости». В целом же эта история уходит корнями еще в «старые» виртуальные(вычисляемые) столбцы, функциональные индексы и extended статистики. Неоднозначностей тут еще много.
PL/SQL support in with
Стоит отметить, что «не везде» это всего лишь scalar subquery caching. A pragma UDF, несмотря на полностью такой же механизм инлайна, все-таки позволяет работать кэшированию deterministic.
ЗЫ: Кстати, ссылка на сам пост, комментарий с SSC там как раз мой :)
SQL Text expansion
Как я в том посте в комментариях говорил, expand_sql работает не совсем честно. Лучше смотреть в 10053 трассе.
DBMS_METADATA and session sequence
стоит упомянуть и про nopartition
PL/SQL support in SQL with in PL/SQL
Собственно, в этом смысла и нет:
1. в pl/sql просто нет необходимости создавать функцию в запросе(мне самому про этот «баг» рассказали, т.к. иначе мне в голову не приходило создавать инлайн функцию внутри запроса в хранимке...)
2. уже сейчас есть некоторая проблема с неймспейсам внутри инлайн функций, а внутри pl/sql это будет еще жестче.
3. это было бы еще лишние переключения контекста, которые у инлайн функций и так есть.
То есть даже если и сделают так чтобы парсер справлялся, то использовать это врядли будут.
PS: Кстати, вспомнил почему попробовал использовать SQL с WITH в PL/SQL.
Я в основном работаю с Oracle из PL/SQL Developer (не так old-school-но, как через sql*plus, зато удобно :) ).
И тут обнаружил, что SQL Window не поддерживает новый синтаксис — ругается.
Ок, думаю — перехожу в command window. Там та же ситуация — ругается на синтаксис.
Плюю, перехожу в честный sql*plus (но на физическом компе стоит клиент ещё от 11)… и обнаруживаю что sql*plus от 11 тоже ругается на новый синтаксис.
Чтобы не ставить новый оракл клиент или не работать из sql*plus виртуалки, думал по принципу: ОК, клиентские приложения не знают нового синтаксиса, но сервер то знает! Надо ему запилить как-то на серверную часть этот запрос. Ну а как проще всего запилить? Всунуть в PL/SQL код — пусть на сервере откомпилируется. Тут то я и узнал что PL/SQL тоже не поддерживает новый синтаксис. Причём, даже через новый SQL*Plus.
Естественно, через execute immediate он в конечном итоге был запущен, «но неприятный осадок остался».
1) Тестирую то со второго дня после релиза (с 30-го июня), но не только этим занимаюсь же — есть ещё работа. А отчего такой вывод?
2) autostart PDB — я согласен, что оракл, скорее всего считает это не багом… но это неудобно с точки зрения потребителя. Я хочу настройку/параметр стартовать ли эту базу автоматически.
3) снимать трассировку — достаточно морочное дело, скажем честно — требуется ряд дополнительных телодвижений, да и не всегда есть доступ к папке с трейсами на сервере, увы. Потому простой способ получить запрос был бы хорошим
4) «PL/SQL in SQL WITH in PL/SQL — в целом по всем пунктам комментариев согласен, однако оракл ведь декларирует, что PL/SQL вполне прозрачно поддерживает включение select / insert / update / delete выражений, но вот тут начинаются исключения. Просто не целостно выглядит. Хотя практическая польза несколько сомнительна. Но от того, что я и вы не применяем это, не значит что этого не захочет использовать ещё кто-то.
Для меня, например, использование локальных подпрограмм (например объявить процедуру внутри процедуры) есть ненужное излишество, т.к. я по большей части не использую standalone процедуры, а пишу пакеты, и я просто могу использовать приватные конструкции. При этом мне этого достаточно. Это не значит что другие не пользуются этой функциональностью в своих ситуациях или предпочтениях.
Надеюсь аналогия понятна.
1) да просто полно более серьезных ошибок, вплоть до краша баз.
2) думаю в 12.2 это будет, т.к. про это уже многократно писалось и говорилось.
3) просто к сведению: под pdb'шным sys'ом все показывает нормально для all_objects
4)
вот тут начинаются исключения
я, собственно, тоже против исключений. Но думаю допилить парсер им будет довольно тяжело и, боюсь, еще новых багов наклепают.

Кстати, насчет трейс файлов: в принципе достаточно один раз все настроить и все будет проще. Для примера сейчас сделал минифункцию чтения трейс файлов: github.com/xtender/xt_scripts/blob/master/inc/trace_dir.sql
Чтобы получить список файлов этой директории:
SQL> select * from table(xt_traces.get_trace_dir_list);
Читаем файл:
SQL> select * from table(xt_traces.get_trace('имя файла'));
Хм. Посмотрел код. Замечательно, но для моего окружения так же неприменима. Чтобы воспользоватся твоим кодом нужно как минимум:
1) GRANT CREATE ANY DIRECTORY чего в моих «энтерпрайз» окружениях я получу ни в жизни — проще получить сетевую шару на папку дампов (что тоже не просто, честно!).
2) Грант на использование джавы — отдельная тема. Вообще с джавой можно добраться на сервере много куда, куда не положено. Потому без сильной необходимости — не дадут-с.

А эта процедура уже включена в релиз, потому для сравнительно простых случаев она очень даже применима. Я не говорю про замену трейс файлов. То, для чего я их использую, всё равно не заменит ничего (ну разве что awr отчёты в некоторой мере).
Этот код должны выполнять дба, а у них соответствующие права есть. Сама же процедура возвращает не тот трансформированный запрос, что будет выполняться, поэтому ее можно использовать только в некоторых случаях.
Впрочем вообще считаю, что такие вещи надо или дев или тест серверах выполнять. К прод.серверам разработчикам вход надо разрешать в крайне редких случаях.
Увы, зачастую, даже на дев сервера доступ сильно ограничен, «чтобы_вдруг_чего_не_вышло». :-\ Таковы реалии entreprise.
Что за контора? Я сколько видел, везде на дев.сервера как минимум нач.отделов и тимлидов права полные.
Если говорить обезличенно — я с этим сталкивался в двух крупных международных инвестиционных банках из top10. Занимал позиции от мид дева до Деливери менеджера. Конечно существуют workarounds, но они трудозатратные. В чистом виде доступ на unix где стоит оракл либо dba права никто не даст. Права где присутствует слово ANY — жёлтая, а то и красная карточка аудита. Это вкратце.
Это интересно какие? В каких отделах?
доступ на unix где стоит оракл
это девелоперам в абсолютном большинстве случаев и не нужно.
Sign up to leave a comment.

Articles