There is really quite a good laundry list on Oracle ScratchPad of things to
check when “nothing changed.” Sometimes a quick look at the list yields a quick
“Oh, that’s what happened” experience.
And of course profiling some particular session that is slower than expected is
the effective way to be sure what is wrong. Whether that leads to an obvious
fix or not is another issue, but at least you won’t find yourself working on
things that are definitely NOT the problem.
mwf
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Sheehan, Jeremy
Sent: Thursday, March 01, 2018 9:02 AM
To: dombrooks@xxxxxxxxxxx; gogala.mladen@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: DBA Job Functions
I agree 100% with this. Many times it is related to a change in execution
plans. In those situations I will go ahead, troubleshoot, and fix. More often
than not (in my situations), it is lazy application support teams that don’t
want to begin troubleshooting on their end first. Most of the time (with the
applications that I support), when application teams come to me the database is
sitting mostly idle or with little to know more activity than it would normally
have.
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Dominic Brooks
Sent: Thursday, March 1, 2018 2:40 AM
To: gogala.mladen@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: DBA Job Functions
Many sudden “database is slow” incidents, in my experience, are SQL plan
changes.
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”.
Experience also shows that it is rarely the network and rarely the storage,
etc. Sometimes it is.
Sent from my iPhone
On 1 Mar 2018, at 03:52, Mladen Gogala <gogala.mladen@xxxxxxxxx> 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@xxxxxxxxx] ;
Sent: Wednesday, February 28, 2018 2:52 PM
To: Sheehan, Jeremy <mailto:JEREMY.SHEEHAN@xxxxxxx> <JEREMY.SHEEHAN@xxxxxxx>
Cc: oracle-l-freelist <mailto:oracle-l@xxxxxxxxxxxxx> <oracle-l@xxxxxxxxxxxxx>
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/ ;
<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pythian.com%2Fblog%2Fauthor%2Fstill%2F&data=02%7C01%7C%7Ca9becef89c7f4c17644d08d57f27d1ab%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636554731355511391&sdata=fPB616KiFHWP2Shmk4W4WWP%2Bu3554ukoEJxZCZmYK7A%3D&reserved=0>
Github: https://github.com/jkstill ;
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjkstill&data=02%7C01%7C%7Ca9becef89c7f4c17644d08d57f27d1ab%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636554731355511391&sdata=jEQ5k82aTYc5qibdlgiFDsiJtlZ2%2BoGUx5MS6O1tA9g%3D&reserved=0>
On Tue, Feb 20, 2018 at 11:18 AM, Sheehan, Jeremy <JEREMY.SHEEHAN@xxxxxxx>
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
