Transcript
Millicom International Cellular SA
MFS - Oracle Monitoring
1
Â
Millicom International Cellular SA
1
MFS - Oracle Monitoring
Version 0.2
Millicom International Cellular SA
2
Table of Contents
1.
Introduction ................................................................................................... 3
1.1.
Definitions .................................................................................................. 3
2.
Scope ............................................................................................................. 3
3.
KPI Definitions ................................................................................................ 4
4.
Solarwinds Screens ......................................................................................... 5
5.
MFS Vendor Support ...................................................................................... 8
Millicom International Cellular SA
3
Version Control
Date/Time Version Changes Changed By
04/08/2015 0.1 First Draft Dileep Nair
04/08/2015 0.2 Data Guard Monitoring Dileep Nair
1.
Introduction
This document is to be used as a high level guideline on oracle monitoring
scope on MFS system.
Document also covers the high level support requirement for the MFS vendors
to enable the monitoring on the MFS system.
Depending upon the monitoring system’s capability the scope will be changed,
this document will give the MFS vendor a high level idea on the pre-requisites
to extend their support.
This document doesn’t cover the implementation detail of any kind and thus
not to be referred for integrations purpose.
1.1.
Definitions
Term Definition
MFS
Mobile Financial Services
ADG
Active Data Guard (Oracle)
2.
Scope
Database Monitoring on primary and secondary (DR) site allows one to
monitor crucial parameters such as availability, Key Read/Write requests,
Table locks, Threads information, Memory consumption, Connections
information, Transaction Rate, User Call Rate etc.
Broader scope of this document falls under the below category and will be
detailed in the following sections
Database Availability
Space Monitoring
Listener
Processes
Archive logs
Recovery Area
Millicom International Cellular SA
4
Replication information
Backup and Scheduler
I/O utilization
Locks
3.
KPI Definitions
1.
Database availability:
Database availability is probably the obvious thing
to monitor for and may seem simple too. We should keep an eye on the
smon, pmon and other key processes to make sure that they are running,
and this will work if you don’t run into other issues, like archive space,
processes or tablespace issues.
Note
: Even if the processes are available,
there could be issue with accessing the DB, so actually database
availability can be ensured by logging into the database and trying a
simple select will show if access to the database is available.
2.
Space, tablespace and filesystem :
This should be the least thing to
worry if we have the proper monitoring is in place, if the monitoring fails
then these space issues can create more issues and outages thant any
other paramenters. The system tablespaces, such as SYSTEM, TEMP,
UNDO, SYSAUX, can cause more issues but are fairly easy to monitor and
set thresholds (~80% this depends on the size of the table space) in the
monitoring by percent full. It is advised to monitor both percent and size.
Another good thing to monitor to be proactive about space is monitor
based on the auto extending and whether that could grow past the size of
the file system.
3.
Listener:
The listener being available is obvious for new connections
coming into the database.
4.
DB Replication (ADG)
: Replication monitoring is to ensure the data
replication is happening timely and efficiently, this involves accessing
some of the additional fixed views (V$) like : V$LOG_HISTORY/
V$ARCHIVED_LOG, V$MANAGED_STANDBY,
V$ARCHIVE_DEST_STATUS,
DBA_LOGSTDBY_EVENTS,
DBA_LOGSTDBY_HISTORY,
DBA_LOGSTDBY_SKIP etc.
The whole idea is the keep the DB in synch and proactively identify issues.
There also a need to monitor the disk I/O for the replication which will be
covered as the system KPI.
5.
Processes:
Hitting max processes can either cause a login to hang which
makes it sometimes difficult to monitor. A threshold is useful to monitor
reaching a percent of max processes, so when it hits 80% there is time to
research what is going on to prevent lock out of the database. When
hitting the threshold, killing processes is an option to prevent reaching the
max processes, because when needing to change the parameter will
require a restart of the instance.
6.
Archive log and recovery area:
Archive log space will cause the system
to hang and give the ORA-00257: archiver error. Connect internal only,
Millicom International Cellular SA
5
until freed error. If using file system space, monitoring the space available
on the mount point is important. Setting thresholds to monitoring when
80 or 85% of space used.
7.
Backup and Scheduler:
Oracle backup monitoring and Scheduler for
critical jobs.
8.
I/O wait and high utilization
: I/O monitoring is important in order to
keep track of the highly utilized resources and proactive tuning of those.
Need to monitor those files whose write/read I/Os are greater than (25 -
50 percent) of total writes/reads. This will allow us to focus in securing
these files in the KEEP pool or split it across to reduce the load.
9.
Oracle Locks:
Oracle locks can be a disastrous and needs monitoring
10.
Others :
Some of the other parameters could be Buffer waits, Redo log
switching and space requests/extends, Shared pool Contention, Full Table
Scan, DBWR contentions, System waits etc.
4.
Solarwinds
Screens
This section will give some hints on how the monitoring screens will look like
on the solar winds tool
i.
DB Alerts
ii.
Resources Monitoring includes the below sections
CPU
Memory
Disk
Sessions
Millicom International Cellular SA
6
iii.
Current Status Monitoring
iv.
Dashboard Trend
Millicom International Cellular SA
7
v.
Â
DB Reports
Millicom International Cellular SA
8
5.
MFS Vendor Support
Monitoring KPI’s spanned across the larger area of the
database (primary and
DR) like the processes, V$ and GV$ (for RAC) objects, alert log etc. this needs
to have a privileged user with read access to all the aspects of the database.
The DB should have a DBA/System user which has the privileged to have
access to all system/schema level objects.
