It is sometimes the Database, it is sometimes the responsibility of the DBA.
With proper instrumentation at all levels you can determine this. With
proper instrumentation on the DB level, you can sometimes rule it out.
I realise it was probably tongue-in-cheek but just because some sessions
are waiting on sql*net... doesn’t mean there’s a problem with the network
OR that there’s NOT a problem on the DB end. Unless you’ve associated the
sessions doing the sql*net wait with the end user call, it’s just a red
herring. These red herrings are common in systems not properly
instrumented.
Funnily enough, we’re currently having problems with our Goldengate
replicat process (seemingly) randomly hanging on sql*net more data from
client while it is trying to query the data dictionary. Not a DB problem
but a DBA problem, possibly a network issue but probably more likely an
application bug.
On Thu, 1 Mar 2018 at 07:40, Dominic Brooks <dombrooks@xxxxxxxxxxx> wrote:
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 ;<jkstill@xxxxxxxxx>]
*Sent:* Wednesday, February 28, 2018 2:52 PM
*To:* Sheehan, Jeremy <JEREMY.SHEEHAN@xxxxxxx> <JEREMY.SHEEHAN@xxxxxxx>
*Cc:* oracle-l-freelist <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
