1. EM12c Monitoring,
Metric Extensions and
Performance Pages
Kellyn Pot’Vin
Sr. Techical Consultant

2. Kellyn Pot’Vin
• Westminster, Colorado
• Oracle ACE, Sr. Technical Specialist at Enkitec
• Multi-Platform DBA
• Specialize in performance and management of large
enterprise environments.
• Board of directors for RMOUG, Director of Training
Days 2013 and Database Track Committee for
KSCOPE 2013
• Blog: DBAKevlar.com
• Twitter: @DBAKevlar

3. Why We Monitor our Databases
• Pro-active notification of issues before resulting in
outages/impact to users.
• Awareness of performance, resource usage and
demands.
• Data collection to investigate performance issues-
current, recent and historical.
• Capacity planning.
• Automation of maintenance work.

4. Monitoring and Notification Downfalls
Yahoo News- “Over 70% of workers would give up
shower[ing] to eliminate unnecessary emails.”
•Paging with “Successful” and/or “I’m OK”.
•Not alerting for enough types of failures, instead
covering with when complete.
•Paging on “Warning”
•Setting Critical thresholds too high vs. giving time to
correct.

5. Presentation Agenda
• EM Architecture
• EM Incident Rules and the Incident Manager
• Metric Extensions- The Why and the How.
• Performance Pages
• Top Activity
• Diagnosing Issues
• SQL Monitor
• ASH Analytics

6. Simple EM Architecture
• Oracle Repository stores
data in an Oracle database.
• OMS (Oracle Management
Service)
• Targets with OMA(Oracle
Management Agent)/Plug-
ins upload data to OMS.
• Cloud Control Console, (aka
EM Console) Used to view
data through interaction
with OMS.

7. Effective Monitoring with Incident
Manager

8. Creating Incidents From Alerts

9. Incident Rules
From EM12c Console
•Setup
•Incidents
•Incident Rules/ Job Events

10. Incident Rule Sets
• Two Non-Editable, Main Rule Sets Come with EM12c
Installation,
• Incident Management
• Event Management

11. Incident Management Rules- Broken
Down
• Incident Creation for metric alerts
• Auto- Clear rule for metric alert older then 7 days.
• Auto-Clear rule for job status change for terminal status events.
• SLA Incident Creation
• Incident Creation for Target Unreachable, Down and Error.
• Clear ADP, (Application Dependency and Performance) alerts
without incident after 7 days.
• Incident creation rule for high-availability events.

12. Utilizing Existing Rule Sets
1. Disable existing, Non-editable, system generated,
incident management rule set.
2. Pre-existing are Quality Rule Sets, but need to be
editable.
3. Need to Copy the Incident Rule Sets.
4. Enhance or Add Additional Rules to the New Copy
of a Rule Set.

13. Disabling and Copying Rule Sets

14. Copying a Rule Set
• Fill in new name of Incident Rule Set.
• Defaults to all targets, exclude, change to target types or specific types.
• Enable if copying a disabled rule set.

15. Copying Rule Set, Rules Tab
• Click on the Rules Tab
• You can Edit Existing rules, enhancing, updating or
changing default settings.
• Remove any unwanted rules.
• Add specific rules for your environment.

16. Copying Rule Set, Co-authors

17. Rules vs. Metric Thresholds
• Rule are Set Globally.
• Rules are Independent of Database Metric Settings.

18. Metric Settings
• Set at database level unless using a template.
• In 12.0.1.0 BP1, only set with warning thresholds.
• Good reason to use a template.

19. What Are Metric Extensions?
• A dynamically configured extensions feature allowing
to monitor environment specific conditions.
• Simplifies monitoring of operational processes that
once only existed outside of the EM12c console.
• Eliminates requirements for secondary monitoring
and management tools.
• Eliminate need for external scripting that may require
more monitoring logic than EM Jobs can provide.

20. Metric Extensions Details
• Metric Extensions replace the formerly known “User
Defined Metrics”
• User Defined Metrics were limited to database and
host types, no longer with Metric Extensions.
• Ability to build a metric extensions library to utilize for
your own environment.
• Full development cycle support
• Using specific protocols , the Oracle Integration
Adapter gathers data about targets for use with
metrics extensions.

