A quick Summary about OEM

The computer application Enterprise Manager (OEM or EM, EM is more appropriate) aims to manage
software produced by Oracle Corporation as well as by some non-Oracle entities.
The latest version of the Oracle database in production today is Oracle 12.x

Back in the days , OEM used a fat client but this was phased out around the Oracle 8i / 9i timeframe -
like back in the old Quest Central days ( if anyone ever remember us having that product ).

The replacement was called OEM database control and went to a 3-tier architecture: database,
application server, and web browser. And yes - the GUI workflow was poor at first but slowly got a little
better - and the performance was less than stellar. In fact it sometimes crashed a lot or was hard to
get/keep connected to.

Now here's some even better news for us. In Oracle 12c which came out in 2013, and will of course take
1-2 years to become mainstream - Oracle have deprecated (i.e. killed) the OEM database cartridge
altogether - as in no more OEM at all. Now with Oracle 12c if you want to manage Oracle databases you
must install the "cloud control" framework for all their monitoring and management, install the
database plug-in, and use that.
Cloud control will require its own dedicated server. The performance will be much the same as OEM -
kind of slow. But the GUI continues to get better. We know from experience of course that web based
GUI's still are less productive than fat client based tools like Toad.
Oracle does include a new "OEM Express" with oracle 12c which is simply a two tier: database and web
browser/flash based solution for just the most basic DBA tasks - but it really offers so little as to be
essentially useless.

These moves by Oracle (big cloud control and light weight stripped OEM Express) should force many
people to Toad for Oracle DBA suite.

OK - so the compare - OEM Database Control vs. newer Cloud Control - both are web based- neither is
fat client

OEM database control

* Three tier web based app: database, app server running Database Control code, and your web
browser to access it

* Middle tier built using more standard or traditional and basic web components (i.e. more
lightweight)

* Used to be available as part of the database install disk, so not viewed as separate thing

Cloud Control

* Three tier web based app: database, app server running cloud control code, and your web
browser to access it

* Middle tier built using oracle's wonderfully fat and overly complex "fusion" technology stack
* Entirely separate product in separate download and with its own set of overwhelming manuals to
read.

The "fat" here is Cloud Control's middleware built using the wonderfully fat and overly complex "fusion"
technology stack. Oracle acquired all those technology companies, cobbled together their various
disjoint wares into one big tool set, and has built their Cloud Control offering on top of all that.

There are some things Cloud Control does well - i.e. manage big things (e.g. patch management and
propagation).
But for the vast majority of day to day admin tasks, it's simply bloated and complex, more Toad sales
predicted.

So where does Toad fit into this

Simple. Toad for Oracle 12 complements Oracle Enterprise Manager 12c

We have written a customer facing document to help you and your customers appreciate the value Toad
for Oracle version 12 adds when a customer has Oracle Enterprise Manager 12c.

Here is the link. https://software.dell.com/techbrief/how-toad-dba-suite-for-oracle-120-complements-

oracle-enterprise-manage826867/

And what if ...

What if the customer doesn't have OEM i.e. no management framework at all to monitor or manage
their Oracle environment Well that's where Foglight for Oracle fits in perfectly. We provide a 24 * 7
framework which is quick & easy to install and allows any customer to quickly manage their Oracle
database performance We do NOT require OEM or any of the OEM packs to do this. We also, do not
require you to be using Oracle Enterprise Edition. We work just as well if the customer has Oracle
Standard deployed And we also support other database platforms such as SQL Server, DB2 and Sybase

How does OEM work technically and why are we different

Oracle Instances come in two flavours , standard and enterprise. The difference between the two
versions is functionality and pricing.
Oracle also provides various ways to deploy them, such as a single standalone Instance, as a cluster (
known as Oracle RAC - Real Application Clustering ) and as a solution ( hardware & software combined
for super speed, aka Oracle ExaData ).
The enterprise version allows for options to be added to it - at extra cost such as partitioning,
compression etc.
If you have the enterprise version then you get the OEM framework - basically the equivalent of our
FMS ( Foglight Management Server ) with no cartridges. However there is basic admin functionality
within the OEM framework & now Oracle also provide a small graphical tool for some other
management components call SQL Developer ( also free ).
OEM needs additional packs to collect detailed information - the main two packs are Diagnostic &
Tuning & these are typically priced at $5k per CPU per pack on top of their Oracle license.

