In the first part of this series I said that RAM access is the slow component of a modern in-memory database engine and for performance you’d want to reduce RAM access as much as possible. Reduced memory traffic thanks to the new columnar data formats is the most important enabler for the awesome In-Memory processing performance and SIMD is just icing on the cake.
This is the text of the “whitepaper” I submitted to DOAG for my presentation on “Core Strategies for Troubleshooting”.
In an ideal world, everyone who had to handle performance problems would have access to ASH and the AWR through a graphic interface – but even with these tools you still have to pick the right approach, recognise the correct targets, and acquire information at the boundary that tells you why you have a performance problem and the ways in which you should be addressing it.
There are only three ways you can waste resources on an Oracle system, and only three different types of activity that need to be investigated. If you don’t appreciate that this is the case then you can waste a lot of time following the wrong strategy and attempting to solve the wrong problems. Once you have a clear statement of what you are trying to achieve it becomes much easier to achieve those aims.
You tend to name PL/SQL parameters and variables in such a way as to prevent name clashes with table columns. Let’s cause an obvious name clash…
The table DUAL has a column called DUMMY with a single row with the value ‘X’.
After my AWR Warehouse session at DOAG in Nuremberg, Germany last week, an attendee asked me if he really needed to use trace files anymore with the value provided by AWR, (Automatic Workload Repository) and ASH, (Active Session History.) I responded that trace files were incredibly val
Recently a customer asked if it was possible to promote unmanaged targets automatically without any interaction. They were already using auto-discovery.
The answer is yes, and of course as soon as you see words like “without any interaction” you know there’s going to be scripting involved. In the Enterprise Manager world, scripting is handled by the EM Command Line Interface, better known as EMCLI. I’ve posted some example scripts of using EMCLI a while back (see this post), but I thought it was worthwhile to show you how this particular request is handled as well. If you have the latest bundle patch on either 22.214.171.124 or 126.96.36.199, you can also use additional parameters to the get_targets verb to list discovered targets (-unmanaged). This includes listing the associated instance targets if you want to promote a RAC database (-associations).
The night before a morning flight is always a little tricky for me. I lie in bed thinking, “What if I oversleep?”, which winds me up and makes it really hard to relax and drop off. I dozed on and off, but eventually gave up, turned the TV on and watched some films for a few hours.
I grabbed a quick breakfast and got the taxi to the airport. The hotel staff advised leaving at 07:00 for a 10:15 flight. The traffic was very light and the queues for check-in and security very small, so I ended up sitting at the boarding gate two hours before the flight. Better to be early than late!
I’ve often found that while I’m investigating one Oracle feature I get waylaid by noticing anomalies in other parts of the code. I was caught by one of these events a little while ago while experimenting with the new (188.8.131.52) Inmemory Columnar Store. After reading a posting by Martin Bach I asked the question:
“If you have a partitioned table with a local index and one of the table partitions has been declared INMEMORY, would a query that could use that index be able to apply table expansion to produce a plan that did a tablescan on the in-memory partition and an indexed access path on the partitions that weren’t in-memory?”