RE: OT- raw meat in these days of devops

Mladen - well said, as always.

You forgot -

                Oracle "forking" Linux, giving rise to "Engineered Systems" that are even more "locked down"

From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> On Behalf Of Mladen Gogala Sent: Thursday, May 20, 2021 2:23 PM
To: oracle-l_at_freelists.org
Subject: Re: OT- raw meat in these days of devops

CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.

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<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdbwhisperer.wordpress.com%2F&data=04%7C01%7Cclay.jackson%40quest.com%7C64d3fa75914547ee372908d91bd58e21%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637571426308489505%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Os0sIBiTYCGtYmmdPxbofWoIq7FLgIBePsHi0%2Bzi9X8%3D&reserved=0>
-- http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Thu May 20 2021 - 23:54:52 CEST