True source of the text below.
Oracle DB has a lot of infrastructure built around SQL execution.
1. Caches all the SQL - binds replaced
2. Optimizer generated plans for these
3. Statistics both System and User
From scratch:
As you switch on the DB it starts encountering SQLs. It will do a hard parse for it, indicated by missed in library cache: 1, in the trace file. It does dynamic sample at this time 10g also does bind peek and generates[in accordance to the current statistics] and caches the plan.
Subsequent execution of this SQL will use this plan even if underlying table/index statistics are changing in realtime.
What is the life scope of plan?
1. Gather stats invalidates plan on the objects.
2. Object invalidation.
3. LRU scheme on cached plans.
Note on Statistics:
Can be collected AUTO magically or manually. If statistics change by > 10% [not sure] then gater statistics is kicked off resulting in invalidating of generated plans on the underlying objects.
Note on Explain / Autotrace:
Are the same. Explain plan or sql_trace=true *causes a hard parse for first execution of any query with this option as true. Effectively, real time execution of queries [row source operation] depict and use the generated plans [soft parse], but if the same tracefile is tkprofed it will do a hard parse of the query and may come up with a completely different plan [as of now]. This is so because the generated plan as aged and statistics have changed.
Sunday, April 29, 2007
Tuesday, April 17, 2007
Easy way out!
To be frank, I will be using this space to store and share my understanding of technical fundas. Consdiering other alternatives a blog was the most presistent store and also an "easy way out". It would mostly be about left brain and less about right though I keep telling myself to excercise the other one more.
Subscribe to:
Posts (Atom)