RE: OEM justification -oem Poll
- From: "Michael Fontana" <MFontana@xxxxxxxxx>
- To: <mzito@xxxxxxxxxxx>, <BSpears@xxxxxxxxxxxxxxxxx>, <Joel.Patterson@xxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 28 Mar 2007 17:34:35 -0400
Well done, Matt. Even if slightly biased, I think you did a good
summarization on the top of using GC and other tools for monitoring.
I like to think of monitoring as an auditing function, in a sense, and I
question whether or not Oracle is going to necessarily expose it's own
poor housekeeping and software failures when reporting on their own
databases. I've already seen where they somehow will neglect to do so
if it's suits their interests.
I work in a large shop offering enterprise hosting to a myriad of
customers. Absolutely none of them are clamoring for GC. They want
things as simple as possible. It is probably an easy install in a lab,
but try getting it to run in the real world where servers are in
multiple physical locations seperated by firewalls and VPNs. That is
one of the major problems I encountered - problem is, when GC can't
report/install on a client, or when the client can't be "discovered"
from the GC host, there are practically NO TOOLS available from Oracle
to determine the problem. Even when you open an SR and it is figured
out, the process is not repeatable. I could go on and on about the
limits of GC, but I do agree that the free pieces are probably worth
looking into, especially if you've just moved into a shop and want a
good picture of the environment, and what needs fixing. But for
day-to-day monitoring of important systems with reliable information, I
would not even consider this product mature enough to be considered....
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Matthew Zito
Sent: Monday, March 26, 2007 1:30 PM
To: BSpears@xxxxxxxxxxxxxxxxx; Joel.Patterson@xxxxxxxxxxx;
oracle-l@xxxxxxxxxxxxx
Subject: RE: OEM justification -oem Poll
Well, speaking as a thoroughly biased software vendor whose product is
often compared to certain pieces of Grid Control, I have spent a fair
bit of time looking at Grid Control and working with customers who use
Grid Control, here's my .02:
- Grid Control is good at what it is free for (basic monitoring). Nice
graphs, useful pictures, good alerting, well done Oracle.
- For just about everything else, it varies wildly.
I've spoken to many customers who say that Oracle pushed Grid Control
heavily into their environment. Among people who have tried to
implement it, experiences have ranged from "couldn't get it to work,
oracle flew an engineer from corporate in, they spent a month, they
couldn't get it to work" to "worked great out of the box". It seems,
again, simply from the people I've talked to, that the diagnostic and
tuning packs work pretty well. The provisioning and configuration
management packs don't work at all (at least, never met anyone who has
successfully gotten them to work). Even in the 10gR3 Grid control,
provisioning and patching have huge swaths of issues.
In general, I think the big test should be - can you set up grid control
in your lab, get it working, and get all of the packs you're going to
spend money on working? Does it meet your needs? Are you better off
picking best of breed technologies for different areas?
Again, I'm biased - we make a automation, provisioning, patching, and
configuration management product for database environments. But none of
this is my opinion, its just based on what I've seen people doing in
different environments.
Matt
--
Matthew Zito
Chief Scientist
GridApp Systems
P: 646-452-4090
mzito@xxxxxxxxxxx
http://www.gridapp.com
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Spears, Brian
Sent: Mon 3/26/2007 11:18 AM
To: Joel.Patterson@xxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: OEM justification -oem Poll
I started the OEM poll and I will give a summary when I get a break in
work
load..
But in response to your question..
- OEM is great for proactivity
- OEM is great for scalable monitoring
- OEM is great for Rapid tuning and problem detection (the newest guy in
the
dba group can do it)
- OEM is great for helping with historical data growth
- OEM has a Waits Graph on system performance.(when u learn how to
use.You
can immediately spot issues)
- OEM is great for looking at impacts of historical
trends...cpu,disk,memory
We have hundreds of databases so it kicks butt in helping us be
proactive...
We could script most stuff..
But then you create something that is homegrown and not industry
supported.
Quite a few people have written some kick butt stuff and can manage
pretty
well without OEM for the basic stuff. But when it comes to it.. It wont
match oem for scalability..if it does.. You are just trying to create
your
own OEM.
OEM is quite extensible... It enables all kinds of time saving
options...
Examples: We set up oem accounts and oracle accounts in our databases
and
let others manage various repetitive duties like unlock account etc.
Nothing
to install.. Give them the link to point to and they are off. We have
too
much project load so we gave a limited access (one database with read
only
on their tables) to OEM to look at their own crappy sql and fix
it..(when
you are starving for time...this is a real breather)
We have been using OEM for years and everyday we get new ideas of how
OEM
can save us time.. Just put in OEM jobs in the scheduler to automate
bounceing/start/stop all dbs per server with hand off pages/emails to
various groups ( In larger companies ...this can be a nightmare... Unix
guys
wont let you hook the startups in the startup directories ) The OEM
scheduler is quite good ... And I see the technology improving in
quality
each release and that oracle is putting effort to make this a critical
management tool....FINALLY!
I find OEM like the Rabbit hole.. Mentioned in Matrix... You just never
know
when you reach the end of functionality.. I find a new screen everytime
I go
in... ( ya it suchs a bit on the user interface... Its not self
educating or
intuitive but one can manage)
It goes on and on... You can monitor the app/web servers as well as the
oracle database and know where the problem is coming from... Without
wasting
time...
There is some great features like comparing hardware setups to check for
differences.. Cloning dbs, patching dbs' with hook into Oracle metalink
do
down load patches etc. Could it be that they are they copying Microsoft
auto
patching (he he)?... I can see down the road this can create incredible
functionality and time saving.
Bottom line...
Does your company need to be that on top of issues? We get new databases
going in all the time so it really helps with problems of change. All
this
stuff takes some spin to do the benefit/cost proposal but
Personally after I was forced away from most of my scripting... I have
come
to respect and value it (although that took a few years...and still some
minor reservations).
If your company is not that big on proactivity and they pay great...
Drop me
a line! Part of why we got into it was the that company wanted to reduce
the
risk of all this dependancy of dba scripting and have an industry common
frame as well as vender supported.
Where do I get my check from Oracle?
Brian
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Joel.Patterson@xxxxxxxxxxx
Sent: Monday, March 26, 2007 8:33 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: OEM justification
I creating a justification for OEM. (Should I?)
The company used to license the packs for EM console, but stopped a year
ago. I want them to license OEM Grid. For what I guess is $40,000?
per 4 processor server? It would monitor 5 servers, 2 of them
development, (maybe more... especially if it were to be extended).
ADDR, Accounts for various activities... e.g. Refreshing Dev or Test
databases from OEM himself without DBA :) (cloning). Managers,
operations,
can see real time graphs of how the database is doing.
Jobs: RMAN backups, Tuning, and on and on.
What is the impact of Not having OEM. The databases will humm along
like normal for a couple more years... but?
Just Listing all the benefits can be over the top -- they would also
have to
understand... and overcome the hurtle posed by the fact that we are
doing
'fine' now -- aren't we?
Any feedback?
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
