RE: Database Control vs. Grid Control

I have discovered, while performance tuning, that the DBC can take a
significant percentage of the DB server's CPU - up to 30%.  I do not think
it is ever advisable to keep the DBC up and running all the time.

 

This is based on my personnel experience.  Maybe others on this list can
verify this.

 

Thanks,

Bryan 

 

Bryan Thomas

Senior Consultant and Practice Manager

Performance Tuning Corporation

www.perftuning.com <http://www.perftuning.com/> 

 

 

  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Allen, Brandon
Sent: Friday, March 30, 2007 12:53 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Database Control vs. Grid Control

 

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:

 

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. 
2.      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? 
3.      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? 
4.      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? 
5.      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. 
6.      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.

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.

Other related posts: