Cisco Headend System Release 2.7 Installation Guide
Appendix C
Perform a DNCS Upgrade in a Disaster Recovery Enabled Network
94
4042389 Rev A
15 Enable the collection of Disaster Recovery Near Real Time Sync DHCT data on
Standby DNCS:
a Type dbaccess dncsdb -q
b UPDATE track_mod_chk SET run_flag="Y", last_run = CURRENT;
a Type dbaccess dncsdb -q
b UPDATE track_mod_chk SET run_flag="Y", last_run = CURRENT;
16 Upgrade the Primary DNCS.
17 Re-install the Disaster Recovery triggers and tables onto the Primary DNCS. See
17 Re-install the Disaster Recovery triggers and tables onto the Primary DNCS. See
Install Disaster Recovery Triggers, Stored Procedures, and Tables (on page 100).
Note: This step can be completed immediately following the DNCS database
conversion step, bldDncsDb, of the DNCS upgrade process.
Note: This step can be completed immediately following the DNCS database
conversion step, bldDncsDb, of the DNCS upgrade process.
18 Log in to the Active MC and type:
a cd /export/home/dradmin/dr/app/ui/webroot/reg/engine
b ./test_buildRoutes.php
Note: This step sets up all of the necessary network routes on the Primary DNCS.
The routes are configured to send the DNCS-generated network traffic for the
emulated QAM modulators and Netcrypts to the Standby MC, the local BFS Data
QAM, Test QPSK modulator, and Test DHCT network traffic to the local standby
DBDS isolation network switch, and the production QPSK modulators and
DHCT network traffic to the Disaster Recovery bit-bucket (the default bit-bucket
address is defined as 192.168.1.4).
b ./test_buildRoutes.php
Note: This step sets up all of the necessary network routes on the Primary DNCS.
The routes are configured to send the DNCS-generated network traffic for the
emulated QAM modulators and Netcrypts to the Standby MC, the local BFS Data
QAM, Test QPSK modulator, and Test DHCT network traffic to the local standby
DBDS isolation network switch, and the production QPSK modulators and
DHCT network traffic to the Disaster Recovery bit-bucket (the default bit-bucket
address is defined as 192.168.1.4).
19 Run a DNCS Doctor report on the Primary DNCS and analyze it for
issues/anomalies. The production QPSK modulators and their respective RF
subnets will not be reachable and will be logged as failures in the Doctor PING
report due to the re-direction of the QPSK mod and DHCT traffic into the
Disaster Recovery bit-bucket.
subnets will not be reachable and will be logged as failures in the Doctor PING
report due to the re-direction of the QPSK mod and DHCT traffic into the
Disaster Recovery bit-bucket.
20 Verify via the Primary DBDS System Test Hub that a DHCT can boot and can
receive advanced services (VOD, IPG, xOD, SDV, etc.). You will want to boot
and verify SARA, Aptive/Pioneer, and MDN/ODN DHCTs if you have them.
This is the time to troubleshoot any issues discovered on the Primary DBDS
system.
and verify SARA, Aptive/Pioneer, and MDN/ODN DHCTs if you have them.
This is the time to troubleshoot any issues discovered on the Primary DBDS
system.
21 Take all of the Disaster Recovery jobs off of hold. See Take Disaster Recovery
Jobs Off Hold (on page 102).
Note: Verify that Disaster Recovery Near Real Time Syncs and Periodic Syncs are
successful. These two syncs will keep the data between the Standby DNCS and
Primary DNCS synchronized until the maintenance window opens and the
Disaster Recovery Switch-Over is performed. It is strongly recommended that
the customer not modify any of the DBDS elements (QAMs, QPSKs, Netcrypts,
etc.) as well as no modification of the logical DBDS entities (channel maps,
sources, services etc.). The Disaster Recovery Near Real Time Sync and Periodic
Sync processes will only keep DHCT-related data/configs and Impulse Pay-Per-
View events and purchase data synchronized between the Standby DNCS and
Primary DNCS.
Note: Verify that Disaster Recovery Near Real Time Syncs and Periodic Syncs are
successful. These two syncs will keep the data between the Standby DNCS and
Primary DNCS synchronized until the maintenance window opens and the
Disaster Recovery Switch-Over is performed. It is strongly recommended that
the customer not modify any of the DBDS elements (QAMs, QPSKs, Netcrypts,
etc.) as well as no modification of the logical DBDS entities (channel maps,
sources, services etc.). The Disaster Recovery Near Real Time Sync and Periodic
Sync processes will only keep DHCT-related data/configs and Impulse Pay-Per-
View events and purchase data synchronized between the Standby DNCS and
Primary DNCS.