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.





Comments

  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.

    ReplyDelete
  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.

    ReplyDelete
  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,
    Iudith

    ReplyDelete
  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.

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

    ReplyDelete
  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.

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

      Delete

Post a Comment

Popular posts from this blog

Quick Guide to User-Defined Types in Oracle PL/SQL

A Twitter follower recently asked for more information on user-defined types in the PL/SQL language, and I figured the best way to answer is to offer up this blog post. PL/SQL is a strongly-typed language . Before you can work with a variable or constant, it must be declared with a type (yes, PL/SQL also supports lots of implicit conversions from one type to another, but still, everything must be declared with a type). PL/SQL offers a wide array of pre-defined data types , both in the language natively (such as VARCHAR2, PLS_INTEGER, BOOLEAN, etc.) and in a variety of supplied packages (e.g., the NUMBER_TABLE collection type in the DBMS_SQL package). Data types in PL/SQL can be scalars, such as strings and numbers, or composite (consisting of one or more scalars), such as record types, collection types and object types. You can't really declare your own "user-defined" scalars, though you can define subtypes  from those scalars, which can be very helpful from the p

The differences between deterministic and result cache features

 EVERY once in a while, a developer gets in touch with a question like this: I am confused about the exact difference between deterministic and result_cache. Do they have different application use cases? I have used deterministic feature in many functions which retrieve data from some lookup tables. Is it essential to replace these 'deterministic' key words with 'result_cache'?  So I thought I'd write a post about the differences between these two features. But first, let's make sure we all understand what it means for a function to be  deterministic. From Wikipedia : In computer science, a deterministic algorithm is an algorithm which, given a particular input, will always produce the same output, with the underlying machine always passing through the same sequence of states.  Another way of putting this is that a deterministic subprogram (procedure or function) has no side-effects. If you pass a certain set of arguments for the parameters, you will always get

My two favorite APEX 5 features: Regional Display Selector and Cards

We (the over-sized development team for the PL/SQL Challenge - myself and my son, Eli) have been busy creating a new website on top of the PLCH platform (tables and packages): The Oracle Dev Gym! In a few short months (and just a part time involvement by yours truly), we have leveraged Oracle Application Express 5 to create what I think is an elegant, easy-to-use site that our users will absolutely love.  We plan to initially make the Dev Gym available only for current users of PL/SQL Challenge, so we can get feedback from our loyal user base. We will make the necessary adjustments and then offer it for general availability later this year. Anyway, more on that as the date approaches (the date being June 27, the APEX Open Mic Night at Kscope16 , where I will present it to a packed room of APEX experts). What I want to talk about today are two features of APEX that are making me so happy these days: Regional Display Selector and Cards. Regional Display Sel