The new Database Express or DB Express database utility is different from the former DB Console. It is based on flash and “built-in” the database. To give you a small overview (sneak peek) into this great new tool for, for example, database performance tuning, hereby some pictures to create some appetite. I created some have …
Oracle DB Express is the new replacement for Oracle DB Console in the Oracle 12c database. Here are some first steps to get started. Oracle DB Express makes use of what is called the “XDB Protocol Server”, which among others supports the Oracle APEX standalone PL/SQL Gateway. For people who are unknown still how to …
Is this one of my highlights? No not really, but it is a remarkable one. Oracle XMLDB functionality is now mandatory and can not be uninstalled. As mentioned in the new feature section of the Oracle XMLDB Developers Guide for Oracle 12c: Oracle XML DB is now a mandatory component of Oracle Database. You cannot …
You can download it from http://edelivery.oracle.com
And now I (and other beta testers) can finally start writing about the new cool features in it! :)
Looks like only the Linux x86-64, Solaris x86-64 + SPARC ports are available first (as usual).
(just a screenshot below, you’ll need to go to http://edelivery.oracle.com to download the files)
Several years ago I wrote the following in “Cost Based Oracle – Fundamentals” (p.47):
The maxthr and slavethr figures relate to throughput for parallel execution slaves. I believe that the figures somehow control the maximum degree of parallelism that any given query may operate at by recording the maximum rate at which slaves have historically been able to operate—but I have not been able to verify this.
Browsing the internet recently, I discovered that that no-one else seems to have published anything to very my comment, so I decided it was about time I did so myself. I’m going to work up to it in two blog notes , so if you do happen to know of any document that describes the impact of maxthr and slavethr on the optimizer’s costing algorithms please give me a reference in the comments – that way I might not have to write the second note.
Cloud Control 12c is a great product. Yes, it is suffering from bloat, but generally it is a really great tool. I’m always encouraging people to ditch the DBControl and switch to Cloud Control!
Having said that, one area that annoys the hell out of me is the job management, which feels really clumsy. I started to write this post, then felt a bit guilty because I hadn’t actually bothered to raise an enhancement request, so that’s what I’ve just done!
My main gripes are the following.
In my last post I made a comment about how the optimizer will use the new format of the index hint to identify an index that is an exact match if it can, and any index that starts with the same columns (in the right order) if it can’t find an exact match. It’s fairly easy to demonstrate the behaviour in 11g by examining the 10053 (CBO) trace file generated by a simple, single table, query – in fact, this is probably a case that Doug Burns might want to cite as an example of how, sometimes, the 10053 is easy to interpret (in little patches):
PS. You can start your downloads, now mine is complete.
PPS. I got the Mac download, but it looks like the others haven’t made it on to the mirrors yet.
PPPS. The other downloads are available now too.
I’ll probably have to file this one under “Optimizer ignoring hints” – except that it should also go under “bugs”, and that’s one of the get-out clauses I use in my “hints are not hints” argument.
Sometimes an invisible index isn’t completely invisible.
Here’s a demonstration from 18.104.22.168 showing something which, to my mind, is a very annoying problem. The objects are in a tablespace that has been created with uniform extents of 1MB on an 8KB block size, using freelist management. I’ve rigged the Hakan factor to ensure that I get exactly 40 rows per block, and I’ve set the system statistics to ensure that a relatively small swing in cost results in a change in execution plan.
Here’s a little quiz: If I take the average row length of the rows in a table, multiply by the number of rows, and convert the result to the equivalent number of blocks, how can the total volume of data in the table be greater than the total number of blocks below the table high water mark ? I’ve got three tables in a schema, and they’re all in the same (8KB block, 1M uniform extent, locally managed) tablespace, but here’s a query, with results, showing their space utilisation – notice that I gather schema stats immediately before running my query: