Кстати, кроме sqlldr можно использовать родные директ инсерты из oci. В целом же я бы просто передавал большими коллекциями для уменьшения sql*net round-trip'ов
Впрочем вообще считаю, что такие вещи надо или дев или тест серверах выполнять. К прод.серверам разработчикам вход надо разрешать в крайне редких случаях.
Этот код должны выполнять дба, а у них соответствующие права есть. Сама же процедура возвращает не тот трансформированный запрос, что будет выполняться, поэтому ее можно использовать только в некоторых случаях.
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('имя файла'));
Хотя я сам использовал result_cache для похожего(выставление и снятие флага), но не в серьезных промышленных задачах, поэтому лучше сразу откажитесь от такого решения, т.к. оно ненадежно:
1. все проблемы джобов остаются;
2. механизм result_cache надостаточно надежен(я в блоге у себя писал про проблему инвалидаций);
3. аварийное падение/незапуск процедуры может оставить функцию неинвалидированной;
4. У вас все неконсистенто: пользовательские блокировки(причем забыли dbms_lock.request), запрос из dba_jobs и создание джоба
5. в многопользовательской большой системе это все может убить производительность. триггеры надо максимально облегчать, а не утяжелять опасными вещами.
Посмотрите лучше в сторону object change notifications(хотя имхо вполне нормально использовать AQ или scheduler). А для флагов используйте глобальные контексты
Согласен про сумбурность повествования, все как-то скомкано и скачками. Недавно только тестируете?
Прокомментирую некоторые вещи:
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. это было бы еще лишние переключения контекста, которые у инлайн функций и так есть.
То есть даже если и сделают так чтобы парсер справлялся, то использовать это врядли будут.
Довольно сложно вы решили подойти к делу… Вообще эти все варинты решений уже тут публиковались либо постами, либо комментариями.
Например, три года назад я уже публиковал на хабре свое решение в посте-ссылке, но потом все посты-ссылки выпилили…
В блоге решение осталось: www.xt-r.com/2010/11/oracle-svn-git-etc.html
Не надо ерничать. Все очевидно. Имейте совесть, даже больной, извращенный в 90-х, смысл этого эпонима не имеет никакого отношения к сабжу. И уж, тем более, первоначальный.
с чего взяли такое? С этим там как раз все ок, нюанс с пакетами только в том, что сбрасывается только для всех функций пакета.
«остальные» моменты я привел в ссылке ниже
зы… так ошибки и не исправили… без dbms_lock.request смысла вообще нет в ваших пользовательских блокировках. нечего там «релизить»
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. все проблемы джобов остаются;
2. механизм result_cache надостаточно надежен(я в блоге у себя писал про проблему инвалидаций);
3. аварийное падение/незапуск процедуры может оставить функцию неинвалидированной;
4. У вас все неконсистенто: пользовательские блокировки(причем забыли dbms_lock.request), запрос из dba_jobs и создание джоба
5. в многопользовательской большой системе это все может убить производительность. триггеры надо максимально облегчать, а не утяжелять опасными вещами.
Посмотрите лучше в сторону object change notifications(хотя имхо вполне нормально использовать AQ или scheduler). А для флагов используйте глобальные контексты
Прокомментирую некоторые вещи:
У меня на oel проблем не было
Принципиально наличие нескольких pdb, не означает, что их все надо открывать при старте. Хотя стоило бы им добавить в настройки отдельных pdb — стартовать вместе с cdb или нет.
Ну лично я считаю, что показывать в sql*plus'овском describe их надо, но дополнительно показывать флаг «невидимости». В целом же эта история уходит корнями еще в «старые» виртуальные(вычисляемые) столбцы, функциональные индексы и extended статистики. Неоднозначностей тут еще много.
Стоит отметить, что «не везде» это всего лишь scalar subquery caching. A pragma UDF, несмотря на полностью такой же механизм инлайна, все-таки позволяет работать кэшированию deterministic.
ЗЫ: Кстати, ссылка на сам пост, комментарий с SSC там как раз мой :)
Как я в том посте в комментариях говорил, expand_sql работает не совсем честно. Лучше смотреть в 10053 трассе.
стоит упомянуть и про nopartition
Собственно, в этом смысла и нет:
1. в pl/sql просто нет необходимости создавать функцию в запросе(мне самому про этот «баг» рассказали, т.к. иначе мне в голову не приходило создавать инлайн функцию внутри запроса в хранимке...)
2. уже сейчас есть некоторая проблема с неймспейсам внутри инлайн функций, а внутри pl/sql это будет еще жестче.
3. это было бы еще лишние переключения контекста, которые у инлайн функций и так есть.
То есть даже если и сделают так чтобы парсер справлялся, то использовать это врядли будут.
Например, три года назад я уже публиковал на хабре свое решение в посте-ссылке, но потом все посты-ссылки выпилили…
В блоге решение осталось: www.xt-r.com/2010/11/oracle-svn-git-etc.html
www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=966657&msg=13101831
www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1034529&msg=14618308