nods. It’s been over a decade when I was surprised if a schema designer didn’t
know what a dataflow diagram was. Heck, it’s been over a decade since I was
surprised there was no schema designer!
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Mladen Gogala
Sent: Thursday, May 20, 2021 5:23 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: OT- raw meat in these days of devops
Once upon a time Bill Gates's SQL Server was sold with a pitch that the
database doesn't need an expensive DBA to run which supposedly made it much
cheaper than Oracle. As a consequence Larry Ellison started talking about the
diminished role of the DBA, all the while both products were quickly becoming
more and more complex. Today, nobody in the right mind would run a significant
SQL Server installation without a DBA. The same goes for Oracle RDBMS. However.
Oracle Corp. is still hostile toward the DBA personnel and is publishing less
and less internal information. And example are private redo threads, which are
not explained anywhere in the Oracle documentation. The only place with the
satisfactory explanations in Jonathan's "DBA Core" book. With Oracle 6, 7 and
8, redo allocation latches and redo copy latches, as well as the whole redo
process were well covered in both the documentation and the support white
papers. We were even modifying spin count for the copy latches. No such
internal information is published any longer.
There were several parallel developments which have poisoned the atmosphere
quite a bit:
1. Java became an industry standard and a myriad of "database neutral" MVC
frameworks like Hibernate and Spring sprang into existence. Those have created
the impression that the underlying database is not important. And those have
generated some ghastly SQL that is very hard to fix.
2. The whole idea of database neutral applications with all the business
rules being handled in the Java code instead of the database gave rise to buggy
monsters usually utilizing application servers like WebLogic, WebSphere or
JBoss to enforce the business logic. That leads to redundant code with the
business logic being enforced differently for the same tables.
3. Educational institutions in their rush to produce more and more
desperately needed Java programmers have neglected teaching the rules of good
design. I've seen the databases without foreign keys, triggers and with tables
with hundreds of columns, frequently duplicated. I was once told to no longer
ask interviewees about the 3rd normal form and the primary keys. Apparently,
Java programmers need not such obscure database stuff.
4. People are not taught the fundamentals of the operating systems that
run the databases. I have heard all kinds of ideas from the programmers. One of
the funnier was the suggestion to increase level of parallelism to 16 in order
to speed up the query. The VM running the database had only 4 virtual
processors.
5. Agile methodology accentuates the speed of development. Frequently,
there is not enough time to asses the performance and management is always
inclined to skip the performance assessment in order to make the artificial
deadlines. The resulting mess is left to the "reactive DBA".
Long story short, rambling about "reactive role" make no sense and further
contribute to the emergence of PHB like characters. Finally, about
grandchildren: my grandson is adorable, he looks just like me when I was a kid.
I am sure that many people on this list find me adorable.
On 5/20/21 11:06 AM, Mark W. Farnham wrote:
This thread is chock full of the divergent definitions of DBA that Oracle
VLDB and MOSES tried to wrap their hands around a while ago - before Codd's
twelve rules reached their silver anniversary.
Even before Codd's model, if the pre-design application functional goal and
architecture team didn't have a DBA to make sure the (IMS? Codasyl? HiSAM?
database structure) made sense, it was considered an amateur prototype. Now
THAT DBA was probably someone who had been a developer and/or sysprog for
half a decade, ran a team, was senior in the organization, but was offered
the chance to bring institutional knowledge to the technical efforts without
having to manage people.
Sigh. I should dredge up the definitions and job descriptions, but I'd
rather spend time with my grandchildren.
Anyway, most of the problems with being a DBA stem from a mismatch between
what a particular DBA thinks the current position duties are and what the
DBA managers think are the duties.
So talk to each other.
--
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
-- //www.freelists.org/webpage/oracle-l ;
