I recently read a blog post by Kyle Hailey regarding some lack of randomness he detected in the Orion I/O generator tool. Feel free to read Kyle’s post but in short he used dtrace to detect Orion was obliterating a very dense subset of the 96GB file Orion was accessing.
In my earlier post, I talked about, how tableau can be used to visualize the data. In some cases, I find it useful to query AWR base tables directly using Python and graph it using matplotlib package quickly. Since python is preinstalled in almost all computers, I think, this method will be useful for almost everyone. Of course, you may not have all necessary packages installed in your computer, you can install the packages using install python packages . Of course, if you improve the script, please send it to me, I will share it in this blog entry.
Script is available as a zip file: plotdb.py
I blogged earlier about heap dump shared pool heap duration and was curious to see how the inmemory – 220.127.116.11 new feature – is implemented. This is a short blog entry to discuss the inmemory area heap.
I have set the initialization parameters sga_target=32G and inmemory_size=16G, meaning, out of 32GB SGA, 16GB will be allocated to inmemory area and the remaining 16GB will be allocated to the traditional areas such as buffer_cache, shared_pool etc. I was expecting v$sgastat view to show the memory allocated for inmemory area, unfortunately, there are no rows marked for inmemory area (Command “show sga” shows the inmemory area though). However, dumping heapdump at level 2 shows that the inmemory area is defined as a sub-heap of the top level SGA heap. Following are the commands to take an heap dump.
NOTE: There’s a link to the full article at the end of this post.
I recently submitted a manuscript to the EMC XtremIO Business Unit covering some compelling lab results from testing I concluded earlier this year. I hope you’ll find the paper interesting.
There is a link to the full paper at the bottom of this block post. I’ve pasted the executive summary here:
Data visualization is a useful method to identify performance patterns. In most cases, I pull custom performance metrics from AWR repository and use tableau to visualize the data. Of course, you can do the visualization using excel spreadsheet too.
We had huge amount of PX qref waits in a database:
Coming up on May 20, I'll be delivering a webinar entitled Oracle SQL Performance: Writing SQL Right. Registration is now open. Once again the webinar will be hosted by Embarcadero and there will be two sessions - one at 10am ET and one at 2pm ET.
Thank you all for coming to my session Cache Buffer Chains Demystified at Collaborate 14, especially for sticking around for a geeky topic like this to the very end. Much appreciated.
I was not aware that I would not be allowed to use my laptop; so I couldn't show all the demos I so carefully prepared. Please download the scripts and execute them yourself.
As promised, here are the materials I used in the session
Needless to say, your comments and feedback will be highly appreciated. And, yes, please don't forget to do the evaluation on the Collab Mobile App.
After collaborating with many performance engineers in a RAC database, I have come to realize that there are common pattern among the (mis)diagnosis. This blog about discussing those issues. I talked about this in Hotsos 2014 conference also.
Here are the golden rules of RAC performance diagnostics. These rules may not apply general RAC configuration issues though.
Looks like, this may be better read as a document. So, please use the pdf files of the presentation and a paper. Presentation slide #10 shows indepth coverage on gc buffer busy* wait events. I will try to blog about that slide later (hopefully).