Sync PDB failed with ORA-40365 while performing 'alter user sys account lock password expire' - How to get rid of it.

As so often, a customer was asking for the solution of an error they have seen at the database. After creating a new Oracle 19c database with a fresh PDB in it, they found the error "Sync PDB failed with ORA-40365 while performing 'alter user sys account lock password expire'" in the view PDB_PLUG_IN_VIOLATIONS.

The Oracle Support Note "Sync PDB failed with ORA-40365 while performing 'alter user sys' (Doc ID 2777162.1)" told him that this error can happen when upgrading a database to a newer version.

Doc ID 2777162.1

You know how it is. Things that go differently than they are described demand analysis and don't give you a moment's peace. So I started to recreate the whole thing...

While the customer is working with version 19.8, I installed version 19.13 on my MS Windows laptop and created a new database there with the DBCA. I was (not) surprised when I saw the error on my end as well.

This means that something fundamentally different is going on here than what was described at Oracle Support. 

Log me, find me, SR me

Well - this error shouldn't happen if you create a new database, isn't it? So first I checked the version of the password file on my laptop for the new created CDB. This can be done with "orapwd" and the parameter describe.

Hm, the password file was created with version 12. But the support note told us, that a fresh created CDB should have password file format 12.2 - if not, we can upgrade the file manually to 12.2 using orapwd (more to come later in this blog post). 

So it looks like the DBCA is creating the wrong password file version in some way. But can this be? Maybe it depends on the password complexity? No, also another attempt with a very complex password ended with the same password file version: 12. 

Well, if the DBCA is doing it wrong, maybe it's recorded in the log file of the creation? And yes, it is.
 
 
As you can see at the highlighted line, the DBCA actually creates the password file fix with version 12 - instead of the version 12.2 we expected.
 
In my opinion, this is a bug - so I opened a service request with Oracle about it.
 
Long story short: This isn't a bug. At least not a bug at the DBCA. It is a bug at the documentation resp. the support note. Based on communication with Oracle Support, a new note has now been created:

Oracle Support Document 2663482.1 (19c DB Does Not Make Password File Default Format As 12.2)

can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=2663482.1
This new note now tells us, that we need to pass "-skipPasswordComplexityCheck false" to the DBCA (one has to ensure, that the password set is passing the password complexity function) to get a 12.2 password file. Also, an enhancement request was created to make the 12.2 password file version as the default one when creating a 19c database.
In the original support note (Doc ID 2777162.1), Oracle also has changed things now. First is, they have put in that his can also happen with a newly created database. Also they tell us, why they haven't changed the behavior. This is mainly because, in addition to password complexity, things like "Password Lifetime" for SYSDBA, SYSBACKUP,... users are turned on with password file version 12.2.
So it should be exciting to see if the behavior will then change fundamentally in a newer database version or if will remain as default 12.

How to get rid of it

Well, first step is to recreate your password file with version 12.2 - you use orapwd with a input file and the version you want the new file created as I did: 
 
Don't forget to rename the fresh created file that it has the same filename as the original one had (and check all topics that a change of the password file version does influence). Afterwards, you can fix the error in PDB_PLUG_IN_VIOLATIONS.
I tried to re-open the PDB as well as using "exec dbms_pdb.sync_pdb" - but the error never was set to resolved - it stayed in PENDING state and I weren't able to use "exec dbms_pdb.clear_plugin_violations".

To have the entry removed, I needed to do something I really DON'T like to do - to delete manually from the data dictionary with a "delete from pdb_plug_in_violations where error=40365;"  statement. Be aware that changing things at the Data Dictionary manually can cause a lot of trouble - you should only do it, if you have a sufficient backup and you are sure you do the right thing.