RE: [External] : RE: OT- raw meat in these days of devops
Date: Fri, 21 May 2021 12:42:13 +0000
Message-ID: <SJ0PR10MB4686567302C545496D8801A3A3299_at_SJ0PR10MB4686.namprd10.prod.outlook.com>
Sql developer data modeler, supports Process Models and data flow diagrams…
From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> On Behalf Of Mark W. Farnham
Sent: Friday, May 21, 2021 8:31 AM
To: gogala.mladen_at_gmail.com; oracle-l_at_freelists.org
Subject: [External] : RE: OT- raw meat in these days of devops
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_at_freelists.org<mailto:oracle-l-bounce_at_freelists.org> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala
Sent: Thursday, May 20, 2021 5:23 PM
To: oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>
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:
- 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.
- 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.
- 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.
- 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.
- 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<https://urldefense.com/v3/__https:/dbwhisperer.wordpress.com__;!!GqivPVa7Brio!KTVGyKyyM3hfWsrbPl7I5L2XFW2RWGeZN2bxEKjHpHvZAYxb_W9hQMwgqlOQSdiOEr8$>
-- http://www.freelists.org/webpage/oracle-l<https://urldefense.com/v3/__http:/www.freelists.org/webpage/oracle-l__;!!GqivPVa7Brio!KTVGyKyyM3hfWsrbPl7I5L2XFW2RWGeZN2bxEKjHpHvZAYxb_W9hQMwgqlOQd9C_esk$>
--
http://www.freelists.org/webpage/oracle-l
Received on Fri May 21 2021 - 14:42:13 CEST