Fix ORDS issue: No pools configured yet

In a previous post, I blogged how I do my Oracle APEX upgrade, and part of that is to copy ORDS.

But when I tried to start ORDS, I got the "No pools configured yet" in my logs. 

ORDS was running, but APEX wasn't accessible.

I spend my night looking at this, as I already had done so many ORDS installation and configurations, but still was puzzled with this... so thought to share the fix, even if it's just so I can remember the next time it happens ;)

Background:

- My Oracle database is a CDB with multiple PDBs

- For every PDB I have a separate ORDS running in standalone

When doing an upgrade of APEX I do:

- Copy PDB called APEX_PDB to APEX[version]_PDB (e.g. APEX192_PDB)

For ORDS I did this:

- Copy directory ords to ords192

- In ords192, change ords.war to ords192.war, set the new path for the configdir and in the standalone directory change standalone.properties to serve a different port and path:

Doing the above, ORDS was running nicely but gave me the "No pools configured yet" error, which also means APEX wasn't accessible.

If in my standalone.properties I wouldn't change the path to /ords192 but keep /ords it worked just fine. But I didn't want that, as I'm used to use /ords[apex_version]

So what finally worked for me, was the following:

- mv the ords directory to ords_old

- create a new directory ords and unpack the ORDS zip

- rename ords.war to ords192.war

- set the config dir of ords192.war

- run java -jar ords.war setup and follow the wizard

- run java -jar ords.war standalone and follow the wizard

- quit

- open the standalone.properties file and change the standalone.context.path=/ords to /ords192

- start ORDS again

To me, it seems a combination of renaming the war file first, setting config dir and make sure to change the standalone properties as the default in there is /ords

Oracle APEX 20.1 installed with only 2 mins downtime

Over the weekend I upgraded our environment to Oracle APEX 20.1.

I describe the process of installing a new version in the Safely Upgrading to Oracle APEX 18.1 blogpost. It comes down to cloning my current PDB, calling the clone the previous version of APEX, and then upgrade the current PDB to the latest APEX version.

This time I decided to not just run @apexins, instead, I wanted to try and minimize the downtime by following the steps described in the documentation under D Maximizing Uptime During an Application Express Upgrade.

Here're my notes, in case you want to maximize uptime.

During the first two phases, the Oracle APEX apps were still running:

SQL> @apexins1.sql sysaux sysaux temp /i/

SQL> @apexins2.sql sysaux sysaux temp /i/

The first two phases took about 7 minutes.
After phase 2, I stopped ORDS, and the downtime started for people wanting to use the Oracle APEX apps.

SQL> @apexins3.sql sysaux sysaux temp /i/

It completed in less than 2 minutes!

At the same time, phase 3 was running, I copied the images folder.
Note: you can also use the CDN by running @reset_image_prefix.sql after phase 3 and specifying: https://static.oracle.com/cdn/apex/20.1.0.00.13/

I ran the following command to allow APEX apps accessing, for example, AOP or other web services:

SQL> BEGIN
    DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
        host => '*',
        ace => xs$ace_type(privilege_list => xs$name_list('connect'),
                           principal_name => 'APEX_200100',
                           principal_type => xs_acl.ptype_db));
END;
/ 

And finally, I validated the ORDS config.

$ java -jar ords.war validate

I started ORDS again (running standalone), and the Oracle APEX apps were back online.

Very slick to do an upgrade with about 2 minutes downtime!

Update 27-APR-2020: Kris Rice sent me a message that there is no need to stop ORDS. It detects when APEX is upgrading and suspends traffic.