This is annoying when you are focusing on the new development projects approaching strict deadlines or working on production impacting issues. I get these nasty emails sometime myself. therefore you are not alone!! You don't have to be ashamed of writing bad queries, everyone has done it. The query that is optimized now can be a bad or worst performing queries in few months. Tuning a query is an ongoing process, not a one time deal.
My experience: DBA thinks developer wrote a poor query and they should fix their query, but tuning a query requires a joint effort from DBA and developers. They both need to utilize each other resources.
Developer can always make a case by saying the code running on production db for 2 yrs and nothing has been changed since then, can you tell me what has changed in your Database System? Similarly, DBA can always make a strong case. This is not about pointing fingers at each other, co-operating and providing all the changes made to the application helps DBA find the bottleneck. Similarly, DBA can also provide some recommendation along with the email helps the developer on where to focus on the queries.
I have compiled the list of tuning tips for both Developer and DBA. This will help you find the bottleneck of your queries not the database. The following list is by no mean in any order so feel free to choose the one that best fits your scenario, however I personally like to follow the steps one-by-one and has always worked in my favor.
What? My LOAD/INSERT is Freaking SLOW:
- Data Size: check if data file has increased significantly?
- Table Structure: Has table structure changed?
- Adding Indexes add load time as it has to load Indexes as well
- Similarly, constraints does add load time like Index
- Drop Index, load data and recreate Index - Loads faster.
- Use Bulk Index or use cursor to load data
- Minimum Logging on Destination table. (nologging, tablock, etc..)
- Research other loading utilities like export/import, bcp, SSIS, etc..)
- Parallel Execution of Insert Statements.
- Did that help?
- Understand the Query
- Run the execution Plan - Check of full table scan.
- Index use is less costly than full table scan (not always!!)
- Re-write query to use Index or add index where needed.
- Why table scan? not Index uses, or missing index?
- Re-write query to use index or create index.
- Table Stats & Index stats - are they current?
- Table/Index fragmentation, Rebuild Indexes.
- Use materialized view or Temp Table where needed.
- Run Tuning Adviser or Profiler for recommendations!
- Table Partitions
- Proper Indexing (Global vs local index) on Partitioned table
- Proper Indexing (clustered vs non-cluster index) - Sql Server
- Business Rule - Can you prune your table data?
- Research Table Dependencies and Impact on your query
- Use of Blind variable
- Proper Join on tables
- Union vs Union ALL.
- Pull only the columns that you need, NOT ALL
- Parallel Query Execution
- Make it Simple.
or your query is fully optimized!! I strongly encourage developer to check with DBA before implementing any changes.You can always look up online for examples of any steps presented here or you can email me and I will do my best to replay.
Interested in working with me? I can be reached at pbaniya04[at]gmail.com for any questions, consulting opportunities or you may drop a line to say HELLO. Thank your again for visiting my blog and looking forward to serving you more.
Have a Database-ious Day!
Have a Database-ious Day!
No comments