Here’s a recent request from the OTN database forum – how do you make this query go faster (tkprof output supplied):
Here’s a little detail I could do without in my database:
select owner, object_type, object_name from all_objects where object_name like '_' order by object_name, object_type ; OWNER OBJECT_TYPE OBJECT_NAME --------------- ------------------- -------------------- APEX_030200 PROCEDURE F PUBLIC SYNONYM F APEX_030200 PROCEDURE G APEX_030200 PROCEDURE P PUBLIC SYNONYM P APEX_030200 FUNCTION V PUBLIC SYNONYM V APEX_030200 PROCEDURE Z PUBLIC SYNONYM Z 9 rows selected.
Public names like P and F for procedures or functions are just not on (unless I create them myself).
Recently I had the pleasure of corresponding with Hans-Peter Sloot. After looking at my simple tool in this post to gather cell IO data from cellcli, he took it a several steps further and created a nice python version that goes to the next level to pull IO statistics from the cells.
This script provides breaks down the IO by “Small” and “Large” as is commonly done by the Enterprise manager. It also provides a summary by cell. Here is a sample output from this script.
I’ve had some papers selected for the OUGN Vårseminar 2014 event in April, so I will be there representing OTN and the Oracle ACE Program. There is an impressive array of speakers lined up for this event already. Should be fun!
I’ve got a couple of months to practice my Captain Jack Sparrow impression. I wouldn’t want to look out of place on the boat!
Earlier in the week I got confirmation I have two papers selected for OUG Ireland 2014.
You can see the full agenda here.
I got on the net to check flight prices and Ryanair were doing a round trip for £13. The booking fee on the travel site I used was more then the flight costs, so the total flight costs came to £30. Needless to say I booked them straight away, so I will be there representing OTN and the Oracle ACE Program.
I often have folks ask me for assistance when target discovery isn’t successful. The following is from a client’s environment that shows just how important it is to ensure your server environment is kept pristine.
If you know anything about bitmap indexes you probably know that a single entry in a bitmap index takes the form (key_value, starting rowid, ending rowid, BBC compressed bit string). So an entry covers a single value for a column over a range of rowids in the table, and the string of bits for that (notional) range is reduce to a minimum by a compression mechanism that eliminate repeated zeros in multiples of 8.
So here’s a question – to which I don’t know the answer, although you may be surprised when you try to find it:
If you have a very large table and in one of its columns the first row and the last row (and no others) hold the value 0 (say) and you create a bitmap index on this column, what’s the largest number of rows you could have in the table before Oracle would HAVE to create two index entries in order to cover both rows ?
The Oracle 11g parameter parallel_degree_limit is designed to put a cap on the maximum DOP for a statement.
The Oracle Database Reference 11g Release 2 (11.2) says this:
A numeric value for this parameter specifies the maximum degree of parallelism the optimizer can choose for a SQL statement when automatic degree of parallelism is active. Automatic degree of parallelism is only enabled if PARALLEL_DEGREE_POLICY is set to AUTO or LIMITED.
But that’s not entirely correct because it turns out you can enable auto DOP via a hint. The PARALLEL hint without a valid object on which to act will enable auto DOP for the statement. Here is an example:
This will be a brief post, mostly so I can save this command somewhere besides the bash_history file on my OEM server. It may prove useful to a few others too… it has been absolutely essential for me on several occasions! (I was just using it again recently which reminded me to stick it in this blog post.) This is how you can make bulk property changes to a large group of targets in OEM: