The client has also configured a small Swap mountpoint, when looking at all memory available on the server. Oracle documentation says this:
The VM has 116GB memory, and 32GB reserved for HugePages. The actual swap mountpoint is 4GB big and, based on the Oracle Server Configuration Checklist for 19c, the swap mountpoint should be in this case 16GB.
I’m using Oracle Linux 9, xfs filesystems. I’ll increase the swap mountpoint online, with the databases running.
(more…)I did script the TDE wallet configuration for my client.
TABLESPACE_ENCRYPTION and WALLET_ROOT in the spfile.When running this 3rd script on a database it failed on the second command:
SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY "wallet_password";
keystore altered.
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "wallet_password";
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "wallet_password"
*
ERROR at line 1:
ORA-28353: failed to open wallet
The client plugged a non-encrypted PDB into a CDB with TDE Encryption Wallet enabled. All works fine, we can read the data. However when trying to create a tablespace we get:
CDB1 SQL> create tablespace TBS_NEW;
Error starting at line : 1 in command -
create tablespace t1
Error report -
ORA-28374: typed master key not found in wallet
28374. 0000 - "typed master key not found in wallet"
*Cause: You attempted to access encrypted tablespace or redo logs with a typed master key not existing in the wallet.
*Action: Copy the correct Oracle Wallet from the instance where the tablespace was created.
What is wrong?
(more…)Some programs are part of Oracle ISV – Independent Software Vendors – program and include various types of Oracle licenses. This allows to install the application database in various Oracle configurations. At my customer, the software includes Advance Security Option Oracle license. This was the reason we decided, even before moving to the cloud, to encrypt the database.
Here is a summary on how to perform full online encryption (TDE) of a database. The process is quite simple, but there are known surprises you might want to avoid.
(more…)TDE – Transparent Data Encryption – is the Oracle solution for protecting data at rest. This refers, protecting data that is stored in one file or one disk. This data will be encrypted. Only after the database is open and the wallet password is given, you can query the data and see it.
Recently I’ve been working more with ExaCC and migrating databases from on-premises to the Cloud. Took quite some days to get into TDE and sometimes confusing terms used in the documentation and on the web.
This post summarizes all the concepts to have in mind when working with Oracle encrypted databases, which is the default in the Cloud and Exadata systems.
(more…)My customer has five standby databases in the same 2-node RAC cluster. Today, after an ASM data diskgroup full, several databases had to recover quite some archivelogs.
The load on the first node immediately went to the roof when I restarted the redo apply, after adding space to the diskgroup.
This because, by default, the redo apply starts on the first available instance of the RAC cluster, which in this case was the first instance for all DBs.
Two things I learned:
(more…)This feature was just backported from Oracle 23ai. The new ORA$MANDATORY audit policy was added with the Oracle 19.26 RU. This policy is not visible at UNIFIED_AUDIT_POLICIES or AUDIT_UNIFIED_ENABLED_POLICIES.
After patching the database to 19.26, then you see entries on UNIFIED_AUDIT_TRAIL:
SYS@CDB2.CDB$ROOT> select EVENT_TIMESTMAP, SYSTEM_PRIVILEGE_USED, ACTION_NAME
from UNIFIED_AUDIT_TRAIL
where UNIFIED_AUDIT_POLICIES='ORA$MANDATORY'
order by EVENT_TIMESTMAP;
EVENT_TIMESTAMP SYSTEM_PRIVILEGE_USED ACTION_NAME
_________________________________ _________________________ _________________
02-FEB-2025 21:54:56.192982000 SYSDBA LOGON
02-FEB-2025 21:54:56.216549000 SYSDBA SELECT
02-FEB-2025 21:55:00.381577000 SYSDBA, ALTER DATABASE ALTER DATABASE
02-FEB-2025 21:55:00.393882000 SYSDBA LOGOFF
...
The actions that are audited by ORA$MANDATORY policy are described on Oracle 23ai documentation.
What I find interesting, is that the “ALTER DATABASE MOUNT” during startup is audited, so we can have a good history of database startups.
(more…)My customer running on ExaCC (Exadata Cloud@Customer) was getting “ORA-64307: Exadata Hybrid Columnar Compression is not supported for tablespaces on this storage type” on one of his test databases.
I did test connecting to SYS and no problem. Then I try to do using his tablespace and indeed, I get the error:
Quite going around, to check what was different on the user tablespace than on others. I test a self created tablespace and it works.
Strange. Until I found that… some datafiles were not in ASM!
Seems the ASM Diskgroup is almost full and the client DBA just put the datafiles somewhere else!
Since many years at my customer I’m using “opatchauto” to perform a out-of-place patching of Oracle Restart (GI+RDBMS).
My customer is concerned about database users using not licensed options, like partitioning. To avoid it, at the installation time the partitioning option is disabled using chopt, like described at Doc ID 948061.1.
Today during a check we noticed that Partitioning option was activated everywhere, which is not the client standard! We found out the origin of the problem was the out-of-place patching with “opatchauto”.
The big advantage of using “opatchauto” is that it allows easily either a single-step or a two-step Out-of-Place patching. We just write in a properties file the name of the new Oracle Homes and it does:
This allows to decrease the patching downtime without RAC to about 10 minutes, with the two-step (prepare clone + switch clone) operation.
Here the steps to reproduce de bug:
(more…)Quick post to add info about the following Goldengate error:
OGG (http://localhost:9300 test1 as ogg_pdb1@CDB2) 10> REGISTER EXTRACT E_TEST1 DATABASE CONTAINER (pdb1)
2024-12-08T17:16:58Z ERROR OGG-08224 Error: CONTAINER option was specified though the database does not support containers.
This means that you are connected directly to the PDB, and not to CDB$ROOT.
To register Goldengate 21 extracts you need to connect to the Root container with a common user.
OGG (http://localhost:9300 test1 as ogg_pdb1@CDB2) 12> DBLOGIN USERIDALIAS ogg_cdb2
Successfully logged into database CDB$ROOT.
OGG (http://localhost:9300 test1 as ogg_cdb2@CDB2/CDB$ROOT) 13> REGISTER EXTRACT E_TEST1 DATABASE CONTAINER (pdb1)
2024-12-08T17:20:36Z INFO OGG-02003 Extract group E_TEST1 successfully registered with database at SCN 8039188.
Well, in the future this is not anymore true, as new version from Goldengate and DBs will work only at PDB level.