Database Control vs. Grid Control
- From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 30 Mar 2007 10:52:47 -0700
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:
