RE: Database Control vs. Grid Control

My 2 cents... (some already covered).

1. Grid Control works fine against Standard Edition (no special licensing or anything for basic usage). You do not require a DB license for the embedded database that comes with GC (even though technically it is an EE version) as long as that database is just used for GC.
2. If you have more than a couple of DB's GC over DC is a no brainer (much less overhead in both CPU and disk usage, one URL).
3. The general reason you put GC on a separate server from the DB's is that it's not a good idea to have a monitoring solution live on the same server as what it is monitoring. If you already have plenty of monitoring solutions and just want GC/DC for its administration/tuning abilities, then it's not a big deal.
4. Even if you don't use either GC or DC, if you plan to access any of the 10G tuning/diagnostic views (i.e. DBA_HIST_*, V$ACTIVE_SESSION_HISTORY, etc...) then you are supposed to buy a license for the Diagnostics pack. However, there is contradictory documentation that says the Management packs are only valid for EE versions of the database. Don't know what that implies really. Does that mean you can use the views in an SE DB or does it mean that if you DO use the views than you should be paying for an EE license? (only Oracle will tell)

Wayne

Wayne Adams Consulting
www.wayneadamsconsulting.com

RE: Database Control vs. Grid Control
. From: "Bryan Thomas" <bthomas_at_xxxxxxxxxxxxxx>
. To: <Brandon.Allen_at_xxxxxxxxxxx>, <oracle-l_at_xxxxxxxxxxxxx>
. Date: Fri, 30 Mar 2007 15:36:56 -0500

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_at_xxxxxxxxxxxxx [mailto:oracle-l-bounce_at_xxxxxxxxxxxxx] On Behalf Of Allen, Brandon
Sent: Friday, March 30, 2007 12:53 PM
To: oracle-l_at_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

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