APEX WWV_FLOW_SECURITY.GET_OWNER_OF_CALLING_CODE and 12.2
Our developers were using WWV_FLOW_API.SET_SECURITY_GROUP_ID
and were surprised to find that that procedure behaves differently in 12.2 than in 12.1.
Our developers were using WWV_FLOW_API.SET_SECURITY_GROUP_ID
and were surprised to find that that procedure behaves differently in 12.2 than in 12.1.
A practical demonstration of how to use custom wrap tables to affect Oracle wrap behavior.
In this blog post, I will show how I discovered the Oracle Wrap substitution table by reverse engineering Oracle binaries.
I have stumbled upon this bug after upgrading one of my databases to 12.2.0.1 when one of application queries started returning extra rows.
I remember watching a video about Amazon Aurora Serverless where it was demonstrated that your database can be started on demand when the first connection comes. Although it is not something that you might want for your 24x7 OLTP database, it can come in handy for Development environments that have the intermittent usage pattern. I decided to write a blog post about how that can be done for an Oracle Database server working on a systemd-based Linux Operating System.
Database triggers are notoriously known for slowing down DML operations. Yet, they lead to a remarkable consequence while applying to the first post of this series in which I demonstrated statement restarts within a single user session updating a non-partitioned table.
During my previous research, I was also testing the same UPDATE
statement against a partitioned table.
I was slightly puzzled that I did not observe any statement restarts in the performance statistics, even after I updated tens of millions of rows in the partitioned table.
It turns out that there are still statement restarts there, however, they do not lead to such dreadful ramifications when a table is being read three times.
When I was reading about statement restarts, I thought it usually happens in a multi-user system or in the presence of triggers. However, last week one of our developers asked me to help him to figure out why a simple update statement was reading far more data than it was in the table. That blog post is published to share my findings about that.
I encountered that issue originally when I migrated one of my databases to 12.2.0.1.190416.
A question about optimizing access to V$DB_PIPES
just came up recently on the SQL.RU Oracle database forum.
The Topic Starter wanted to find out if there is a way to speed up the query against V$DB_PIPES
, or there are any other options to see if a named pipe exists.