21. The “More” of Metric Extensions
• A simple wizard allows for easy development and
refinement of metric extensions.
• Ability to test metrics using the “Test Page” allows an
ability to run real-time metric evaluations to ensure
definitions and scripts are free of errors before
deploying.
• Loved, stand-alone scripts, with small changes can
become metric extensions, too!

22. Development Life Cycle

23. Enterprise > Monitoring > Metric
Extensions

24. The Creation

25. Creation, Part II

26. Creation, Part III
• Defaults meet the needs for example.

27. Creation, IV

28. Add Columns
• Columns
• AGENT_PID with Description of “AGENT PID”
• MEM_USG with Description of “MEMORY USAGE”
• VAL_MEM with Description of “VALUE of MEMORY”
• Number of occurrences before alerting=5, then click OK

29. Credentials
• Choose a pre-existing setup or new?

30. The Finale!
• Test, rinse, and repeat, (deploy/publish!)

31. Publishing/Deploying/Retaining

32. Metric Extensions Summary
• Create development metric extension, wizard will
simplify process.
• Test with test page and verify that all steps, all
features of the metric extension test correctly.
• Deploy to target separately or to groups.
• Utilize to fulfill any missing areas in monitoring
environment.

33. EM12c Performance Pages
• Summary Page
• Top Activity
• SQL Monitor
• ASH Analytics
• ASH/AWR Reports
• SQL Tuning Advisor
• Misc. Features

34. The Summary Page

35. Database Level Summary Page

36. Top Activity, “The Grid”
• Graphical display of performance usage.
• 15 second refresh, manual refresh or historical.
• Review up to time retained in AWR.

37. The low down of the Top Activity
• Top SQL on left.
• Top sessions, clients, etc. on right in drop down.

38. Here’s our spike, which waits?
• Commonly, focus on pink,
orange, red and brown for
issues.
• Network and queuing do have
opportunities for tuning, as
well.
• Green and blue are expected,
but also part of problems
when over utilized.

39. We’re in the Red, (Orange, too!)
• Inspect High
% use.
• Red, orange,
brown and
pink.

40. Session Details

41. Next?
• Two sessions are executing
• Option to run an ASH report, (right hand side)

42. What ASH Tells Us

43. The Icing on the Cake
• Duh, add some memory to the EM12c box! 

44. SQL Monitor
• Elapsed Time
• SQL_ID, Beginning SQL Text.
• Parallel, Waits and Execution Time

45. Top Activity, ASH style
Ability to choose timelines by:
Hour Day
Week Month
Calendar Custom

46. Familiar Interface
Changes to interface were minimal for user comfort

47. Sql Details View

48. Load Map
New Visual Way of Showing Data, Multiple
Ways!

49. ASH Analytics Summary
• Future of “Top Activity”
• Easy Agent Deployment through EM12c Console
• Comfortable Interface for those familiar with Previous
Versions.
• Cool new features, new learning curve for some.
• Oracle user DOES NOT need sudo, disregard the
instructions.

50. Links
Step by Step to create a metric extension from Rob Zoeteweij-
http://oemgc.files.wordpress.com/2012/05/using-metric-extensions-in-em12c.pdf
EM12c blogs-
Gokhan Atil- http://www.gokhanatil.com/
Martin Bach- http://martincarstenbach.wordpress.com
Niall Litchfield- http://orawin.info/blog/
Info for Me!
Company Website: www.enkitec.com
Twitter: @DBAKevlar
RMOUG: www.rmoug.org
RMOUG Training Days– Feb. 11th-13th, 2013, Denver, CO
Linkedin: Kellyn Potvin and/or Rocky Mountain Oracle User Group
Email: dbakevlar@gmail.com or kpotvin@enkitec.com or
TrainingdaysDir@rmoug.org
Blog: dbakevlar.com

51. SAVE THE DATE!
COLLABORATE 13
April 7-11, 2013
Colorado Convention Center
Denver, Colorado
http://collaborate13.ioug.org