Introduction
Oracle releases new APEX versions regularly, and 24.1 brings performance improvements, new app-building components, and updated security patches over 23.2. Unlike a fresh install, an upgrade needs to preserve your existing applications, workspaces, and data while swapping in the new engine underneath. In this article, we'll walk through upgrading Oracle APEX from 23.2 to 24.1 step by step, including the parts that differ from a clean installation.
Prerequisites
Before starting, make sure the following are in place. Skipping any of these can leave you with a broken or partially upgraded environment:
- Complete the APEX 23.2 installation first. This guide assumes you're upgrading an existing 23.2 environment, not installing from scratch.
- Stop the currently running APEX instance by killing the ORDS process. The upgrade scripts need exclusive access to the APEX schema, so ORDS can't be serving requests while this runs.
- Take a full database backup before proceeding. If anything goes wrong mid-upgrade, this is your rollback path back to a working 23.2 environment.
Step 1: Create a Directory and Place the APEX 24.1 Software
Just like the original installation, we set up a dedicated directory for the new version's software rather than overwriting the 23.2 files. Keeping the old version's files around also means you have something to fall back on if you need to compare configurations later.
[oracle@apex oracle]$ mkdir apex24_1
[oracle@apex oracle]$
[oracle@apex oracle]$ cd apex24_1
[oracle@apex apex24_1]$ pwd
/u02/app/oracle/apex24_1
[oracle@apex apex24_1]$ ls
apex_24.1.zip
[oracle@apex apex24_1]$ cd apex
[oracle@apex apex]$ pwd
/u02/app/oracle/apex24_1/apex
Step 2: Create a New Tablespace
We create a separate tablespace for APEX 24.1 rather than reusing the 23.2 tablespace. Keeping them separate makes it easy to check disk usage per version and gives you a clean rollback point if you ever need to drop the new version without touching the old one.
SQL> show pdbs
CON_ID CON_NAME OPEN MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 APEXPDB READ WRITE NO
SQL> alter session set container=APEXPDB;
Session altered.
SQL> create tablespace APEX241 datafile '/u02/app/oracle/oradata/APEXDB/apexpdb/apex241_01.dbf' size 500m autoextend on;
Tablespace created.
Step 3: Run the Installation Script
Running apexins.sql against an existing APEX schema is what actually performs the upgrade. The script detects the existing 23.2 metadata and migrates it forward to 24.1 rather than creating a fresh schema from scratch, which is what makes this an upgrade rather than a parallel install.
SQL> @apexins.sql APEX241 APEX241 TEMP /i/
...set_appun.sql
PL/SQL procedure successfully completed.
...set_ufrom_and_upgrade.sql
PL/SQL procedure successfully completed.
Session altered.
FOO3
------------------------------
install2024-09-25_04-11-58.log
. ORACLE
. Oracle APEX Installation.
..
Thank you for installing Oracle APEX 24.1.0
Oracle APEX is installed in the APEX_240100 schema.
The structure of the link to the Oracle APEX administration services is as follows:
http://host:port/ords/apex_admin
The structure of the link to the Oracle APEX development interface is as follows:
http://host:port/ords
timing for: Phase 3 (Switch)
Elapsed: 1.68
timing for: Complete Installation
Elapsed: 15.73
Notice the log references set_ufrom_and_upgrade.sql specifically, this is the script that migrates your existing applications and data forward, and its presence confirms the process ran as an upgrade rather than a fresh install.
Step 4: Verify the Users, APEX Version, and Image Prefix
After installation, confirm both the old and new APEX schemas exist side by side, unlock the new one, and check that the version and image prefix updated correctly. Skipping this check is a common reason people troubleshoot login issues later without realizing the account is still locked.
SQL> set lines 333 pages 333
SQL> col username for a30
SQL> col account_status for a30
SQL> select username, account_status from dba_users where username like '%APEX%';
USERNAME ACCOUNT_STATUS
------------------------------ ------------------------------
APEX_LISTENER OPEN
APEX_PUBLIC_USER OPEN
APEX_REST_PUBLIC_USER OPEN
APEX_PUBLIC_ROUTER OPEN
APEX_230200 OPEN
APEX_240100 LOCKED
6 rows selected.
SQL> alter user APEX_240100 identified by "YourP@ssw0rd" account unlock;
User altered.
SQL> select username, account_status from dba_users where username like '%APEX%';
USERNAME ACCOUNT_STATUS
------------------------------ ------------------------------
APEX_LISTENER OPEN
APEX_PUBLIC_USER OPEN
APEX_REST_PUBLIC_USER OPEN
APEX_PUBLIC_ROUTER OPEN
APEX_230200 OPEN
APEX_240100 OPEN
6 rows selected.
SQL> select username, account_status from dba_users where username like '%ORDS%';
USERNAME ACCOUNT_STATUS
------------------------------ ------------------------------
ORDS_PUBLIC_USER OPEN
ORDS_METADATA OPEN
ORDSYS LOCKED
SQL> col VERSION_NO for a20
SQL> col API_COMPATIBILITY for a20
SQL> col PATCH_APPLIED for a20
SQL> select * from apex_release;
VERSION_NO API_COMPATIBILITY PATCH_APPLIED
-------------------- -------------------- --------------------
24.1.0 2024.05.31 APPLIED
SQL> col NAME for a30
SQL> col VALUE for a50
SQL> select * from apex_instance_parameters where name='IMAGE_PREFIX';
NAME VALUE CREATED_O LAST_UPDA
------------------------------ --------------------------------------------- --------- ---------
IMAGE_PREFIX https://static.oracle.com/cdn/apex/24.1.0/ 25-SEP-24 25-SEP-24
Note: use a real, unique password instead of the example above, and notice that APEX_230200 stays open. Both schema versions coexist after the upgrade, which is expected and gives you a fallback if you ever need to reference the old version.
Step 5: Update the ORDS Images Directory
ORDS still points to the old version's static assets until you update the images directory. Renaming the old folder instead of deleting it keeps a backup in case you need to compare or roll back, and then we copy over the 24.1 images so the new APEX UI renders correctly.
[oracle@apex ords]$ pwd
/u02/app/oracle/ords
[oracle@apex ords]$ ls
bin docs icons lib linux-support nohup.out ords-latest.zip scripts
config examples images LICENSE.txt logs NOTICE.txt ords.war THIRD-PARTY-LICENSES.txt
[oracle@apex ords]$ mv images images_23_2
[oracle@apex apex]$ pwd
/u02/app/oracle/apex24_1/apex
[oracle@apex apex]$ cp -r images/ /u02/app/oracle/ords/
Step 6: Start the ORDS Service
With the new schema installed and images updated, start ORDS again using nohup so it keeps running independently of your current shell session.
nohup ords --config /u02/app/oracle/ords/config serve &
Step 7: Access APEX Through the Browser
With ORDS running again, verify the upgrade by logging into both the development and admin interfaces below. Confirm your existing workspaces and applications are visible and functioning as expected.
http://192.168.101.7:8080/ords/
http://192.168.101.7:8080/ords/apex_admin
APEX Home
Workspace Login
APEX Admin Login
Admin Home
Manage Workspace
Thank you for reading!
I hope this content has been helpful to you. Your feedback and suggestions are always welcome. Feel free to leave a comment or reach out with any queries.
Abhishek Shrivastava
Oracle DBA with hands-on experience managing production Data Guard, RAC, GoldenGate, and APEX environments. I write practical, tested installation and troubleshooting guides based on real deployment work.
Comments
Post a Comment