OEM Packs

The Oracle Diagnostics Pack and Oracle Tuning Pack are the most popular packs since they deal with
database performance and tuning, which almost every database requires eventually.
Performance diagnostics and tuning capabilities are actually an integral part of the core database engine
from Oracle Database 10g to Oracle Database 11g and beyond.
The Oracle Diagnostics pack provides automated performance & diagnostic monitoring functionality and
includes such components as Workload Repository (AWR), Active Session History (ASH), the Automatic
Database Diagnostic Monitor (ADDM), Blackouts, Event Notifications The Oracle Tuning Pack requires
the Diagnostic Pack to be purchased as a prerequisite, and includes the following features the SQL
Tuning Advisor, the SQL Access Advisor, SQL tuning sets and the ability to reorganize objects.

Oracle also offers other packs such as the Oracle Configuration Management pack & the Change
Management pack. Again at additional costs.

Collecting & storing of the performance metrics

Once the packs are purchased and the relevant objects created inside each monitored Instance, then
OEM typically uses AWR ( Automated Workload Repository ) and ASH ( Active Session History ) to collect
performance metrics and it stores that information inside each monitored instance

By default it collects these metrics every 60 minutes ( 1 hour ) and stores them for up to 8 days in the
Instance it collects from. ( sysaux tablespace )

It starts with a baseline snapshot, then takes additional snapshots and compares collected metrics to the
baseline. It's looking for deviations based on a starting point in time.

You can then use OEM or the AWR reports to view what has been collected.

They also sample using the active session history (ASH) sampler. ASH samples the current state of all
active sessions. This data is collected into memory and can be accessed by a V$ view. It is also written
out to persistent store by the AWR snapshot processing. ASH samples every second & only collects a
subset of the metrics available, keeping the overhead to a minimum.

Oracle then introduced ADDM or Automatic database diagnostic monitor as it is also known. This
provides automatic performance tuning capabilities, the heart of this function is the statistics collection
facility AWR.

ADDM ranks both the problems and its recommendations according to the crucial DB time statistic.
Every time AWR runs ADDM will automatically do a top-down system analysis and report its findings on
the database control home page of OEM. The purpose of ADDM is to reduce a key database metric
called DB Time which is the total time (in microseconds) the database spends actually processing users
requests. DB time includes the total amount of time spent on actual database calls (at the user level)
and ignores time spent on background process. ADDM will only report on processes that contribute
excessive DB time.

For a RAC environment Oracle then has to combine individual instance metrics together using ADDM to
get a cluster view. Under grid control / cloud control oracle uses agents to collect from each repository
on each instance so you can view the data via the web client

If you have Toad for Oracle installed and you are collecting these snapshots then Toad also has a viewer
for AWR and ADDM metrics. Useful to know.

The good & the bad

OEM collects data and stores it in each database that it monitors. That's an overhead to start with.
Grid control is a framework that allows you to link all the OEM monitored instances together, but the
data is still stored in each monitored instance. So whilst grid control is nice it's not built as a bottom up
solution.
And metrics collected are minimal and only collected once an hour by default.
The OEM framework does provide some Operating System metrics for the server running the instance
and it also provides some management functionality. It's a framework for management & monitoring.

Monitoring Firstly

So why Foglight with Performance Analysis ( PA )

