Showing posts with label Database Configuration Assistant. Show all posts
Showing posts with label Database Configuration Assistant. Show all posts

Differences in DBCA responsefiles in Oracle Database 19c and Oracle AI Database 26ai

 After the release of Oracle Database AI 26ai (Enterprise Edition only) there are some questions to ask. 

One is, can I reuse my response files created with the Database Configuration Assistant of my 19c database, where do I maybe need to or would be able to do changes? To answer this question, a view/comparison of the two response files is necessary. The configuration was done on both database versions with “advanced configuration” on Linux (as all other 26ai versions are not available yet, the 19c dbca response file was created with 19c RU 24).

So, let’s start with the comparison. One interesting fact is found at the beginning of the response file. The file version is 12.2.0 (because 19c was/should have been a 12.2.X release) while the 26ai is using response file 23.0.0 – not a big surprise, as 26ai is showing itself as a 23.26 in a lot of different places.

The next interesting fact is the databaseConfigType. In 19c there was SI (Single Node), RAC and RACONENODE available, with 26ai Oracle added SEHA (Standard Edition High Availability). As today (Feb. 5th, 2026) the Standard Edition Software is not available for 26ai there is no chance to test this, but it should make the configuration of SEHA environments easier in the future. Therefore, 26ai added also more SEHA related parameters, e.g the sehaServiceName and the sehaNodeList (unfortunately it is not grouped together in the response file, so one must search for the parameters manually).

The next topic added is the managementPolicy. It controls, how the database handles PDBs when restarting. Flora has a very informative blog post done for 23c, so details how to use that can be found here: https://oracleandme.com/2023/05/16/23c-floating-pdbs-the-lab/

As there is no Database Express management possibility anymore in 26ai, emConfiguration now does only allow CENTRAL (Enterprise Manager Cloud Control) or NONE as values. DBEXPRESS and BOTH are not allowed anymore.

One interesting fact: In my 19c response file the fast recovery area was part of the InitParams line, with 26ai a new parameter recoveryAreaSize was added, but the value is also still part of the initParams line. What will happen, if there are two different sizes specified in the response file? Is there a difference between the setup part and the running part later?

Also new are the specification of the dbOptions and pdboptions, which now can be different, e.g. SPATIAL can be installed at CDB level with dbOptions SPATIAL:true but can be excluded from the PDB pdbOptions with SPATIAL:false.

The last new parameter I found in the 26ai response file is useOMF, which can be set to true of false. In the 19c response file, there is no useOMF parameter – it was set at the background to true.

The last new parameter I’ve found is enableArchive which is default set to false, meaning the database is not using archive log mode after it was created.

sampleSchema installation is now removed from the 26ai response file, typically now one installs them in a production or test environment.

All in all, there are not so many differences in the response files. All new parameters are not mandatory except of SEHA, if one uses this option the depending parameters must be inserted, and the default values are typically set to none.

One funny thing in 26ai is, that createAsContainerDatabase is not mandatory, but the default value is still false. As 26ai can’t be installed as non-CDB, I question myself, why this was inserted (also inserted is the initParams entry “enable_pluggable_database=true”):

#-----------------------------------------------------------------------------
# Name          : createAsContainerDatabase
# Datatype      : Boolean
# Description   : flag to create database as container database
# Valid values  : Check Oracle12c Administrator's Guide
# Default value : false
# Mandatory     : No
#-----------------------------------------------------------------------------
createAsContainerDatabase=true

If you are interested in the response files, you can download them from my storage:

19c: dbca_19c.rsp
26ai: dbca_26ai.rsp

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.






DBT-00007 User does not have the appropiate write privilege when starting dbca

At the moment I am preparing some virtualboxes to create the live demos for my presentation about "Single Tenancy is only more complexity!?" at the DOAG Conference 2018.

For this, I have setup a fresh new Linux and installed 18c Grid Infrastructure into it (using role separation, so GI is installed with the grid user, the databases should be installed with the oracle user).

After I have created my 2 ORACLE_HOMEs with the Standard Edition 2 and the Enterprise Edition database (Software only) I wanted to set up the first databases, but unfortunately the dbca (Database configuration assistant) struggled with "a [DBT-00007] User does not have the appropriate write privilege when starting dbca" error. Since I NEVER have seen that error before, I really was wondering, what happens (and I don't think I have missed some steps). And no, I don't want to check this with the Oracle support, like mentioned at the popup window details.

I have setup my ORACLE_BASE and ORACLE_HOME before I have started dbca, so this isn't the cause for this error. As the popup window does not shown anything in addition, I tried to check the log of the dbca at $ORACLE_BASE/cfgtoollogs/dbca - but there wasn't any.
So the problem seemed to by correlated to this directory.

The owner of $ORACLE_BASE/cfgtoollogs was grid (group oinstall) and the rights set were 755 - so only the grid user was allowed to write, group members weren't.

To change this I have first changed the owner of the cfgtoollogs directory:

chown -hR oracle:oinstall /u01/app/oracle/cfgtoollogs
and afterwards I have given write rights to all subdirectories, so also the grid user would still be able to add his stuff to the log directory:

chmod 775 /u01/app/oracle/cfgtoollogs/
chmod 770 /u01/app/oracle/cfgtoollogs/dbca
chmod 770 /u01/app/oracle/cfgtoollogs/asmca
chmod 770 /u01/app/oracle/cfgtoollogs/netca


That's it folks, the dbca started after I have made these changes.