This content has been marked as final. Show 10 replies
If your company spent the money required to purchase an Exadata then they've likely got a few thousand dollars they can apply to providing you, or a member of your team, with training.
When you write, as you did, "l please suggest what all database features/ exadata tuning we can use in our applications" you are asking for someone to teach you a class. Which is something unsuited to a forum where Q&A consists of a few paragraphs.
Thanks Damorgan for your suggestion. I truly agree with you.
But, we are not here expecting any tutorials or lessons. Just wanted name of some features/db level modifications that we could do before we get machines. If anyone who has already did something like this, there learning could just help us.
To be honest, your request is too broad and vague. It's like asking, "what are the best methods and materials to build a house with?"
The answer to that question starts with "It depends". Truly more information is needed to give a meaningful response -- information specific to this application.
- what does "batch" mean?
- what does "batch" do?
- how does "batch" do its work? row by row processing or set-based?
- does "batch" use parallel execution or not?
- etc., etc., etc.
Greg Rahn | blog | twitter | linkedin
As i said, and as Greg has reinforced, the question you have asked, as you have asked it, can only be answered with taking a class.
I could give you a very long list that would include both proper indexing and dropping unnecessary indexes, TKPROF, explain plan, DBMS_XPLAN, OEM Grid Control, hybrid columnar compression, partitioning, native compilation, direct load, avoiding single-row processing, and literally hundreds of other topics ... even reading the excellent books by Jonathan Lewis, Christian Antognini, Cary Millsap, and others ... and perhaps none of it would be relevant and perhaps all of it would be relevant.
There are not short cuts ... go to your manager, show him or her this thread, and ask for support in taking a class.
Some step that may increase the performance of your applications are:
Stop forcing your queries toward index path, Smart scan makes full table scan usually fly.
Start checking which queries might benefit from smart scan, and check out if you really do need all indexes attached to your tables (Exadata still have some issues to realize that full scan (smart scan) now it´s SOMETIMES better than index access.)