Oracle made some interesting improvements in the Database Configuration Assistant (DBCA) in 18c simplifying the creation of a standby database, namely allowing to create a copy of a database that will be a RAC database itself regardless of what type the primary database is (e.g. single-instance/RAC/etc.). This post demonstrates this capability.
The other day I debugged some Oracle provided utilities and came across another way of determining an Oracle Database edition. It does not require a running database instance.
I came across this error while applying Database Release Update 19.7 to my RAC database.
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.