When I use the Gird Control (GC) to gather the information from the
database. (the one that has an agent running on the same box)

Sometimes I monitor the performance from the performance tab of the
grid control and I see that the OMS process is responsible of the high
CPU usage.

username : DBSNMP
program : OMS

What do you advise me, to control the behavious of the GC.

It is not a performance problem but having not much control over this,
scares me.

newhorizon wrote:
> When I use the Gird Control (GC) to gather the information from the
> database. (the one that has an agent running on the same box)
>
> Sometimes I monitor the performance from the performance tab of the
> grid control and I see that the OMS process is responsible of the high
> CPU usage.
>
> username : DBSNMP
> program : OMS
>
> What do you advise me, to control the behavious of the GC.
>
> It is not a performance problem but having not much control over this,
> scares me.

What version? What hardware? What operating system? For how long a
period of time?
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

On Jul 6, 4:22 pm, newhorizon <mehmete...@gmail.com> wrote:
> When I use the Gird Control (GC) to gather the information from the
> database. (the one that has an agent running on the same box)
>
> Sometimes I monitor the performance from the performance tab of the
> grid control and I see that the OMS process is responsible of the high
> CPU usage.
>
> username : DBSNMP
> program : OMS
>
> What do you advise me, to control the behavious of the GC.
>
> It is not a performance problem but having not much control over this,
> scares me.


use the latest patchset (10.2.0.3) - there were improvements in lower
CPU utilitsation.

regards

stefan Kapitza

On Jul 6, 10:22 am, newhorizon <mehmete...@gmail.com> wrote:
> When I use the Gird Control (GC) to gather the information from the
> database. (the one that has an agent running on the same box)
>
> Sometimes I monitor the performance from the performance tab of the
> grid control and I see that the OMS process is responsible of the high
> CPU usage.
>
> username : DBSNMP
> program : OMS
>
> What do you advise me, to control the behavious of the GC.
>
> It is not a performance problem but having not much control over this,
> scares me.

Not a performance problem?

Probably submitting a service request is the best idea.

There's been a bunch of bugs in this product and maybe you are just
behind on applying some maintenance that would alleviate this.

It occurs on a single node of a 9.2 Cluster database.
The Version of the GC is (10.2.0.3).

It happens when I start to watch the performance of the cluster
database. When I open that page It starts to gather performance
events.
On 10G databases, the performance page automatically displays the past
data even if you are not watching the performance from that page.

I guess the absence of AWR on 9i has a great impact over the system.
Could It be possible ?

I guess I found something.

Grid Control runs the following query for every 3 or 4 seconds.

It executed 278 times in 70 min, took total 5 CPU seconds.

"SELECT s.sid, s.sql_address, s.sql_hash_value, sw.event, sw.p1,
DECODE(sw.wait_time, 0, 'W', 'C'), s.serial#, s.user#, s.program FROM v
$session s, v$session_wait sw WHERE s.sid = sw.sid;"

On Jul 10, 3:51 am, newhorizon <mehmete...@gmail.com> wrote:
> I guess I found something.
>
> Grid Control runs the following query for every 3 or 4 seconds.
>
> It executed 278 times in 70 min, took total 5 CPU seconds.
>
> "SELECT s.sid, s.sql_address, s.sql_hash_value, sw.event, sw.p1,
> DECODE(sw.wait_time, 0, 'W', 'C'), s.serial#, s.user#, s.program FROM v
> $session s, v$session_wait sw WHERE s.sid = sw.sid;"


I am experiencing similar situations. I have GC 10.2.0.2 on a seperate
machine from the host, so the only thing running on the host (other
than two databases) that the CPU is getting hammered is the management
agent. The host is running AIX5L and one 10.2.0.2 db, and one 9.2.0.5
db. Was there something that you did to control how ofter it executed
that statement?

I GUESS the issue is there is AWR on 10G but for 9i there is no
active session history because of that the grid control is simulating
the behavior of AWR.

You may see the performance tab in 10G is filled automatically. But
for 9i you have to keep the browser open at all times for the
performance tab to reflect the last 1 hour wait statistics.

---------Anyone has a solid proof or a metalink document for that
hypothesis.