I just returned from RMOUG 2013 training days in Denver, CO and I have to say that I’m impressed!
This was an incredibly well organized and well run event with lots of great speakers and great presentations. As a former board member of Tampa’s ORACLE users group, I know how hard it is to make an event like this happen, especially at this scale. Great job, @DbaKevlar and the rest!
Read consistency is one of the coolest features of ORACLE database.
In a nutshell, it means that your queries (at least, logically) do not pay attention to the outside world. I.e. your tables may be hit with thousands of changes per second, but your query will ignore all the hoopla and will always see only the data that existed when the query started.
Have you ever heard that the speed of the system is determined by its slowest component ? I am made painfully aware of that every time I do data migrations.
I.e. it doesn’t matter if you have 64 core systems with 100+ Gb of memory on either end if the majority of time is spent waiting for data to trickle across a slow 1 Gb network link.
Watching data trickle for hours, while the rest of the system is doing nothing is a pretty frustrating experience. But limitations breed creativity … so lately, I’ve been experimenting with several different copy techniques to see if there is any way transfer speed can be improved, perhaps using some of the idle capacity to speed things up.
Thanks everyone, who attended my presentation about database sharding at IOUG Collaborate. That was a lot of fun!
I’ve always wondered how many of my SQLs are NOT using baselines.
Of course, when you run DBMS_XPLAN.DISPLAY_CURSOR for the statement, it can put a nicely formatted note for you, something like:
- SQL plan baseline "SQL_PLAN_01yu884fpund494ecae5c" used FOR this statement
But can you find it globally for ALL SQLs in the shared pool ?
If you’ve been a DBA long enough, you’ve probably seen multiple cases where certain SQL queries just refuse to cooperate.
I.e. you KNOW that the query is supposed to use index IDX1, but ORACLE stubbornly decides to take IDX2. Rats!
The usual suspect here is bad statistics and thus the usual advise is: start re-collecting them. But while this might help, the success is far from guaranteed! Moreover, with a ‘real production’ data statistics collection could take hours (days?) and you already have people screaming about slow performance … In other words, you need to fix the problem NOW and waiting until stats collection maybe fixes the problem a few hours down the road is just not an option!
Remember the ever annoying (but hilarious) Dos Equis guy commercials about “the most interesting man in the world…” ?
Well, I’ve heard a good one today:
… I don’t always test my software … but when I do, I test it in PROD !
Thanks, Arup. Stay thirsty my friends
When you start working with SQL Plan baselines, one of the annoying things that you might find is that the main “baseline” dictionary view dba_sql_plan_baselines does not have sql_id column.
Sometimes when you trace things, you can discover some really interesting (and unexpected) stuff.
For example, here is a simple way to “freeze” your ORACLE database, which I “discovered” while tracing system calls in LGWR process (ORACLE 220.127.116.11 on Linux 2.6.18 ×64).
A very brief update.
One of the smaller (and nicer) part of ORA_MEM package is ora_cpu.pl utility that shows graphically what active db processes are doing at the moment … be it running SQL, accessing db object or waiting for something.
As an added benefit, it also shows some important OS statistics, such as process state or ‘spot’ CPU utilization for your database sessions.