This blog post is about two things: one how you can monitor who is bringing you database up and down (there is a twist at the end!) and two how you can very conveniently do that with aggregated logs in a browser with a tool called ‘Kibana’, which is the K in ELK.
A question about parallel query and cardinality estimates appeared on OTN a little while ago that prompted me to write this note about helping the optimizer do the best job with the least effort. (A critical point in the correct answer to the original question is that parallel query may lead to “unexpected” dynamic sampling, which can make a huge difference to the choice of execution plans, but that’s another matter.)
The initial cardinality error in the plan came from the following predicate on a “Date dimension” table:
A little over a year ago I was at the BGOUG Spring Conference and I watched a session by Maja Veselica about auditing in Oracle Database 12c. At the time I noted that I really needed to take a look at this new functionality, as is was quite different to what had come before. Fast forward a year and I’ve finally got around to doing just that.
I found out yesterday that we have an Oracle license audit in January, so I spent yesterday having a look at everything we have to check what features we are using…
Our licensing situation is a little different to anywhere I’ve worked before, in that they are based on the number of Full Time Employees (FTEs), not on named users or processors. As a result, we don’t need to worry about the number of installations we have. We just need to make sure we are not using features we are not licensed for.
The database side is quite easy because we have FTE licenses for Enterprise Edition, Diagnostics and Tuning Pack and Partitioning. I checked the DBA_FEATURE_USAGE_STATISTICS view on each server and everything looks OK.