CCMS Alert Monitoring

The SAP Computing Center Management System (CCMS) provides a special alert monitor for SAP Exchange Infrastructure.

Suppose your landscape is very big and contains more than 50 servers, it would be tough to manually monitor all those systems. So, it is better to get CCMS configured in Solman system and all other satellite systems that are to be monitored.

You use this alert monitor to monitor the ABAP and Java components (including the Business Process Engine) of your Exchange Infrastructure centrally, and to identify different categories of system errors and application errors in the various interfaces and interface namespaces of the components involved.

The CCMS Alert Monitor has the following advantages:

●      Automated, central monitoring that does not require any administration, except where alerts occur.
●      Proactive monitoring by means of alerts that are triggered as soon as a particular threshold value is not reached, or is exceeded.
●      Support for problem solving through predefined analysis functions, which you can use to remove the cause of an alert in a particular component.

To create the system group, there are two steps:

Go to CCMS Transaction RZ21

a.      Choose Technical infrastructure---->Configure Central System---->Create Entry for Remote System from the menu and maintain all systems (components) of your Exchange Infrastructure.

b.      Choose Technical infrastructure---->Configure Central System---->Maintain system groups and define the system group ExchangeInfrastructure_Systems comprising the systems created previously.
If you are setting up monitoring in a local system that is part of the system group, you can include it in the group by specifying the system ID.

Procedure of using an alert monitor:

1. Choose CCMS--->Control/Monitoring--->Alert monitor.
Alternatively, call Transaction RZ20. The system displays the CCMS Monitor Sets.

2. Expand the monitor sets by positioning the cursor on the CCMS Monitoring Templates and choosing Edit--->Expand tree.
SAP provides default monitor sets, the SAP CCMS Monitor Templates and the SAP CCMS Technical Expert Monitors. These monitor sets are always available to you.

3. Display the Entire System monitor in the SAP CCMS Monitor Templates monitors by positioning the cursor on it and choosing Monitor --->Start monitor.

* The monitor displays the tree as it was last used. The monitoring tree is a hierarchical display of the monitoring objects (system components) and monitoring attributes (types of information on objects) in the system. The Entire System monitoring tree shows all objects and attributes that are visible at the Expert level or for which there are alerts.

* In addition to the Entire System monitor, there are other predefined monitors for special purposes. For example, if you are the database administrator, you may wish to open the Database monitor instead of Entire System.

* One special monitor is the CCMS Selfmonitoring in the SAP CCMS Technical Expert Monitors. This monitor displays any problems with the alert monitor and the monitoring architecture itself. Check in this monitor to ensure that all data collection methods that the alert monitor starts are running normally.

4. Check the current state of your R/3 System.

* Set the monitor to show the current system status.
Display the Current system status if this is not displayed already.

The Current system status reflects the most recent performance values and status messages reported to the alert monitor. Older alerts that are still open (that is, not processed) are not reflected in the color-coding.

* Check the color-coding in the monitoring tree.
The colors of the nodes, or MTEs (Monitoring Tree Elements) in the tree have the following meaning:

Green: The component is running normally. Everything is ok.

Yellow: A warning or "yellow-alert" has been issued.

Red: A problem or critical condition has been reported, a "red alert."

Gray: No data is being supplied for an MTE. (Check the Self-monitoring monitor to see why the collection method for this MTE is not available.)

To display a legend of the colors and icons used in the alert monitor, choose Extras---->Legend.

* The alert monitor propagates the highest alert level up the monitoring tree. For example, if the MTE with the name of your R/3 System is green, that means that all components in the R/3 System's monitoring tree have the "green" status. There is no problem with the system.

* Double click on any MTE to start the analysis method associated with the MTE. The analysis method displays more detailed information on the current status of the MTE.

* Optionally, you can choose to automatically refresh the display. To do this, choose Extras---->Display options and switch to the General tab. In the Refresh display box, mark Yes, interval and enter the refresh interval. The suggested value is 300 seconds or longer. If the automatic refresh is deactivated, the alert monitor displays the data that was available when you started it.

5. Check to see what has happened recently in the system by choosing Open alerts.
Instead of showing the current status of the system, the color coding now shows where open alerts exist. Open alerts are those that have not yet been analyzed.

