Re: DBA Job Functions

On 03/01/2018 02:39 AM, Dominic Brooks wrote:
> Many sudden “database is slow” incidents, in my experience, are SQL
> plan changes.

I agree 110%. This is especially true with 12CR1.

>
> I qualify these as database problems. Even though the data model and
> the way the SQL is written etc may be contributory factors and then we
> get into DBA semantics - “well it’s not an infrastructure DBA problem,
> it’s an application DBA problem”.
>

Semantics matters and it matters very much. And yes, most of the times the problem is in the data model. These days you rarely see fine art like creating IOT's for mostly read only tables (addresses, states, phone areas), clustering tables which are frequently queried together, joined on a specific key, hash clustering a single table to emulate partitioning, or using materialized views to speed up reports. Even uniform extent tablespaces are an increasing rarity. If you want plan stability, Oracle still supports outlines. They never change. And, of course, agile methodology and devops deserve honourable mentions because they usually produce useless data model which causes more problems than it solves. The daily scum meetings are not a replacement for the detailed peer review, which we did in OXHP, which has used SDLC, a methodology which qualifies as "waterfall" and is considered obsolete today. I have some war stories to tell about the agile methodology, but cannot since the main characters would probably recognize themselves and start threatening lawsuits. Suffices to say that one of the results of the "agile methodology" was the fact that there was a whole bunch of tables and functions in the SYS schema. I don't believe in witches, werewolves and database problems.

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217

--
http://www.freelists.org/webpage/oracle-l