Okay – so it’s not night time in my home time-zone, but I’m in Singapore at the moment so it’s night time.
A very simple little quiz – so I’ve disabled comments for the moment and will re-enable them tomorrow morning to allow more people to have a chance to see the question without the solution.
Explain the anomaly displayed in the following “cut-n-paste” from a session running SQL*Plus on 22.214.171.124:
SQL> create unique index t1_i1 on t1(v1 desc); create unique index t1_i1 on t1(v1 desc) * ERROR at line 1: ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found SQL> create unique index t1_i1 on t1(v1); Index created.
Well it didn’t take long for an answer and several bits of related infomration to show up – as Martin pointed out, all I have to do is insert NULL into the table twice.
Like the recent article on deleting histograms this is another draft that I rediscovered while searching for some notes I had written on a different topic – so I’ve finally finished it off and published it.
Here’s a quirky little detail of extended stats that came up in an OTN thread earlier on this week [ed: actually 8th Jan 2014]. When you create column group stats, Oracle uses an undocumented function sys_op_combined_hash() to create a hash value, and if you gather simple stats on the column (i.e. no histogram) you can get some idea of the range of values that Oracle generates through the hash function. For example:
This is the index to a series of articles I’ve been writing for redgate, published on their AllThingsOracle site, about generating and reading execution plans. I’ve completed a few articles that haven’t yet been published, but I’ll add their URLs when they’re available.
I don’t really know how many parts it’s going to end up as – there’s an awful lot that that you could say about reading execution plans, even when you’re trying to cover just the basics; every time I’ve started writing an episode in the series it’s turned into two episodes. I’ve delivered 5 parts to redgate so far; the active URLs below are the ones that they are currently online.
It’s amazing how you can find little bugs (or anomalies) as soon as you start to look closely at how things work in Oracle. I started to write an article for All Things Oracle last night about execution plans with subqueries, so wrote a little script to generate some sample data, set up the first sample query, checked the execution plan, and stopped because the final cost didn’t make sense. Before going on I should point out that this probably doesn’t matter and probably wouldn’t cause a change in the execution plan if the calculation were corrected – but it is just an interesting indication of the odd things that can happen when sections of modular code are combined in an open-ended way. Here’s the query (running on 126.96.36.199) with execution plan:
Here’s a note which I drafted in Novemeber 2010, and then didn’t publish. I found it earlier on this morning while looking for another note I’d written about histograms so, even though it may not be something that people need so much these days, I thought: better late than never.
I’ve pointed out in the past that I’m not keen on seeing lots of histograms on a system and tend to delete them if I think they are not needed. Here’s an example of the type of code I use to delete a histogram.
We are back to REPVFY, (Repository Verification Utility) this week, (first post can be found here…) And I’m onto the next file of substance since looking at the advisor log, (performance data). The next files are the two “details” files. One is a query used to produce the output and the second is the actual output
It’s always the combinations that catch you out.
Bigfile tablespaces have their uses – especially in big systems
Materialized views have their users – especially in big systems
There’s absolutely no reason why the two technologies should interfere with each other … until you find a bug !
Running an example, stripped to the bare minimum, and doing a couple of things that I personally don’t like doing, on 188.8.131.52:
I’ve been having a play with Oracle Linux 7 beta over the weekend. Not surprisingly my first thoughts were to install the Oracle database on it.
As expected, the installations were almost identical or Fedora 19.
Some time back, I investigated the options to do profiling of processes in Linux. One of the things I investigated was systemtap. After careful investigation I came to the conclusion that systemtap was not really useful for my investigations, because it only worked in kernelspace, only very limited in userspace. The limitation of working in userspace was that you had to define your own markers in the source code of the program you wanted to profile with systemtap and compile that. Since my investigations are mostly around Oracle products, which are closed source, this doesn’t help me at all.
When working with Top Activity, we’re accustomed to viewing to wait class in the top, graphed area and below left, the top SQL by SQL_ID and below right is our Top Session information. ASH Analytics was designed so you would enter into a view that looked very similar to Top Activity, but was enhanced so the user could update it to view the data in multiple ways.