Re: DBA Job Functions

From: Kenny Payton <k3nnyp_at_gmail.com>
Date: Wed, 28 Feb 2018 22:34:45 -0500
Message-Id: <ABB27E55-F105-4F70-9969-A6AB683F7AB9_at_gmail.com>



Hah,

The network teams are fighting back. Have you seen Tetration? Network stats down to the PID tracked historically in an analytics engine. Very interesting from a compliance and policy enforcement standpoint but on the surface seems also to be a great tool for complex network troubleshooting

No disclaimer necessary….

Kenny

> On Feb 28, 2018, at 10:10 PM, Mladen Gogala <gogala.mladen_at_gmail.com> wrote:
> 
> Jeremy, it never is a database problem. You can always blame network. Try as they may, network  engineers can never prove their innocence. If an application is slow, it's always the network. Application service can't reach the database and you can always show "waiting for more data from the client" wait events to prove that your network is slow. The next in line are system administrators. Is that app server swapping? How much CPU is it using? The art of being a good DBA involves knowing how to find the appropriate culprit.
> 
> Joking aside, it really never is a database problem. What is slow is always an application, not the database. Database is just storage, nothing else. It's not the garage it's slow. When I was a DBA, I once got the following complaint: "the database is slow in the northern half of the sales room, but is fast in the southern half".  This intrigued me so much that I accepted the claim that "the database is slow". What ended up being the problem was the router. The router for the northern part of the room was plugged in the router port that was blinking red. 
> 
> You always start troubleshooting from the application. That is the lesson from the Cary Millsap's book. It's simply incredible how long it takes for that simple and obvious message to sink in.
> 
> 
> On 02/28/2018 02:58 PM, Sheehan, Jeremy wrote:

>> HAHAHAHA! #truth
>>
>> Perhaps proving that it isn’t a database problem can be added to the list?
>>
>> From: Jared Still [mailto:jkstill_at_gmail.com <mailto:jkstill_at_gmail.com>]
>> Sent: Wednesday, February 28, 2018 2:52 PM
>> To: Sheehan, Jeremy <JEREMY.SHEEHAN_at_fpl.com> <mailto:JEREMY.SHEEHAN_at_fpl.com>
>> Cc: oracle-l-freelist <oracle-l_at_freelists.org> <mailto:oracle-l_at_freelists.org>
>> Subject: Re: DBA Job Functions
>>
>> CAUTION - EXTERNAL EMAIL
>>
>> Also included: everything the DBA cannot get someone else to do.
>>
>>
>> Jared Still
>> Certifiable Oracle DBA and Part Time Perl Evangelist
>> Principal Consultant at Pythian
>> Pythian Blog http://www.pythian.com/blog/author/still/ <http://www.pythian.com/blog/author/still/>
>> Github: https://github.com/jkstill <https://github.com/jkstill>
>>
>>
>> On Tue, Feb 20, 2018 at 11:18 AM, Sheehan, Jeremy <JEREMY.SHEEHAN_at_fpl.com <mailto:JEREMY.SHEEHAN_at_fpl.com>> wrote:
>> Hello Guru’s,
>>
>> My boss is asking me to compile a list of typical job functions for a DBA. I came up with a brief list, but would like to hear any other recommendations that you might have. What he said was, “We don’t want to go into great detail, but not be too vague either. Somewhere between the 10,000ft and 1,000ft view.
>>
>> Agile Work
>> Backup/Recovery
>> Change Deployment
>> Database Design
>> Database Install
>> Documentation
>> DR Activities (testing/maintenance)
>> Lifecycles
>> Performance Tuning/Monitoring
>> Scripting DB/Host
>> Solution Design
>> On-call/Operations
>>
>> Thanks in advance,
>>
>> Jeremy
>>
> 
> -- 
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217


--
http://www.freelists.org/webpage/oracle-l
Received on Thu Mar 01 2018 - 04:34:45 CET

Original text of this message