As you may know, one of the many areas of responsibility I have as a product manager in the Enterprise Manager product management team is BI Publisher. BI Publisher is the tool of choice for reporting in Enterprise Manager. If it’s not a tool you’re familiar with, then you are missing out on a lot of the power of the Enterprise Manager repository to provide you the information you need to extend Enterprise Manager beyond the capabilities it currently has. You can read more about it on my BI Publisher page.
Of course, to reach the full capacity of the reporting you can extend Enterprise Manager with, you need to understand the Enterprise Manager repository, and that’s what this post will introduce you to. First, however, you need to understand a little more about the BI Publisher security model.
This note models one feature of a problem that came up at a client site recently from a system running 220.127.116.11 – a possible bug in the way the optimizer handles a multi-column in-list that can lead to extremely bad cardinality estimates.
The original query was a simple three table join which produced a bad plan with extremely bad cardinality estimates; there was, however, a type-mismatch in one of the predicates (of the form “varchar_col = numeric”), and when this design flaw was addressed the plan changed dramatically and produced good cardinality estimates. The analysis of the plan, 10053 trace, and 10046 trace files done in-house suggested that the problem might relate in some way to an error in the handling of SQL Plan Directives to estimate cardinalities.
A number of emails I received about trying out Delphix Express was regarding VMWare. Many of my followers had used Virtualbox for a long time and we all know, no one likes change, (OK, maybe me, but we know how abnormal I am anyway… :))
I have already written about the use of Connection Manager 11.2 to govern access to a database. While researching this piece I have updated the original post so that it’s relevant for 12c as well.
Although the idea of using Connection Manager is tempting, the obvious first question is about high availability of the process, you don’t want it to become a Single Point of Failure (SPOF). After all, if the gatekeeper to your database environment fails, you are effectively closed for business. One option would be to add another CMAN process that could be used.
I have created a few VMs to simulate the scenario. I installed CMAN in 2 VMs running Oracle Linux 7 and CMAN 12c. The client homes have been patched up to the April PSU because that’s considered good practice (although I couldn’t find a reference to CMAN in the OPatch logs). The hosts are named oracledev and server4.
Null represents the absence of a value in a database column. Null means no value at all, and in that sense null can be thought of as nothing. Should you fear the nothing? Yes, indeed! Because nulls lead to three-valued logic, which is more like a three-headed monster because of all the unintended, counterintuitive, and often just plain wrong results it can cause.
Following is a contrived example showing how nulls can lead to counterintuitive results. Execute the query and check the number of rows that are returned. Compare to the total number of products. Evidently there is a large quantity of products that are simultaneously not red and not some other color. How can this be?
#333333; font-family: "verdana" , "arial" , sans-serif; font-size: 13px; line-height: 16.9px;">The next part of the video tutorial explaining the XPLAN_ASH Active Session History functionality continuing the actual walk-through of the script output.
#333333; font-family: verdana, arial, sans-serif; font-size: 13px; line-height: 16.9px;" />#333333; font-family: "verdana" , "arial" , sans-serif; font-size: 13px; line-height: 16.9px;">More parts to follow.
This blogpost is about using the linux ftrace kernel facility. If you are familiar with ftrace and specifically the function_graph tracer, you might already be aware of this functionality. This is Linux specific, and this facility is at least available in kernel 2.6.39 (Oracle’s UEK2 kernel).
Beginning with Oracle 12c columns may be marked “INVISIBLE” in CREATE and ALTER TABLE statements.
Suppose you have code that uses “SELECT *” (no, really this sometimes occurs) and you need to add a column or columns? Oops! Code using “SELECT *” now breaks as does code using INSERT statements without a column list. (I know, ALL of your system’s code uses explicit column name lists in SELECT and INSERT