Fwd: EM 13, CC12 agent use shared server connection

adding the list back in
---------- Forwarded message ----------
From: Niall Litchfield <niall.litchfield_at_gmail.com> Date: Tue, Nov 1, 2016 at 3:06 PM
Subject: Re: EM 13, CC12 agent use shared server connection To: Fernando Andrade <correo_at_fjandrade.com>

What does lsnrctl services tell you about the handlers for the db services

On Tue, Nov 1, 2016 at 1:57 PM, Fernando Andrade <correo_at_fjandrade.com> wrote:

> Thanks Niall
>
>
>
> I have to check if the database is configured for shared servers for
> default, thanks for the tip.
>
> I have walk through doc 1415999 and I see a lot of contention for having
> only two dispatchers
> and not enough shared server but I was looking for a workaround since any
> minimal change on this database takes months!
>
> So I was thinking on forcing the agent on dedicated connection but
> couldn’t find the connection string anywhere.
>
>
>
> Now I have to figure out why the agents are connecting via shared server
> if this is not the normal behavior.
>
>
>
> FJA
>
>
>
> *From: *Niall Litchfield <niall.litchfield_at_gmail.com>
> *Date: *Tuesday, November 1, 2016 at 5:32 AM
> *To: *<correo_at_fjandrade.com>
> *Cc: *ORACLE-L <oracle-l_at_freelists.org>
> *Subject: *Re: EM 13, CC12 agent use shared server connection
>
>
>
> Cloud Control doesn't use shared servers as far as I'm aware, see below is
> relevant cluster wide summary from one of our busy (well we think so) RAC
> databases. There are no virtual circuit waits and the shared server stats
> are zero in each of the individual AWR reports. I imagine it is possible
> that your database is configured to default connections to shared server,
> in which case you should work through doc *1415999.1* to see what is
> going on. Usually, insufficient shared servers and/or long running queries.
>
>
>
> Obviously, you haven't shared your troubleshooting up to now but it at
> least appears to be based on "I can only touch certain things, so I must
> use them" rather than "what's the root cause, how do we address this".
>
>
> Top Timed Events
>
> - Instance '*' - cluster wide summary
> - '*' Waits, %Timeouts, Wait Time Total(s) : Cluster-wide total for
> the wait event
> - '*' 'Wait Time Avg (ms)' : Cluster-wide average computed as (Wait
> Time Total / Event Waits) in ms
> - '*' Summary 'Avg Wait Time (ms)' : Per-instance 'Wait Time Avg (ms)'
> used to compute the following statistics
> - '*' [Avg/Min/Max/Std Dev] : average/minimum/maximum/standard
> deviation of per-instance 'Wait Time Avg(ms)'
> - '*' Cnt : count of instances with wait times for the event
>
>
>
> *Wait*
>
> *Event*
>
> *Wait Time*
>
> *Summary Avg Wait Time (ms)*
>
> *I#*
>
> *Class*
>
> *Event*
>
> *Waits*
>
> *%Timeouts*
>
> *Total(s)*
>
> *Avg(ms)*
>
> *%DB time*
>
> *Avg*
>
> *Min*
>
> *Max*
>
> *Std Dev*
>
> *Cnt*
>
> *
>
>
>
> DB CPU
>
>
>
>
>
> 17,147.51
>
>
>
> 67.46
>
>
>
>
>
>
>
>
>
> 5
>
> *
>
> User I/O
>
> db file sequential read
>
> 2,031,886
>
> 0.00
>
> 4,326.97
>
> 2.13
>
> 17.02
>
> 2.81
>
> 1.64
>
> 5.05
>
> 1.34
>
> 5
>
> *
>
> Network
>
> TCP Socket (KGAS)
>
> 10,054
>
> 17.83
>
> 1,195.31
>
> 118.89
>
> 4.70
>
> 795.90
>
> 90.69
>
> 1501.11
>
> 997.32
>
> 5
>
> *
>
> Application
>
> enq: TX - row lock contention
>
> 103,261
>
> 98.41
>
> 556.98
>
> 5.39
>
> 2.19
>
> 6.09
>
> 2.93
>
> 12.66
>
> 4.50
>
> 5
>
> *
>
> System I/O
>
> log file parallel write
>
> 859,360
>
> 0.00
>
> 373.79
>
> 0.43
>
> 1.47
>
> 0.47
>
> 0.42
>
> 0.63
>
> 0.09
>
> 5
>
> *
>
> Cluster
>
> gc cr grant 2-way
>
> 1,326,083
>
> 0.00
>
> 330.21
>
> 0.25
>
> 1.30
>
> 0.25
>
> 0.24
>
> 0.26
>
> 0.01
>
> 5
>
> *
>
> Cluster
>
> gc current block 3-way
>
> 716,855
>
> 0.00
>
> 261.36
>
> 0.36
>
> 1.03
>
> 0.36
>
> 0.35
>
> 0.37
>
> 0.01
>
> 5
>
> *
>
> System I/O
>
> db file parallel write
>
> 461,612
>
> 0.00
>
> 175.81
>
> 0.38
>
> 0.69
>
> 0.40
>
> 0.29
>
> 0.53
>
> 0.09
>
> 5
>
> *
>
> Cluster
>
> gc buffer busy acquire
>
> 213,927
>
> 0.00
>
> 156.68
>
> 0.73
>
> 0.62
>
> 0.75
>
> 0.51
>
> 0.98
>
> 0.17
>
> 5
>
> *
>
> Cluster
>
> gc current block 2-way
>
> 614,304
>
> 0.00
>
> 136.19
>
> 0.22
>
> 0.54
>
> 0.23
>
> 0.22
>
> 0.25
>
> 0.01
>
> 5
>
>
>
>
>
>
>
> On Mon, Oct 31, 2016 at 5:33 PM, Fernando Andrade <correo_at_fjandrade.com>
> wrote:
>
> Hi listers.
>
> Maybe someone had this issue before and can bring me some light.
>
>
>
> I have two OEM, one EM 13 and other Cloud Control 12.
>
> Both of them connects via shared server to the database no matter what,
> since this is a heavy transactional RAC
> the virtual circuit wait event rise high and is the main wait event in the
> database.
>
> When I put both OEM to work ( I´m migrating from 12c to 13c) the Virtual
> Circuit wait sky rocket.
>
> I tried to fix this adding “(SERVER=DEDICATED )” just before de service
> name on the connection string in the monitoring
> and updating the agents for both EM13 and CC12 but this isn’t working. The
> agent keeps connecting via shared server.
>
>
>
> I can´t touch this database, so I can´t raise the shared pool/buffer cache
> or do other tuning in the database, I have to
> change the connection string, but I don´t find where in the agent software
> is this.
>
>
>
> EM 13.2.0.0 on RH 6.x Linux64 -> all clients RH 6.x, BDD 11.2.0.3.X ->
> agent 13.2.0.0
>
> EM 12.1.0.5 on RH 5.x Linux64 -> same clients -> agent 12.1.0.5
>
>
>
> Thanks for your time.
>
>
>
> FJA
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info



-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

--
http://www.freelists.org/webpage/oracle-l