Mostly Making oracle easy, mostly:
Search for:
In ORDS

ORDS version 24.1 is now available, time to upgrade!

3 Mins Read

I won’t read the release notes for you, but I will summarize. Consider this your TL;DR summary!

Core ORDS

By ‘core ORDS’ – I mean the basic ‘guts’ of the Oracle REST Data Services software. One of changes is significant.

  • Metadata Caching enabled by default with a default timeout of 1 second

This means heavy consumers of REST APIs, esp those of the AUTO variety, could see as much as 3x faster response times. That’s pretty cool. Note we’ve just changed the ‘DEFAULT’ behavior – you can always go into the config and turn this off, explicitely.

Run ‘ords config list –include-defaults’ to see all the ORDS configuration settings.

This means if you make a change to a REST API definition, it could take as long as 1 second for that definition to be updated/reflected in your environments.

This effectively means we run fewer SQLs internally to pull up the REST API and privilege definitions before running your APIs. Less work, means faster APIs. The more you hit the endpoints, the more benefit you will see. If you don’t see the benefit, you may want to increase the cache timeout period.

SQL Developer Web

New Home Page

No more generic list of index cards! Now you get a ‘recent’ or ‘pinned’ list of features on the ‘LauchPad,’ or you get a list of features by feature area, complete with descriptions, doc links, and screenshots to give you an idea of what’s possible.

You can still choose to land directly on any page/feature you want.

Running SQL, w/o the paging

In the SQL Worksheet, there’s now a drop-down button when you want to execute a SQL statement.

What does this mean?

Remember when I wrote that post, ‘How does paging work?‘ When you run SQL, we don’t just run that SQL, we wrap it with an Analytic Function – like so:

If you’re looking in V$SQL or SQL Monitor and notice your query looks ‘funny,’ this is why.

To support this on the backend, the REST Enabled SQL feature has also been enhanced, if you set the offSet to -1, it turns off paging. We also add a limit of 256 rows, so we don’t overwhelm your browser with query results.

SQL History has been moved from your browser to the database

Instead of storing your SQL History in your browser (using a browser based database), stored for each database user, for each database you login to, it will now be stored by SCHEMA in the database you’re logged in as.

If you’re using a ‘read only’ environment, the SQL History will default back to your browser.

You’ll see that data sourced here SCHEMA.DBTOOLS$EXECUTION_HISTORY –

This means anyone using this schema/login, will see the SQL ran as that database user.

IF you disable SQL History, it will nuke the data in the table, meaning anyone relying on the history for that database user account, will lose it. So if you’re sharing database logins, ‘be nice.’

There’s a lot more I could go over, but then this wouldn’t be a TL;DR summary 🙂

Author

I'm a Distinguished Product Manager at Oracle. My mission is to help you and your company be more efficient with our database tools.

Related Posts

8 Comments

  1. Jeff Reply

    Hi Fellow Jeff,

    We are running Apex 23 with customer managed ORDS 24.1 on Tomcat 9 against ATP DB in OCI.

    I just did an upgrade of Apex to 24.1, can’t get to Apex console via Cust Ords, but can using public endpoint. Saw a potential bug notice so upgraded Cust Ords to 24.2.2 to match what’s on the ATP DB.

    We are getting the “missing prehook” error when trying to get to …/ords/apex and to a couple of similar application (Oracle Retail) url’s. However, the connection to the DB is valid on the Cust Ords node and back-end use of ords for job submission is working. Only direct /ords/xxx access seems to throw the error.

    The prehook error is a fun one to troubleshoot, but the only change to the stable system is the upgrades so wondered if you had an idea on this, or perhaps better, to a process to diagnose and repair prehook errors. (i.e. in our last upgrade, /ords would bring us to Apex console before, but after the last upgrade we had to use /ords/apex – was a hard one to diagnose) so an approach to diagnosis of this error would be a very beneficial process note.

    Thanks for the help and for all you bring to an infrastructure plumber saddled with ORDS administration.

    – Jeff B

    • thatjeffsmith Post Author

      I would need to see the actual error.

      You can still have /ords redirect to apex, simply set the misc.defaultPage parameter to ‘apex’

      You need to make sure ords_public_user, apex_public_user have execute privs on your your prehook, and that if you execute the function it returns a TRUE or FALSE, that’s about all the debug info I can provide, unless you want to share what you’re using the prehook function for?

    • Jeff

      The prehook was a call to Oracle Retail packaged code, so I have no idea what it is doing.

      However, we found the issue – someone had blocked the return traffic from the DB to our internal load balancer, so the call was never being returned. So it was a network access error (security feature) leading to the prehook error message. We can get to the console via DB private endpoint so all is well.

      The change was not communicated and had nothing to do with the upgrade – “just so happened” to be interesting timing.

      Thanks for the help.

      – Jeff

  2. mark Reply

    Hi Jeff, just noticed that my schema now has DBTOOLS$EXECUTION_HISTORY which increased my backup size by 25MB

    No big deal but how can I purge this history table.

    I’m backing up my schema to Github and even with the compression option this might exceed Github 100MB limit.

    • thatjeffsmith Post Author

      It’s a table, you can truncate it or whatever you want – but you’ll lose your SQL History.

      I would program your backup to OMIT that table completely, so you can have your cake and eat it.

Write A Comment