Re: Grid Control - opinions please

Here, here Daniel. I'm beating my head on my desk trying to get simple jobs scheduled that in 9i were simple. Small example - 9i - there was a drop list of 'types' of jobs you wanted to run or combine together for 1 job. I wrote a procedure for rman backups - takes certain parms and builds the script based on what you pass into it and writes it to the filesystem via an Oracle directory. I had 2 steps in a job in 9i, one to execute the proc and another that was an 'rman' task that ran rman using the script created in step 1. Very simple and straightforward, I'm NOT a windows guy and this place uses OEM so I wanted to continue what they started.

Upgraded to 10g and 'grid control' - if you've read any of my other recent postings about the job scheduler you'll see the pain I'm going through. GC removed what was so convenient in 9i. So I built a small perl script to call through an external program and have spent numerous hours trying to get that to work through GC.

IMHO - 9i OEM was much better on a lot of fronts than GC. GC gives you other 'control' though, assuming you can navigate the console to find what you're looking for.

Brian S. Wisniewski
Sr. Oracle Database Administrator
Central Technology Infrastructure & Operations brian.x.wisniewski_at_jpmchase.com
Cell: 614.975.2905

Daniel Fink <danielwfink_at_yahoo.com>
Sent by: oracle-l-bounce_at_freelists.org
04/05/2006 06:50 PM
Please respond to danielwfink  

        To:     Oracle-L Freelists <oracle-l_at_freelists.org>
        cc: 
        Subject:        Re: Grid Control - opinions please

I've used OEM on and off since 7.2, though not enough to qualify as an 'expert' (or even mid).

The version of OEM in 9 I found to be pretty good. The basic functions for administration are pretty good. It has been very handy when putting together tasks to clean up databases. I recently worked with one client who used it extensively for most of the routine dba work (their dba was spread pretty thin and the Oracle db was low priority). In working with jobs and alerts, the functionality was decent, but the documentation was geared more toward a java programmer than a good ol' command line dba
(that is my excuse and I am sticking to it).

So...why blather on about OEM when the question is about GC...because I have not found GC to be better than OEM for even the basic functions. The first installation for my personal playdatabase on WinXP was less than stellar. Perhaps I had grown too familiar to the OEM interface, but I found it more difficult to find the basic task areas. On Win2k, it caused the boot time to increase and would often throw errors, so I removed 10g completely and reinstalled without GC. Much better.

GC version 1 took away alot of custom reporting. It is supposed to be added back in v2, but that version is not available for all platforms
(last I checked). We have also had a lot of minor problems getting it to
work properly on HP.

All in all...I had become a fan of OEM for most day to day stuff I would do for operations support. I'm not impressed with GC.

Daniel Fink

Jared Still <jkstill_at_gmail.com> wrote:

Well, is that subject a loaded question, or what?

Background: I have never used OEM.

Well, I have actually, but only long enough to try it and discard it because I didn't like it too much.

I've been told that GC is completely re-written and a much better product than OEM. What I want to find out is if there is some community concensus to back up that claims.

Let's assume none of the add-on packs ($$$$) will be used, and RAC is not involved.

What does GC bring to the table that is worthwhile in your opinion?

I was also told that GC could be used to (easily?) download and apply Critical Patch Updates. Maybe not quite automated, but simplified at least. Has anyone experienced that?

It was also stated that this beast would require 8Gig of RAM, which seems rather excessive.

TIA,

-- 
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist




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