Немного камней по дороге к APEX 5.0

Как писал раньше, для начала планировал создать отдельную подключаемую БД, в которой уже потом разворачивать APEX 5.0. Для этого решил создать контейнерную БД Oracle 12.1.0.2.3 (CDB) на Linux 86-64, смигрировать уже имеющуюся холодную не-контейнерную БД (non-CDB) в виде подключаемой (PDB) в новосозданную и на её копию установить новый APEX. Создал и обновил БД, на следующем шаге воспользовался руководством: Multitenant : Migrate a Non-Container Database (CDB) to a Pluggable Database (PDB) in Oracle Database 12c Release 1 (12.1). И это было ошибкой. :)

Как промежуточный результат, получил CDB, в которой APEX уже был установлен в корневом контейнере и мог быть обновлён только для всех контейнеров сразу. Если попытаться обновить его только в одном из контейнеров, то те из них, в которых версия APEX не совпадала с версией в корневом контейнере, просто открывались в ограниченном режиме, оставляя сообщения об ошибках в PDB_PLUG_IN_VIOLATIONS:

> alter session set container=cdb$root

session SET altered.

> select message from pdb_plug_in_violations 
 where type = 'ERROR' 
   and status <> 'RESOLVED';

MESSAGE                                                                                            
----------------------------------------------------------------------------------------------------
APEX mismatch: PDB installed version 4.2.6.00.03 CDB installed version 4.2.5.00.08                   

Поэтому пришлось удалять полученную PDB, затем удалять APEX из CDB (Multitenant : Uninstall APEX from the CDB in Oracle Database 12c Release 1 (12.1)) и создавать PDB как копию non-CDB с установленным APEX заново. Но и на этом всё не закончилось: PDB открывалась со следующей ошибкой:

Sync PDB failed with ORA-65177 during 'alter user APEX_PUBLIC_USER account unlock'

Гугл на это сказал немного, как и MOS. Поскольку в корневом контейнере такого пользователя не обнаружил, а в PDB у него были лишь права DML на FLOWS_FILES.WWV_FLOW_FILE_OBJECTS$, то решил его пересоздать в PDB, не мудрствуя лукаво:

conn / as sysdba
alter session set container=pdb1;
drop user apex_public_user;

На что Oracle ответил:

28014. 00000 -  "cannot drop administrative users"
*Cause:    An attempt was made to drop administrative users.
           Administrative users can be dropped only by SYS during
           migration mode.
*Action:   Try dropping administrative users during migration mode.

Немного погуглив, изменил подход:

alter pluggable database pdb1 close immediate;
alter pluggable database pdb1 open upgrade;
alter session set "_oracle_script"=true;
alter session set container=pdb1;
drop user apex_public_user;
alter pluggable database pdb1 close;
alter pluggable database pdb1 open;

PDB открылась без ошибок. После этого можно было пересоздать пользователя APEX_PUBLIC_USER:

alter session set container=pdb1;
create user apex_public_user identified by apex_public_user;
grant select, insert, update, delete on flows_files.WWV_FLOW_FILE_OBJECTS$ 
  to apex_public_user;
grant connect to apex_public_user;

Пользователь на месте, PDB успешно открыта. Увы, попытка достучаться из ORDS к базе возвращала 503 Service unavailable. В alert.log нашёл «воодушевляющее» сообщение:

ORA-00600: internal error code, arguments: [kpdbAttachSga: bad pdb], [0], [pdb1.workgroup], [], [],[], [], [], [], [], [], []

Поиск на MOS вывел на похожий параметром ORA-00600 баг 20438519 и устраняющий его патч 19972766. После установки последнего наконец-то всё заработало.