Upgrading to Prime Network 5.2 from 5.1, 5.0, 4.3.2, 4.3.1, 4.3 (Intermediate Steps)
Note The steps provided below are intermediate steps that are to be followed while Upgrading to Prime Network 5.2 and Oracle 12.2.0.1.
After upgrading to Prime Network 5.2 you must also upgrade to Oracle 12.2.0.1 version. No other Oracle version must be used with Prime Network 5.2.
If you are running Prime Network with RHEL 5.8 before upgrading Prime Network 5.2, upgrade the RHEL version to RHEL 6.x or 7.x version based on your current Prime Network RHEL version support.
Caution
Do
not apply any service patches during any phase of the upgrade to Prime Network 5.2. Apply them after the upgrade is completed.
Before You Begin
(for Oracle 12.1.0.2) $ORACLE_BASE/product/12.1.0.2/db_1/network/admin
(for Oracle 12.1.0.1) $ORACLE_BASE/product/12.1.0.1/db_1/network/admin
Note While upgrading Prime Network in a HA setup, you should always start the upgrade from the Primary gateway as active gateway. The active gateway should not be the secondary gateway when starting the upgrade process.
To upgrade the Prime Network gateway:
Step 1 Create a temporary upgrade directory on the gateway.
Note Make sure that upgrade directory is not a subdirectory of $PRIME_NETWORK_HOME (which is /export/home/pnuser by default).
Step 2 Insert Disk 3: Upgrade Files into the DVD drive.
Step 3 Copy these files from the DVD to the temporary upgrade directory you created:
- ivne-drivers.tar file
- Prime_Network_upgrade directory and its dependent contents
Step 4 Assign pnuser:pngroup owner permissions to the Prime_Network_upgrade directory and its contents:
chown –R pnuser:pngroup Prime_Network_upgrade
Step 5 To verify the group name, run the following command as pnuser: id --group --name
Step 6 As pnuser, move to the following location in your temporary upgrade directory:
Step 7 If you have not upgraded from fresh install of Prime Network 5.1, 5.0, 4.3.2, 4.3.1, 4.3, 4.2.3, or 4.2.2 to Prime Network 5.2, as PN user, run status command to check if Compliance Manager is UP, if not, run:
cmctl start
For example, pn52@imeir-pn50-01 [~]% cmctl status
Step 8 Start the upgrade:
Note Compliance server should be up and running for performing the upgrading process.
Note While exporting custom policies, if you are prompted with the following message,
Export failed, Do you want to continue (YES/NO),
then you can follow the below conditions based on your requirements:
Choose NO to stop the upgrading process and exit, or YES to continue.
When you choose YES, the following message appears:
Warning ! All the custom policies has been wiped out, Do you want to continue (YES/NO).
Choose NO to stop the upgrading process and exit, or YES to continue the upgrade process.
Step 9 Enter the required information as shown in the following table.
|
|
|
Password for OS root user |
Operating system root password |
Linux root password In a high availability environment, you will be required to enter the OS root user for each machine in the setup. |
Verifying whether you have completed database backup |
yes |
This prompt is to check whether you have recently completed database backup. Default is yes. If you enter no, the upgrade process will stop and will ask you to back up the database. For information on backing up your database, see Step 4 in the pre-upgrade checklist. |
Destination location for backing up the existing installation tar file |
directory |
Specify a directory with at least 6000 MB of free space. Verify that the backup directory is available for pnuser. The backup directory needs write permission. Enter the following command to add write permission to the backup directory: chmod 777 <directory> |
Disabling Configuration Audit |
yes |
Configuration Audit is deprecated and replaced by Compliance Audit. If you still want to use Configuration Audit, enter no and it will remain available from Change and Configuration Management. |
Path to the ivne-drivers.tar file |
full pathname |
Provide the full pathname to the temporary upgrade location from Step 1. |
Prime Network root password |
root password |
The root password used to log into the Prime Network GUI applications. |
Step 10 After the upgrade is complete, Prime Network restarts. Log in as pnuser for the environment changes to take effect.
Note While importing the custom policies, if the number of custom policies exported is zero, then the importing process is skipped with a message No Custom Policies to import. If the custom policies exported is not zero and if the compliance server is up, then the importing process begins. If the compliance server is not up within 30 seconds, the following message is prompted to the user:
Failed : Run <PN_Home>/utils/independent/compliance/bin/importPolicies.sh manually
Step 11 If any of the preceding steps fail, the following error message is shown:
Failed to execute hook-type for hook-name. See log for further details.
- Hook hook-name terminated with failure
- Please choose one of the following:
1. Abort the upgrade process
In the error message, hook-type and hook-name are the type and name of the procedure that failed.
a. Check the upgrade log ( PRIME_NETWORK_HOME /Main/upgrade- timestamp.log) to identify the reason for the failure.
b. If you can identify the problem and fix it manually, do so; then, choose option 2 to rerun the hook. The upgrade procedure continues from the procedure that failed.
c. If you cannot fix the problem, choose option 1 to cancel the upgrade. After canceling the upgrade, Prime Network cannot be started. Contact your Cisco account representative to fix the problem; then, rerun the upgrade. The upgrade procedure continues from the procedure that failed.
Note If you decide not to rerun the upgrade, you must roll back to your base Prime Network environment, including rolling back the database. See Rolling Back to Earlier Prime Network Version.
Step 12 If you upgraded a gateway configured with local high availability, take the ana and oracle_db services out of maintenance mode:
Step 13 Clear the web browser cache.
Step 14 Perform the necessary tasks listed in Prime Network Post-upgrade Tasks.
Note To remove previous device package reference errors in avm file: 11.out, execute the following command as a Prime Network user: networkctl restart –avm 11.
After the upgrade of Prime Network, you can implement SNMPv2 protocol on all devices. Follow the below steps to run the script:
1. Navigate to ‘<PRIME_NETWORK_HOME>/local/scripts’ directory in the GateWay (GW).
2. Run the script as pnuser from the GW.
Note To run script, Prime Network should be down in both GW and Units. This condition is applicable for all VNEs and not applicable to a specific VNE.
3. Run the script file using the command below:
perl updateSNMPver.pl <currentSnmpver> <newSnmpVer>
Ex1: perl updateSNMPver.pl v2 v2only
Ex2: perl updateSNMPver.pl v1 v2only
Note Valid SnmpVer parameters for the above script are v1,v2,v2 only and the parameters are case sensitive. The log files are available in the following path; ‘<PRIME_NETWORK_HOME>/SnmpVerchange_logs’ in the GW.
4. Start the Prime Network to reflect the changes.
Upgrading or Downgrading OS in HA Environment
You can upgrade or downgrade RHEL version on the local cluster and install HA on all VMs. For example, you can install VM1 and VM2 in a local cluster and VM3 as Geo/DR in a Local with Geographical setup or Install VM1 in a local cluster and VM3 as Geo/DR in a Geo only setup. VM1 is considered as Local or Primary VM, VM2 as secondary local cluster VM where both PN and oracle services not running, and VM3 as standby and distant Geo/DR.
Upgrade of OS in HA Environment
To perform the upgrade, follow the steps:
Step 1 Install HA on a Local cluster VM with Geographical setup or Geographical only setup that has RHEL5.8 or 6.x on all VMs.
Step 2 Shutdown the Primary VM (VM1) in case of both Local+HA local clusters without loss of generality.
Step 3 Execute the following script on the StandBy VM (VM3):
Note After execution, VM3 will be your new Primary, and either VM1 or VM2 will be your new Geo/DR.
Step 4 Upgrade the RHEL from 5.8 to 6.x or 7.5 on the local cluster.
-or-
Upgrade the RHEL from 6.x to 7.5 on the local cluster.
Complete the below steps:
a. Take the backup of Prime Network, re-image the server with RHEL 6.x or RHEL 7.5, install the Prime Network 5.2, and then restore the Prime Network backup.
b. In case, if you are re-imaging the server with RHEL 7.5, ensure to configure the cluster with Pacemaker. For more information, see Configuring Clusters for Pacemaker and Corosync Setup.
Note In Prime Network 5.2, in-line upgrade is supported from RHEL 6.9 to RHEL 6.10. For support on new RHEL 6.10 installation with Prime Network 5.2, contact the account manager and the Advance Services representative.
Step 5 Setup VM cluster (VM1 or VM2) for HA installation as shown below:
a. Create /etc/hosts file
b. Set permissions for both /tmp and /etc/shadow
c. Mount build locations
d. Mount again various 4 disk partitions without loss of generality on the primary VM as shown below:
– mount/dev/sdb1/export1/ana-home/ana
– mount/dev/sdb2/ora/opt/ora1
– mount/dev/sdb3/directio
– mount/dev/sdb4/datafiles/dbf
Step 6 Log in to the Primary VM (VM1) without loss of generality, and then navigate to /tmp path to unzip RH_ha.zip.
Note Your new Geo/DR VM will be the new DR.
Step 7 Navigate to /tmp/RH_ha path and then execute the following script on VM1:
#"perl resumeFromFailOver.pl –- reinstall_setup" from /tmp/RH_ha on the primary VM
Note When the script fails, do the following:
a. Add OVERRIDE_SWAP=true to the file /tmp/RH_ha/auto_install_RH.ini
b. Execute perl install_Prime_HA.pl-autoconf auto_install_RH.ini
Step 8 Execute perl resumeFromFailOver.pl --reconfigure_setup also on the primary VM1.
Step 9 Log in to standby VM (VM3) and navigate to /tmp/RH_ha path.
Step 10 Execute “perl resumeFromFailOver.pl --setup_replication” on the standby VM (VM3).
Step 11 To upgrade OS on your new primary VM(VM3) to RHEL 6.5 or 6.7 or 6.8 or 7.4, repeat steps 2 through 10.
a. Shutdown VM3 and execute perl primeha –fail script on Local VM (VM1).
b. Upgrade OS on VM3 to 6.7, 6.8, 6.9, 6.10, 7.4, or 7.5.
Note In Prime Network 5.2, in-line upgrade is supported from RHEL 6.9 to RHEL 6.10. For support on new RHEL 6.10 installation with Prime Network 5.2, contact the account manager and the Advance Services representative.
c. Setup VM3 to install HA If VM3.
d. Execute the scripts perl resumeFromFailOver.pl –-reinstall_setup and perl resumeFromFailOver.pl --reconfigure_setup on VM3.
e. Execute perl resumeFromFailOver.pl --setup_replication on VM1.
Downgrade OS in HA Environment
To perform the downgrade follow the steps:
Step 1 Install HA on a Local cluster VM with Geographical setup or Geographical only setup that has RHEL 6.5, 6.7, 6.8, 7.4, or 7.5 on all VMs.
Step 2 Shutdown the Primary VM without loss of generality in case of both Local +HA clusters.
Step 3 Execute the following script on the StandBy VM (VM3):
Note After execution, VM3 will be your new Primary, and either VM1 or VM2 will be your new Geo/DR.
Step 4 Downgrade the RHEL from 7.5 to 6.x on the local cluster.
Note Downgrade to RHEL 5.8 is not supported.
Step 5 Setup VM cluster for the HA installation as shown below:
a. Create /etc/hosts file
b. Set permissions for both /tmp and /etc/shadow
c. Mount build locations
d. Mount again various 4 disk partitions without loss of generality on the primary VM as shown below:
– mount/dev/sdb1/export1/ana-home/ana
– mount/dev/sdb2/ora/opt/ora1
– mount/dev/sdb3/directio
– mount/dev/sdb4/datafiles/dbf
Step 6 Login to the Primary VM without loss of generality, and then navigate to /tmp path to unzip RH_ha.zip.
Note Your new Geo/DR VM will be the new DR.
Step 7 Navigate to /tmp/RH_ha path and then execute the following script:
#"perl resumeFromFailOver.pl –- reinstall_setup" from /tmp/RH_ha on the primary VM
Note When the script fails, do the following:
a. Add OVERRIDE_SWAP=true to the file /tmp/RH_ha/rf_auto_install_RH.ini
b. Execute perl install_Prime_HA.pl-autoconf rf_auto_install_RH.in
Step 8 Execute perl resumeFromFailOver.pl --reconfigure_setup also on the primary VM.
Step 9 Login to standby VM and navigate to /tmp/RH_ha path.
Step 10 Execute perl resumeFromFailOver.pl--setup_replication on the standby VM.
Step 11 To downgrade OS on your new primary VM to RHEL6.x, repeat steps 2 through 10.
a. Shutdown VM3 and execute perl primeha –fail script on Local VM (VM1)
b. Downgrade OS on VM3 to RHEL 6.x
c. Setup VM3 to install HA
d. Execute the scripts perl resumeFromFailOver.pl –-reinstall_setup and perl resumeFromFailOver.pl --reconfigure_setup on VM3
e. Execute perl resumeFromFailOver.pl --setup_replication on VM1.
Configuring Clusters for Pacemaker and Corosync Setup
From RHEL7.2 onwards Pacemaker is the default cluster resource manager. Pacemaker provides maximum availability for your cluster services and resources by detecting and recovering node and resource-level failures. It uses messaging and membership capabilities provided by Corosync to keep the resource availability on any of the cluster nodes
Corosync is the open source cluster engine that manages cluster interconnect and maintains the same cluster configuration across all the cluster nodes. All the configuration changes will be replicated to other node using corosync cluster engine. Pacemaker and Corosync are powerful open source technologies that completely replaces the CMAN and RGManager technologies from previous Redhat cluster releases.
Use the following procedure to configure clusters:
Step 1 Install the required packages for Pacemaker on both nodes.
yum-config-manager --enable rhel-7-server-optional-rpms
yum install pcs fence-agents-all
yum install lvm2-cluster gfs2-utils
yum install nfs-utils rpcbind
yum install pacemaker pcs
Step 2 (Optional) Verify Pacemaker /Corosync /pcs is available or not-a | grep pacemaker.
rpm -q -a | grep corosync
Step 3 Stop the firewalld services and Network Manager on both nodes.
systemctl disable firewalld.service
systemctl stop firewalld.service
systemctl stop NetworkManager.service
Step 4 Disable selinux on both nodes.
update SELINUX=enforcing permissive
[root@pn52-qa-ha-01 /]# setenforce 0
[root@pn52-qa-ha-01 /]# getenforce
Configure SELINUX=disabled in the /etc/selinux/config file:
Step 5 (Optional) Verify Hostnames on both nodes.
[root@pn52-qa2-ha-01 /]# cat /etc/hostname
[root@pn52-qa2-ha-02 /]# cat /etc/hostname
Step 6 (Optional) Verify system configurations.
cat /etc/sysconfig/network-scripts/ifcfg-ens192
Step 7 Add Hostnames, IP addresses and Virtual IPs on both nodes (Vi /etc/hosts)
[root@pn51-qa2-ha-01 /]# vi /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.56.57.204 pn51-qa2-ha-01 pn52-qa2-ha-01.cisco.com
10.56.57.205 pn51-qa2-ha-02 pn52-qa2-ha-02.cisco.com
10.56.57.212 ana-cluster-ana
10.56.57.211 ana-cluster-oracle
[root@pn52-qa2-ha-02 /]# vi /etc/hosts
Step 8 Set the cluster password on both the nodes.
Step 9 Start and enable the pcsd sevice on both nodes.
systemctl start pcsd.service
systemctl enable pcsd.service
Step 10 Authenticate and authorize the nodes, any one node
pcs cluster auth <Node1> <Node2> (Proper “HOSTNAME” should be given as it is case sensitive)
Eg: pcs cluster auth pn52-qa2-ha-01 pn52-qa2-ha-02.
Step 11 Start the cluster on one of the nodes. Execute the below command:
pcs cluster setup --start --name <Cluster_Name> <Node1> <Node2>
Note Node1 and Node2 can accept hostname and is case sensitive. For example, pcs cluster setup --start --name hacluster pn52-qa2-ha-01 pn52-qa2-ha-02
Step 12 Enable a cluster with the specified command on both nodes.
Step 13 Log in to the Cluster GUI.
For example, https:// <Anynode>:2224;https://10.56.57.204:2224
a. Enter the username and password.
b. Click Login o access the HAcluster. The High Availability Management window appears.
Figure 10-1 High Availability Login Screen
Step 14 To add a Hostname to an existing Cluster GUI, follow the below steps:
a. Click the MANAGE CLUSTERS tab, and then click Add Existing.
Figure 10-2 Add Existing Clusters
b. In the Add Existing Cluster dialog box, enter the relevant hostname/IP of a node, and then click Add Existing.
Note To create a new cluster, click Create New.
Step 15 To view individual Cluster information, follow the below steps:
a. In the Left pane, check a cluster name to view the nodes, resources, and fence-devices information of the selected cluster.
Note Prime Network installation does not support fencing. Fencing can be configured manually as per the instructions in RHEL documentation.
Step 16 In the right pane, under the Nodes area, click any one node and view the Cluster Status in GUI or in CLI.
Rolling Back to Earlier Prime Network Version from Prime Network 5.2 Including Oracle Rollback
This section describes the procedure to rollback to earlier versions of Prime Network and Oracle from Prime Network 5.2 and Oracle 12.2.0.1.
Note You must do Oracle rollback before rolling back to an earlier Prime Network version.
Refer the following table to decide which Oracle version to rollback to:
Table 10-4 Oracle Rollback Procedures
If you are rolling back to Prime Network version
|
Rollback to this Oracle version
|
Refer the following procedures in order
|
In
or
|
5.1, 5.0 |
Oracle 12.1.0.2 |
|
4.3.2, 4.3.1, 4.3 |
Oracle 12.1.0.1 |
|
In
or
|
5.1, 5.0 |
Oracle 12.1.0.2 |
|
4.3.2, 4.3.1, 4.3 |
Oracle 12.1.0.1 |
|
After completing Oracle rollback, rollback to an earlier Prime Network version. Refer Rolling Back to Earlier Prime Network Version.
Rolling Back to Earlier Oracle Version
Prerequisites
Step 1 Gateway Pre-Upgrade Tasks.
Step 2 Execute the following command as root user to switch to oracle user:
su - <oracleuser>
Step 3 Change directory to $ORACLE_BASE/backup and record the time stamp of earlier Prime Network version backup (which is Year: 2019 Month: 02 Date: 26 HR:15 MIN: 54 in the example below) and the file name.
Note For Oracle rollback in Geo DR and Local HA, the path for backup file is /ora/opt/ora1/backup.
For example,
oracle@pn-sgw-02-lnx [~]#cd $ORACLE_BASE/
oracle@pn-sgw-02-lnx [~]# cd backup
oracle@pn-sgw-02-lnx [~/backup]# ls -la
drwxr-xr-x. 2 oracle oinstall 4096 Feb 26 15:54.
drwxr-x---. 16 oracle oinstall 4096 Feb 25 20:41..
-rw-r-----. 1 oracle dba 180060160 Feb 25 15:38 ANADB_before_upgrade_cold_07tqpc3p_1_1
-rw-r-----. 1 oracle dba 10125312 Feb 26 15:45 cfc-4025296251-20190226-01
-rw-r-----. 1 oracle dba 10125312 Feb 26 15:54 cfc-4025296251-20190226-02
-rw-r-----. 1 oracle dba 1114112 Feb 25 20:21 CONTROLFILE_before_upgrade.rman
-rw-r--r--. 1 oracle dba 1393 Feb 25 20:18 PFILE_before_upgrade.manual
-rw-r-----. 1 oracle dba 10043392 Feb 25 20:21 snapcf_anadb.f
-rw-r-----. 1 oracle dba 98304 Feb 25 20:20 SPFILE_before_upgrade.rman
Step 4 (Applicable only for Local HA and Local HA + Geo DR)
On Active server, freeze the cluster configured services (ana and oracle_db) by executing the following command as the root user:
clusvcadm -Z <service-name> (for RHEL 6.x)
pcs resource unmanage <service-name> (for RHEL 7.x)
Step 5 (Applicable only for Local HA + Geo DR)
a. On both Active and Standby server, navigate to the location
(for Oracle 12.1.0.2) cd /ora/opt/ora1/oracle/product/12.1.0.2/db_1/network/admin/
(for Oracle 12.1.0.1) cd /ora/opt/ora1/oracle/product/12.1.0.1/db_1/network/admin/
and edit the file tnsnames.ora to match the below content:
Note The line to be edited in file tnsnames.ora is shown in bold below.
-----------------------------------------------------------------------------------------------------------
# tnsnames.ora Network Configuration File: /ora/opt/ora1/oracle/product/12.1.0.2/db_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.
ANADB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.56.57.214)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = anadb)
)
)
ANADB_SB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.56.57.199)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = anadb_sb)
)
)
~
----------------------------------------------------------------------------------------------------------
b. On Standby server, navigate to the location
(for Oracle 12.1.0.2) cd /ora/opt/ora1/oracle/product/12.1.0.2/db_1/network/admin/
(for Oracle 12.1.0.1) cd /ora/opt/ora1/oracle/product/12.1.0.1/db_1/network/admin/
and edit the file listener.ora to match the below content:
Note The line to be added in file listener.ora are shown in bold below.
-----------------------------------------------------------------------------------------------------------
# listener.ora Network Configuration File: /ora/opt/ora1/oracle/product/12.1.0.2/db_1/network/admin/listener.ora
# Generated by Oracle configuration tools.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = pn-ha-qa-pn50-dr.cisco.com)(PORT = 1521))
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME=anadb)
(SID_NAME = anadb)
(ORACLE_HOME= /ora/opt/ora1/oracle/product/12.1.0.2/db_1)
)
(SID_DESC =
(GLOBAL_DBNAME=anadb_sb)
(SID_NAME = anadb)
(ORACLE_HOME= /ora/opt/ora1/oracle/product/12.1.0.2/db_1)
)
)
ADR_BASE_LISTENER = /ora/opt/ora1/oracle
~
-----------------------------------------------------------------------------------------------------------
Standalone and Local HA: Rollback to Oracle 12.1.0.2
Step 1 Execute the following commands as a pnuser to stop the Prime Network gateway:
networkctl stop
Step 2 To rollback Oracle 12.2.0.1 to Oracle 12.1.0.2:
a. Execute the following commands:
su – <oracleuser>
cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
SHUTDOWN IMMEDIATE
startup downgrade pfile=<pfilename>;
To retrieve the pfilename, switch to oracle user and go to pfile location:
Note In case of Local HA rolback, the path for pfile will be
cd /ora/opt/ora1/oracle/admin/anadb/pfile/
oracle@pn-sgw-02-lnx [~]# cd /export/home/oracle/admin/anadb/pfile/
oracle@pn-sgw-02-lnx [~/admin/anadb/pfile]# ls
init.ora.1242019133348
For example,
<pfilename> = /export/home/oracle/admin/anadb/pfile/init.ora.1242019133348
SQL> startup downgrade pfile=/export/home/oracle/admin/anadb/pfile/init.ora.1242019133348
SPOOL downgrade.log
@catdwgrd.sql
SPOOL OFF
SHUTDOWN IMMEDIATE
Exit
b. Copy the three files, namely cshrc, inventory.xml, and oratab, and execute source command as follows:
oracle@pn-sgw-02-lnx [~]# cd /etc
oracle@pn-sgw-02-lnx [/etc]# ls -la | grep oratab
-rw-rw-r--. 1 oracle dba 791 Feb 26 12:03 oratab
-rw-r--r--. 1 root root 789 Feb 26 12:03 oratab.12.1.0.2
oracle@pn-sgw-02-lnx [/etc]# cp oratab.12.1.0.2 oratab
oracle@pn-sgw-02-lnx [/etc]# cd
oracle@pn-sgw-02-lnx [~]# ls -la | grep.cshrc
-rw-r--r--. 1 oracle oinstall 1306 Feb 26 12:03.cshrc
-rw-r--r--. 1 root root 1304 Feb 26 12:03.cshrc.12.1.0.2
oracle@pn-sgw-02-lnx [~]# cp.cshrc.12.1.0.2.cshrc
oracle@pn-sgw-02-lnx [~]# cd
oracle@pn-sgw-02-lnx [~]# cd oraInventory/ContentsXML/
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# ls -la | grep inventory.xml
-rw-rw----. 1 oracle dba 573 Feb 26 12:00 inventory.xml
-rw-rw----. 1 oracle dba 478 Feb 26 11:59 inventory.xml.12.1.0.2
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# cp inventory.xml.12.1.0.2 inventory.xml
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# cd
oracle@pn-sgw-02-lnx [~]# source.cshrc
c. Replace the sqlnet.ora file available at location $ORACLE_BASE/product/12.1.0.2/db_1/network/admin with the backup file that you took in Before You Begin of Upgrading to Prime Network 5.2 from 5.1, 5.0, 4.3.2, 4.3.1, 4.3 (Intermediate Steps).
d. Execute the following commands:
cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
STARTUP UPGRADE
SPOOL reload.log
@catrelod.sql
SPOOL OFF
SHUTDOWN IMMEDIATE
STARTUP
@utlrp.sql
e. Switch to Prime Network user and execute the following commands:
pn432@pn-sgw-02-lnx [~]% cd Main/scripts/embedded_db/
pn432@pn-sgw-02-lnx [~/Main/scripts/embedded_db]% emdbctl --update_oracle_home
pn432@pn-sgw-02-lnx [~]% networkctl start
f. Switch to oracle user and restart the lsnrctl status:
lsnrctl stop
lsnrctl start
Step 3 Rollback Prime Network and restore the database as described in Rolling Back to Earlier Prime Network Version.
Step 4 (Applicable only for Local HA)
Unfreeze the cluster configured services (ana and oracle_db) by executing the following command as the root user:
clusvcadm -U <service-name> (for RHEL 6.x)
pcs resource manage <service-name> (for RHEL 7.x)
Standalone and Local HA: Rollback to Oracle 12.1.0.1
Step 1 Execute the following commands as a pnuser to stop the Prime Network gateway:
networkctl stop
Step 2 To rollback Oracle 12.2.0.1 to Oracle 12.1.0.1:
a. Execute the following commands:
su – <oracleuser>
cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
SHUTDOWN IMMEDIATE
startup downgrade pfile=<pfilename>;
To retrieve the pfilename, switch to oracle user and go to pfile location:
Note In case of Local HA rolback, the path for pfile will be
cd /ora/opt/ora1/oracle/admin/anadb/pfile/
oracle@pn-sgw-02-lnx [~]# cd /export/home/oracle/admin/anadb/pfile/
oracle@pn-sgw-02-lnx [~/admin/anadb/pfile]# ls
init.ora.1242019133348
For example,
<pfilename> = /export/home/oracle/admin/anadb/pfile/init.ora.1242019133348
SQL> startup downgrade pfile=/export/home/oracle/admin/anadb/pfile/init.ora.1242019133348
SPOOL downgrade.log
@catdwgrd.sql
SPOOL OFF
SHUTDOWN IMMEDIATE
Exit
b. Copy the three files, namely cshrc, inventory.xml, and oratab, and execute source command as follows:
oracle@pn-sgw-02-lnx [~]# cd /etc
oracle@pn-sgw-02-lnx [/etc]# ls -la | grep oratab
-rw-rw-r--. 1 oracle dba 791 Feb 26 12:03 oratab
-rw-r--r--. 1 root root 789 Feb 26 12:03 oratab.12.1.0.1
oracle@pn-sgw-02-lnx [/etc]# cp oratab.12.1.0.1 oratab
oracle@pn-sgw-02-lnx [/etc]# cd
oracle@pn-sgw-02-lnx [~]# ls -la | grep.cshrc
-rw-r--r--. 1 oracle oinstall 1306 Feb 26 12:03.cshrc
-rw-r--r--. 1 root root 1304 Feb 26 12:03.cshrc.12.1.0.1
oracle@pn-sgw-02-lnx [~]# cp.cshrc.12.1.0.1.cshrc
oracle@pn-sgw-02-lnx [~]# cd
oracle@pn-sgw-02-lnx [~]# cd oraInventory/ContentsXML/
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# ls -la | grep inventory.xml
-rw-rw----. 1 oracle dba 573 Feb 26 12:00 inventory.xml
-rw-rw----. 1 oracle dba 478 Feb 26 11:59 inventory.xml.12.1.0.1
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# cp inventory.xml.12.1.0.1 inventory.xml
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# cd
oracle@pn-sgw-02-lnx [~]# source.cshrc
c. Replace the sqlnet.ora file available at location $ORACLE_BASE/product/12.1.0.1/db_1/network/admin with the backup file that you took in Before You Begin of Upgrading to Prime Network 5.2 from 5.1, 5.0, 4.3.2, 4.3.1, 4.3 (Intermediate Steps)
d. Execute the following commands:
cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
STARTUP UPGRADE
SPOOL reload.log
@catrelod.sql
SPOOL OFF
SHUTDOWN IMMEDIATE
STARTUP
@utlrp.sql
e. Switch to Prime Network user and execute the following commands:
pn432@pn-sgw-02-lnx [~]% cd Main/scripts/embedded_db/
pn432@pn-sgw-02-lnx [~/Main/scripts/embedded_db]% emdbctl --update_oracle_home
pn432@pn-sgw-02-lnx [~]% networkctl start
f. Switch to oracle user and restart the lsnrctl status:
lsnrctl stop
lsnrctl start
Step 3 Rollback Prime Network and restore the database as described in Rolling Back to Earlier Prime Network Version.
Step 4 (Applicable only for Local HA)
Unfreeze the cluster configured services (ana and oracle_db) by executing the following command as the root user:
clusvcadm -U <service-name> (for RHEL 6.x)
pcs resource manage <service-name> (for RHEL 7.x)
Geo DR and Local HA + Geo DR: Rollback to Oracle 12.1.0.2
Step 1 Execute the following commands to move the Standby server from OPEN_MODE to MOUNTED mode:
su – <oracleuser>
sqlplus / as sysdba
SHUTDOWN IMMEDIATE
startup mount
select open_mode from v$database;
OPEN_MODE
--------------------
MOUNTED
exit
Step 2 Execute the following commands as pnuser to stop the Prime Network gateway on both Active and Standby server:
networkctl stop
Step 3 To rollback Oracle 12.2.0.1 to Oracle 12.1.0.2:
Note After logging in to SQL, the following three additional commands must be executed on both servers after each SQL command to ensure that the sequence generated in Active server is synced with the Standby server:
On Active server:
select thread#, max(sequence#) "Last Primary Seq Generated" from v$archived_log val, v$database vdb where val.resetlogs_change# = vdb.resetlogs_change# group by thread# order by 1;
On Standby server:
select thread#, max(sequence#) "Last Standby Seq Received" from v$archived_log val, v$database vdb where val.resetlogs_change# = vdb.resetlogs_change# group by thread# order by 1;
select thread#, max(sequence#) "Last Standby Seq Applied" from v$archived_log val, v$database vdb where val.resetlogs_change# = vdb.resetlogs_change# and val.applied in ('YES','IN-MEMORY') group by thread# order by 1;
a. Execute the following commands on both servers unless stated otherwise:
su – <oracleuser>
cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
SHUTDOWN IMMEDIATE
startup downgrade pfile=<pfilename>;
To retrieve the pfilename, switch to oracle user and go to pfile location:
oracle@pn-sgw-02-lnx [~]# cd /ora/opt/ora1/oracle/admin/anadb/pfile/
oracle@pn-sgw-02-lnx [~/admin/anadb/pfile]# ls
init.ora.1242019133348
For example,
<pfilename> = /ora/opt/ora1/oracle/admin/anadb/pfile/init.ora.1242019133348
SQL> startup downgrade pfile= /ora/opt/ora1 /oracle/admin/anadb/pfile/init.ora.1242019133348
SPOOL downgrade.log
@catdwgrd.sql [execute this command only on Active server]
SPOOL OFF
SHUTDOWN IMMEDIATE
Exit
b. Copy the three files on both servers, namely cshrc, inventory.xml, and oratab, and execute source command on both servers as follows:
oracle@pn-sgw-02-lnx [~]# cd /etc
oracle@pn-sgw-02-lnx [/etc]# ls -la | grep oratab
-rw-rw-r--. 1 oracle dba 791 Feb 26 12:03 oratab
-rw-r--r--. 1 root root 789 Feb 26 12:03 oratab.12.1.0.2
oracle@pn-sgw-02-lnx [/etc]# cp oratab.12.1.0.2 oratab
oracle@pn-sgw-02-lnx [/etc]# cd
oracle@pn-sgw-02-lnx [~]# ls -la | grep.cshrc
-rw-r--r--. 1 oracle oinstall 1306 Feb 26 12:03.cshrc
-rw-r--r--. 1 root root 1304 Feb 26 12:03.cshrc.12.1.0.2
oracle@pn-sgw-02-lnx [~]# cp.cshrc.12.1.0.2.cshrc
oracle@pn-sgw-02-lnx [~]# cd
oracle@pn-sgw-02-lnx [~]# cd oraInventory/ContentsXML/
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# ls -la | grep inventory.xml
-rw-rw----. 1 oracle dba 573 Feb 26 12:00 inventory.xml
-rw-rw----. 1 oracle dba 478 Feb 26 11:59 inventory.xml.12.1.0.2
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# cp inventory.xml.12.1.0.2 inventory.xml
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# cd
oracle@pn-sgw-02-lnx [~]# source.cshrc
c. Replace the sqlnet.ora file available at location $ORACLE_BASE/product/12.1.0.1/db_1/network/admin with the backup file that you took in Before You Begin of Upgrading to Prime Network 5.2 from 5.1, 5.0, 4.3.2, 4.3.1, 4.3 (Intermediate Steps)
d. Execute the following commands on both servers unless stated otherwise:
cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
STARTUP UPGRADE
SPOOL reload.log
@catrelod.sql [execute this command only on Active server]
SPOOL OFF
SHUTDOWN IMMEDIATE
STARTUP [execute this command only on Active server]
STARTUP MOUNT [execute this command only on Standby server]
@utlrp.sql [execute this command only on Active server]
Note Before performing Step 4, execute the three SQL commands mentioned in the note of To rollback Oracle 12.2.0.1 to Oracle 12.1.0.2: to ensure that the sequence generated in Active server is synced with the Standby server.
Step 4 Check if the sequence number is same on both servers and execute the following commands only on Standby server to move the server from OPEN_MODE to READ ONLY:
a. Start mrp process
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
b. Stop mrp process
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
c. Change to READ ONLY
ALTER DATABASE OPEN READ ONLY;
d. Start mrp process
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Step 5 Exit SQL and Oracle user on both servers.
Step 6 On Active server, login as pnuser and execute the following commands under /Main/scripts/embedded_db:
emdbctl --update_oracle_home
For example,
pn432@pn-sgw-02-lnx [~/Main/scripts/embedded_db]% emdbctl --update_oracle_home
pn432@pn-sgw-02-lnx [~]% networkctl start
Step 7 Switch to oracle user and restart the lsnrctl status on both servers:
lsnrctl stop
lsnrctl start
Step 8 Rollback Prime Network and restore the database as described in Rolling Back to Earlier Prime Network Version.
Step 9 (Applicable only for Local HA + Geo DR)
Unfreeze the cluster configured services (ana and oracle_db) by executing the following command as the root user:
clusvcadm -U <service-name> (for RHEL 6.x)
pcs resource manage <service-name> (for RHEL 7.x)
Geo DR and Local HA + Geo DR: Rollback to Oracle 12.1.0.1
Step 1 Execute the following commands to move the Standby server from OPEN_MODE to MOUNTED mode:
su – <oracleuser>
sqlplus / as sysdba
SHUTDOWN IMMEDIATE
startup mount
select open_mode from v$database;
OPEN_MODE
--------------------
MOUNTED
exit
Step 2 Execute the following commands as pnuser to stop the Prime Network gateway on both Active and Standby server:
networkctl stop
Step 3 To rollback Oracle 12.2.0.1 to Oracle 12.1.0.1:
Note After logging in to SQL, the following three additional commands must be executed on both servers after each SQL command to ensure that the sequence generated in Active server is synced with the Standby server:
On Active server:
select thread#, max(sequence#) "Last Primary Seq Generated" from v$archived_log val, v$database vdb where val.resetlogs_change# = vdb.resetlogs_change# group by thread# order by 1;
On Standby server:
select thread#, max(sequence#) "Last Standby Seq Received" from v$archived_log val, v$database vdb where val.resetlogs_change# = vdb.resetlogs_change# group by thread# order by 1;
select thread#, max(sequence#) "Last Standby Seq Applied" from v$archived_log val, v$database vdb where val.resetlogs_change# = vdb.resetlogs_change# and val.applied in ('YES','IN-MEMORY') group by thread# order by 1;
a. Execute the following commands on both servers unless stated otherwise:
su – <oracleuser>
cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
SHUTDOWN IMMEDIATE
startup downgrade pfile=<pfilename>;
To retrieve the pfilename, switch to oracle user and go to pfile location:
oracle@pn-sgw-02-lnx [~]# cd /ora/opt/ora1/oracle/admin/anadb/pfile/
oracle@pn-sgw-02-lnx [~/admin/anadb/pfile]# ls
init.ora.1242019133348
For example,
<pfilename> = /ora/opt/ora1/oracle/admin/anadb/pfile/init.ora.1242019133348
SQL> startup downgrade pfile= /ora/opt/ora1 /oracle/admin/anadb/pfile/init.ora.1242019133348
SPOOL downgrade.log
@catdwgrd.sql [execute this command only on Active server]
SPOOL OFF
SHUTDOWN IMMEDIATE
Exit
b. Copy the three files on both servers, namely cshrc, inventory.xml, and oratab, and execute source command on both servers as follows:
oracle@pn-sgw-02-lnx [~]# cd /etc
oracle@pn-sgw-02-lnx [/etc]# ls -la | grep oratab
-rw-rw-r--. 1 oracle dba 791 Feb 26 12:03 oratab
-rw-r--r--. 1 root root 789 Feb 26 12:03 oratab.12.1.0.1
oracle@pn-sgw-02-lnx [/etc]# cp oratab.12.1.0.1 oratab
oracle@pn-sgw-02-lnx [/etc]# cd
oracle@pn-sgw-02-lnx [~]# ls -la | grep.cshrc
-rw-r--r--. 1 oracle oinstall 1306 Feb 26 12:03.cshrc
-rw-r--r--. 1 root root 1304 Feb 26 12:03.cshrc.12.1.0.1
oracle@pn-sgw-02-lnx [~]# cp.cshrc.12.1.0.1.cshrc
oracle@pn-sgw-02-lnx [~]# cd
oracle@pn-sgw-02-lnx [~]# cd oraInventory/ContentsXML/
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# ls -la | grep inventory.xml
-rw-rw----. 1 oracle dba 573 Feb 26 12:00 inventory.xml
-rw-rw----. 1 oracle dba 478 Feb 26 11:59 inventory.xml.12.1.0.1
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# cp inventory.xml.12.1.0.1 inventory.xml
oracle@pn-sgw-02-lnx [~/oraInventory/ContentsXML]# cd
oracle@pn-sgw-02-lnx [~]# source.cshrc
c. Replace the sqlnet.ora file available at location $ORACLE_BASE/product/12.1.0.1/db_1/network/admin with the backup file that you took in Before You Begin of Upgrading to Prime Network 5.2 from 5.1, 5.0, 4.3.2, 4.3.1, 4.3 (Intermediate Steps).
d. Execute the following commands on both servers unless stated otherwise:
cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
STARTUP UPGRADE
SPOOL reload.log
@catrelod.sql [execute this command only on Active server]
SPOOL OFF
SHUTDOWN IMMEDIATE
STARTUP [execute this command only on Active server]
STARTUP MOUNT [execute this command only on Standby server]
@utlrp.sql [execute this command only on Active server]
Note Before performing Step 4, execute the three SQL commands mentioned in the note of To rollback Oracle 12.2.0.1 to Oracle 12.1.0.1: to ensure that the sequence generated in Active server is synced with the Standby server.
Step 4 Check if the sequence number is same on both servers and execute the following commands only on Standby server to move the server from OPEN_MODE to READ ONLY:
a. Start mrp process
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
b. Stop mrp process
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
c. Change to READ ONLY
ALTER DATABASE OPEN READ ONLY;
d. Start mrp process
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Step 5 Exit SQL and Oracle user on both servers.
Step 6 On Active server, login as pnuser and execute the following commands under /Main/scripts/embedded_db:
emdbctl --update_oracle_home
For example,
pn432@pn-sgw-02-lnx [~/Main/scripts/embedded_db]% emdbctl --update_oracle_home
pn432@pn-sgw-02-lnx [~]% networkctl start
Step 7 Switch to oracle user and restart the lsnrctl status on both servers:
lsnrctl stop
lsnrctl start
Rollback Prime Network and restore the database as described in Rolling Back to Earlier Prime Network Version.
Step 8 (Applicable only for Local HA + Geo DR)
Unfreeze the cluster configured services (ana and oracle_db) by executing the following command as the root user:
clusvcadm -U <service-name> (for RHEL 6.x)
pcs resource manage <service-name> (for RHEL 7.x)
Rolling Back to Earlier Prime Network Version
Rollback to Prime Network 5.1, 5.0, 4.3.2, 4.3.1, or 4.3 is available if you encounter problems during the upgrade, or if you want to roll back to the previous version after the upgrade completes.
Before You Begin
- Verify that the gateway and units are powered up and connected; that is, you can open an SSH session between the gateway and all units.
- Disconnect standby and NAT units from the gateway using the Administration GUI.
- Verify that the Prime Network application is not running with networkctl status.
- Before performing the rollback, stop PN integration layer and watchdog monitoring process. For stopping the Integration layer, refer Chapter 9, “Installing the Prime Network Integration Layer”.
- Rollback Oracle version, refer Table 10-4 Oracle Rollback Procedures.
To Roll back Prime Network gateway:
Step 1 If your deployment has units that are connected to the gateway, roll back the units (before rolling back the gateway). The rollback will remove redundant units from the registry and the golden source.
Step 2 Configure all units using the following command:
network-conf -rollback
Step 3 Enter no at the prompt to start the unit.
Step 4 Restore the backed-up database and start the database services and the listener. Because the database table structure changes after the upgrade, the database is backed up as part of the upgrade process. The old table structure must be recovered.
Note If you have a gateway high availability deployment, the services ana and oracle_db services should be moved to maintenance state.
- To restore an external database, contact your database administrator.
- To restore an embedded database:
– Log into the gateway as pnuser.
– Change to the directory PRIME_NETWORK_HOME /Main/scripts/embedded_db:
# cd $PRIME_NETWORK_HOME/Main/scripts/embedded_db
– Restore the embedded database to the latest backup taken as per Step 1 of Prerequisites:
Note While executing emdctl --restore_db, enter the time stamp and ensure that your restore is from the time stamp you recorded in Step 3 of Prerequisites (which is Year: 2019 Month: 02 Date: 26 HR:15 MIN: 54 in the step’s example).
For more information on prompts that appear while restoring an embedded database, see the
Cisco Prime Network 5.2 Administrator Guide.
After restoring the database, enter no at the prompt to start Prime Network.
Step 5 As pnuser, move to the temporary upgrade directory (created in Step 1 of the procedure in Upgrading to Prime Network 5.2 from 5.1, 5.0, 4.3.2, 4.3.1, 4.3 (Intermediate Steps)).
Step 6 Enter the following command to change to the upgrade directory:
Step 7 Enter the following command on the gateway (only):
Step 8 Perform the rollback by entering the required information as shown in the following table.
|
|
|
Confirm that you have restored the database |
yes |
Confirm that you have restored the database. Note If you have not restored the database, enter no and exit the script. Restore the database and begin again. |
Confirm whether you have reinstalled units |
yes |
Confirm that you performed Step 3. Note If you have not rolled back the units, enter no and exit the script. Rollback the units and begin again. |
Confirm whether you want to roll back to the older version |
yes |
— |
Full path to the backup file |
full pathname |
Location of the backup file (it is not deleted during the rollback). An example is: /export/home/PrimeNetworkBackUp _xxxxxxxxxx.tar.gz |
Step 9 When the rollback is complete, log in as the pnuser to apply the environment changes.
Step 10 Start the unit:
- networkctl start (without running network-conf again)
Step 11 Reconnect standby and NAT units to the gateway using the Administration GUI.
Note 1. Rollback logs can be found in the Prime_Network_upgrade folder under PRIME_NETWORK_HOME.
2. If you are rolling back in Geo DR, after performing the rollback, execute the following command as pnuser:
webcontrol start
If you get the following error:
(98)Address already in use: make_sock: could not bind to address [::]:1311
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:1311
Execute the following command to list the webserver processes:
grep webserver
Kill the running processes using the kill command.
Re-check the error by executing webcontrol start command.
Prime Network Post-upgrade Tasks
After the upgrade to Prime Network 5.2 is complete, perform the post-upgrade tasks that apply to your deployment.
Enable Units to Restart Automatically After they are Rebooted
After upgrade, you need to perform the following steps on each unit in your setup otherwise the units will not restart automatically after they are rebooted.
Step 1 Log into the unit as pnuser.
Step 2 Copy rootdeploy.cmd from the gateway, as follows:
remote_copy.cmd "<Gateway_IP>:.deploy/independent/on_boot/rootdeploy.cmd" ".deploy/independent/on_boot/rootdeploy.cmd"
Step 3 Switch to the root user:
As the root user, execute the root deploy command:
cd $PRIME_NETWORK_HOME/.deploy/independent/on_boot ;./rootdeploy.cmd
Restoring Customized Crontabs
If you saved user-defined cron jobs in PRIME_NETWORK_HOME /local/cron/crontab.user.list, they are restored. User-defined cron jobs that are not placed in this directory must be manually recreated.
Restarting Crontab Jobs for NAT Units
Cron jobs on NAT units must be manually restarted.
Step 1 Log into the unit as pnuser.
Step 2 Copy the upgrade_restart_crons.pl script from the gateway, as follows:
remote_copy.cmd [gw-ip]:$PRIME_NETWORK_HOME/Main/scripts/upgrade_restart_crons.pl Main/scripts
Step 3 Run the upgrade_restart_crons.pl script. It will display output similar to the following:
./Main/scripts/upgrade_restart_crons.pl
+ Updating the unit's cronjobs
- Writing log to ~/Main/logs/upgrade_crons.log
- Copying the files from the gateway (gateway's_ip)
- Restarting the cronjobs
+ Please wait while the unit is being updated.................................Done.
Step 4 Verify that the crontab list is not empty:
Step 5 The upgrade is now complete. Run the status command and check the version number to make sure that the upgrade has been successful.
Fixing the Database Entry for Vision Clients with NAT
If you are using network address translation (NAT) with the Prime Network Vision client, update the database host in the Prime Network registry to contain the hostname instead of the IP address.
If you already use a hostname instead of an IP address, you do not have to repeat this procedure.
Step 1 Make sure Prime Network is running.
Step 2 Verify that the client workstations have the correct Domain Name System (DNS) mapping.
Step 3 From PRIME_NETWORK_HOME/Main, run the following commands:
./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0 site/persistency/nodes/main/Host database-server-hostname
./runRegTool.sh -gs 127.0.0.1 set 0.0.0.0 site/persistency/nodes/ep/Host database-server-hostname
Step 4 Enter the following command to restart Prime Network:
Updating the Port Watchdog (AVM Protection) Scripts
After upgrading to Prime Network 5.2, copy the port watchdog scripts to /var/adm/cisco/prime-network/scripts. Enter the following commands as the root user:
mkdir –p /var/adm/cisco/prime-network/scripts
cp PRIME_NETWORK_HOME/Main/scripts/port_watchdog.pl /var/adm/cisco/prime-network/scripts
cp PRIME_NETWORK_HOME/Main/scripts/keep_alive_port_watchdog.pl /var/adm/cisco/prime-network/scripts
chmod -R 700 /var/adm/cisco/prime-network/scripts
chown -R pnuser:network /var/adm/cisco/prime-network/scripts
Restore Links Between Devices and Cloud VNEs
If your deployment had cloud VNEs that were connected to devices with static links, the connection between the cloud VNE and the device may be lost after the upgrade. Delete and recreate the link using the Administration GUI.
Support for Third-Party VNEs
Prime Network supports third-party devices through Cisco Advanced Services engagement. As of release 5.0, Prime Network will not natively support third-party devices, and a Cisco Advanced Services contract will be required for their enablement and support.
Command Builder Scripts
If you had customized Command Builder scripts (which you should have uninstalled), you may need to update your scripts if your deployment:
- Executes command scripts using the Prime Network northbound APIs (for example, BQL)
- Includes references to IMOs or to the Prime Network internal model
Verify whether the command names, parameters, or IMO references have changed, in which case you must update your scripts. The reinstall your customized scripts.
Gathering DB Statistics in First 24 Hours
The pnuser _admin user performs maintenance tasks—such as gathering statistics—on the other Prime Network database schemas. After this user is created, a cron job runs every 24 hours to gather statistics on the Fault Database tables.
However, if you expect a high scale in the first 24 hours, you might need to manually force statistics gathering twice during the first day, 1 and 5 hours after noise start. To force statistics gathering, enter the following UNIX command as pnuser :
cd $PRIME_NETWORK_HOME/Main/scripts ;./call_update_ana_stats.pl >& /dev/null
If you deploy Prime Network to handle a high event rate, disabling Oracle’s automatic maintenance jobs is recommended. Automatic maintenance significantly affects Oracle performance and increases event processing time. See Disabling Automatic Maintenance Jobs.
Prime Network supports the resetVneSSHv2Algorithms.pl to clean up the ‘algorithms’ key in avm registry files.
It is recommended to run this script if you are managing the VNE’s from Prime Network3.7 or earlier.
To run the script, follow the below steps:
Step 1 Navigate to ‘<PRIME_NETWORK_HOME>/local/scripts’ directory in GW.
Ensure the following:
– Script runs as PN user from the GW.
– PN should be down in both GW and Units.
Step 2 Run the script file using the below command:
perl resetVneSSHv2Algorithms.pl
Step 3 Start the PN in GW and Units to reflect the changes.
Adding Managed Elements to the Database Manually for PC-FM Resync
After upgrading Prime Network, you can execute BQL commands to invoke a VNE insert operation in a new MANAGED ELEMENTS table for all the existing MANAGED ELEMENTS.
Execute the below BQL commands, which has a VNE name “CopyAllManagedElementsToDB” and IP “0.0.0.0”.
Note Make sure to execute the BQL command before restarting PNIL. BQL execution will not introduce any new VNE, but only performs DB refreshing for all the existing VNE’s; inserts all Managed Elements to DB.
<?xml version="1.0" encoding="UTF-8"?>
<management.IElementManagement type="management.IElementManagement" instance_id="0">
<ID type="Oid">{[MCNetwork][MCVM(IP=X.X.X.X)][ElementManagement(Key=CopyAllManagedElementsToDB)]}</ID>
<IP type="com.sheer.types.IPAddress">0.0.0.0</IP>
<ElementName type="String">CopyAllManagedElementsToDB</ElementName>
</management.IElementManagement>
Note Replace X.X.X.X in the above BQL with Gateway IP Address.
To terminate the further processing of BQL, an Exception that will be returned as part of the response to the BQL must be invoked (Invocation of this Exception is an already available approach used for Validating the input values while creating a new VNE through Modelling tabs.)
Note The below exception message is expected after executing the BQL:
“<Description type="String">ERROR (5133): The VNE's name contains invalid characters. valid chars are: A-Z, a-z, 0-9, _, '@', '!', '~', '.', ' '.</Description>”
For details on BQL and other integrations after the upgrade, refer to the Cisco Developer Network at https://developer.cisco.com/site/prime-network/.