Search

Top 60 Oracle Blogs

Recent comments

upgrade

Application Express – the PSE update

I published a post a couple of days ago about how due to the architecture of PL/SQL and hence Application Express, we can rapidly deliver and deploy updates to the core APEX product to deliver timely fixes to the APEX community.

Because a single patch may now evolve over time to contain additional fixes, long time friend of the APEX community Peter Raganitsch then made the following observation on Twitter:

image

Updating my APEX 20.2 installation

One of (or should I say “another of”!) the very cool features of Application Express (APEX) is that by being a database-centric software installation, patching of the product can be done very efficiently and easily by simply loading fresh versions of the underlying PL/SQL source.

The reason loading PL/SQL source is such a good thing is that when you load PL/SQL source that is unchanged the database can simply treat that as a “no-op” which

  • makes loading the unchanged PL/SQL faster,
  • avoids invalidation and recompilation impacts

We can see that with this simple demo.

APEX 20.2 comes to town (well, to my PC)

As always, you should read the Installation/Upgrade manual from top to bottom before upgrading any piece of software, and be aware of all of the pre-requisites and processes.  But for me, my Application Express 20.2 upgrade was as simple as:

  • Download Application Express
  • Unzip to my target location
  • sqlplus / as sysdba
    • SQL> @apexins.sql SYSAUX SYSAUX TEMP /i/
  • Validate my ORDS installation
    • java -jar ords.war validate
  • sqlplus / as sysdba

And voila! A freshly upgraded Application Express in a matter of minutes…

DBMS_JOB and 19c – code changes needed

Here’s a “gotcha” brought to my attention by one of our AskTOM readers. I’ve mentioned in the past that DBMS_JOB, having been deprecated in favour of DBMS_SCHEDULER, got a new lease of life in 19c because under the covers we translated calls to create a job under DBMS_JOB to the same mechanism in DBMS_SCHEDULER.

The benefit of that is that we don’t need to maintain our older DBMS_JOB code base, but your existing code is fine to keep running. However, as I said in the other post, you do need to alter your privileges, but here is another discovery that might impact you as well.

How to upgrade to Oracle 19.8 on Windows

As always, you should follow the instructions in the README.html that comes with the Release Update, but because I know many people like to see what the experience of others is like, here’s my run of the patch application.

As always don’t forget to run your CMD prompt as Administrator, otherwise OPatch will typically have trouble accessing and locking the software inventory

Prerequisites

Get your environment setup as per the patch notes.

Upgrading…Its Time!

Gough Whitlam was an Australian politician who rose to power in the 1970s with the campaign slogan “It’s Time!”. Politics aside, it loosely ran on the premise that not to have the occasional dramatic change ultimately leads to stagnation in social and economic progress.

428px-Gough_Whitlam_1973

MAX_STRING_SIZE – stretching the dictionary

This post cycles back too some other historical posts of mine related to max_string_size and the fact that the data dictionary uses LONG data type columns because of historical reasons related to backward compatibility. Most of us probably have existing databases that have gone through the standard upgrade through various versions of the Oracle Database, and as such, all of our existing database have a max_string_size of STANDARD. Thus to convert to the larger string size, we start by setting max_string_size to EXTENDED, run the appropriate scripts after shutting out database down and re-opening it in upgrade mode, setting the appropriate initialization parameters for the instance in our SPFILE. But what if you are creating a new database?

From 19.6 to 19.7 on Windows

I must say this Release Update (RU) was probably the smoothest I’ve ever done. Obviously you should always read the patch notes carefully before proceeding on your own systems, but for me, it was a simple exercise. I’m posting this just to cover a couple of things that the patch notes “assume” and don’t explicitly state.

  • Shutdown everything Oracle related. I just go to “Services” and look for anything with Oracle. Also shutdown the “Distributed Transaction Coordinator service”.

This next one is key … I’ve made this mistake so many times. Open a command prompt window as administrator. If you don’t, things will progress OK for a tiny bit and then OPatch is going to throw a wobbly.

I did both the 19.7 RU and the 19.7 OJVM with OPatch, and both went through without incident.

APEX 20 patch

I’ve been debugging an issue within an APEX application and wanted to make sure that my local installation was at the same version as apex.oracle.com. So I logged on to my workspace and ran queries on APEX_RELEASE and APEX_PATCHES and discovered that there was a patch available for 20.1.

That patch is 30990551 and you can download it from the usual spot on My Oracle Support. None of the bugs listed in the “Fixed Bugs” helped me with my issue, because it turned out to be my own code Smile. But here is what is fixed in the patch:

APEX upgrade – don’t forget your CDN

I haven’t dug too deep into this one, so what follows may be just coincidental but I thought I would blog it out just in case it happens to anyone else.

While testing AskTOM as part of our Application Express upgrade to version 20.1, I got a bit of a shock when I fired up AskTOM (in a testing environment) after the upgrade. The screen was … well…. “slim”. Smile

image