Pythian Group

No, not that kind of trigger this time around… :)

Anyone can fall into this scenario.  Everyone is carefully taking time to test before applying a couple patches to address an async I/O issue in Oracle to ensure all testing environments are exact, all patching is approved by everyone that would like to review it.  No one is willing to pull this trigger and apply the patches until they are absolutely sure they have every SQL statement, every network tweak, every application scenario looked over and over again.

Suddenly, the database reaches what every DBA dreads- that threshold where standard processing is now in the range of the I/O bug, not once a month but multiple times a week due to one or two queries that are pivotal to production processing.  The good intentions, hoping to avoid a production outage has now inadvertently caused them.   The customer is frantic, (as expected) and you, as the DBA, are the one quickly expected to assess the situation and attempt to come up with a battle plan.
Read the rest of this entry . . .

Undoubtedly, the database performance specialist upon first meeting a customer will be told, “but this database functioned great for the first five years and it’s slowed down to a grinding halt at year ten – why??”

As the specialist, you now have to carefully take the time, explaining in layman’s terms, that the natural life of a database is growth and although the pants you bought your child may have fit him wonderfully when he was five years old, he wouldn’t be moving too well in them at the age of ten, either… (We’ll discuss that high-maintenance dry-clean only, misshapen, hand-knitted sweater from Aunt Developer Deena a bit later, but we do want to take this slowly…)
Read the rest of this entry . . .