About

This is Bobby Durrett’s blog.

Mainly I’m interested in Oracle database performance tuning.  I’ve set up this blog for two purposes:

1 – To tell my coworkers at US Foods about the things I’m learning about Oracle performance tuning for the benefit of our company

2 – To share my knowledge with the Oracle community at large and to learn from others outside my company

What sorts of things do I know about that someone would want to get out of this blog?

Currently I’m working with both transactional and data warehouse database applications at a large company.  While doing a variety of DBA tasks, I’ve also been digging into Oracle tuning by reading books and learning through experimentation.  I’ve been working with Oracle database software since 1994 so I have some good experience.  Also, I have a computer science degree from Harvard University and a couple of good years in graduate school computer science at Brown University so I have a strong theoretical and academic foundation to my practical business computing experience.

My intention is that as people search for particular issues they will run across my site when something I blogged about matches their current needs, like a particular error number or the name of an Oracle-supplied function.  With all the information out there I can’t find time to read blogs myself so I figure most people will come here if they are searching for something in particular.  But, you can subscribe to email updates if you want to follow the blog in that way.  Also, I’ve connected my blog to my LinkedIn and Twitter accounts so you can follow my posts on those systems.

Needless to say there are smarter people out there than me and better communicators as well about the same topics.  Folks like Craig Shallahamer, Jonathan Lewis, Tom Kyte, Cary Millsap, David Kurtz, and Don Burleson have all been very helpful to me in my career and I highly recommend their books, talks and other products.  But, this blog may add value to what already exists because of my unique job experience, personality, and writing style.  Besides, I enjoy writing the blog anyway so if nothing else it causes me to put into words the technical issues I’m working through and is fun as well.

One caution which applies to anything on this blog and anything else published about Oracle tuning is that you must test things for yourself and double-check everything.  Check everything against multiple sources and by all means test things in a test environment before making any change in a live production system.

– Bobby

p.s. Feel free to interact with me by commenting on blog posts or contact me directly at bobby@bobbydurrettdba.com.  I am not selling any product or service so don’t worry – I won’t harass you with sales calls or email spam if you reach out to me.

p.p.s.  This blog is aggregated by these two sites:

http://orana.info/

http://www.orafaq.com/aggregator

Misc:

LinkedIn: My profile

Twitter: @bobbydurrettdba

GitHub: My URL

shirt

4 Responses to About

  1. Jeferson Bezerra says:

    Hi Bobby, I am Jeferson Bezerra, I work in Brazil as a Oracle DBA, I’m learning about Oracle performance tuning…

  2. Laurel says:

    Hi Bobby! Nice site with good info. Can you point me to right direction ?
    10g database 6G sga, 19G memory on server
    0.sql using HASH joins with full scans.
    1.Exactly same sqlplan /planhashvalue yesterday and today .
    Queried from cache and awr report to compare
    2. stats the same / the counts of rows practicaly the same (compared)
    3. But today its using Temporary tablespace for hash joins
    and last 1 hour
    4. Exported profile from working instance -> sql using -> still the same issue sorting on temp tablespace
    5. Noticed some minor paging on server
    5. altered policy to manual and gave lot of hash_area_size -> same

    What i am missing here ? 🙂
    Any hints ?
    Thank you!
    Br.Laurel

    • Bobby says:

      I’m not sure. One thing I have seen is that the plan does not always include all of the details of what the database does. So, forcing the profile or having the same plan hash value does not guarantee the same behavior as in the past in all aspects. I read some things in Jonathan Lewis’ book about hash joins and when they spill to disk versus using PGA. It might be a good resource for you or his web site. You say there is sorting to the temp tablespace. The hash join doesn’t do sorting I don’t think. I think it just puts part of the hash table on disk when needed. Maybe you need to manually bump up sort area size if you are trying to manage the PGA manually, but that’s just a guess.

      If you could do select count(*) queries on the two sides of the hash join it might tell you how many rows are really part of the join although you may have done that already.

      Those are some ideas. Hard to know if this is helpful without digging into it myself.

Leave a Reply