Re: Database Control vs. Grid Control

My 2cents are inline

On 3/30/07, Allen, Brandon <Brandon.Allen_at_oneneck.com> wrote:
>
> Hi List,
>
> I know there's already been a lot of discussion about Grid Control lately,
> but this is a different question that I couldn't find any discussion about
> on this list or anywhere else out on the web - my question is simply:
>
> Do I really need Grid Control (GC) or should I just use the individual
> Database Control (DBC)?
>
> If you're just managing one or two databases, then DBC is probably the way
> to go, but at what point does the overhead of installing and maintaining
> Grid Control begin to make sense? Certainy the answer will depend on the
> specifics of each environment, so here are the specifics of mine:
>

My thinking is that when there are more than one DB on a machine, it's better to have GC on another one to monitor these DBs.

I'll be running about fifty 10.2.0.3 databases (Std. Ed.) on a 3-node HPUX
> 11.11 cluster (HA/failover, not RAC). I don't plan to use any of the
> management packs (I can't even if I wanted to since it's Std. Ed.) so I'm
> only considering the base EM products in my decision.
>
> Here are my thoughts so far:
>
>
> 1. With GC, I'll have a single URL to go to for a consolidated view
> of all 50 databases vs. DBC where each database will have a separate URL.
>
>

And also you can create groups of dbs and have a better look at these groups

> 1. With GC, I'll need an extra database for the repository, but this
> can be consolidated with my rcat repository too. GC will have the overhead
> of the OMS and its repository database running on one node (unless I put it
> on a separate server of its own, but I'm hoping to avoid that), plus an
> agent on each of the 3 nodes. With DBC, I'll have the overhead of the Java
> processes, agents, host metric gathering &
> storage and everything else associated with DBC multiplied by each of my 50
> databases. I'm not really sure which configuration will cause the most
> overhead, but it seems to me that it would most likely be the 50 instances
> of DBC - any thoughts?
>
>

Surely one agent consumes less than a dbconsole (it does the same thing plus the interface , i.e. all the java things)

> 1. With my only other 10g database I'm using DBC on AIX 5.3 and I
> have problems occasionally with DBC not responding and then I have to
> restart it a few times before it starts working again. With 50 instances of
> DBC in this environment I'm afraid I could be constantly restarting the DBC
> processes. Maybe GC would be more stable?
>
>

It'll be surely more stable than several dbconsoles on the same machine

> 1. I have no experience installing & configuring GC, but from what
> I've seen on this list it seems to be quite a challenge to get it running
> properly, although it sounds like recent releases are significanly better
> than the early ones. Do I really need the extra headache?
>
>

My advice: if you have a 32bits machine, use linux and install 10.2.0.1 and immediately upgrade it to 10.2.0.3. If it's a 64bits machine install the x64 version (10.2.0.3 direct). I would not advise you install it on your db servers. use another machine.

> 1. For *database management only*, does GC provide any extra
> functionality over DBC other than just the consolidation of information from
> multiple databases? None that I know of but please enlighten me if I'm
> missing anything.
>
>

No

> 1. Is an Enterprise Edition database license required for running
> Grid Control? I don't see this stated anywhere in the 10.2 online
> docs, but it is mentioned on a slide from a 1-day seminar I attended a few
> months ago. I've opened an SR and am awaiting confirmation. This could
> make my decision for me.
>
>

You do not pay the licence for the repository db, and it is an EE (it has partitioning, ...)

Are there any other important factors I've failed to consider? Have any of
> you tried both DBC & GC and discovered any major benefits of one over the
> other (for database management only)?
>
> Thanks in advance for your time and thoughts.
>
> Regards,
> Brandon
>
>
> Privileged/Confidential Information may be contained in this message or
> attachments hereto. Please advise immediately if you or your employer do not
> consent to Internet email for messages of this kind. Opinions, conclusions
> and other information in this message that do not relate to the official
> business of this company shall be understood as neither given nor endorsed
> by it.
>

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