Here is an interesting limitation to Exadata Smart Scans - if more than 254 columns from a table (not HCC compressed, more on that in moment) need to be projected, Smart Scans for that particular segment will be disabled and Exadata will fall back to conventional I/O.
One thing that I have found sorely missing in the performance pages of Enterprise Manager is latency values for various types of I/O. The performance page or top activity may show high I/O waits but it won’t indicated if the latency of I/O is unusually high or not. Thus I put together a shell script that shows latency for the main I/O waits
Of course it would be nice to add a few others like direct path writes, direct path writes temp and log file sync but there is only so much room in the screen width.
The script is called oramon.sh and is available on github at
This past year I joined up on the board of the Northern California Users Group (NoCOUG) and am excited to help the NoCOUG team bring great conferenes to the Bay Area.
Our new conference director Ben Prusinski has scheduled a whole slew of NoSQL and Big Data presentations at Conference 105 on February 21. Has NoCOUG abandoned SQL? You can bet your bottom dollar it hasn’t! In fact, it was Oracle’s own idea to have so many NoSQL and Big Data presentations at Conference 105. Dave Rubin, Director of NoSQL Database Development at Oracle will explain why NoSQL Database and Oracle Database are the perfect match. They are not mortal enemies. They complete and complement each other. They shine in different use cases.
The example I gave last week showing how a SORT operation in an execution plan might include the work of resolving function calls in your SQL and might, therefore, be reporting much higher resource utilisation than expected reminded me of some problems I’ve had with gaps in execution plans in the past. So I thought I’d give a little demonstration of the way in which the completeness of execution plans can develop over time.
We’ll start with the same two tables I had in last week’s demo.
The problem of transient PK updates is well known and comes from the fact that pretty much every replication solution on the market applies changes using row-by-row approach.
To quickly recap the problem, if you have a table like:
SQL> create table tpk (n number primary key);
SQL> insert into tpk values (1);
1 row inserted
SQL> insert into tpk values (2);
1 row inserted
Then executing the following statement...
update tpk set n=n+1
...will result in a transient PK problem since the replication solution will have to decompose it into the following two statements:
update tpk set n=2 where n=1;
Van 3 tot en met 7 maart vindt in Irving, Texas, het internationale Oracle Performance Symposium Hotsos plaats. Dit jaar belooft het symposium een garantstelling voor inhoudelijk hoogstaande presentaties en discussies, want naast presentaties van Tom Kyte, Cary Millsap, Maria Colgan en Steven Feuerstein over performance, worden er ook onderwerpen behandeld zoals Big Data, noSQL, …
I was using UltraEdit 3.3 on Fedora 17 with no problems. After the upgrade to Fedora 18 it continued to work fine. Then I noticed there was a newer build of 3.3 on the IDM website, so I downloaded and installed it. Unfortunately, it didn’t work. I guess it was a later build for Fedora 17, not a new Fedora 18 build.
I dropped the guys at IDM an email and they did a new build straight away and it worked fine. This build is available from the website now.
It’s nice when people write cool apps and back them up with good service when you need help!