# odacli describe-job -i 2ff3fd5d-f611-4ae6-aae0-63df7c08ec71
 
Job details
----------------------------------------------------------------
                     ID:  2ff3fd5d-f611-4ae6-aae0-63df7c08ec71
            Description:  DB Home Patching to 19.31.0.0.0: Home ID is 1c101fd3-2ca8-55f6-9415-22ec5abc53da
                 Status:  Failure (To view Error Correlation report, run "odacli describe-job -i 2ff3fd5d-f611-4ae6-aae0-63df7c08ec71 --ecr" command)
                Created:  June 09, 2026 15:07:23 CEST
                Message:  DCS-10001:Internal error encountered: Unable to autoextend tablespace TEMP.

The issue is that Oracle tries to “set autoextend on” on the temporary files in 19.31., but runs a syntactically wrong command. E.g. in the alert.log I could see

2026-06-09T15:54:14.898088+02:00
alter database tempfile '/u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4kz32_.tmp /u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4l3wf_.tmp' autoextend on next 100m maxsize 20g
ORA-1516 signalled during:  alter database tempfile '/u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4kz32_.tmp /u02/app/oracle/oradata/mydbt_dc2/MYDBT_DC2/datafile/o1_mf_temp_m2d4l3wf_.tmp' autoextend on next 100m maxsize 20g ...

I.e. Oracle just listed all tempfiles separated by blank in one string. This is of course wrong and produces the error.

The workaround was to 

 – create a temporary tablespace temp2

 – make temp2 the default temporary tablespace

 – drop temporary tablespace temp

 – create the temporary tablespace temp with just 1 tempfile

 – make temp the default temporary tablespace

 – drop temporary tablespace temp2

Then run the “odacli update-dbhome” again and it will be successful. Afterwards add your temporary files to tablespace temp again. 

Please consider that it is not obvious in the produced errors of odacli in what DB the error happened (odacli update-dbhome patches all DBs running in the specified ORACLE_HOME). To find out what DB is affected it’s a good idea to scan the alert-logs for the error:

$ find /u01/app/odaorabase/oracle/diag/rdbms/*/*/trace -name "alert*.log" -exec grep -il "ORA-1516" {}\;

To proactively avoid the issue when patching to 19.31. on the ODA, I’d recommend to check your databases in advance if they have more than 1 tempfile in the temporary tablespace and implement the workaround mentioned above.

select count(*) from dba_temp_files where tablespace_name='TEMP';

We opened a SR with Oracle to get the issue fixed for the next release.

Update 18.06.2026:

If you do use a Standby DB (Data Guard) and use the workaround mentioned above, then please consider that you have to add the tempfiles at the standby site as well after recreating TEMP. See here, here and here.

L’article Temporary tablespace and ODA 19.31. est apparu en premier sur dbi Blog.

So, let’s consider that you have a performance issue with a query and you want to test if an optimizer bug fix caused a suboptimal plan. How can you find the optimizer bug fix which caused that plan asap?

REMARK: I do assume that you have a script /tmp/sql.sql with the sql-query to reproduce the slowly running SQL.

Let’s get started to find the optimizer bug-fix:

Problem: Query is running slow in 19c. The query has been provided in the script /tmp/sql.sql

Currently we are on 19.26. and do have OPTIMIZER_FEATURES_ENABLE set to the default, which is 19.1.0 in 19c:

SQL> show spparameter optimizer_features_enable

SID	 NAME			       TYPE	   VALUE
-------- ----------------------------- ----------- ----------------------------
*	 optimizer_features_enable     string

–> not explicitly set in the spfile, so it’s set to default:

SQL> show parameter optimizer_features_enable

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_features_enable            string      19.1.0

SQL> show parameter fix_control
SQL> 

–> no _fix_control-parameter set.

According Active Session History (ASH) the query did run for days in the past (!!!):

SQL>  select sql_exec_start, sql_plan_hash_value, (count(*)*10)/3600 active_hours, max(sample_time)-min(sample_time) duration
  2  from dba_hist_active_sess_history
  3  where sql_id='8cdydzbsh10dd'
  4  group by sql_exec_start, sql_plan_hash_value
  5  order by 1;
 
SQL_EXEC_START       SQL_PLAN_HASH_VALUE ACTIVE_HOURS DURATION
-------------------- ------------------- ------------ ----------------------------
05-APR-2025 07:36:03           126619261        80.12 +000000003 08:14:27.685
07-APR-2025 07:36:07           126619261        32.33 +000000001 08:22:43.551
08-APR-2025 16:06:00           126619261        47.68 +000000001 23:45:26.074
10-APR-2025 15:57:22           126619261        17.76 +000000000 17:47:30.125
19-APR-2025 05:32:25           126619261       178.23 +000000007 10:31:45.271
21-APR-2025 05:32:46           126619261       134.60 +000000005 14:48:49.602
23-APR-2025 05:33:08           126619261        86.01 +000000003 14:09:08.540
 
7 rows selected.

REMARK: Please consider that using ASH requires the diagnostics pack to be licensed

1. Check if there is an Optimizer-Version-Setting, where the issue did not happen

We can test with different OPTIMIZER_FEATURES_ENABLE (OFE) settings, on what release this query may initially became slow with. But what different OPTIMIZER_FEATURES_ENABLE settings do we have? There’s a simple method to find that out. You just provide a non-existing OFE and the error tells you what OFE-settings are available:

SQL> alter session set optimizer_features_enable=blabla;
ERROR:
ORA-00096: invalid value BLABLA for parameter optimizer_features_enable, must
be from among 19.1.0.1, 19.1.0, 18.1.0, 12.2.0.1, 12.1.0.2, 12.1.0.1, 11.2.0.4,
11.2.0.3, 11.2.0.2, 11.2.0.1, 11.1.0.7, 11.1.0.6, 10.2.0.5, 10.2.0.4, 10.2.0.3,
10.2.0.2, 10.2.0.1, 10.1.0.5, 10.1.0.4, 10.1.0.3, 10.1.0, 9.2.0.8, 9.2.0,
9.0.1, 9.0.0, 8.1.7, 8.1.6, 8.1.5, 8.1.4, 8.1.3, 8.1.0, 8.0.7, 8.0.6, 8.0.5,
8.0.4, 8.0.3, 8.0.0

So now we can go backwards with OFE-settings to find a version where the query may have run fast:

alter session set OPTIMIZER_FEATURES_ENABLE='18.1.0';
@/tmp/sql.sql

--> Ctrl-C after some time.

alter session set OPTIMIZER_FEATURES_ENABLE='12.2.0.1';
@/tmp/sql.sql

--> Ctrl-C after some time.

alter session set OPTIMIZER_FEATURES_ENABLE='12.1.0.2';
@/tmp/sql.sql

--> Ctrl-C after some time.

alter session set OPTIMIZER_FEATURES_ENABLE='12.1.0.1';
@/tmp/sql.sql

--> Ctrl-C after some time.

alter session set OPTIMIZER_FEATURES_ENABLE='11.2.0.4';
@/tmp/sql.sql

--> Ctrl-C after some time.

alter session set OPTIMIZER_FEATURES_ENABLE='11.2.0.3';
@/tmp/sql.sql

--> Ctrl-C after some time.

alter session set OPTIMIZER_FEATURES_ENABLE='11.2.0.2';
@/tmp/sql.sql

--> Ctrl-C after some time.

alter session set OPTIMIZER_FEATURES_ENABLE='11.2.0.1';
@/tmp/sql.sql

Elapsed: 00:00:00.36

--> With 11.2.0.1 the query finished in 0.36 secs.

I.e. a change between 11.2.0.1 and 11.2.0.2 caused the optimizer to produce a suboptimal plan.

2. Test which bug fix caused the suboptimal plan

We can generate a script, which tests all _fix_control-settings which were introduced with OFE=11.2.0.2 to see what fix caused the query to run slow:

set lines 200 pages 999 trimspool on
spool /tmp/sql_fc.sql

