It may also be pertinent to review note 1929003.1 and perhaps 1560526.1
that detail somewhat unexpected interaction between adaptive threshold
metrics introduced in 12.1.0.4 EM and server-generated alerts from previous
database versions. This is especially true if you also have or had db
console enabled for the databases in question.
Niall
On Wed, Dec 27, 2017 at 5:00 PM, Tim Gorman <tim.evdbt@xxxxxxxxx> wrote:
it is very hard for me to spend time to do that instead I would like toIdeally it maybe good to investigate why so many logins happening but
simply disable it.
Ashoke, my apologies for being blunt, but the previous sentence is one of
those occasions where one simply *must* ask, "Did I REALLY write that?"
This is the cry of a drowning person. Please allow the members of this
list to assist you? We cannot (and will not) do your job for you, but you
have several hundred collective years of experience on tap, and you have an
ideal opportunity to not only get your initial question answered, but
possibly also address root cause and take control of the situation.
Doubtless Kellyn has provided all the information you need to silence (at
least temporarily) the alerts. That resolves your initial problem.
Please do realize that the alerts you've just silenced are leverage for
you to take to your management for time to delve into root cause? Both
Oracle Enterprise Manager (i.e. vendor) and the contributors to this email
list are assuring you that more than 150 logons/sec is very bad, regardless
of what the vendor of the software causing this problem say (or don't say).
There was an earlier suggestion to use database auditing, but if the
initialization parameter AUDIT_TRAIL is set to NONE (which is often the
case), then you'll need to bounce the instance to change it. Even if
database auditing is already enabled, then the purported rate of logons
might swamp Oracle's auditing capability, or at least cause a noticeable
impact, so perhaps a less-intrusive way to being investigating might be
running a query similar to the following, which attempts to display which
USERNAME has created the most connections in the past 24 hours...
select (sysdate-logon_time)*86400 loggedon_secs, username, count(*)
cnt
from v$session
where (sysdate-logon_time) < 1
group by (sysdate-logon_time)*86400, username
order by loggedon_secs desc;
Once you find a probable USERNAME as the culprit, you could drill in
closer by filtering just for those sessions and checking another bit of
information, such as PROGRAM...
select (sysdate-logon_time)*86400 loggedon_secs, program, count(*)
cnt
from v$session
where (sysdate-logon_time) < 1
and username = 'BAD-USERNAME'
group by (sysdate-logon_time)*86400, program
order by loggedon_secs desc;
Of course, if you wish, start with PROGRAM and then perhaps drill down to
USERNAME? Or some other metric?
If you could run some queries like this and post the results back to the
list, we would appreciate it?
Hope this helps...
-Tim
On 12/27/17 08:40, Ashoke Mandal wrote:
Hi Kellyn, Jonathan,Mladen,Thank you all for the reply. Here are some
answer to some of your points.
I never had this type of flooding alerts in OEM 11g.
It is happening for each of my server(host) not from one ow two.
So I would like to disable this alert if there is an option.
Ideally it maybe good to investigate why so many logins happening but it
is very hard for me to spend time to do that instead I would like to simply
disable it.
Any further tips will be appreciated.
Ashoke
On Tue, Dec 26, 2017 at 3:49 PM, Jonathan Lewis <
jonathan@xxxxxxxxxxxxxxxxxx> wrote:
Ashoke,
The correct way to fix this problem is to find out what is logging on 146
times per second and stop it - it can't possibly be necessary and it's
probably having an appalling effect on the performance of the database. I'd
expect to see lots of time lost on library cache latch and dictionary cache
latch activity, probably with plenty of mutex sleeps as well and
"connection management" showing up with a significant (though relatively
small) amount of time in the Time Model report.
If you want to avoid too many messages flooding your inbox (until you've
fixed the important problem) create a rule that redirects the incoming
alert messages to a separate file based on the subject and some aspect of
the message content.
Regards
Jonathan Lewis
________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx> on
behalf of Ashoke Mandal <ramukam1983@xxxxxxxxx>
Sent: 26 December 2017 13:17
To: Kellyn Pot'Vin-Gorman
Cc: Mladen Gogala; ORACLE-L
Subject: Re: OEM 12c (12.1.0.5) generating too many alerts on Metrics
"Logons Per Sec"
Hi Kellyn, Here is the details of the alert. This alert is is coming too
many times and flooding my Inbox. Any help will be appreciated. Thanks,
Ashoke
Host=<Host_Name>
Target type=Database Instance
Target name=<DB_Name>
Categories=Load
Message=Metrics "Logons Per Sec" is at 149.676<https://gva04cn1.lau.m
edtronic.com:7800/em/redirect?pageType=sdk-core-event-consol
e-detailEvent&issueID=600D37F6B8350327E054001B2194CD2D>
Severity=Warning
Event reported time=Dec 26, 2017 6:02:38 AM MST
Operating System=SunOS
Platform=sparc
Associated Incident Id=2606<https://gva04cn1.lau.m
edtronic.com:7800/em/redirect?pageType=sdk-core-event-consol
e-detailIncident&issueID=613EE5C7DFBA26EDE054001B2194CD2D>
Associated Incident Status=New
Associated Incident Owner=
Associated Incident Acknowledged By Owner=No
Associated Incident Priority=None
Associated Incident Escalation Level=0
Event Type=Metric Alert
Event name=Server_Adaptive_Threshold_Metric:instance_throughput__l
ogons_ps
Metric Group=Server_Adaptive_Threshold_Metric
Metric=Cumulative Logons Per Sec<https://gva04cn1.lau.medtr
onic.com:7800/em/redirect?pageType=sdk-core-metric-details&
timePeriod=byDay&metric=Server_Adaptive_Threshold_
Metric&target=thdmas.dmas.medtronic.com&metricColumn=instanc
e_throughput__logons_ps&type=oracle_database&keyValue=SYSTEM>
Metric value=149.675702644271
Key Value=SYSTEM
Rule Name=MTC_MECC_DMAS Incident All Targets,Create incident for critical
metric alerts
Rule Owner=SYSMAN
Update Details:
Metrics "Logons Per Sec" is at 149.676
Incident created by rule (Name = MTC_MECC_DMAS Incident All Targets,
Create incident for critical metric alerts; Owner = SYSMAN).
On Mon, Dec 25, 2017 at 8:42 PM, Kellyn Pot'Vin-Gorman <
dbakevlar@xxxxxxxxx<mailto:dbakevlar@xxxxxxxxx>> wrote:
Can you please paste the alert you receive, editing out andy company Info
here? The alert contains the data to isolate the metric.
Thank you,
Kellyn
On Sun, Dec 24, 2017 at 2:16 PM Ashoke Mandal <ramukam1983@xxxxxxxxx
<mailto:ramukam1983@xxxxxxxxx>> wrote:
I have disabled the entire Throughput Metric (containing Cumulative
Logons Per Sec) but it doesn't help and still receiving too many alerts on
Metrics "Logons Per Sec".
I am still looking for help on how to turn off this alert.
Thanks,
Ashoke
On Fri, Dec 22, 2017 at 3:55 PM, Ashoke Mandal <ramukam1983@xxxxxxxxx
<mailto:ramukam1983@xxxxxxxxx>> wrote:
Hello Kellyn and Mladen, Thanks for your reply.
So far I found out Throughput Metric and that has Cumulative Logons Per
Sec. I have disabled the entire Throughput Metric and will see if that
stops this warning alert.
under Oracle Database -> Monitoring -> All Metrics -> Throughput
Ashoke
On Fri, Dec 22, 2017 at 1:14 PM, Mladen Gogala <gogala.mladen@xxxxxxxxx
<mailto:gogala.mladen@xxxxxxxxx>> wrote:
The most probable cause is having both OEM with Grid Control DB and a
local EM running.
Regards
On Fri, 22 Dec 2017 09:43:32 -0600
Ashoke Mandal <ramukam1983@xxxxxxxxx<mailto:ramukam1983@xxxxxxxxx>>
wrote:
Dear All,(12.1.0.5).
I have migrated some of our databases from OEM 11g to OEM 12c
It working OK but getting too many extra warning like this.ic.com> - Metrics "Logons Per Sec" is
EM Event: Warning:thdmas.dmas.medtronic.com<http://thdmas.dmas.medtron
at 105.409in
I would like to disable this but not able to locate the related metric
12c OEM console.area
I logged into the database via OEM 12C and checked under the following
but not able to find the Metrics "Logons Per Sec" .
Oracle Database -> Monitoring -> Metric and collection settings
Oracle Database -> Monitoring -> All Metrics
Any help will be highly appreciated.
Thanks,
Ashoke
--
Mladen Gogala
Oracle DBA
Tel: (347) 321-1217<tel:%28347%29%20321-1217> <%28347%29%20321-1217>
--
<http://about.me/dbakevlar>
[Kellyn Pot'Vin on about.me]
Kellyn Pot'Vin-Gorman
about.me/dbakevlar
--
//www.freelists.org/webpage/oracle-l