We have one central management server where all the data is stored. We don't have the overhead and
have a proper central console
We don't need OEM or any of the packs for Foglight to work ( Foglight could therefore replace those
OEM packs ). Customer will need at least the Diagnostic pack to compare OEM to anything we offer.
We don't even need the database version to be Enterprise, we are equally as happy if the Oracle is just
the Standard version. You should always check with database versions your customer is using.
OEM thresholds are static ( you can at least set a minimum & maximum ), whereas Foglight uses both
fixed & baselines ( thresholds based on a 14 week running average broken up into 7 days). This is cool
because we avoid either too many alarms ( threshold too low ) or no alarms ( threshold too high )
OEM stores data collected for a maximum of 8 days, whereas Foglight is unlimited. Historical analysis
and time comparison reporting is very useful which OEM struggles to provide ( it has some basic
functionality but it is very manual to operate and limited in its findings ). We can answer questions like
"why is the system slow today when yesterday it was ok"
Performance Analysis allows us to quickly diagnose the problem and why, OEM doesn't have the
workflow to show this plus they don't have the depth of data to show all the related users & queries
being run.
Performance Analysis also allows us to show change tracking (what has changed and show how they
could have potentially been a reason for the performance issue). OEM doesn't provide change tracking.
Changes can be proactive as well as reactive but both are significant for the DBA
If the DBA is really pro Oracle and OEM / Grid control the BIG thing we wow with is Performance
Analysis (change tracking and time period comparisons)

We are also cross database. OEM does offer DB plugins like plugins for DB2 and SQL Server. Just
google them. They certainly have room for improvement. We are cross-DB out of the box. If this is
relevant.

And then Administration

Whilst there is some good management functionality in OEM it doesn't compete with what we offer in
Toad for Oracle. It is fair to say that they do offer some functionality that Toad doesn't but Toad is
much deeper in functionality plus easier to license. Toad also offer cross-DB versions and a community
site of rich information.
We have a useful document to explain how Toad compliments OEM for certain customer situations but
in most it is simply the Administrative tool of choice. You can reference it here
https://software.dell.com/techbrief/how-toad-dba-suite-for-oracle-120-complements-oracle-
enterprise-manage826867/

And finally

Put both Foglight & Toad for Oracle together with our SQL optimization capabilities we have a powerful
set of tools to help Optimize any identified performance issues.

The main differences from the customers perspective is pricing as well as functionality. So what else
also needs to be managed.
We price per instance and extend beyond Oracle, and per DBA user ( seat ) for the Toad solutions.
Oracle prices per CPU and you'll need at least 2 of the management packs to have some realistic
technical comparison.

Some further information on OEM

Oracle Licensing Model for the Management Packs

The Oracle Licensing model for the management packs is what is referred to as "The Honor System".
There have been some improvements on Oracle's side to improve the visibility for the licensed options
being used, but there are still many sneaky ways to get those options enabled by accident by the users
who are not very well versed with the intricacies of these options.

Some relatively newer changes that helps users be informed

Oracle

1) For the diagnostics pack ( that includes the access to the AWR as well), starting with Oracle 11g,
there is a new initialization parameter: "CONTROL_MANAGEMENT_PACK_ACCESS". Users can restrict
the usage (accidental) for the Diagnostics and Tuning packs. Reference :
http://docs.oracle.com/cd/E11882_01/license.112/e47877/options.htm#DBLIC165 and
http://docs.oracle.com/cd/E16655_01/license.121/e17614/options.htm#DBLIC165

2) This can be traced as way back as Oracle 10g - Disable access to Management packs links in Oracle
Enterprise Manager ( now called, Cloud Control) using the Management Pack Access.

3) The Oracle view that tracks the feature usage (features that are packaged with the Oracle EE or are
extra cost options/management packs) : dba_feature_usage_statistics

Toad for Oracle

1) Any window that accesses the OEM management packs, will bring the warning message as shown
below, upon first time invocation of any OEM window. User agreement is must before getting started on
OEM windows.

2) Database health check in Toad DB Admin Module that tracks the Oracle EE options and Diagnostics
and Tuning packs.

The Above options leave out another method to activate the usage for the Diagnostics and Tuning pack -
Using Command line API . Generating AWR report or simply reading data from the AWR tables.

So, in the end it is upon user to be proactive to not trigger any un-licensed database option/pack in
Oracle. Whether user has Toad or not, is irrelevant. If they were using simply SQL* Plus, it could very
well be declared the "culprit" as well. But the problem is in the messaging/education of users regarding
the Oracle licensing.