select 'alter session set "_fix_control"='''||to_char(bugno)||':'||to_char(value)||''';'||chr(10)||
       'PROMPT '||to_char(bugno)||chr(10)||
       '@/tmp/sql.sql' 
from v$system_fix_control 
where OPTIMIZER_FEATURE_ENABLE='11.2.0.2';

...

spool off

REMARK: The CHR(10) inserts the necessary linefeeds in the script.

SQL> !vi /tmp/sql_fc.sql
--> remove all lines, which are not necessary
SQL> !cat /tmp/sql_fc.sql
alter session set "_fix_control"='6913094:1';
PROMPT 6913094
@/tmp/sql.sql

alter session set "_fix_control"='6670551:1';
PROMPT 6670551
@/tmp/sql.sql

...

alter session set "_fix_control"='9407929:1';
PROMPT 9407929
@/tmp/sql.sql

alter session set "_fix_control"='10359631:1';
PROMPT 10359631
@/tmp/sql.sql

SQL> 

First I do set OFE to 11.2.0.1 and then run my generated script to enable the fixes one after the other until it becomes slow:

SQL> alter session set optimizer_features_enable='11.2.0.1';
SQL> @?/tmp/sql_fc.sql

Session altered.

8602840

1 row selected.


Session altered.

8725296

1 row selected.

...

Session altered.

9443476

1 row selected.


Session altered.

9195582

--> after enabling fix for bugno 9195582 there is no output generated anymore, i.e. the query becomes slow.

So, we could identify the fix for bugno 9195582, which causes the optimizer to produce a suboptimal plan.

3. Details about bug 9195582 and the implementation of a workaround

The description field of v$system_fix_control provides more details about the bug-fix:

SQL> select description from v$system_fix_control where bugno=9195582;

DESCRIPTION
----------------------------------------------------------------
leaf blocks as upper limit for skip scan blocks
SQL> 

Searching in My Oracle SUpport for the bug resulted in MOS Note

Bug 9195582 – Skip Scan overcosted when an index column has high NDV (Doc ID 9195582.8)

In there we have the following description:

Symptoms:

Performance Of Query/ies Affected 

Description

The estimate for skip scan blocks will now be no more than leaf blocks.
Index skip scans will be used more often than previously.

REDISCOVERY INFORMATION:
If an index skip scan is not being selected for a query due to having a
high cost and one of the skip scan index columns has NDV which is higher
than the number of leaf blocks of the index then you may be facing this
bug.

Workaround
Force the skip scan using a hint.

Interestingly the faster plan did not have a skip scan in it, but a change in the estimation of blocks for skip scans, may of course also lead to other plans being skipped or considered.

At this point I did a relogin to the DB and ran my query with the appropriate fix turned off to verify that the query runs fast:

SQL> select value from v$session_fix_control where bugno=9195582;

     VALUE
----------
         1

SQL> alter session set "_fix_control"='9195582:OFF';

Session altered.

SQL> select value from v$session_fix_control where bugno=9195582;

     VALUE
----------
         0

SQL> @/tmp/sql.sql

Elapsed: 00:00:00.36

--> OK, it works around the issue.

For that workaround to become active, we can implement a SQL patch for the query with the issue. As I did not have the query anymore in the shared pool, I had to take the query text from Automatic Workload Repository (AWR) to create the SQL Patch:

REMARK: Again, please consider that AWR requires to diagnostics pack to be licensed.

set serveroutput on
declare
        v1      varchar2(128);
        v_sql   clob;
begin
        select sql_text into v_sql from dba_hist_sqltext where sql_id='8cdydzbsh10dd';
        v1 :=   dbms_sqldiag.create_sql_patch(
                        sql_text  => v_sql,
                        hint_text => q'{opt_param('_fix_control' '9195582:OFF')}',
                        name    => 'switch_off_fix_9195582'
                );
        dbms_output.put_line(v1);
end;
/
switch_off_fix_9195582

PL/SQL procedure successfully completed.

Later on you may check if the query runs fast by checking the data in the shared pool or in the AWR history:

select executions, (elapsed_time/executions)/1000000 avg_elapsed_secs, sql_patch from v$sql where sql_id='8cdydzbsh10dd';

Summary:

Sometimes you have to be fast to implement a workaround for a slowly running query. One option is to check if a query did run faster with older OPTIMIZER_FEATURES_ENABLE-settings and, if that is the case, identify the bugno which caused a suboptimal plan to be produced. Always implement only the smallest change possible (just disable a bug fix instead of going back to a previous OFE-setting) and change as local to the problem as possible (i.e. add a hint or a SQL Patch to a query and, if possible, do not change a parameter on session or even system level). And finally, document your change and try to get rid of that workaround as soon as you have time to do a deeper analysis.

The Oracle Support tool SQLTXPLAIN (see MOS Note “All About the SQLT Diagnostic Tool (Doc ID 215187.1)”) contains the XPLORE utility, which goes much deeper for a single SQL-statement and checks the plan change caused by all “_fix_control”-settings and optimizer-changes (underscore parameters) between releases and produces html-output.

L’article Oracle: A possible method to address a slow query if there is time pressure est apparu en premier sur dbi Blog.

[root@oak0 ~]# odacli create-appliance -r /u01/patch/my_new_oda.json
...
[root@mynewoda ~]# odacli describe-job -i 88e4b5e3-3a73-4c18-9d9f-960151abc45e

Job details                                                      
----------------------------------------------------------------
                     ID:  88e4b5e3-3a73-4c18-9d9f-960151abc45e
            Description:  Provisioning service creation
                 Status:  Failure (To view Error Correlation report, run "odacli describe-job -i 88e4b5e3-3a73-4c18-9d9f-960151abc45e --ecr" command)
                Created:  April 23, 2025 16:15:35 CEST
                Message:  DCS-10001:Internal error encountered: Failed to provision GI with RHP at the home: /u01/app/19.26.0.0/grid: DCS-10001:Internal error encountered: PRGH-1002 : Failed to copy files from /opt/oracle/rhp/RHPCheckpoints/rhptemp/grid8631129022929485455.rsp to /opt/oracle/rhp/RHPCheckpoints/wOraGrid192600
PRKC-1191 : Remote command execution setup check for node mynewoda using shell /usr/bin/ssh failed.
No ECDSA host key is known for mynewoda and you have requested strict checking.Host key verification failed...

It happened randomly in the past that we got this error “host key verification failed” and we just had to rerun our “odacli create-appliance” command again. However, this time restarting was not possible:

[root@mynewoda ~]# odacli create-appliance -r /u01/patch/my_new_oda.json
DCS-10047:Same job is already running: Provisioning FAILED in different request.

Following MOS Note “ODA Provisioning Fails to Create Appliance w/ Error: DCS-10047:Same Job is already running : Provisioning FAILED in different request. (Doc ID 2809836.1)” I cleaned up the ODA, updated the repository with the Grid Infrastructure clone and DB clone:

Stop the dcs agent on both nodes:

# systemctl stop initdcsagent

Then, run cleanup.pl on ODA node 0.

# /opt/oracle/oak/onecmd/cleanup.pl -f
...

If you get warnings that the cleanup cannot transfer the public key to node 1 or cannot setup SSH equivalence, then run the cleanup on node 1 as well.

At the end of the cleanup-output you get those messages:

WARNING: After system reboot, please re-run "odacli update-repository" for GI/DB clones,
WARNING: before running "odacli create-appliance".

So, after the reboot I updated the repository with the GI and DB Clone:

[root@oak0 patch]# /opt/oracle/dcs/bin/odacli update-repository -f /u01/patch/odacli-dcs-19.26.0.0.0-250127-GI-19.26.0.0.zip
...
[root@oak0 patch]# odacli describe-job -i 674f7c66-1615-450f-be27-4e4734abca97

Job details                                                      
----------------------------------------------------------------
                     ID:  674f7c66-1615-450f-be27-4e4734abca97
            Description:  Repository Update
                 Status:  Success
                Created:  April 23, 2025 14:37:29 UTC
                Message:  /u01/patch/odacli-dcs-19.26.0.0.0-250127-GI-19.26.0.0.zip
...

[root@oak0 patch]# /opt/oracle/dcs/bin/odacli update-repository -f /u01/patch/odacli-dcs-19.26.0.0.0-250127-DB-19.26.0.0.zip
...
[root@oak0 patch]# odacli describe-job -i 4299b124-1c93-4d22-bac4-44a65cbaac67

Job details                                                      
----------------------------------------------------------------
                     ID:  4299b124-1c93-4d22-bac4-44a65cbaac67
            Description:  Repository Update
                 Status:  Success
                Created:  April 23, 2025 14:39:34 UTC
                Message:  /u01/patch/odacli-dcs-19.26.0.0.0-250127-DB-19.26.0.0.zip
...

Checked that the clones are available:

[root@oak0 patch]# ls -ltrh /opt/oracle/oak/pkgrepos/orapkgs/clones
total 12G
-rwxr-xr-x 1 root root 6.0G Jan 28 03:33 grid19.250121.tar.gz
-rwxr-xr-x 1 root root   21 Jan 28 03:34 grid19.250121.tar.gz.info
-r-xr-xr-x 1 root root 5.4G Jan 28 03:42 db19.250121.tar.gz
-rw-rw-r-- 1 root root  19K Jan 28 03:42 clonemetadata.xml
-rw-rw-r-- 1 root root   21 Jan 28 03:43 db19.250121.tar.gz.info
[root@oak0 patch]# 

The same on node 1:

[root@oak1 ~]# ls -ltrh /opt/oracle/oak/pkgrepos/orapkgs/clones
total 12G
-rwxr-xr-x 1 root root 6.0G Jan 28 03:33 grid19.250121.tar.gz
-rwxr-xr-x 1 root root   21 Jan 28 03:34 grid19.250121.tar.gz.info
-r-xr-xr-x 1 root root 5.4G Jan 28 03:42 db19.250121.tar.gz
-rw-rw-r-- 1 root root  19K Jan 28 03:42 clonemetadata.xml
-rw-rw-r-- 1 root root   21 Jan 28 03:43 db19.250121.tar.gz.info
[root@oak1 ~]# 

Before running the create-appliance again, you should first validate the storage topology on both nodes again.

[root@oak0 ~]# odacli validate-storagetopology
INFO    : ODA Topology Verification         
INFO    : Running on Node0                  
INFO    : Check hardware type               
INFO    : Check for Environment(Bare Metal or Virtual Machine)
SUCCESS : Type of environment found : Bare Metal
INFO    : Check number of Controllers       
SUCCESS : Number of onboard OS disk found : 2
SUCCESS : Number of External SCSI controllers found : 2
INFO    : Check for Controllers correct PCIe slot address
SUCCESS : Internal RAID controller   : 
SUCCESS : External LSI SAS controller 0 : 61:00.0
SUCCESS : External LSI SAS controller 1 : e1:00.0
INFO    : Check for Controller Type in the System
SUCCESS : There are 2 SAS 38xx controller in the system
INFO    : Check if JBOD powered on          
SUCCESS : 1JBOD : Powered-on
INFO    : Check for correct number of EBODS(2 or 4)
SUCCESS : EBOD found : 2
INFO    : Check for External Controller 0   
SUCCESS : Controller connected to correct EBOD number
SUCCESS : Controller port connected to correct EBOD port
SUCCESS : Overall Cable check for controller 0
INFO    : Check for External Controller 1   
SUCCESS : Controller connected to correct EBOD number
SUCCESS : Controller port connected to correct EBOD port
SUCCESS : Overall Cable check for Controller 1
INFO    : Check for overall status of cable validation on Node0
SUCCESS : Overall Cable Validation on Node0
INFO    : Check Node Identification status  
SUCCESS : Node Identification
SUCCESS : Node name based on cable configuration found : NODE0
INFO    : The details for Storage Topology Validation can also be found in the log file=/opt/oracle/oak/diag/oak0/oak/storagetopology/StorageTopology-2025-04-23-14:42:34_70809_7141.log
[root@oak0 ~]# 

Validate the storage-topology on node 1 as well. Not validating the storage topology may lead to the following error when creating the appliance again:

OAK-10011:Failure while running storage setup on the system. Cause: Node number set on host not matching node number returned by storage topology tool. Action: Node number on host not set correctly. For default storage shelf node number needs to be set by storage topology tool itself.

Afterwards the “odacli create-appliance” should run through.

Summary

If your “odacli create-appliance” fails on an ODA HA environment and you cannot restart it, then run a cleanup, update the repository with the Grid Infra- and DB-clone and validate the storage-topology before doing the create-appliance again.

L’article odacli create-appliance failed on an ODA HA est apparu en premier sur dbi Blog.

For a migration to another server, we have different possibilities:

• Data Pump expdp/impdp
• Logical replication with e.g. Golden Gate
• Setup of a Standby DB with Data Guard (or third party products like dbvisit standby for Standard Edition 2 DBs) and switchover during cutover
• Using a refreshable PDB in case the multitenant architecture is already used. During migration, stop the source PDB and do a final refresh, stop refreshing and open the target PDB read/write.
• Relocate a PDB
• Unplug PDB, copy PDB-related files and Plug-In the PDB
• RMAN backup and restore. To reduce downtime this can also be combined with incremental backups restored regularly on the target until cutover, when a last incremental backup is applied to the target DB.
• RMAN duplicate
• Data Pump Full Transportable, where you set your source tablespaces read only, export the metadata and physically move datafiles to the target, where you can import the metadata.
• Transportable tablespaces. This can be combined with Incremental Backups to do a cross platform migration to a different endian as described in MOS Note “V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)”
• Detaching ASM devices from the old server and attaching them to the new server.
  REMARK: This is kind of what happens when migrating to a new OS-version on the Oracle Database Appliance with Data Preserving Reprovisioning (DPR). See the blogs from my colleague Jérôme Duba on that: https://www.dbi-services.com/blog/author/jerome-dubar/
• Just copy (e.g. with scp) all needed files to the new server

There are even more possibilities, but with above list you should find a method which fits your needs. Some of the methods above do require to be on the same Operating System and hardware architecture (no endian change), and some of them are totally independent on platform, version or endian change (like the logical migrations with data pump or Golden Gate).

One of the best methods in my view is the possibility of refreshable PDBs, because

• it is very easy to do
• provides a short downtime during cutover
• allows a fallback as the previous PDB is still available
• allows migrating PDBs individually at different times
• allows migrating non-CDBs to PDBs as well. I.e. I can refresh a non-CDB to a PDB.
• it is available since 12.2. and can also be used with Standard Edition 2 (SE2) DBs
• allows going to a different Release Update (RU)
• even allows going to a different major release and run the PDB upgrade afterwards on the target CDB
• if the source PDB is on SE2 then the target PDB can also be on Enterprise Edition (EE)
• moving Transparent Data Encrypted PDBs is almost as easy as moving non-encrypted PDBs
• the inital copy of the PDB can be done very fast as Oracle is using a block-level-copy mechanism when cloning a PDB and parallelism is allowed as well on EE
• we can use 3 PDBs per CDB since 19c without licensing the Multitenant Option. This provides some flexibility on which CDB to move the PDB to

You may check this blog with the steps to do when migrating through the refreshable PDB mechanism.

Can we migrate a 19c database to 23ai with refreshable PDBs? Yes, we can do that as shown below:

REMARK: The whole process described below can be done with the autoupgrade tool automatically. However, to see each step separately, I do this manually here.

1. Preparing the source CDB, which is on 19.22.:

sys@CDB0> select force_logging from v$database;

FORCE_LOGGING
---------------------------------------
YES

sys@CDB0> create user c##refresh_pdbs identified by welcome1 container=all;

User created.

sys@CDB0> grant create session, create pluggable database to c##refresh_pdbs container=all;

Grant succeeded.

2. Create the refreshable PDB

To have a connection between the Oracle Cloud and my on-prem 19.22.-DB I used the method described here through a ssh-tunnel:
https://www.ludovicocaldara.net/dba/push-pdb-to-cloud/

On the target server:

[oracle@db23aigi ~]$ sqlplus / as sysdba

SQL*Plus: Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on Fri Apr 4 15:16:15 2025
Version 23.7.0.25.01

Copyright (c) 1982, 2024, Oracle.  All rights reserved.


Connected to:
Oracle Database 23ai EE High Perf Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems
Version 23.7.0.25.01

SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
SQL> exit
Disconnected from Oracle Database 23ai EE High Perf Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems
Version 23.7.0.25.01
[oracle@db23aigi ~]$ cat clone_db.sh 
SRC_PDB=$1
TGT_PDB=$2
ALIAS=$3
 
export ORACLE_HOME=/u01/app/oracle/product/23.0.0.0/dbhome_1
export ORACLE_SID=DB23AIGI
 
$ORACLE_HOME/bin/sqlplus -s / as sysdba <<EOF
        set timing on
        create database link prod_clone_link connect to c##refresh_pdbs
          identified by welcome1 using '$ALIAS';
        create pluggable database $2 from $1@prod_clone_link refresh mode manual;
        dbms_session.sleep(120);
        alter pluggable database $2 refresh;
        alter pluggable database $2 refresh mode none;
        exit
EOF
[oracle@db23aigi ~]$ 

On the source-server:

oracle@pm-DB-OEL8:~/Keys/dbi-OCI/dbi3oracle/DB-systems/db23aigi/ [cdb0 (CDB$ROOT)] ssh -i ./ssh-key-2025-04-04.key opc@<public-ip-OCI> -R 1522:pm-DB-OEL8:1521 "sudo -u oracle /home/oracle/clone_db.sh PROD PROD23AI localhost:1522/PROD_PRI"

Database link created.

Elapsed: 00:00:00.01

Pluggable database created.

Elapsed: 00:06:16.42

Pluggable database altered.

Elapsed: 00:00:14.99

Pluggable database altered.

Elapsed: 00:00:00.78
oracle@pm-DB-OEL8:~/Keys/dbi-OCI/dbi3oracle/DB-systems/db23aigi/ [cdb0 (CDB$ROOT)] 

3. Upgrade the PDB to 23ai on the target server

SQL> alter pluggable database PROD23AI open upgrade;

Pluggable database altered.

SQL> select name, open_mode, restricted from v$pdbs where name='PROD23AI';

NAME				 OPEN_MODE  RES
-------------------------------- ---------- ---
PROD23AI			 MIGRATE    YES

SQL> 

[oracle@db23aigi ~]$ $ORACLE_HOME/bin/dbupgrade -c "PROD23AI" -l /tmp
....
Upgrade Summary Report Located in:
/tmp/upg_summary.log

     Time: 673s For PDB(s)

Grand Total Time: 673s 

 LOG FILES: (/tmp/catupgrd*.log)


Grand Total Upgrade Time:    [0d:0h:11m:13s]
[oracle@db23aigi ~]$ 

REMARK: As mentioned initially I should have used autoupgrade for the whole process (or just the upgrade) here as $ORACLE_HOME/bin/dbupgrade has been desupported in 23ai, but for demonstration purposes of refreshable PDBs it is OK.

4. Final steps after the upgrade

-- check the PDB_PLUG_IN_VIOLATIONS view for unresolved issues
SQL> alter session set container=PROD23AI;

Session altered.

SQL> select type, cause, message 
from PDB_PLUG_IN_VIOLATIONS 
where name='PROD23AI' and status != 'RESOLVED';  2    3  

TYPE		CAUSE			       MESSAGE
--------------- ------------------------------ ------------------------------------------------------------------------------------------
WARNING 	is encrypted tablespace?       Tablespace SYSTEM is not encrypted. Oracle Cloud mandates all tablespaces should be encrypted.
WARNING 	is encrypted tablespace?       Tablespace SYSAUX is not encrypted. Oracle Cloud mandates all tablespaces should be encrypted.
WARNING 	is encrypted tablespace?       Tablespace USERS is not encrypted. Oracle Cloud mandates all tablespaces should be encrypted.
WARNING 	Traditional Audit	       Traditional Audit configuration mismatch between the PDB and CDB$ROOT

SQL> administer key management set key using tag 'new own key' force keystore identified by "<wallet password>" with backup;

keystore altered.

SQL> alter tablespace users encryption online  encrypt;

Tablespace altered.

SQL> alter tablespace sysaux encryption online  encrypt;

Tablespace altered.

SQL> alter tablespace system encryption online  encrypt;

Tablespace altered.

SQL> exec dbms_pdb.CLEAR_PLUGIN_VIOLATIONS;

PL/SQL procedure successfully completed.

SQL> select type, cause, message 
from PDB_PLUG_IN_VIOLATIONS 
where name='PROD23AI' and status != 'RESOLVED';

no rows selected


-- Recompile invalid objects using the utlrp.sql script:
SQL> alter session set container=PROD23AI;
 
Session altered.
 
SQL> @?/rdbms/admin/utlrp.sql
 
PL/SQL procedure successfully completed.

-- Downtime ends. Check the DBA_REGISTRY_SQLPATCH view:
SQL> alter session set container=PROD23AI;
 
Session altered.
 
SQL> select patch_id, patch_type, status, description, action_time from dba_registry_sqlpatch order by action_time desc;

  PATCH_ID PATCH_TYPE STATUS	 DESCRIPTION						      ACTION_TIME
---------- ---------- ---------- ------------------------------------------------------------ --------------------------------
  37366180 RU	      SUCCESS	 Database Release Update : 23.7.0.25.01 (37366180) Gold Image 04-APR-25 04.00.06.975353 PM

Summary:

If you haven’t done this yet, then I do recommend to migrate to the multitenant architecture as soon as possible. It makes several DBA tasks so much easier. Especially the migration to a new server with refreshable PDBs is very easy to do with low downtime, high flexibility and almost no impact on the source PDB during refreshes. On top of it you do not lose your source PDB during the process and may go back to it in case tests show that the target is not working correctly.

L’article Migrating an Oracle database to another server est apparu en premier sur dbi Blog.

Below the steps to setup an Oracle database from scratch on a Virtualbox VM on my MacBook Air M1.

Install Virtualbox and a VM with Oracle Enterprise Linux 8

First things first: Install Virtualbox. To do that go to www.virtualbox.org and click on the download link:

Click on “macOS / Apple Silicon hosts”, which downloads VirtualBox-7.1.4-165100-macOSArm64.dmg (at the time when writing this Blog):

In Finder double click the DMG to install Virtualbox. Go through the usual installation process until you see the following screen:

When starting Virtualbox the first time I set the Expert mode:

But before creating a VM I downloaded Oracle Enterprise Linux 8 for ARM from here:

Then I create a new VM by clicking “New” in Virtualbox:

Provided the information requested:

Then clicked “Finish”.

Before starting the VM I enabled host caching under Settings -> Storage -> Controller: VirtioSCSI:

I set the network to bridged, so that I also can reach the VM remotely for some tests (if you want to access your VM remotely, you have to adjust the firewall on your Mac):

Then I powered the machine on by clicking “Start”. I had to provide access to the keyboard and computer in the security settings of the Mac. The VM booted from the ISO and I could see the installation screen and choose to install Linux 8:

Then choose the language and other settings and begin the installation:

Then reboot the system:

Install Oracle 19c (19.25.)

After the reboot I can login to the machine through ssh as root and prepare for the Oracle installation:

dnf -y update 
dnf -y install oracle-database-preinstall-19c.aarch64

mkdir -p /u01/app/oracle
chown -R oracle:oinstall /u01/app

systemctl stop firewalld

passwd oracle

dnf -y install xterm.aarch64 tigervnc-server.aarch64

The Oracle software can be downloaded here. I uploaded it to the /tmp directory on my just created VM and installed Oracle 19c:

su - oracle
mkdir -p /u01/app/oracle/product/19.0.0/dbhome_1
cd /u01/app/oracle/product/19.0.0/dbhome_1

unzip -oq /tmp/LINUX.ARM64_1919000_db_home.zip

export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
export ORACLE_HOSTNAME=`hostname`
export ORA_INVENTORY=/u01/app/oraInventory


./runInstaller -ignorePrereq -waitforcompletion -silent             \
    -responseFile ${ORACLE_HOME}/install/response/db_install.rsp    \
    oracle.install.option=INSTALL_DB_SWONLY                         \
    ORACLE_HOSTNAME=${ORACLE_HOSTNAME}                              \
    UNIX_GROUP_NAME=oinstall                                        \
    INVENTORY_LOCATION=${ORA_INVENTORY}                             \
    SELECTED_LANGUAGES=en,en_GB                                     \
    ORACLE_HOME=${ORACLE_HOME}                                      \
    ORACLE_BASE=${ORACLE_BASE}                                      \
    oracle.install.db.InstallEdition=EE                             \
    oracle.install.db.OSDBA_GROUP=dba                               \
    oracle.install.db.OSBACKUPDBA_GROUP=backupdba                   \
    oracle.install.db.OSDGDBA_GROUP=dgdba                           \
    oracle.install.db.OSKMDBA_GROUP=kmdba                           \
    oracle.install.db.OSRACDBA_GROUP=racdba                         \
    SECURITY_UPDATES_VIA_MYORACLESUPPORT=false                      \
    DECLINE_SECURITY_UPDATES=true

su - root
/u01/app/oraInventory/orainstRoot.sh
/u01/app/oracle/product/19.0.0/dbhome_1/root.sh
exit

Then install the 19.25. release update, which I copied to /tmp/19.25:

cd $ORACLE_HOME
mv OPatch OPatch_1919
unzip -oq /tmp/19.25/p6880880_190000_Linux-ARM-64.zip 
cd /tmp/19.25
unzip -oq p36912597_190000_Linux-ARM-64.zip 
cd 36912597/
$ORACLE_HOME/OPatch/opatch apply

Start a listener and install a DB

$ORACLE_HOME/bin/lsnrctl start

export ORACLE_SID=db19ee
export PDB_NAME=pdb1
export DATA_DIR=$ORACLE_BASE/oradata
mkdir -p $DATA_DIR

$ORACLE_HOME/bin/dbca -silent -createDatabase                            \
      -templateName General_Purpose.dbc                                   \
      -gdbname ${ORACLE_SID} -sid  ${ORACLE_SID} -responseFile NO_VALUE   \
      -characterSet AL32UTF8                                              \
      -sysPassword oracle_4U                                              \
      -systemPassword oracle_4U                                           \
      -createAsContainerDatabase true                                     \
      -numberOfPDBs 1                                                     \
      -pdbName ${PDB_NAME}                                                \
      -pdbAdminPassword oracle_4U                                         \
      -databaseType MULTIPURPOSE                                          \
      -memoryMgmtType auto_sga                                            \
      -totalMemory 2500                                                   \
      -storageType FS                                                     \
      -datafileDestination "${DATA_DIR}"                                  \
      -redoLogFileSize 200                                                \
      -emConfiguration NONE                                               \
      -ignorePreReqs

$ORACLE_HOME/bin/sqlplus / as sysdba <<EOF
alter system set db_create_file_dest='${DATA_DIR}';
alter pluggable database ${PDB_NAME} save state;
exit;
EOF

As root adjust the firewalld:

# systemctl start firewalld
# cd /etc/firewalld/services
# vi oranetwork.xml
# cat oranetwork.xml
<?xml version="1.0" encoding="utf-8"?> <service>
<short>oranetwork</short>
<description>Oracle Network communication</description> <port protocol="tcp" port="1521"/>
</service>
# firewall-cmd --permanent --add-service=oranetwork
# firewall-cmd --reload 
# firewall-cmd --list-all
...
  services: cockpit dhcpv6-client oranetwork ssh
...

Finally I can connect to my 19.25.-DB:

[oracle@db19c-arm ~]$ . oraenv
ORACLE_SID = [db19ee] ? db19ee
The Oracle base remains unchanged with value /u01/app/oracle
[oracle@db19c-arm ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Dec 5 19:35:34 2024
Version 19.25.0.0.0

Copyright (c) 1982, 2024, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.25.0.0.0

SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
SQL> 

Summary

Consultants and DBAs who are used to run Oracle Database test environments on Virtualbox, can do this now on Apple Silicon as well. The steps to setup and run an Oracle DB on ARM are the same as on x86-64. Please consider that there are still some limitations on ARM. E.g. 19c is not supported on Oracle Enterprise Linux 9 (OEL9) on ARM.

L’article Oracle Database on Apple Silicon with Virtualbox 7.1 est apparu en premier sur dbi Blog.

I do want to compare 3 different methods on how connects to the DB are handled and see what is the fastest in terms of connect-time:

1. Dedicated Server
2. Shared Server
3. Database Resident Connection Pooling (DRCP)

For the test I used the following configuration:

• Container database cdb0, version 19.19. with pluggable database pdb0 running in a VM on Proxmox.
• Client with version 19.16. running on a VM on Proxmox (different physical server than the DB).

REMARK: I do not use technologies, which may increase logon-time (like logon-triggers or logon-auditing) during the tests performed.

Preparation

Setup shared server

For shared server I created a service pdb0_shared in my PDB pdb0:

alter session set container=pdb0;
exec dbms_service.create_service('pdb0_shared','pdb0_shared');
exec dbms_service.start_service('pdb0_shared');

Then I setup 10 shared server processes and 4 dispatchers. This has to be done in the root container:

connect / as sysdba
ALTER SYSTEM SET shared_servers= 10 SCOPE = BOTH ;
ALTER SYSTEM SET max_shared_servers = 100 SCOPE = BOTH;
ALTER SYSTEM SET dispatchers ='(INDEX=1)(PROTOCOL=TCP)(dispatchers=4)(SERVICE=pdb0_shared)' SCOPE = BOTH;

REMARK: The INDEX=1 means that I do not change the existing dispatcher-setting (e.g. for XDB).

Verify the setup:

$ lsnrctl services listener1
...
Service "pdb0_shared" has 1 instance(s).
  Instance "cdb0", status READY, has 4 handler(s) for this service...
    Handler(s):
      "D004" established:0 refused:0 current:0 max:1022 state:ready
         DISPATCHER <machine: pm-DB-OEL8, pid: 57522>
         (ADDRESS=(PROTOCOL=tcp)(HOST=pm-DB-OEL8)(PORT=32407))
      "D003" established:0 refused:0 current:0 max:1022 state:ready
         DISPATCHER <machine: pm-DB-OEL8, pid: 57520>
         (ADDRESS=(PROTOCOL=tcp)(HOST=pm-DB-OEL8)(PORT=17299))
      "D002" established:0 refused:0 current:0 max:1022 state:ready
         DISPATCHER <machine: pm-DB-OEL8, pid: 57518>
         (ADDRESS=(PROTOCOL=tcp)(HOST=pm-DB-OEL8)(PORT=19185))
      "D001" established:0 refused:0 current:0 max:1022 state:ready
         DISPATCHER <machine: pm-DB-OEL8, pid: 57516>
         (ADDRESS=(PROTOCOL=tcp)(HOST=pm-DB-OEL8)(PORT=15569))
The command completed successfully

$ sqlplus cbleile@pm-DB-OEL8:1531/pdb0_shared:shared

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Jan 18 19:29:34 2024
Version 19.16.0.0.0

Copyright (c) 1982, 2022, Oracle.  All rights reserved.

Enter password: 
Last Successful login time: Thu Jan 18 2024 19:17:55 +01:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.19.0.0.0

SQL> 

REMARK: Please consider the “:shared” in the Easy Connect string. Using a service, which has no shared service connect handler results in an error when connecting:

$ sqlplus cbleile@pm-DB-OEL8:1531/pdb0:shared

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Jan 18 19:30:40 2024
Version 19.16.0.0.0

Copyright (c) 1982, 2022, Oracle.  All rights reserved.

Enter password: 
ERROR:
ORA-12520: TNS:listener could not find available handler for requested type of server

Setup pooled connections through the DRCP

This is simple with a single command in the root container:

sys@CDB0> EXEC DBMS_CONNECTION_POOL.start_pool;

PL/SQL procedure successfully completed.

For details see
https://oracle-base.com/articles/11g/database-resident-connection-pool-11gr1
https://oracle-base.com/articles/23c/database-resident-connection-pool-enhancements-23c

Testing

I created 3 test scripts for dedicated, shared and pooled connections:

$ cat loop_connect_speed_pdb0_dedicated.sh
#!/bin/bash
# Purpose: Connect to a DB using a dedicated server connect and immediately 
#          disconnet then. Do this n times (parameter 1).
# History: 18.01.2024 CBL: Created
#############################################################################

if [ $# -ne 2 ]
then
   echo "Usage: $0 <number of connections> <listener port>"
   exit 1
fi

NUMBER_OF_CONNECTS=$1
LISTENER_PORT=$2

for (( c=1; c<=$NUMBER_OF_CONNECTS; c++ ))
do
   echo exit | sqlplus -S cbleile/<password>@pm-DB-OEL8:${LISTENER_PORT}/pdb0:dedicated
done


$ cat loop_connect_speed_pdb0_shared.sh
#!/bin/bash
# Purpose: Connect to a DB using a shared server connect and immediately 
#          disconnet then. Do this n times (parameter 1).
# History: 18.01.2024 CBL: Created
#############################################################################

if [ $# -ne 2 ]
then
   echo "Usage: $0 <number of connections> <listener port>"
   exit 1
fi

NUMBER_OF_CONNECTS=$1
LISTENER_PORT=$2

for (( c=1; c<=$NUMBER_OF_CONNECTS; c++ ))
do
   echo exit | sqlplus -S cbleile/<password>@pm-DB-OEL8:${LISTENER_PORT}/pdb0_shared:shared
done


$ cat loop_connect_speed_pdb0_pooled.sh
#!/bin/bash
# Purpose: Connect to a DB using a pooled server connect and immediately 
#          disconnet then. Do this n times (parameter 1).
# History: 18.01.2024 CBL: Created
#############################################################################

if [ $# -ne 2 ]
then
   echo "Usage: $0 <number of connections> <listener port>"
   exit 1
fi

NUMBER_OF_CONNECTS=$1
LISTENER_PORT=$2

for (( c=1; c<=$NUMBER_OF_CONNECTS; c++ ))
do
   echo exit | sqlplus -S cbleile/<password>@pm-DB-OEL8:${LISTENER_PORT}/pdb0:pooled
done

The scripts do 400 connects to the DB (one after the other in the loop) through the listener listening on port 1531. The results for 400 connects to the DB are as follows:

$ time ./loop_connect_speed_pdb0_dedicated.sh 400 1531

real	0m24.489s
user	0m7.418s
sys	0m3.132s

I.e. in average 61ms per connect/disconnect using a dedicated server.

 time ./loop_connect_speed_pdb0_shared.sh 400 1531

real	0m17.399s
user	0m7.460s
sys	0m3.038s

I.e. in average 44ms per connect/disconnect using a shared server.

$ time ./loop_connect_speed_pdb0_pooled.sh 400 1531

real	0m18.235s
user	0m7.413s
sys	0m3.099s

I.e. in average 46ms per connect/disconnect using a pooled server.

I repeated the test several times and results are consistent. I.e. shared server connections are the fastest followed closely by pooled connections and dedicated server connections are obviously the slowest.

REMARK: Please consider that also the disconnect time is part of the measured time.

In above tests I connected 400 times serially, i.e. one after the other. What happens when connects happen concurrently? How does it scale?

Concurrent connects

I developed a second script, which starts e.g. 400 connections 2 or more times in parallel. I.e. with parallel 2 means I did 400 connections in two sessions, i.e. 800 connections in total using the following script:

oracle@19c-dg2:/home/oracle/ [rdbms1916] cat run_loop_pdb0_dedicated.sh
#!/bin/bash
# Purpose: Connect to a DB using a dedicated server connect and immediately 
#          disconnet then. Do this n times (parameter 1) and do this n times in parallel (parameter 2).
# History: 18.01.2024 CBL: Created
#############################################################################

if [ $# -ne 3 ]
then
   echo "Usage: $0 <number of connections> <number of parallel starts> <number of listeners>"
   exit 1
fi

NUMBER_OF_CONNECTS=$1
NUMBER_OF_PARALLEL_STARTS=$2
NUMBER_OF_LISTENERS=$3

for (( c=1; c<=$NUMBER_OF_PARALLEL_STARTS; c++ ))
do
   let "port_nr = $(($c % $NUMBER_OF_LISTENERS)) + 1"
#   echo $port_nr
   ./loop_connect_speed_pdb0_dedicated.sh $NUMBER_OF_CONNECTS 153${port_nr} &
done

# jobs

wait

The scripts for shared and pooled connects look accordingly.

Here the results to connect 1 – 6 times in parallel 400 connections (all going over 1 listener) via dedicated server:

oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_dedicated.sh 400 1 1

real	0m24.265s
user	0m7.485s
sys	0m3.099s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_dedicated.sh 400 2 1

real	0m24.569s
user	0m14.677s
sys	0m6.273s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_dedicated.sh 400 3 1

real	0m26.511s
user	0m21.708s
sys	0m9.807s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_dedicated.sh 400 4 1

real	0m29.579s
user	0m28.625s
sys	0m13.461s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_dedicated.sh 400 5 1

real	0m33.383s
user	0m35.570s
sys	0m16.990s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_dedicated.sh 400 6 1

real	0m37.954s
user	0m42.894s
sys	0m20.418s

So obviously something is slowing us down the higher concurrent logins get.

Results for shared server connects:

oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_shared.sh 400 1 1

real	0m17.319s
user	0m7.531s
sys	0m3.028s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_shared.sh 400 2 1

real	0m17.301s
user	0m14.338s
sys	0m6.468s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_shared.sh 400 3 1

real	0m21.004s
user	0m21.426s
sys	0m9.922s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_shared.sh 400 4 1

real	0m25.325s
user	0m28.712s
sys	0m13.222s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_shared.sh 400 5 1

real	0m29.989s
user	0m35.659s
sys	0m16.876s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_shared.sh 400 6 1

real	0m35.180s
user	0m42.738s
sys	0m20.573s

I.e. also a slow down and with higher concurrency the times get closer to dedicated connections. Finally pooled connections:

oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_pooled.sh 400 1 1

real	0m17.977s
user	0m7.355s
sys	0m3.192s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_pooled.sh 400 2 1

real	0m18.000s
user	0m14.439s
sys	0m6.428s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_pooled.sh 400 3 1

real	0m21.257s
user	0m21.505s
sys	0m9.970s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_pooled.sh 400 4 1

real	0m25.417s
user	0m28.549s
sys	0m13.497s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_pooled.sh 400 5 1

real	0m30.227s
user	0m35.761s
sys	0m16.912s
oracle@19c-dg2:/home/oracle/ [rdbms1916] time ./run_loop_pdb0_pooled.sh 400 6 1

real	0m35.146s
user	0m42.688s
sys	0m20.551s

Here a graph showing the result:

Summary

If it gets to connect time to an Oracle database then shared and pooled server connects are faster than dedicated server. However, changing from dedicated server connections to e.g. shared server connects is only a workaround. The base problem should be addressed: The application should be designed to use a connection pool and re-use connections without doing login/logout for every action or, in case of classical client server, keep the connection open. Please consider that connecting and disconnecting to/from the DB may take a considerable time in your application. The reason why connects do not scale that well when connecting concurrently will be addressed in a future blog.

L’article What is the fastest method to connect to an Oracle database? est apparu en premier sur dbi Blog.

srvctl start listener -listener <listener-name>

worked without any problem though. So what is the issue?

Analysis

Looking at the listeners which do not start in the listener.ora it becomes obvious that all listeners, which had an SID_LIST_<listener-name> did not start when booting.

My first step was to check crs:

[root@mysrv ~]# . oraenv
ORACLE_SID = [root] ? +ASM1
ORACLE_HOME = [/home/oracle] ? /u01/app/19.20.0.0/grid
The Oracle base has been set to /u01/app/grid
[root@mysrv ~]# crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

That looks good.

For testing purposes it’s of course easier to stop crs and restart it instead of rebooting the server:

[root@mysrv ~]# crsctl stop crs -f
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'mysrv'
CRS-2673: Attempting to stop 'ora.crsd' on 'mysrv'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on server 'mysrv'
...
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'mysrv' has completed
CRS-4133: Oracle High Availability Services has been stopped.
[root@mysrv ~]# crsctl start crs
CRS-4123: Oracle High Availability Services has been started.
[root@mysrv ~]# 

The listeners could be shutdown without any issue, but they did not come up when starting crs. In the alert.log I did see this:

[root@mysrv app]# view /u01/app/grid/diag/crs/mysrv/crs/trace/alert.log
....
2023-10-24 17:04:57.042 [CRSD(90854)]CRS-2807: Resource 'ora.LISTENER1.lsnr' failed to start automatically.
2023-10-24 17:04:57.044 [CRSD(90854)]CRS-2807: Resource 'ora.LISTENER2.lsnr' failed to start automatically.
...

To find the reason why the cluster registry services of grid infrastructure did not start those specific listeners LISTENER1 and LISTENER2, I searched in the oraagent trace-files for SID_LIST_LISTENER1:

[root@mysrv app]# pwd
/u01/app
[root@mysrv app]# grep -il sid_list_listener1 ./grid/diag/crs/mysrv/crs/trace/crsd_oraagent_*.trc
...
./grid/diag/crs/mysrv/crs/trace/crsd_oraagent_grid.trc
...
[root@mysrv app]# view ./grid/diag/crs/mysrv/crs/trace/crsd_oraagent_grid.trc
...
2023-10-24 20:46:58.914 :CLSDYNAM:1738524416: [ora.LISTENER1.lsnr]{1:60057:2} [start] ConfigFile::parse mmap name:sid_list_listener1 nameWithCase:SID_LIST_LISTENER1 value: comment:
2023-10-24 20:46:58.915 :CLSDYNAM:1700701952: [ora.LISTENER1.lsnr]{1:60057:2} [start] LsnrAgent::Lsnrctl::start lsnrctl start complete lsnrname:LISTENER1 output:
LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 24-OCT-2023 20:46:58

Copyright (c) 1991, 2023, Oracle.  All rights reserved.

Starting /u01/app/19.20.0.0/grid/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 19.0.0.0.0 - Production
System parameter file is /u01/app/19.20.0.0/grid/network/admin/grid/listener.ora
Log messages written to /u01/app/grid/diag/tnslsnr/mysrv/listener1/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER1)))
TNS-01201: Listener cannot find executable /u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_10/bin/oracle for SID INST9

Listener failed to start. See the error message(s) above...

So the listener could not find the oracle executable in the ORACLE_HOME provided in the SID_LIST_LISTENER1. The executable is of course required to start a connection through a statistic listener entry. When I saw that, it became clear why the listeners did not start: Since ODA 19.11. the ORACLE_HOMEs are located on the ACFS-Filesystem

/u01/app/odaorahome

REMARK: For more details about that change see an earlier Blog.

The issue was that that filesystem has not been mounted yet when the listener is being started by the oraagent. So I needed to add a startup dependency to the listeners to wait until the ACFS-Filesystem has been mounted.

REMARK: Starting the listener with srvctl manually worked, because in the meantime the ACFS-filesystem was mounted.

Solution and verification of the solution

What is the current start dependency?

[grid@mysrv grid]$ crsctl status resource ora.LISTENER1.lsnr -f | grep START_DEPENDENCIES=
START_DEPENDENCIES=hard(type:ora.cluster_vip_net1.type) pullup(type:ora.cluster_vip_net1.type)
[grid@mysrv grid]$

How to modify the start dependency? Oracle provides the command crsctl modify, but it allows modifications only with the “-unsupported” option set. We opened a SR with Oracle and they confirmed that we can use that option. The resource we are depending on is “ora.data.orahome_sh.acfs”. So the needed adjustment is:

[grid@mysrv grid]$ crsctl modify resource ora.LISTENER1.lsnr -attr "START_DEPENDENCIES='hard(type:ora.cluster_vip_net1.type,ora.data.orahome_sh.acfs) pullup(type:ora.cluster_vip_net1.type)'" -unsupported
[grid@mysrv grid]$ 

I tested it (crsctl stop crs -f and crsctl start crs) and it worked, the listener came up as expected. Afterwards I changed all required listeners accordingly and rebooted the server. All listeners came up during the boot process.

Summary

Introducing ORACLE_HOMEs on ACFS in 19.11. was a very welcome improvement, because it took away the space pressure we usually had on ODAs on the /u01-filesystem with many ORACLE_HOMEs. Such new features however, may have side effects, which are not obvious initially. Doing a proper analysis usually yields to a solution or a workaround. If you have to implement the solution/workaround then it’s a good practice to double check with Oracle Support that your solution is supported by Oracle – especially on the ODA.

L’article Oracle Database Appliance (ODA): Some listeners do not start anymore when booting est apparu en premier sur dbi Blog.

The database software Oracle 19c is not certified on MacOS. To run it on a Mac you have to install a Linux for Arm in a virtual machine and then install Oracle 19c in there as well. Virtualization software available on Apple Silicon are

• Parallels
• VMWare Fusion
• Virtualbox (was available as Beta software, but while writing this blog is no longer available for download)
• UTM as a wrapper for QEMU

I’ve been running Virtualbox on Intel for a long time, but the beta software was available only as 32-Bit for Apple M1. Due to the fact that Parallels and VMWare have to be licensed or need an account to download software, I tested UTM as a virtualization platform. Below the steps I used to

• install UTM
• create a virtual machine and install Oracle Enterprise Linux 8 for Arm
• install Oracle Database 19c for Arm
• create an Oracle Database

1. Install UTM

You may install UTM from the App Store, which costs a couple of Dollars/Euros/Swiss Franks or you download it from here.
The software from the App Store and the download from the mentioned website is identical. The only difference is that you donate some money for the project when you download and install the software from the App Store.

The installation is a typical Mac-installation. Just download from the App Store and install it or double click on the downloaded UTM.dmg and follow the instructions.

2. Create a VM in UTM and install Oracle Enterprise Linux 8 for Arm

Click on the +-sign to create a new VM:

Click on Virtualize:

Click on Linux:

Click on Browse… in the section “Boot ISO image”:

Select the downloaded ISO-image you downloaded from here:

Click on “Continue”:

Select the amount of memory you want to provide to the VM and leave the rest on its defaults. Then press “Continue”:

REMARK: If you leave “CPU Cores” on Default then UTM will create a VM with 4 cores. This is half the number of cores available on my M1 which also seems to be related to the fact that an M1 has 4 performance and 4 efficiency cores.

Specify the size of the virtual disk attached to the VM:

I do not use a shared directory:

Check your settings (you may give it another name than “Linux”) and click “Save”:

Your VM is now ready for booting the first time:

I changed the name to “Oracle DB on Arm” by clicking the “Edit selected VM”:

And renamed it to “Oracle DB on Arm”:

Click “Save” and then the “Play”-Button:

Select to install OEL8:

Chose your Language:

Setup Keyboard and the usual other settings:

After adjusting everything to my needs (I do use the minimal install) it looked as follows:

So I clicked on “Begin Installation” and could check the progress:

Finally I can reboot:

When the machine is down I clicked on the Power-Off-Button to adjust not to use the ISO-Image after reboot. I.e. moved the USB-drive down in the Boot-order:

After clicking on “Save” I also adjusted the Network to have a Bridged Network. After that I powered the VM on:

A couple of secs later the machine is up:

The machine is reachable through ssh then and I can use my Terminal to continue with the installation.

3. Install Oracle Database software 19c for Arm

Login as root and do the required steps (steps are mainly taken from here):

dnf -y update 
dnf -y install oracle-database-preinstall-19c.aarch64

mkdir -p /u01/app/oracle
chown -R oracle:oinstall /u01/app

systemctl stop firewalld

passwd oracle

dnf -y install xterm.aarch64 tigervnc-server.aarch64

The Oracle software can be downloaded here. I uploaded it to the /tmp directory on my just created VM. Just by coincidence I saw that the 19.19.-version available for Arm is smaller than the 19.3.-version for x86-64:

Install the Oracle software:

su - oracle
mkdir -p /u01/app/oracle/product/19.0.0/dbhome_1
cd /u01/app/oracle/product/19.0.0/dbhome_1

unzip -oq /tmp/LINUX.ARM64_1919000_db_home.zip

export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
export ORACLE_HOSTNAME=`hostname`
export ORA_INVENTORY=/u01/app/oraInventory


./runInstaller -ignorePrereq -waitforcompletion -silent             \
    -responseFile ${ORACLE_HOME}/install/response/db_install.rsp    \
    oracle.install.option=INSTALL_DB_SWONLY                         \
    ORACLE_HOSTNAME=${ORACLE_HOSTNAME}                              \
    UNIX_GROUP_NAME=oinstall                                        \
    INVENTORY_LOCATION=${ORA_INVENTORY}                             \
    SELECTED_LANGUAGES=en,en_GB                                     \
    ORACLE_HOME=${ORACLE_HOME}                                      \
    ORACLE_BASE=${ORACLE_BASE}                                      \
    oracle.install.db.InstallEdition=EE                             \
    oracle.install.db.OSDBA_GROUP=dba                               \
    oracle.install.db.OSBACKUPDBA_GROUP=backupdba                   \
    oracle.install.db.OSDGDBA_GROUP=dgdba                           \
    oracle.install.db.OSKMDBA_GROUP=kmdba                           \
    oracle.install.db.OSRACDBA_GROUP=racdba                         \
    SECURITY_UPDATES_VIA_MYORACLESUPPORT=false                      \
    DECLINE_SECURITY_UPDATES=true

su - root
/u01/app/oraInventory/orainstRoot.sh
/u01/app/oracle/product/19.0.0/dbhome_1/root.sh
exit

4. Create a DB

Start a listener and create an Oracle DB:

$ORACLE_HOME/bin/lsnrctl start

export ORACLE_SID=db19ee
export PDB_NAME=pdb1
export DATA_DIR=$ORACLE_BASE/oradata
mkdir -p $DATA_DIR

$ORACLE_HOME/bin/dbca -silent -createDatabase                            \
      -templateName General_Purpose.dbc                                   \
      -gdbname ${ORACLE_SID} -sid  ${ORACLE_SID} -responseFile NO_VALUE   \
      -characterSet AL32UTF8                                              \
      -sysPassword oracle_4U                                              \
      -systemPassword oracle_4U                                           \
      -createAsContainerDatabase true                                     \
      -numberOfPDBs 1                                                     \
      -pdbName ${PDB_NAME}                                                \
      -pdbAdminPassword oracle_4U                                         \
      -databaseType MULTIPURPOSE                                          \
      -memoryMgmtType auto_sga                                            \
      -totalMemory 2500                                                   \
      -storageType FS                                                     \
      -datafileDestination "${DATA_DIR}"                                  \
      -redoLogFileSize 200                                                \
      -emConfiguration NONE                                               \
      -ignorePreReqs

$ORACLE_HOME/bin/sqlplus / as sysdba <<EOF
alter system set db_create_file_dest='${DATA_DIR}';
alter pluggable database ${PDB_NAME} save state;
exit;
EOF

As root adjust the firewalld:

# systemctl start firewalld
# cd /etc/firewalld/services
# vi oranetwork.xml
# cat oranetwork.xml
<?xml version="1.0" encoding="utf-8"?> <service>
<short>oranetwork</short>
<description>Oracle Network communication</description> <port protocol="tcp" port="1521"/>
</service>
# firewall-cmd --permanent --add-service=oranetwork
# firewall-cmd --reload 
# firewall-cmd --list-all
...
  services: cockpit dhcpv6-client oranetwork ssh
...

Finally I can connect to my 19.19.-DB:

[oracle@oracleonarm ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Aug 17 13:31:16 2023
Version 19.19.0.0.0

Copyright (c) 1982, 2023, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.19.0.0.0

SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
SQL>     

Performance

The DB on my Apple Macbook Air M1 runs really fast. The M1 has 8 cores, 4 performance cores and 4 efficiency cores. By using the default concerning number of cores in UTM, it uses 4 cores in the VM and tests showed that performance cores were active:

# lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Vendor ID:           0x00
BIOS Vendor ID:      QEMU
Model:               0
BIOS Model name:     virt-8.0
Stepping:            0x0
BogoMIPS:            48.00
L1d cache:           unknown size
L1i cache:           unknown size
L2 cache:            unknown size
NUMA node0 CPU(s):   0-3
Flags:               fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp flagm2 frint

I tested the number of logical IOs a single process can do on my VM with SLOB. The method I used is described here. On my M1 running Oracle inside UTM I could do quite impressive 1,242,790.7 LIOs with a single process per second. The table size I did LIOs on was 2GB.

dbi services DMK (Database Management Kit)

Our DMK 2.0.0 could be installed with only a minor issue: The provided rlwrap-executable did of course not work, because the deployed one is for x86-64. I downloaded the source code and quickly compiled it on my VM and could use DMK without issues then:

L’article Running an Oracle Database 19c on Apple Silicon (Apple Macbook Air M1) est apparu en premier sur dbi Blog.

So what can you do? You may run your test environment on the Cloud, but that produses additional costs and is not so easy to setup (except if you use YaK ).

I want to explain another alternative here: Running your Oracle Sandbox on a separate AMD-based Mini PC. I used AMD instead of Intel, because it’s more affordable with a 4-Core processor. To manage several environments on my external Mini PC I’m using Proxmox (Open Source Type I hypervisor/virtualisation software) to virtualise my Sandbox environments. Here are my components:

I.e. on the right I have my Apple MacBook Air 10,1 with 8GB of RAM and the M1 processor. On the left my external machine, which has the following specifications: Mini PC, AMD Ryzen 7 3750H Desktop PC (Quad-Core), 16GB DDR4 RAM 512GB. The Mini PC was purchased for 300.- Euros. It is small and light: 12×4.5×14.5 cm, 476g. Below the Mini PC an USB stick with a Proxmox ISO image on it.

To be able to use the Sandbox when connected to a network, the 2 machines should be connected through network cable with private IP addresses. In case the Mac has network access through WLAN it should act as a Gateway for the Mini PC.

Before switching on the Mini PC I configured the Mac to act as an Internet Gateway. First of all I gave my Mac a fix internal IP on the network adapter used:

Then I setup Internet Sharing on my Mac, i.e. the Mac acts as a gateway, In the System Settings I searched for “internet sharing”:

Clicking on the little “I” next to enabling Internet Sharing I get this to setup what interface I provide internet sharing with:

After confirming that and enabling Internet Sharing the following message appears:

That’s OK, because I’m using my own private network to the Mini PC only. So I clicked Start:

At this point I can start setting up Proxmox on my Mini PC. I installed it with DHCP enabled, so that it gets an IP address from my Mac automatically.

The hypervisor gets an IP-address 192.168.2.2 and I can connect to it with the browser:

Now I can install e.g. an Oracle 23cFree for developers in a VM as described here.

Finally I have my portable Oracle Sandbox running and accessible from my Apple SIlicon Laptop:

Summary

In the past I used Virtualbox and Vagrant to run my Oracle-Sandbox-environments directly on my Intel MacBook Pro 2019. If I want to remain on a Mac on Apple SIlicon then I need to adjust my Sandbox environment. Using an external AMD (or Intel) based Mini PC is affordable today. With Proxmox as a Type 1 hypervisor I can handle the VMs easily. The only efforts I have is to migrate my Virtualbox-VMs managed in Vagrant to Proxmox.

REMARK 1: If you can afford to spend more money for your Mini PC then you may check the latest Intel NUC 13 Pro, which is a high-performance device. See e.g. the Youtube-video here.

REMARK 2: If you want to remain on Virtualbox and Vagrant then just install Linux or Windows on your Mini PC, but this requires maintaining the OS as well. Maintaining Proxmox requires much less efforts.

UPDATE 29th of June 2023: Oracle is now also available on the ARM platforms! See here

L’article Building a transportable Oracle Sandbox environment for an Apple Silicon Laptop (MacBook with M1- or M2-processor) est apparu en premier sur dbi Blog.

First download the OVA-file from here:

The next step is to create a VM in Proxmox without disks and without CD (ISO) attached to it:

First provide a name:

Then provide the OS-details and select to not use any CD/DVD media.

At the System settings you may leave everything on default:

Delete the disk, which is pre-selected by clicking on the waste-baskett at the left side:

So that it looks as follows:

Provide the number of CPUs you want to use on your VM. In my case I do use 2 cores. I usually set the Type to “host” to provide all features my host-CPU provides to the VM:

Set the amount of RAM you want to provide to your VM:

In the last step define your network settings. I left everything on default on my setup:

Finally check the confirmation page and make sure to NOT select the “Start after created” box. Then click on Finish:

After a couple of seconds the VM is visible on your Proxmox GUI:

To import the OVA-file downloaded, follow the steps below:

scp the OVA-file to the hypervisor in e.g. the /tmp-directory (my Proxmox hypervisor has IP 192.168.2.2):

$ scp Oracle_Database_23c_Free_Developer_Appliance.ova root@192.168.2.2:/tmp

Login to the hypervisor and untar the OVA-file:

root@pve-sandbox:~# cd /tmp
root@pve-sandbox:/tmp# ls -ltr *.ova
-rw-r--r-- 1 root root 6996211200 Jun  2 20:50 Oracle_Database_23c_Free_Developer_Appliance.ova
root@pve-sandbox:/tmp# tar xvf Oracle_Database_23c_Free_Developer_Appliance.ova
Oracle DB Developer VM.ovf
Oracle DB Developer VM-disk001.vmdk
Oracle DB Developer VM-disk002.vmdk
root@pve-sandbox:/tmp# 

List the VMs you have. In my case I only have the one with VM ID 100 I just created:

root@pve-sandbox:/tmp# qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID       
       100 Ora23cFREE           stopped    8192               0.00 0         
root@pve-sandbox:/tmp# 

Check the storage on my system:

root@pve-sandbox:/tmp# pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        98497780        17173872        76274360   17.44%
local-lvm     lvmthin     active       366276608               0       366276608    0.00%
root@pve-sandbox:/tmp# 

I.e. I have storage local-lvm, which I can use to import the disks to.

Import the 2 disks to my VM with VM ID 100, storage local-lvm. Due to blanks in the file-name, please consider the single quotes around the vmdk-file:

root@pve-sandbox:/tmp# qm importdisk 100 'Oracle DB Developer VM-disk001.vmdk' local-lvm -format qcow2
importing disk 'Oracle DB Developer VM-disk001.vmdk' to VM 100 ...
  Logical volume "vm-100-disk-0" created.
transferred 0.0 B of 29.3 GiB (0.00%)
transferred 300.0 MiB of 29.3 GiB (1.00%)
transferred 600.0 MiB of 29.3 GiB (2.00%)
transferred 900.0 MiB of 29.3 GiB (3.00%)
transferred 1.2 GiB of 29.3 GiB (4.00%)
...
transferred 29.0 GiB of 29.3 GiB (99.07%)
transferred 29.3 GiB of 29.3 GiB (100.00%)
transferred 29.3 GiB of 29.3 GiB (100.00%)
Successfully imported disk as 'unused0:local-lvm:vm-100-disk-0'
root@pve-sandbox:/tmp# 

root@pve-sandbox:/tmp# qm importdisk 100 'Oracle DB Developer VM-disk002.vmdk' local-lvm -format qcow2
importing disk 'Oracle DB Developer VM-disk002.vmdk' to VM 100 ...
  Logical volume "vm-100-disk-1" created.
transferred 0.0 B of 29.3 GiB (0.00%)
transferred 300.0 MiB of 29.3 GiB (1.00%)
transferred 600.0 MiB of 29.3 GiB (2.00%)
transferred 900.0 MiB of 29.3 GiB (3.00%)
transferred 1.2 GiB of 29.3 GiB (4.00%)
...
transferred 29.0 GiB of 29.3 GiB (99.04%)
transferred 29.3 GiB of 29.3 GiB (100.00%)
transferred 29.3 GiB of 29.3 GiB (100.00%)
Successfully imported disk as 'unused1:local-lvm:vm-100-disk-1'
root@pve-sandbox:/tmp# 
root@pve-sandbox:/tmp# pvesm list local-lvm
Volid                   Format  Type             Size VMID
local-lvm:vm-100-disk-0 raw     images    31457280000 100
local-lvm:vm-100-disk-1 raw     images    31457280000 100
root@pve-sandbox:/tmp# 

Add the disks as scsci-disks to the VM in the Proxmox GUI by going the the VM hardware and double click on the “Unused disk 0”:

Click on Add:

Do the same for Unused disk 1:

Afterwards the disks are listed as normal scsci-harddisks:

The last step is to adjust the boot order. Go to the VM options, double click on “boot order” and drag and drop the first disk to the top and enable it:

Before:

After:

The VM options then look as follows:

Then start the VM the first time. After booting the console shows:

I opened a terminal in the console and had an IP address assigned automatically:

So I could login as oracle (password oracle) via ssh:

$ ssh oracle@192.168.122.1
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.122.1' (ED25519) to the list of known hosts.
oracle@192.168.122.1's password: 
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Mon Jun  5 10:18:36 2023
[oracle@localhost ~]$ 

And connect to my DB after unsetting the TWO_TASK:

[oracle@localhost ~]$ ps -ef | grep pmon | grep -v grep 
oracle      1900       1  0 10:18 ?        00:00:00 db_pmon_FREE
[oracle@localhost ~]$ echo $ORACLE_SID

[oracle@localhost ~]$ . oraenv
ORACLE_SID = [oracle] ? FREE
The Oracle base has been set to /opt/oracle
[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 23.0.0.0.0 - Developer-Release on Mon Jun 5 10:26:24 2023
Version 23.2.0.0.0

Copyright (c) 1982, 2023, Oracle.  All rights reserved.

ERROR:
ORA-01017: invalid credential or not authorized; logon denied


Enter user-name: ^C
[oracle@localhost ~]$ echo $TWO_TASK
FREEPDB1
[oracle@localhost ~]$ unset TWO_TASK
[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 23.0.0.0.0 - Developer-Release on Mon Jun 5 10:26:43 2023
Version 23.2.0.0.0

Copyright (c) 1982, 2023, Oracle.  All rights reserved.


Connected to:
Oracle Database 23c Free, Release 23.0.0.0.0 - Developer-Release
Version 23.2.0.0.0

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 FREEPDB1                       READ WRITE NO
SQL> 

Summary: Setting up an Oracle 23c Free Developer DB on Proxmox is fast and easy in a couple of steps.

L’article Installing Oracle 23c Free developer release on Proxmox est apparu en premier sur dbi Blog.