There is a wrong results issue I stumbled upon this morning. A developer told me that one of their queries started returning wrong results after we upgraded one of our databases from 12.2.0.1 to 19.7.
This post is a continuation of a previous one: OR Expansion and Virtual Columns. The last post demonstrated that OR Expansion can somehow be affected by virtual columns in such a way that queries that did not perform OR Expansion can start using it as soon as a virtual column is created. Both an FBI and extended statistics lead to the same result provided that a certain column used in the query is included in them. This time around, I am going to take a look at how 19c has changed that.
The following test case can be used to demonstrate a little peculiarity of the OR Expansion transformation, that was introduced in 12.2.
Developers wanted to call external programs from the database using a Java class. By default, those commands are run under the database user account which is anything but secure. Let's see how to improve security in this scenario.
I was asked if there is a way to identify what redo tag was set for a specific transaction. Let's find it out in this post.
I decided to take a look at what events Oracle provides to diagnose or troubleshoot SQL Macro Expansions.
While reviewing the list of bugs fixed in 19.6, I found that Oracle backported SQL Macros to 19.6 judging by the bug description.
A practical demonstration of performing unattended Grid Infrastructure Out of Place patching using opatchauto and property files.
SQL92_SECURITY has changed its default value to TRUE starting from 12.2.0.1: Upgrade Guide.
That might lead to ORA-01031: insufficient privileges errors being thrown in runtime as this post demonstrates.
I have recently optimized one of processes working with LOBs and decided to write a blog post about it.