Forum Stats

  • 3,815,367 Users
  • 2,259,007 Discussions


Are these versions ok to migrate to 22.1.0 ?

Paavo Member Posts: 736 Silver Badge

What is the minimum version which can be migrated to 22.1.0 ?

ords   : 21.2.0.r1741826
java   : 17.0.3
tomcat : 9.0.xx (ajp with frontend apache)
apex   : 21.2.6

Or should ords first be upgraded to 21.4.2 ?

And if having ords per pdb only silent install setup, what else to consider?

rgrds Paavo

Best Answer


  • thatJeffSmith-Oracle
    thatJeffSmith-Oracle Distinguished Product Manager Posts: 8,510 Employee
    Answer ✓

    You're fine to migrate ords 21.2 directly to 22.1

    For standalone users we're looking at a bug with JVM memory footprint on startup, so there will be a 22.1.1 update shortly to address that.

  • Paavo
    Paavo Member Posts: 736 Silver Badge


    FYI: just did upgrade to 21.4.2 for one of the PDB's and noticed that ords_installer_privileges.sql has new privileges added, so I had to rerun that for my ords installer user.

    And 3 stupid questions,

    1.) isn't Oracle REST Data Services JDBC driver optional for those who are developing jdbc apps?

    2.) ords has its own jdbc - so no need to download and configure jdbc

    3.) when going with the java 17.0.3 it is 'free' to run ords in tomcat

    rgrds Paavo

  • thatJeffSmith-Oracle
    thatJeffSmith-Oracle Distinguished Product Manager Posts: 8,510 Employee

    1 - do you mean the REST Driver? Separate download on ORDS Page?

    Yes, it's optional, if you want a java app to connect to ORDS vs the DB directly.

    2 - Correct.

    3 - Oracle Java is always avail at no additional cost for Oracle products requiring Java, such as ORDS. Licensing for Java 17 is such that it's free for all users/use cases as I understand it. Also, ORDS only requires a JRE, and the JRE licensing is different than JDK.

  • Paavo
    Paavo Member Posts: 736 Silver Badge

    While happily reading the docs I noticed features to watchout. @thatJeffSmith-Oracle sent you some log files.

    1.) Be careful and read the ORDS upgrade logs. Pay attention to esp. drop synonyms. For my setup the drop_ords_apex_synonyms.sql burbs in silent install upgrade to 21.4.2.x when using install account for ords (not sysdba). It will also fail switch the synonyms to most recent APEX-schema when upgrading to 22.1.0.x

    2.) The config dir for silent upgrade requires subdirectorys name under the config-dir/xxx

    3.) When deploying ords.war with e.g. pdb1.war context names, then it remains to be tested that the ORDS config dir specified in tomcats bin/ works and it is possible to have separate versions of ords/apex per pdb. Frankly speaking didn't yet check how the ords.war knows its config dir.

    rgrds Paavo

  • thatJeffSmith-Oracle
    thatJeffSmith-Oracle Distinguished Product Manager Posts: 8,510 Employee
  • Paavo
    Paavo Member Posts: 736 Silver Badge

    Yes, I placed that path to file - because I assume it gets grabbed from there>>

    [[email protected] bin]$ cat
    export JAVA_OPTS="-Dconfig.url=/host_u01/ords_config/221"
    [[email protected] bin]$ pwd
  • Paavo
    Paavo Member Posts: 736 Silver Badge

    I have been busy in preparing the migration to 22.1.0 by first upgrading to 21.4.2.r0621806. As note above the synonyms were a bit strange, so decide to do the following:

    1. prepare tomcat docker with most recent java 17.0.3
    2. backup rest services with sqldeveloper
    3. give privileges for ordsinst again to be sure
    4. silent uninstall whatever ords version there was
    5. MAKE SURE APEX is most recent, do upgrades if necessary with the myos patches
    6. silent install ords Oracle REST Data Services version : 21.4.2.r0621806
    7. and then pour the rest services back where needed

    So now the synonyms are not whining but I think there are less synonyms than before esp. ORDS_METADATA has none. So maybe they moved to public synonyms? Anyway these are internals of ORDS and as long the logs are clear from errors I am happy pucka.

    I am not very sure, but I have feeling that the routing configurations expect only one ords.war as context in the path.

    --> will be handled by  ?

    So only one ords.war can be deployed to e.g. tomcats webapps/- directory and the routing takes care routing to correct pdb. This sounds reasonable but might require all pdbs's specific ords to be upgraded at the same time?

    Noticed the following: the ORDS 21.4.2.x seems to look the path to configs mentioned in and not look the configs defined per ords.war. So how to set the config dir so that ORDS 21.4.2.x can co-exist with 22.1.0 ?

    rgrds Paavo

  • Paavo
    Paavo Member Posts: 736 Silver Badge
    edited May 2, 2022 10:35AM

    FYI: managed to configure a working setup by organizing the silently migrated pdb specific ords configs as follows:

    /somedir/ords_pkgs/22.1.0/bin/ords --config /pathxx/ords_config/221/devpdb install --admin-user myordsinst --legacy-config /legacy_config_dir/devpdb/2142/conf/devpdb --log-folder /some/ords_logDir/2210/devpdb --password-stdin < devpdb_pass.txt
    --generates, with similar whine about 
    --WARNING The setting named: db.sid is not a recognized configuration setting. Run: ords config info to get a list of known configuration settings
    [/pathxx/ords_config/-221/devpdb]$ ls -R
    databases devpdb_pass.txt global
    pool.xml wallet
    -- so this above migrated config didn't workout directly because in my approach there are ords.war + its legacy configdirs per pdb.
    -- also note that the tomcat level config dir overrides the legacy config dirs per ords.war so couldn't make the older versions to co-exist with 22.1.0
    /pathxx/ords_config -- this path I added to for tomcat to pick
    └── 221
      └── databases
      ├── devpdb
      │ ├── paths
      │ ├── pool.xml
      │ └── wallet
      │ └── cwallet.sso
      ├── intpdb
      │ ├── paths
      │ ├── pool.xml
      │ └── wallet
      │ └── cwallet.sso
      └── uatpdb
      ├── paths
      ├── pool.xml
      └── wallet
      └── cwallet.sso
    --where the paths contained
    -- in the pool.xml I had all the imaginable entry keys .. including the ones in the settings.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE properties SYSTEM "">
    <comment>Saved on Mon May 02 06:43:32 UTC 2022</comment>
    <entry key="db.username">ORDS_PUBLIC_USER</entry>
    <entry key="plsql.gateway.mode">proxied</entry>
    <entry key="database.api.enabled">true</entry>
    <entry key="db.connectionType">basic</entry>
    <entry key="db.hostname">mydb.server.somewhere</entry>
    <entry key="db.port">1521</entry>
    <entry key="db.sid">devpdb</entry>
    <entry key="feature.sdw">true</entry>
    <entry key="">true</entry>
    <entry key="security.requestValidationFunction">wwv_flow_epg_include_modules.authorize</entry>
    -- not sure if the entry keys, common for all pdb's could have been in some global/globals settings.xml - didn't find from docs how to do that
    -- didnt touch the cwallet.sso files generated, so just copied the directories from the migrate
    -- then deployed the ords.war to webapps
    -- and configured the ajp13 as follows, you can argue the reverse, but lets stick to same path
    <Location /devpdb>
      ProxyPass ajp://localhost:8119/ords/devpdb
      ProxyPassReverse ajp://localhost:8119/ords/devpdb
    <Location /ords>
      ProxyPass ajp://localhost:8119/ords
      ProxyPassReverse ajp://localhost:8119/ords
    -- didn't yet check the migrate status of the actual rest services, but checked that Apex works.
    -- now the side-effect is that there is everywheren .../ords/.. in the URI's
    -- also in the example rest-api's e.g. json ref.
    e.g. https://myfrontend.somewhere/ords/devpdb/apischemaalias/hr/employees/7369
    instead of : https://myfrontend.somewhere/devpdb/apischemaalias/hr/employees/7369
    items: [
    uri: {
    $ref: "https://myfrontend.somewhere/ords/devpdb/apischemaalias/hr/employees/7369"
    rn: 1,
    empno: 7369,
    ename: "SMITH",
    job: "CLERK",
    hiredate: "1980-12-17T00:00:00Z",
    mgr: 7902,
    sal: 800,
    comm: null,
    deptno: 20

    So this seems to be a bit one-way-ticket but feels progress anyway. At least felt much faster than previous setup.

    @thatJeffSmith-Oracle see this progress, and if you know cure to the added "ords" in the URI then it would be good to know. Also if there could be option to deploy older versions of ords.wars with their own config directories to tomcat, then that would allow smoother transition to new 22.x.x. versions of ords.

    ps. there were no errors in the ords_upgrade_2022-05-02_095139_64267.log silent upgrade files when doing the upgrade over the clean 21.4.2.r0621806 install.

    rgrds Paavo