If you are just coming in to work or returning from lunch, you can use the Open alerts view to see if anything happened in the system while you were away. The monitor saves alerts for you to review even if the condition that caused the alert has since improved.

6. Respond to an alert.
If you see yellow or red entries in the monitoring tree, that means that a warning (yellow) or error (red) condition exists.

Proceed as follows:

* Ensure that you are displaying the Open alerts view.

The monitor now displays how many alerts there are for each MTE. It also shows the most serious of the alert messages that are waiting.

* Position the cursor on a yellow or red monitoring tree element and choose Display alerts.

The system opens the alert browser and displays the open alerts for that MTE. The alert browser includes all alerts in the branch of the tree that you have marked. Position the cursor "higher" up in the monitoring tree to display a broader range of alerts. If you position the cursor on an MTE at the lowest level, you display only alerts that pertain to that MTE.

* Analyze an alert.

Each line in the alert browser provides you with summary information on an alert, including the alert message.

The browser also offers two further sources of information. Mark an alert and choose:

* Start analysis method to start the problem analysis transaction or method that is associated with an alert. (Analysis methods are still being added to the system; not all monitoring tree elements have such methods as yet.)
For example, with buffer freespace problems, you can start the R/3 Buffer Tuning Summary from the alert monitor.

* Display details to display details on the monitoring tree element. These include the most current values or status messages, the alert thresholds, and the performance data for the last measurement period (only for performance monitoring tree elements). You can graph performance data by marking the appropriate row and choosing Display performance values graphically.

7. Has the alert been resolved? Then set it to Complete.
Once you have analyzed the problem and have either resolved it or can safely ignore it, you can set the problem to completed.

Mark the alert and choose Complete alert. The alert monitor deletes the alert from the open alerts.

Oracle Shutdown Stages:

There are 4 Oracle shutdown stages.

1. Shutdown Normal
2. Shutdown Immediate
3. Shutdown Transaction
4. Shutdown Abort

Shutdown Normal:
A normal shutdown of an Oracle database is actually rarely used. This is because the normal shutdown waits for everyone to complete their work and then logoff in an orderly fashion. When a normal shutdown occurs, the database is closed in a normal manner, and all changes made in the database are flushed to the database datafiles.  This is known as a “clean shutdown”.

Here is an example of the use of the normal shutdown command.

SQL> shutdown

Shutdown Immediate:
Perhaps the best way to initially shutdown the database is the shutdown immediate command. This command will prevent any new logins, then rollback any uncommitted transactions, and then bring down the database. In the process of bringing down the database, Oracle will flush all the changes in memory out to the database datafiles too, just like a regular shutdown does. This makes database startup quicker.

Here is an example of shutting down a database with the shutdown immediate command:

SQL> shutdown immediate

Shutdown Transaction:
At this shutdown stage,
-No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued.
-After all transactions have completed, any client still connected to the instance is disconnected.

Here is an example using the shutdown abort command:

SQL> shutdown transaction

Shutdown Abort:
The shutdown abort command is pretty much a guaranteed way to get your database to shutdown. It’s a “hard crash” of the database, and this can result in a longer time to start the database back up.
A shutdown abort should not be your first shutdown method of choice, there may be times when you must force the database down.
At this stage,
-No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued.
-Current client SQL statements being processed by Oracle Database are immediately terminated.
-Uncommitted transactions are not rolled back.
-Oracle Database does not wait for users currently connected to the database to disconnect. The database implicitly disconnects all connected users.
-The next startup of the database will require instance recovery procedures.

Here is an example using the shutdown abort command:

SQL> shutdown abort

Oracle Startup Stages:

There are 3 Oracle startup stages.

1. NoMount
2. Mount
3. Open

The differences in the 3 startup stages for oracle db are as below.

NoMount Stage:
When DB is in the nomount stage, oracle first opens and reads the initialization parameter file "init.ora" for the DB configuration which includes various parameters required for initialization. Based on the parameters, the memory areas in database instance are allocated and db background processes are started. The instance then starts.

Mount Stage:
When DB is in this stage, it opens and reads the control file which contains the physical structure of db  like the database datafiles etc.. It determines the location of the datafiles and the database is ready to be opened.

Open Stage:
When DB is in this stage, it opens the database, it tries to access all of the datafiles associated with the database. Once it has accessed the database datafiles, it makes sure that all of the database datafiles are consistent.

After that DB is into normal operations state.