Developers and DBAs: can't we all just get along?
Sure we can!
We just have to break out of the old routine of
Developer: Hey, DBA, add twelve indexes to make my code run faster!
DBA: Hey, Developer, tune your code to make it run faster!
That is, finger-pointing.
Instead, we need to work together, and developers I am not the least big reluctant to say:
It's up to us, not the DBAs, to take the first steps.
So here are tips on what you, the developer, can do to foster a strong, collaborative and highly productive relationship with your DBA:
1. Ask your DBA for advice.
"I want to make my code run faster. What do you think I should do?" There's no better to improve a relationship than to show some humility and express interest in the opinions - and knowledge - of others.
2. Do the right thing.
Learn about the performance-related features of PL/SQL (and SQL) and apply them. Here are some links to help get started:
PL/SQL Optimization and Tuning (Doc)
High Performance PL/SQL Videos
SQL Analytics Videos by Connor McDonald
Introduction to Indexing Videos by Chris Saxon
3. Give your DBA a heads-up when your pattern of writing code changes.
Utilizing new and different features of PL/SQL can have a ripple effect on memory consumption and overall application performance. Don't blindside your DBA.
For example, you learn about executing "bulk SQL" from PL/SQL. So cool! So powerful! And potentially a big PGA memory suck, through the use of collections.
Or you discover the Function Result Cache. Another very exciting enhancement added in 11.1. "Hey, I'm going to add the RESULT_CACHE clause to 100 functions. So easy!" Yes, but you might kill overall database activity with latch contention.