Skip to main content

Tips for getting along with your DBA

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.


  1. In theory this is nice. But unfortunatly the real world is different.

    In the real world large companies have outsourced there DBAs to another consulting firm. This consulting firm has outsourced the database support to bangladore or some other IT capital.

    The DBAs there have no idea anymore what the original system is about and can only run scripts without giving advise. They are only paid to close tickets and not to create better database applications. I do not blame them. I blame the management of the company that decided to outsource their DBA knowledge in the first place.

    The only place where Developers and DBAs can still work hand in hand and everbody can have good expertise is mid sized companies or the ones in the IT industry.

  2. Thanks for these insights, Sven. Yes, with such a configuration (whether DBAs are outsourced to another firm or simply off in some other division of the company), collaboration becomes really hard.

  3. Hello All,
    I just waited for someone else to start commenting on this ...

    In my late company, though the DBA was not outsourced, its activity was
    mostly related to database installations, upgrades, patches, clones,
    backup, deployment and so on.
    They did not have effective knowledge of the applications beyond
    their indirect involvement, because the DBA team was the only
    one allowed to deploy application changes in production.

    At most, they sometimes took emergency actions to solve urgent performance problems, but at the database level only, without deeper involvement in the application logic or data knowledge.

    It was NOT a proper hand-in-hand working with the developers.

    Working hand-in-hand requires a full familiarity with the application logic and data characteristics, and it requires sitting together and thinking together, and this was not the case.

    Each side had its own "ticking clock" and urgent tasks.

    Regarding outsourcing, I think that the development side had a much higher "chance" to be outsourced than the DBA side.
    Therefore, for some reason, the DBA team was held on a "much higher esteem" than the developers ...

    In my strange position as a "full heart" developer,
    but "officially" belonging to the DBA team,
    I can only be sorry that this was the case :(

    By the way, the "black and white" children in the picture do tell the story ... it only remains to be specified who is who ...

    Thanks a lot & Best Regards,

  4. Steven, you're so right! Once I had a work in company, where they chose exactly that way to work, and it was great! There's nothing impossible, just when you don't know how to do something right, or are in doubt whether to pick up this strategy, you just go to some of DBA and discuss it. Our DBA team was very experienced, not in application logic, but in Oracle, so we always solved our problems together. That way most 'for loops' were rewritten to bulks, we started to use result cache and scalar subquery caching instead of marking some undeterministic function as DETERMINISTIC just to improve performance of one query.
    And thank you, Steven, that you help to create better solutions.

  5. Dmitry, thanks for taking the time to share your experience. It is nice to hear a positive story.

  6. So I'm one of the lucky guys :-)

    At our company there's a cafeteria where admins and developers meet each day at 9 o'clock for small talk and if you have a problem you will find all the experts there. Pro's an Con's of new features, security aspects, different viewpoints: nothing is done surreptitiously but usually it is smoother to talk about the 'how to' before going the official way.

    Most important is that this is an informal meeting. Whenever there is no technical problem we talk about family, movies, whatever. IMHO it's much easier to handle problems if you know each other well.

    1. What a great idea, thanks for sharing. I hope it will inspire others to do the same.


Post a Comment

Popular posts from this blog

Get rid of mutating table trigger errors with the compound trigger

When something mutates, it is changing. Something that is changing is hard to analyze and to quantify. A mutating table error (ORA-04091) occurs when a row-level trigger tries to examine or change a table that is already undergoing change (via an INSERT, UPDATE, or DELETE statement). In particular, this error occurs when a row-level trigger attempts to read or write the table from which the trigger was fired. Fortunately, the same restriction does not apply in statement-level triggers. In this post, I demonstrate the kind of scenario that will result in an ORA-04091 errors. I then show the "traditional" solution, using a collection defined in a package. Then I demonstrate how to use the compound trigger, added in Oracle Database 11g Release1,  to solve the problem much more simply. All the code shown in this example may be found in this LiveSQL script . How to Get a Mutating Table Error I need to implement this rule on my employees table: Your new salary cannot be mo

How to Pick the Limit for BULK COLLECT

This question rolled into my In Box today: In the case of using the LIMIT clause of BULK COLLECT, how do we decide what value to use for the limit? First I give the quick answer, then I provide support for that answer Quick Answer Start with 100. That's the default (and only) setting for cursor FOR loop optimizations. It offers a sweet spot of improved performance over row-by-row and not-too-much PGA memory consumption. Test to see if that's fast enough (likely will be for many cases). If not, try higher values until you reach the performance level you need - and you are not consuming too much PGA memory.  Don't hard-code the limit value: make it a parameter to your subprogram or a constant in a package specification. Don't put anything in the collection you don't need. [from Giulio Dottorini] Remember: each session that runs this code will use that amount of memory. Background When you use BULK COLLECT, you retrieve more than row with each fetch,

Working With JSON Arrays in PL/SQL

Oracle Database 12c Release 2 built upon the 12.1 SQL/JSON features by adding a number of builtin object types (similar to classes in object-oriented languages) for manipulating JSON data in PL/SQL blocks. In this post, I explore some of the array-oriented JSON features, all made available through the JSON_ARRAY_T type and its methods. Just like a class, an object type offers a pre-defined constructor function to instantiate new instances of that type, static methods and member methods. Here are the methods you are most likely to use: A couple of things to remember, generally, about working with JSON elements generally and JSON arrays specifically in PL/SQL: Error Handling Behavior By default, if an error occurs when you call a member method for your JSON array (or object), NULL is returned. In other words, an exception is not  raised back to your block. If you want errors to be propagated from the method as an exception, call the ON_ERROR method and pass a value greate