2 General Description
The health check is to be performed as directed to by software release upgrade procedures, extension shelf installation MOPs, or My Oracle Support personnel. It may also be utilized during FOA, hardware installations, or customer problem analysis.
This document outlines a series of commands and procedures to be performed on the system. With each command, there is a description of the command, expected command output, and what problems may be detected with the command. If the desired goal/output is not obtained by executing the command, contact My Oracle Support (MOS) to investigate the deficiencies.
The entire set of commands should be executed each time in order to obtain a complete system status and configuration. Some of the commands may not be supported on all EAGLE releases, resulting in a command rejection. These rejected commands will not harm the system in any way and will be verified during the analysis of the captured data. The goal of this health check procedure is to be non-intrusive. Only spare equipment swap-out and the IMT bus testing are intrusive and should be executed during a maintenance window. The procedures that are intrusive are highlighted in Health Check Type.
Recommendations for Performing Health Check
The commands in this document should be executed during periods of FOA, new software or hardware installations, upgrades, or customer problems.
Frequency of Health Check
The frequency of executing these commands should be determined in upgrade execution procedures, extension shelf installation MOP, and the release FOA plan/strategy developed by Oracle. For software upgrade, three health checks are executed. The recommended time frames of these checks are the following: two weeks prior (UHC1), forty-eight hours prior (UHC2), and seventy-two hours following an upgrade (UHC3). For extension shelf, one health check is executed prior to installation. The exact time is based on availability of personnel and scheduled maintenance windows.
Data Capture
During the execution of this procedure, some method of data capture is necessary for proper analysis and for future reference. If a terminal emulation application is being used which supports capturing, the application should be enabled. A KSR or printer terminal may be selected as the capture terminal since output from the user terminal can be echoed to those terminal types. If no other method is available, input and output from the user terminal can be echoed to a configured printer. A capture file must be generated so a comparison can be made with other capture files from the same node to determine if any system degradation occurred between the two capture periods. Some of the procedures explicitly identify anomalies to be checked, if present, these occurrences should be noted. After conclusion of the Health Check procedures the capture file and any notes are to be sent to Oracle for review. If the Health Check is being performed in preparation for an upgrade, contact My Oracle Support (MOS) upon completion to verify that the upgrade can be performed after analysis of the capture file
Step Check-Off and Recording Configuration
All steps in this Health Check are to be initialed by the person performing the step. Also certain steps request recording of data, which is specific to the configuration of the switch being checked.
Note:
The Health Check may take several hours to complete depending on the size of the system, the part number and version of MASPs in use, and user experience.Health Check Record
Each time the System Health Check has been completed, record the date, the reason for the health check (for example, upgrade preparation, new installation, post-upgrade verification, etc.) and record which procedure passed/failed in the following table.
Table 2-1 Health Check Record
| DATE | Reason for running health check | List any procedures that failed (Procedure number and name) | Technician Signature |
|---|---|---|---|
| Upgrade HC #1 | |||
| Upgrade HC #2 | |||
| Upgrade HC #3 | |||
| Extension Shelf HC |
Health Check Type
The following table lists the procedures to be executed depending on the type of health check being performed.
Table 2-2 Health Check Type Procedures
| Procedure | Non-Intrusive Upgrade (UHC1, UHC3) | Intrusive Upgrade (UHC2) | Extension Shelf, New Product |
|---|---|---|---|
| Health Check Preparation | yes | yes | yes |
| General System Status | yes | yes | yes |
| Report System Troubles | yes | yes | yes |
| Verifying Database Status | yes | yes | n/a |
| Verifying GPLs | yes | yes | n/a |
| Retrieving Obituaries | yes | yes | yes |
| Verify SCCP Load | yes | yes | n/a |
| Verifying LNP and LSMS | yes | yes | n/a |
| Verifying SEAS | yes | yes | n/a |
| Verifying optional features | yes | yes | yes |
| Verifying IP Signaling Status | yes | yes | yes |
| Verifying EROUTE | yes | yes | yes |
| Verifying IMT Status | yes | yes | yes |
| Retrieving Trouble Data | yes | yes | yes |
| Verifying Clock Status | yes | yes | yes |
| Verifying MPS Foot 1 | yes | yes | n/a |
| Verify Source Database Foot 1 | n/a | yes | n/a |
| Verifying Fixed and Removable Media (Part 1)Foot 1 | n/a | yes | n/a |
| Testing IMT StatusFoot 1 | n/a | yes | yes |
| Verifying Fixed and Removable Media (Part 2)Foot 1 | n/a | yes | n/a |
| Table Capacity Status | yes | yes | n/a |
| Health Check Conclusion | yes | yes | yes |
Footnote 1 Intrusive procedures are shaded.