when it runs on your computer ...

... please don't see it ready for customers.

I try to enable Database Vault on an existing 12.2 database.
A proper document to follow is How To Enable Database Vault in a 12c database ? (Doc ID 2112167.1)

At some point it tells to run

@$ORACLE_HOME/rdbms/admin/catmac.sql system temp <system_password>

unfortunately this fails with

CREATE USER dvsys IDENTIFIED BY "D_DVSYSPW"
*
ERROR at line 1:
ORA-28003: password verification for the specified password failed
ORA-20025: Password must contain at least 1 digit(s)

(you need to spool the results into a file to find it in the output stream)

The reason is obvious:

SQL> select * from dba_profiles where resource_name='PASSWORD_VERIFY_FUNCTION' and Profile='DEFAULT';

PROFILE                        RESOURCE_NAME                    RESOURCE LIMIT                                    COM
------------------------------ -------------------------------- -------- ---------------------------------------- ---
DEFAULT                        PASSWORD_VERIFY_FUNCTION         PASSWORD ORA12C_VERIFY_FUNCTION                   NO

and so is the solution:

alter profile default limit PASSWORD_VERIFY_FUNCTION null;
@$ORACLE_HOME/rdbms/admin/catmac.sql system temp <system_password>
alter profile default limit PASSWORD_VERIFY_FUNCTION ORA12C_VERIFY_FUNCTION;

Oracle requires to disable a security feature to enable another one.
In this sandbox environment it's not a specific, hand-made password verify function. It's the default one from oracle.
It would be very nice if oracle would test it's security features to run with each other.

There is no problem for me, but I'm wondering how serious (holistic) Oracle takes "security"?

preupgrade.jar version number

Mike Dietrich is very motivated to convince everyone who wants to take Oracle database upgrades serious to use always the latest version of preupgrade.jar.

Some parts of Note:884522.1 - How to Download and Run Oracle's Database Pre-Upgrade Utility
 are misleading in my point of view:

If the upgrade-to version is 12.2 or higher, then save the file to your target $ORACLE_HOME/rdbms/admin directory and then unzip the file. It could be your source or target $ORACLE_HOME.

but this will be sorted out for sure in the new future.

For me deploying some files to an ORACLE_HOME (after it's own well defined deployment process) sounds creepy, and I'm interested how this will fit into the concept of read-only ORACLE_HOMEs in 18c+.

As I don't want to modify anything (even replacing with the identical files in case latest preupgrades.jar is deployed already) it's better to check the version of current preupgrade.jar.

If it is used already, the Build number is visible in
preupgrade.log:

Report generated by Oracle Database Pre-Upgrade Information Tool Version
12.2.0.1.0 Build: 14

Upgrade-To version: 12.2.0.1.0

=======================================
Status of the database prior to upgrade
=======================================
...

But if it is not executed (yet), you have to get the Build number from the jar file.
At the moment (Build 014) you can get it from preupgrade_package.sql by a simple statement:

unzip -p $PATH_TO_PREUPGRADE/preupgrade.jar preupgrade_package.sql | \
awk '$1 ~ /c_build/ { print $5 }' | tr -d \;

This can help to identify the current installation and if a (re-)installation is really required.

---

unfortunately there are some inconsistencies.
e.g. in preupgrade_181_cbuild_2_lf.zip:
if you unzip this file you will get a preupgrade_package.sql with c_build is 2
but the preupgrade_package.sql inside of preupgrade.jar shows c_build is 1