Anyone who has used Oracle for a while will be familiar with the Parent/Child locking "issue" when it comes to tables and indexes on foreign keys. For many years you’d hear people crying "bug" etc but thankfully most now know the reason, and accept it as sensible behaviour.
But lets take a look at a slight variation on that theme.
Lets start with a table called "LOC" which will be our parent table in (more...)
This was going to the be the immediate follow up to my previous post, but 188.8.131.52 came out and I got all excited about that and forgot to post this one :-)
Anyway, the previous post showed how easy it is to convert between nested tables and associative arrays. The nice thing in 12c is that this is no longer needed – you can query the associative arrays directly
One of my favourite security "tricks" used to be the following:
SQL> [create|alter] user MY_USER identified by values 'impossible';
Looks odd, but by setting the encrypted value of someone’s password to something that it is impossible to encrypt to, means you’ll never be able to connect as that account. (Think schema’s owning objects etc).
I hear you ask: "Why not just lock the account?"
Well…in my opinion, that’s a security hole. Let’s (more...)
A common criticism of PLSQL is that the "original" array datatype, now called associative arrays are perfect for passing stuff back and forth to 3GL environments (for example .Net), but canno be used within SQL natively, for example:
SQL> create or replace
2 package BLAH is
3 type num_list is table of number index by pls_integer;
4 type str_list is table of varchar2(30) index by pls_integer;
6 procedure ODP_PROC(n out num_list, s out str_list);
Sadly there seems to be no concept of the Hakan factor for an IOT.
I have an application which merges into an IOT, the merge incrementally populating a swag of initially null columns, hence growing the rows in size. Some simple benchmarking shows the overhead of this versus merging into a table with pre-populated values:
SQL> create table T1
2 ( x int primary key,
3 y1 number(10),
4 y2 number(10),
5 y3 number(10),
We have a fairly common query process, where we run a MERGE command to compare a remote table to a local copy of it, as "poor mans" Golden Gate to bring that table up to date on a regular basis. [Editors note: Writing MERGE's is more complicated but a lot cheaper than Golden Gate :-)]
After an upgrade to 12c, the performance of some of the MERGE’s went very bad…and you can see what (more...)
I played a lot of volleyball in a bygone life :-) and subsequently ruined my knees to the extent that I needed surgery. I got a shock when the surgeon (after a series of x-rays and checks) said to me: "Of course, we’ll only know once we’re in there".
So here’s a body part (a knee) that’s had hundreds of thousands of years to evolve, so you’d expect that knees are pretty much the same (more...)
We did a "real" upgrade to 12c this weekend, where "real" means a production system, as opposed to my laptop, a play VM etc etc :-)
It all went relatively smoothly except for one interesting thing, that I can’t 100% say was caused by the upgrade, but it would appear to be the case.
After the upgrade, our scheduler external jobs started failing. A quick look in the alert log revealed:
Sun Jun 29 (more...)
In the previous post, I pontificated about triggers that "lock you in" to having them fire, which can create dramas when it comes to doing data patching.
Maybe you can design your application around this, but if you cant, the last thing you want to be doing is having to take an outage so that you can disable the trigger whilst you do your data maintenance. Ideally you want the trigger to fire (more...)
Some people hate triggers, some people love triggers…
I am not that opinionated on them in either direction, but one thing I do hate, whether it be a trigger or not, is dumb code. And today’s post just happens to be about dumb code in a trigger.
Consider this simple trigger (you see these everywhere pre 12c):
CREATE OR REPLACE TRIGGER MY_TRG
BEFORE INSERT ON MY_TABLE
FOR EACH ROW
SELECT MY_SEQ.NEXTVAL INTO (more...)