Professional Documents
Culture Documents
Software Patching Guide: Hig1800 Element Management System (Ems)
Software Patching Guide: Hig1800 Element Management System (Ems)
Software Patching Guide: Hig1800 Element Management System (Ems)
The information or statements given in this documentation concerning the suitability, capacity,
or performance of the mentioned hardware or software products are given "as is" and all
liability arising in connection with such hardware or software products shall be defined
conclusively and finally in a separate agreement between Nokia Siemens Networks and the
customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that
the instructions contained in the document are adequate and free of material errors and
omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks,
explain issues which may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO
EVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS
DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO
SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES,
SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS
INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE
OF THIS DOCUMENT OR THE INFORMATION IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws. The wave logo is a
trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia
Corporation. Siemens is a registered trademark of Siemens AG. Other product names
mentioned in this document may be trademarks of their respective owners, and they are
mentioned for identification purposes only.
1 Introduction .................................................................................................................. 5
1.1 Purpose and Scope........................................................................................................... 5
1.2 Acronyms .......................................................................................................................... 5
1.3 Terminology ...................................................................................................................... 5
2 EMS/hiG1800 Patching Overview................................................................................ 6
2.1 TYPES OF APPLICATION BINARIES .............................................................................. 6
2.2 EMS Active/Standby Applications ..................................................................................... 6
2.3 EMS Load Sharing Applications........................................................................................ 6
2.4 EMS Platform Applications................................................................................................ 7
2.5 hiG1800 Platform Applications.......................................................................................... 7
2.6 Patch Bundle Naming Explanation.................................................................................... 7
2.7 hiG1800 Patch Naming Explanation ................................................................................ 7
3 Patch Bundle Installation Prerequisites ..................................................................... 8
3.1 Prerequisites Overview EMS BUNDLE ............................................................................. 8
3.2 Pre-Patch Checks ............................................................................................................. 9
3.3 Copy New patching files from FTP server....................................................................... 12
3.4 Run CHECK DATABASE scripts .................................................................................... 13
3.5 Backup Current msfswcontrolfile..................................................................................... 14
3.6 Verify current patch level on EMS ................................................................................... 14
3.7 Verify current patch level on hiG1800 ............................................................................. 15
3.8 Backup current database on both EMS nodes................................................................ 15
3.9 Install Tekbase 1.8 (or Latest Version) ........................................................................... 15
4 Patching EMS Server ................................................................................................. 17
4.1 Applying Patches To EMS .............................................................................................. 17
4.1.1 Verify patches are present on EMS ...................................................................... 17
4.1.1.1 Apply Patch Bundles to EMS Nodes ....................................................... 18
5 Patching the hiG1800 ................................................................................................. 19
5.1 Applying hiG1800 Patches To EMS Nodes .................................................................... 19
5.1.1 Check Node Link Status ....................................................................................... 19
5.1.2 Generating the MsfSwControlFile ......................................................................... 20
5.1.3 Predownload MsfSwControlFile and New hiG1800 Patch Load.......................... 21
5.1.4 Patching the Standby Packet and Control (PAC) card ......................................... 22
5.1.5 Monitor Call rate with RTHM................................................................................. 23
5.1.6 Patching VS (Voice Server) Cards (If Applicable)................................................. 23
5.1.7 Signaling Gateway (SG) Server Cards (If Applicable) .......................................... 24
5.1.8 Patching Standby GigE-2 Card (If Applicable)...................................................... 24
5.1.9 Patching ES CARDs (If Applicable) ...................................................................... 25
5.1.10 Load Standby SST Card with DSP/PCM Binaries (If applicable).......................... 26
5.1.11 Patching Standby QOC3 Cards (If Applicable) ..................................................... 27
5.1.12 Have Customer Execute Critical Call-Through Test Plan ..................................... 29
5.1.13 Upgrade Remaining Half of (hiG1800) (If Decision to Proceed) ........................... 29
5.1.14 Patching the Newly Standby QOC3 Cards (If Applicable) .................................... 29
5.1.15 Load Newly Standby SST Card with DSP/PCM Binaries (If applicable)............... 31
5.1.16 Patching Newly Standby GigE-2 Card (If Applicable) ........................................... 32
1.2 Acronyms
Acronym Description
SWOPs Software Operations
hiG1800 NSN Media Gateway Distributed Switching Solution
TAC Technical Assistance Center
CCC Customer Call Center
MOP Method of Procedure
CSR Customer Service Request
1.3 Terminology
Term Definition
Software The act of upgrading a switching product from one major release to another..
Upgrade
Patching Activity The act of patching software on a switching product.
Patch removal is simply a reversal of what is done during patching. Instead of utilizing the new
application binaries from the patch, the pre-requisite (the previous patch) is utilized to get the
replacement application binary from. Deactivation of a removed patch follows the same
procedures as patch application.
The following sections outline the different subsystem patching methodology as well as the
technical means by which they are accomplished.
The base application binaries are initially placed in the /opt/SANTone/msc/active/bin directory
upon initial installation of the SANTone package. Patches to these binaries are placed in the
directory: /Santera/msc/active/patch. Binaries have names, such as SgwIsup_07023037, and a
UNIX symbolic link with the application name pointing to the patched file. Running applications
can be replaced now with a new binary prior to an application restarting (i.e., the patching tools
place a new patch in the /Santera/msc/active/patch directory called SgwIsup_07023039, then
link SgwIsup to it. Once this occurs, the standby application should be identified and restarted
first using the EMS GUI. Once it has successfully restarted, the active side will restart causing
the old standby to become active. At this point, the new version of the application is running.
A cumulative bundle is a bundle package that contains every released file at the point the
CBUNDLE is created.
IBUNDLE
An incremental bundle is a bundle package that contains files that are new in that update. There
may be many incremental bundles. The incremental bundle is intended to be small.
0703.xx.xx.install
When an MG load is release it will have the above naming convention. This is an executable
install file.
1. A patch bundle can only be installed using the “installbundle” script contained in the
patch bundle itself.
2. A patch bundle can only be removed using the “uninstallbundle” script contained in the
patch bundle itself.
3. Once a patch bundle is installed the binaries and scripts contained in that patch bundle
should not be removed, altered, or modified in any way unless they are completely
removed using the “uninstallbundle” script contained in the patch bundle itself.
4. If a binary or script is removed, altered, or modified by the user after the patch bundle
was installed using the “installbundle” script it must be restored to its original condition
before installing new patch bundles.
5. If an incremental bundle is removed it must be replaced (reinstalled) before continuing
patch bundle installation.
6. Before installing the next subsequent patch release level (e.g. from 07.01.20.00 to
07.01.40.00) ALL incremental bundles must be installed on the current patch release
level. Please see section 1 of most recent RN’s for most current software
released for each software stream.
See example below:
Current release: 07.02.40.10
Currently installed bundles:
CBUNDLE113
IBUNDLE114
IBUNDLE115
Not yet installed bundles:
IBUNDLE116
IBUNDLE117
All bundles are in the “tar.gz” format. The “tar.gz” file is a compressed file containing all files
located in the associated patch bundle sub-directory. A “tar” file is a UNIX command that allows
the user to create a single archive file containing many files. Such archiving allows the user to
maintain directory relationships and facilitates transferring complex programs with many
separate but integrated parts that must have their relationships preserved. This single “tar.gz”
file is the file that is transferred to and installed on the system.
Execution
Steps Node User Estimated time of completion: 15 min.
a) Fault Tab
b) Freeze
c) Clear All Alarms (right click on alarms)
d) Click ‘Yes’
e) Click ‘OK’
f) Refresh Button
g) Tools: Request Active Alarms
h) Click ‘Yes’
i) Print Screen and Save File
Verify that there are no processes exits are occurring. Check counters too for recent
5 EMS 1 & ROOT
exits.
2
Run Command: ptree_view
Example:
ptree View of Apps on bocalaba1
Example: Application 47 OamLr is Locked and Disable. This application will not run.
PM's View of Applications on bocalaba1
Id Execute Name Admin St. Oper St. Sch Pr Cnt Start Time
1 BsPm UNLOCKED ENABLED RT 30 1 Thu Oct 22 06:02:47 2009
2 BsDm UNLOCKED ENABLED RT 20 1 Thu Oct 22 06:02:48 2009
3 BsBootpd UNLOCKED ENABLED RT 10 1 Thu Oct 22 06:02:53 2009
4 OamFault UNLOCKED ENABLED RT 20 1 Thu Oct 22 06:02:55 2009
15 CsTftpd UNLOCKED ENABLED RT 10 1 Thu Oct 22 06:02:57 2009
40 OamCfg UNLOCKED ENABLED RT 10 1 Thu Oct 22 06:02:59 2009
41 OamTrap UNLOCKED ENABLED RT 15 1 Thu Oct 22 06:03:01 2009
43 OamPfm UNLOCKED ENABLED RT 10 1 Thu Oct 22 06:03:03 2009
44 OamNm UNLOCKED ENABLED RT 20 1 Thu Oct 22 06:02:49 2009
45 OamMt UNLOCKED ENABLED RT 10 1 Thu Oct 22 06:03:05 2009
46 OamMgMgr UNLOCKED ENABLED RT 15 1 Thu Oct 22 06:03:07 2009
47 OamLr LOCKED DISABLED TS 0
48 OamDbAudit UNLOCKED ENABLED RT 1 1 Thu Oct 22 06:03:09 2009
56 NamingService UNLOCKED ENABLED TS 0 1 Thu Oct 22 06:03:11 2009
57 NotificationService UNLOCKED ENABLED TS 0 1 Thu Oct 22 06:03:13 2009
58 CorbaEmsServer UNLOCKED ENABLED TS 0 1 Thu Oct 22 06:03:15 2009
59 CliServer UNLOCKED ENABLED TS 0 1 Thu Oct 22 06:03:17 2009
70 OamDbMaint UNLOCKED ENABLED RT 10 1 Thu Oct 22 06:02:50 2009
71 OamSysWatch UNLOCKED ENABLED RT 25 1 Thu Oct 22 06:03:20 2009
117 BsSnmpMonitord UNLOCKED ENABLED RT 25 0 Thu Oct 22 06:02:31 2009
120 timestend UNLOCKED ENABLED RT 5 0 Mon Sep 21 15:11:46 2009
122 snmpdm UNLOCKED ENABLED RT 0 0 Thu Oct 22 06:02:32 2009
/dev/dsk/c0t1d0s4 5161014 1981221 3128183 39% /var (less than 50%)
swap 20538664 20256 20518408 1% /tmp (less than 50%)
swap 20518432 24 20518408 1% /var/run (less than 50%)
/dev/dsk/c0t3d0s7 9029429 7983012 956123 90% /dbbackup (cleans up manually)
/dev/dsk/c0t3d0s6 123779200 65557 122475851 1% /billing (less than 50%)
/dev/dsk/c0t1d0s7 8658869 2430418 6141863 29% /space (less than 50%)
Execution
Ste Node User Estimated time of completion: 30min to 1hr. (depends on transfer speed)
ps
1 EMS 1 santera Use scp or ftp to copy patch files from patch repository to EMS1
login to EMS1
ssh ems1
cd /stats/bundles
ftp public server
cd /location of EMS patches
bin
prompt
mget *bundle418*gz
cd /location hiG1800patch
mget 0702.xx.xx.install
cd /location latest TEKbase (if applicable)
get TEKbase1.8 (need for installing new bundles during patch or
upgrade, please always use the latest TEKbase version)
NOTE
If errors occur in checkDbHealth portion refer to
/space/Santera/db/log/checkDbHealth.log
Some of the errors that are displayed can be ignored such as alarm card
errors. You are looking for differences in the database and if the
checkDbHealth passed.
NOTE
If errors are exhibited, refer to /space/Santera/db/log/checkDbHealth.log
and call your next level of support.
a) cd /space/Santera/msf/1/07.02.40.00
b) ls –ltr (and look for the MsfSwControlFile.txt file)
c) mv MsfSwControlFile.txt MsfSwControlFile.old.txt
a) cd /space/Santera/msf/1/07.02.40.00
b) ls –ltr (and look for the MsfSwControlFile.txt file)
c) mv MsfSwControlFile.txt MsfSwControlFile.old.txt
OR
View the last update level to verify that the hiG1800 is ready to be patched
as well. The location of the hiG1800 Application is
/opt/Santone/msf/<software update release level> in R.7.2.
Example Output
select msfrelnodenum,msfrelcmcslotid,msfrelswversion,msfrelswupdatelevel
from santera.msfreleasecontrol;
< 1, 7, 07.02.40.00 , 07.02.40.32 >
< 1, 8, 07.02.40.00 , 07.02.40.32 >
< 2, 7, 07.02.40.00 , 07.02.40.32 >
< 2, 8, 07.02.40.00 , 07.02.40.32 >
4 rows found.
2 EMS 2 a) cd /opt/SANTone/msc/active/cron
b) dbbackup.sh
c) ls –lrt /dbbackup (to check current database
backup)
Revised:
Note:
% = santera
# = root
CAUTION
NOTE
In the tables below, bold text should be typed.
a) cd /stats/bundles
b) gunzip < bundlename.tar.gz | tar xvf –
4 EMS ROOT Switch user to root
Nodes
a) su
b) <root password>
c) zsh
5 EMS ROOT To install the patch bundle:
Nodes
a.) cd /stats/bundles/ <bundlename >
b.) ls –la
c.) installbundle
The upgrade of the hiG1800s are split into 2 phases. The first phase is when all of the standby
cards are upgraded to the latest release and switched over first before doing any of the
redundant cards. Performing the upgrade in phases allows for a simpler and quicker way to
downgrade the gateway since can perform switchovers to revert back to the previous release
rather than having to downgrade the standby cards and doing switchover on the standby cards.
The cards that use a load share protection scheme are patched during phase one. The cards
are completed one at a time to avoid affecting service. The second phase is when the newly
standby cards on the old release will be upgraded.
/space/Santera/msc/07.02.40.00/patch/scfmgr --common --
baserelease=07.02.40.00 --patchrelease=0702.47.00 --node=1 --slot=7
cd /space/Santera/msf/1/07.02.40.00
ls –l MsfSwControlFile.txt
cat MsfSwControlFile.txt
/space/Santera/msc/07.02.40.00/patch/scfmgr --common --
baserelease=07.02.40.00 --patchrelease=0702.47.00 --node=2 --slot=7
cd /space/Santera/msf/1/07.02.40.00
ls –l MsfSwControlFile.txt
cat MsfSwControlFile.txt
Note: Compare the size and contents of the file with the
other EMS node.
/space/Santera/msc/07.02.40.00/patch/scfmgr --common --
baserelease=07.02.40.00 --patchrelease=0702.47.00 --node=1 --slot=7
cd /space/Santera/msf/1/07.02.40.00
ls –l MsfSwControlFile.txt
cat MsfSwControlFile.txt
/space/Santera/msc/07.02.40.00/patch/scfmgr --common --
baserelease=07.02.40.00 --patchrelease=0702.47.00 --node=2 --slot=7
cd /space/Santera/msf/1/07.02.40.00
ls –l MsfSwControlFile.txt
cat MsfSwControlFile.txt
Note: Compare the size and contents of the file with the
other EMS node.
2 EMS GUI GUI From EMS, set SwUgrade flag for standby PAC card
The upgrade flag is turned ON to indicate to the hiG1800 to not sync database
from its mate CM card but get the new release database from EMS. The
Software Revision must be set to 07.02.40.00 otherwise the Regeneration of
the Software Control File will not occur.
CAUTION
Wait for the status to be "System Ready"
4 EMS GUI GUI From EMS, ensure standby PAC card displays “Hot Standby”
6 EMS GUI GUI From EMS, Clear the SwUpgrade flag for new active PAC card
CAUTION
If calls drop significantly and do not recover have customer make test calls. If necessary, call next level
of support.
2 EMS GUI GUI From EMS, switchover traffic to the protecting VS (only on Standby/Active
Protection shceme.)
CAUTION
Verify the switchover was successful. Active card should become Standby and
Protecting card should become Active
CAUTION
Monitor VS for it to finish booting
4 EMS GUI GUI From EMS, repeat steps 1 thru 3 for each provisioned VS
cards
2 EMS GUI GUI From EMS, switchover traffic to the protecting SG Cards
CAUTION
Verify the switchover was successful. Active card should become Standby and
Protecting card should become Active
3 EMS GUI GUI From EMS, reset protecting Signaling Gateway (SG) Server card
CAUTION
Monitor Signaling Server Card for it to finish booting
4 EMS GUI GUI From EMS, repeat steps 1 thru 3 for each provisioned
Signaling Gateway (SG) Server cards
CAUTION
Wait for GigE-2 switchover to complete
4 Repeat all the above steps for any other standby GIGE pairs that are
provisioned.
CAUTION
Monitor ES for it to display “Active”
CAUTION
Wait 2 minutes for the SST to completely stabilize
2 EMS GUI GUI From the EMS GUI, Nodes->MG Nodes->Node Number->SST DSP Groups,
reload each Standby DSP Group type.
On Protecting QOC3 card, take note of the OC3 Ports and their
status. All ports must be in a “Hot Standby” mode.
CAUTION
All Ports not on “Hot Standby” must have their mated port investigated for issues.
Failure to do this could cause call degradation.
d) Check alarms, errors and logs for any issues that may have caused the
port to not be Active.
NOTE
Once it is determined no issues reside on the Working Card Ports, switch them
over to Active.
CAUTION
Failure to monitor ports (logs, alarms and calls) could result in service degradation.
h) Monitor the ports logs, alarms and look for any call failures for 5 minutes.
Revert the port back if issues can’t be resolved in a timely manner.
i) Perform f through k for all Protecting ports not “Hot Standby”.
2 EMS GUI GUI Upgrade the Protecting QOC3 card by resetting it from EMS.
CAUTION
Failure to follow these steps precisely could result in service degradation.
CAUTION
Failure to monitor card for call failures and adverse logs or alarms, could result in
service degradation.
3 Validate stability of newly upgraded card. Card is Enabled and Hot Standby.
On Protected QOC3 card, take note of the OC3 Ports and their status. All ports
must be in a “Hot Standby” mode.
CAUTION
All Ports not on “Hot Standby” must have their mated port investigated for issues.
Failure to do this could cause call degradation.
d) Check alarms, errors and logs for any issues that may have caused the
port to not be Active.
NOTE
Once it is determined no issues reside on the Working Cards Ports, switch them
over to Active.
CAUTION
Failure to monitor ports (logs, alarms and calls) could result in service degradation.
h) Monitor the ports logs, alarms and look for any call failures for 5 minutes.
Revert the port back if issues can’t be resolved in a timely manner.
5 EMS GUI GUI Validate all QOC3 cards have correct software load and bootloaders.
Connect to each QOC3 cpu and display the bootloader information.
CAUTION
Failure to validate software could result in service degradation.
i. send 22,0:connect
j. info
k. disconnect
CAUTION
Make sure all test calls pass before proceeding. Evaluate EMS/hiG1800 switch performance. Pay special
attention to Cards switching over on their own, processes exiting, and call rate completion dropping.
Now is the time to decide on proceeding with the upgrade or falling back to the OLD Release on the
hiG1800. If necessary, call next level of support.
WARNING
Failure to upgrade all active cards could result in call processing degradation.
On Protecting QOC3 card, take note of the OC3 Ports and their
status. All ports must be in a “Hot Standby” mode.
CAUTION
All Ports not on “Hot Standby” must have their mated port investigated for issues.
Failure to do this could cause call degradation.
d) Check alarms, errors and logs for any issues that may have caused the
port to not be Active.
NOTE
Once it is determined no issues reside on the Working Card Ports, switch them
over to Active.
h) Monitor the ports logs, alarms and look for any call failures for 15
minutes. Revert the port back if issues can’t be resolved in a timely
manner.
i) Perform f through k for all Protecting ports not “Hot Standby”.
2 EMS GUI Upgrade the Protecting QOC3 card by resetting it from EMS.
CAUTION
Failure to follow these steps precisely could result in service degradation.
CAUTION
Failure to monitor card for call failures and adverse logs or alarms, could result in
service degradation.
d) Monitor QOC3 for load completion, adverse alarms and logs or call
failures.
3 Validate stability of newly upgraded card. Card is Enabled and Hot Standby.
On Protected QOC3 card, take note of the OC3 Ports and their status. All ports
must be in a “Hot Standby” mode.
CAUTION
All Ports not on “Hot Standby” must have their mated port investigated for issues.
Failure to do this could cause call degradation.
d) Check alarms, errors and logs for any issues that may have caused the
port to not be Active.
NOTE
Once it is determined no issues reside on the Working Cards Ports, switch them
over to Active.
CAUTION
Failure to monitor ports (logs, alarms and calls) could result in service degradation.
h) Monitor the ports logs, alarms and look for any call failures for 15
minutes. Revert the port back if issues can’t be resolved in a timely
manner.
5 EMS GUI GUI Validate all QOC3 cards have correct software load and bootloaders.
Connect to each QOC3 cpu and display the bootloader information.
CAUTION
Failure to validate software could result in service degradation.
a. send 22,0:connect
b. info
c. disconnect
6 EMS GUI GUI Make sure both Active and Standby QOC3 cards are on the NEW release.
5.1.15 Load Newly Standby SST Card with DSP/PCM Binaries (If applicable)
CAUTION
Wait 5 minutes for the SST to completely stabilize
2 EMS GUI GUI From the EMS GUI, Nodes->MG Nodes->Node Number->SST DSP Groups,
reload each Standby DSP Group type.
3 EMS GUI GUI Make sure both Active and Standby SST cards are on the NEW
release.
CAUTION
Monitor GigE-2 for it to finish unlocking
CAUTION
Wait for the status to be "System Ready"
CAUTION
Wait for the status to be "System Ready"
4 EMS GUI GUI From EMS, ensure standby PAC card displays “Hot Standby”
5 Make sure both Active and Standby PAC cards are on the NEW
release.
Example:
nechbrgems2% dis_appmgr_index
Allow the processes 1-2 minutes to finish shutdown. If processes do not shutdown
after 2 mintutes, lock the standby EMS node from the EMS GUI.
Once the shutdown is complete, the node will automatically be locked. Any
applications which were active on this node will be activated on the other EMS node
Ensure the applications for the standby node have started and are stable.
Once booted, the new software will be running on the standby node. Since the
standby node is locked, no links with other node will be established. All applications
will come up in the default state of In Service or Standby. The process EMSCfg will
also come up standby and will not send routing to any of the applications.
6 EMS 2 GUI Using the EMS GUI, UNLOCK the standby EMS. This will cause a node sync to be
Standby performed by the active EMSCfg to bring this node online.
Node
a) System
b) Nodes
c) EMS (MSC)
d) Node # (example: 2 ewlinofxp -2)
e) Right Click: Admin State: Unlocked
If a process remains in COLD state for an extended period of time, restart the process
and monitor it again for going HOT.
Example:
nechbrgems2% dis_appmgr_index
EMSFault should be Active on the EMS Node 2 that is running the new software
release.
CAUTION
Make sure all test calls pass before proceeding. If necessary, call next level of support.
Example:
nechbrgems2% dis_appmgr_index
Allow the processes 1-2 minutes to finish shutdown. If processes do not shutdown
after 2 mintutes, lock the standby EMS node from the EMS GUI.
Once the shutdown is complete, the node will automatically be locked. Any
applications which were active on this node will be activated on the other EMS node
Ensure the applications for the standby node have started and are stable.
Once booted, the new software will be running on the standby node. Since the
standby node is locked, no links with other node will be established. All applications
will come up in the default state of In Service or Standby. The process EMSCfg will
also come up standby and will not send routing to any of the applications
6 EMS 1 GUI Using the EMS GUI, UNLOCK the standby EMS. This will cause a node sync to be
Standby performed by the active EMSCfg to bring this node online.
Node
a) System
b) Nodes
c) EMS (MSC)
d) Node # (example: 1 ewlinofxp -1)
e) Right Click: Admin State: Unlocked
If a process remains in COLD state for an extended period of time, restart the process
and monitor it again for going HOT.
Example:
nechbrgems2% dis_appmgr_index
EMSFault should be Active on the EMS Node 1 that is running the new software
release.
CAUTION
Make sure all test calls pass before proceeding. If necessary, call next level of support.
a) Verify alarms
b) Run checkDbHealth
*<EMS1> <EMS2> -all
*<EMS2> <EMS1> -all
c) Run dbbackup
d) Verify Binaries
e) Run switchcheck –b
NOTE
If errors are exhibited, refer to /space/Santera/db/log/checkDbHealth.log and
call your next level of support.
2 EMS 2 Santera a) su - santera
b) cd /opt/SANTone/msc/active/TimesTen/scripts
c) checkDbHealth <localMGCnode> <peerMGCnode>
SanteraDatabases
NOTE
If errors are exhibited, refer to /space/Santera/db/log/checkDbHealth.log and
call your next level of support.
Execution
Steps Node User Estimated time of completion: 5min.
5 All All
CAUTION
Action Items
Action Assignee Exp. Resolution Date
Fix the following suggestions