Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 3169 invoked from network); 23 Dec 2006 04:58:42 -0600 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 23 Dec 2006 04:58:41 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 82E2E57B7A9; Sat, 23 Dec 2006 05:57:42 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09758-03; Sat, 23 Dec 2006 05:57:42 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id EA79457B834; Sat, 23 Dec 2006 05:57:41 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Sat, 23 Dec 2006 05:56:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 749E457B803 for ; Sat, 23 Dec 2006 05:56:37 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09394-01 for ; Sat, 23 Dec 2006 05:56:37 -0500 (EST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 8E9CE57B74D for ; Sat, 23 Dec 2006 05:56:36 -0500 (EST) Received: by ug-out-1314.google.com with SMTP id a2so3152410ugf for ; Sat, 23 Dec 2006 02:57:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=tpgihQ+IYtNFP+QmtBL6I0aPUsCkyQO0JZdb3xNSI4VxsnGkghYPV3fvs9rxbjev3oNUI4sJRwaopiV+kyZmYLDdNhlnip8tThHVlPOfVgJm287cVsr9qBrFMJZLijs+uRtTbltu2rSLCwgtTaMhnPR0Rxr8Ah2GyPTBxXUyz8Q= Received: by 10.78.185.15 with SMTP id i15mr72587huf.1166871454170; Sat, 23 Dec 2006 02:57:34 -0800 (PST) Received: by 10.78.124.5 with HTTP; Sat, 23 Dec 2006 02:57:33 -0800 (PST) Message-ID: <411d50f60612230257i3a38904fu59aa93cf512debc3@mail.gmail.com> Date: Sat, 23 Dec 2006 11:57:34 +0100 From: "Ghassan Salem" To: goodjobfastcar@gmail.com Subject: Re: Does anyone use 10gR2 Grid control for enterprise wide monitoring ? Cc: Oracle-L@freelists.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_61040_31743083.1166871454042" References: <56d3d5610612220342t5137f03ejb26ba6ce68c8682@mail.gmail.com> X-archive-position: 43656 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: salem.ghassan@gmail.com Precedence: normal Reply-to: salem.ghassan@gmail.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at avenirtech.net ------=_Part_61040_31743083.1166871454042 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Peter, when you setup the agent, it takes for timezone the default on your system. This does not have to be the same as the one on the OMS. It just has to be a supported timezone (list is a file called supportedtz.lst somewhere under sysman). If afterwards, by any manipulation, the default TZ of the machien was changed, then you have to reset the timezone of the agent (using emctl). If there is any TZ problem, you find a clue easily in emagent.trc, but I agree that it should tell you that you have a problem with the TZ instead of just hanging. rgds rgds On 12/23/06, Peter Smith wrote: > > People, > > I made some progress. > > I found a blog with a hint which probably fixed my problem: > > > http://www.dbazine.com/blogs/blog-cf/chrisfoot/blogentry.2005-09-17.7657940139 > > There is one other parameter in emd.properties that may cause a few > problems. If your agent NEVER successfully uploads data after > installation, check the TIMEZONE parameter in the emd.properties > file. It is usually the last parameter in emd.properties. When our > agent's time zones didn't match the time zone in the management > server's configuration file, we weren't able to establish a successful > connection between the agents and the management service. So if you > have agentTZRegion=America/New_York in the agent's emd.properties > file, you'll prevent a lot of headaches if you use the same time zone > in the management server's emd.properties configuration file. We don't > have any servers in different time zones, but there is a wealth of > information contained in the 10G Grid Control documentation to help > those that do. What I do know is that when the time zones didn't > match, we couldn't make a connection. > > > On my host, > the values for agentTZRegion did not match. > > For the agent I have this: > > agentTZRegion=US/Pacific > > For OMS I had this: > > agentTZRegion=GMT > > For OMS I now have this: > > agentTZRegion=US/Pacific > > After I made the changed I bounced oms with this: > > emctl stop oms > emctl start oms > > Then I bounced the agent. > > Then I did: > > > bash-3.1$ > bash-3.1$ > bash-3.1$ emctl upload agent > Oracle Enterprise Manager 10g Release 10.2.0.1.0. > Copyright (c) 1996, 2005 Oracle Corporation. All rights reserved. > --------------------------------------------------------------- > EMD upload completed successfully > bash-3.1$ > bash-3.1$ > > > That was encouraging. > > I checked status: > > > bash-3.1$ > bash-3.1$ > bash-3.1$ emctl status agent > Oracle Enterprise Manager 10g Release 10.2.0.1.0. > Copyright (c) 1996, 2005 Oracle Corporation. All rights reserved. > --------------------------------------------------------------- > Agent Version : 10.2.0.1.0 > OMS Version : 10.2.0.1.0 > Protocol Version : 10.2.0.0.0 > Agent Home : /usr/lib/oracle/xe/gc2/OracleHomes/agent10g > Agent binaries : /usr/lib/oracle/xe/gc2/OracleHomes/agent10g > Agent Process ID : 14275 > Parent Process ID : 14247 > Agent URL : https://ow2:3872/emd/main/ > Repository URL : https://ow2:1159/em/upload > Started at : 2006-12-22 18:22:44 > Started by user : oracle > Last Reload : 2006-12-22 18:22:44 > Last successful upload : 2006-12-22 18:23:18 > Total Megabytes of XML files uploaded so far : 0.68 > Number of XML files pending upload : 0 > Size of XML files pending upload(MB) : 0.00 > Available disk space on upload filesystem : 68.83% > Last successful heartbeat to OMS : 2006-12-22 18:22:47 > --------------------------------------------------------------- > Agent is Running and Ready > bash-3.1$ > bash-3.1$ > bash-3.1$ > bash-3.1$ > bash-3.1$ > > > Next, I went to the console page in the UI: > > http://ow2:4889/em/console/home > > My targets had reappeared! > > And I nosed around in alerts and found a bunch of > new alerts which had been bottled up in Agent alert queue. > > And I check my e-mail, and I had a bunch of new > e-mail alerts. > > So the smell of some progress is sweet. > > But... > I have no idea how this POS software ended up in this > hole and I don't have much of a clearer picture of how > it works. > > Anyway EM-GC is functioning in my lab and maybe it will > stay stable for another 10 minutes. > > ...Peter > http://GoodJobFastCar.com > > ------=_Part_61040_31743083.1166871454042 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Peter,
when you setup the agent, it takes for timezone the default on your system.
This does not have to be the same as the one on the OMS. It just has to be a supported timezone (list is a file called supportedtz.lst somewhere under sysman). If afterwards, by any manipulation, the default TZ of the machien was changed, then you have to reset the timezone of the agent (using emctl).
If there is any TZ problem, you find a clue easily in emagent.trc, but I agree that it should tell you that you have a problem with the TZ instead of just hanging.

rgds
rgds

On 12/23/06, Peter Smith <goodjobfastcar@gmail.com> wrote:
People,

I made some progress.

I found a blog with a hint which probably fixed my problem:

http://www.dbazine.com/blogs/blog-cf/chrisfoot/blogentry.2005-09-17.7657940139

There is one other parameter in emd.properties that may cause a few
problems. If your agent NEVER successfully uploads data after
installation, check the TIMEZONE parameter in the emd.properties
file. It is usually the last parameter in emd.properties. When our
agent's time zones didn't match the time zone in the management
server's configuration file, we weren't able to establish a successful
connection between the agents and the management service. So if you
have agentTZRegion=America/New_York in the agent's emd.properties
file, you'll prevent a lot of headaches if you use the same time zone
in the management server's emd.properties configuration file. We don't
have any servers in different time zones, but there is a wealth of
information contained in the 10G Grid Control documentation to help
those that do. What I do know is that when the time zones didn't
match, we couldn't make a connection.


On my host,
the values for agentTZRegion did not match.

For the agent I have this:

agentTZRegion=US/Pacific

For OMS I had this:

agentTZRegion=GMT

For OMS I now have this:

agentTZRegion=US/Pacific

After I made the changed I bounced oms with this:

emctl stop oms
emctl start oms

Then I bounced the agent.

Then I did:


bash-3.1$
bash-3.1$
bash-3.1$ emctl upload agent
Oracle Enterprise Manager 10g Release 10.2.0.1.0. 
Copyright (c) 1996, 2005 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
 EMD upload completed successfully
bash-3.1$
bash-3.1$


That was encouraging.

I checked status:


bash-3.1$
bash-3.1$
bash-3.1$ emctl status agent
Oracle Enterprise Manager 10g Release 10.2.0.1.0. 
Copyright (c) 1996, 2005 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
Agent Version     : 10.2.0.1.0
OMS Version       : 10.2.0.1.0
Protocol Version  : 10.2.0.0.0
Agent Home        : /usr/lib/oracle/xe/gc2/OracleHomes/agent10g
Agent binaries    : /usr/lib/oracle/xe/gc2/OracleHomes/agent10g
 Agent Process ID  : 14275
Parent Process ID : 14247
Agent URL         : https://ow2:3872/emd/main/
 Repository URL    : https://ow2:1159/em/upload
Started at        : 2006-12-22 18:22:44
Started by user   : oracle
Last Reload       : 2006-12-22 18:22:44
Last successful upload                       : 2006-12-22 18:23:18
Total Megabytes of XML files uploaded so far :     0.68
Number of XML files pending upload           :        0
Size of XML files pending upload(MB)         :     0.00
Available disk space on upload filesystem    :    68.83%
Last successful heartbeat to OMS             : 2006-12-22 18:22:47
---------------------------------------------------------------
Agent is Running and Ready
bash-3.1$
bash-3.1$
bash-3.1$
bash-3.1$
bash-3.1$


Next, I went to the console page in the UI:

http://ow2:4889/em/console/home

My targets had reappeared!

And I nosed around in alerts and found a bunch of
new alerts which had been bottled up in Agent alert queue.

And I check my e-mail, and I had a bunch of new
e-mail alerts.

So the smell of some progress is sweet.

But...
I have no idea how this POS software ended up in this
hole and I don't have much of a clearer picture of how
it works.

Anyway EM-GC is functioning in my lab and maybe it will
stay stable for another 10 minutes.

...Peter
http://GoodJobFastCar.com


------=_Part_61040_31743083.1166871454042-- -- http://www.freelists.org/webpage/oracle-l