Upgrading Broadband Access Center
This chapter describes how to upgrade a Cisco Broadband Access Center for Cable (BACC) 2.6.2.7 installation to Cisco Broadband Access Center (BAC) 4.0. If you have a BAC release preceding BACC 2.6.2.7, you must first upgrade your system to BACC 2.6.2.7 and then complete this upgrade procedure.
This BAC release supports online migration, using which you can migrate one server at a time without disrupting the entire BAC deployment.
Caution
Before upgrading to 4.0, ensure that you obtain the license file that this release supports. Once the upgrade is complete, the installation program deletes all existing license keys. You must then install the license file that 4.0 supports using the administrator user interface. For details on obtaining and installing the license file, see the
Release Notes for the Cisco Broadband Access Center 4.0.
Table 5-1 summarizes the upgrade tasks required for the different BAC components.
Table 5-1 Upgrading to BAC 4.0
|
|
|
Network Registrar Extension Points
|
|
BACC 2.6.2.7 Note Migration of RDU database is required |
Run pkgadd. At the end, the installer prompts you to run the migration tool. |
Run pkgadd to upgrade the DPE. |
Run pkgadd to upgrade the Network Registrar extensions. |
Run pkgadd to upgrade the KDC. |
When upgrading to 4.0 from 2.6.2.7, you must enter a new target location for these directories:
–Home (BPR_HOME)
–Data (BPR_DATA)
–Database logs (BPR_DBLOG)
Note Once the upgrade is complete, BAC does not restart the process watchdog (bprAgent) automatically. You must migrate your existing database first.
The BAC online upgrade procedure requires that you upgrade the components in the order specified below. Performing the upgrade in any other order results in errors during provisioning.
1. Before You Begin
2. Upgrading the RDU
3. Upgrading the DPE
4. Upgrading Network Registrar Extensions
5. Upgrading the KDC
Before You Begin
Before upgrading BAC components, ensure that you back up the RDU database files.
To back up the RDU database, run the backupDb.sh script in the BPR_HOME/rdu/bin directory.
For example:
# backupDb.sh /var/backup
where /var/backup identifies the database backup directory.
In this example, all backup database files are stored in a directory called /var/backup/rdu-backup-20071116-031028. The last subdirectory (rdu-backup-20070316-111028) is automatically created with a current time stamp.
Note The time-stamped subdirectory format is rdu-backup-yyyyMMdd-HHmmss. In this example, the subdirectory would be rdu-backup-20071116-031028, meaning that the directory contains a backup that was started at 3:10:28 a.m. on November 16, 2007.
For additional information on using the backupDb.sh tool, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
Upgrading the RDU
Before upgrading the RDU, we recommend that you archive your files in the BPR_HOME/rdu/conf directory.
To upgrade the RDU:
Step 1 Disable access to the RDU from the operations support system.
Step 2 Back up the existing RDU database, using the backupDb.sh tool. For details, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
For example:
# /opt/CSCObpr/rdu/bin/backupDb.sh -nosubdir /disk1/backup
•-nosubdir—Disables the automatic creation of a subdirectory. If you do not use this option, a subdirectory is created and reported to the console.
•/disk1/backup—Identifies the location for the database backup files.
Step 3 Verify if the database has been backed up by checking the history.log file, which resides in the BPR_DATA directory.
Step 4 Restore the database that you have backed up to a consistent state, using the recoverDb.sh tool. For details, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
For example:
# /opt/CSCObpr/rdu/bin/recoverDb.sh /disk1/backup
where /disk1/backup identifies the location of the database backup files.
Step 5 Copy the backed-up database to a safe location.
Step 6 If the operating system (OS) on which the existing BAC version runs does not meet the requirements for the 4.0 release, upgrade the OS.
Step 7 Install the 4.0 version.
For example:
# pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac
The installation program prompts you to enter locations for the:
•Home directory (BPR_HOME)
•Database directory (BPR_DATA)
•Database logs directory (BPR_DBLOG)
It then upgrades the necessary libraries and property files but leaves your RDU database intact. After installation is complete, it prompts you to migrate your RDU database.
Step 8 After the installation is complete, upgrade the RDU database by following the steps described in Migrating the RDU Database.
Upgrading the DPE
Before upgrading your DPE, we recommend that you archive your files in the BPR_HOME/dpe/conf directory.
To upgrade the installed DPE from BACC 2.6.2.7 to BAC 4.0:
Step 1 Run the pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac command.
Output similar to the following appears. The output has been trimmed for brevity.
Processing package instance <CSCObac> from </var/CSCObac.pkg>
Welcome to the Cisco Broadband Access Center for (BAC) installation program. This
installation program installs BAC on your system.
Press Enter to Continue or q to Quit:
Upgrading BAC from 2.6.2.7 to 4.0. Are you sure? [n]: y
Stopping BAC Process Watchdog...
File installation completed.
Installation of <CSCObac> was successful.
Step 2 To verify if the version information indicates BAC release 4.0, enter:
# pkgparam CSCObac VERSION
Step 3 You must manually restart the DPE process to finish the upgrade process.
For example, from the command line, run:
# /etc/init.d/bprAgent start dpe
Upgrading Network Registrar Extensions
Before upgrading Cisco Network Registrar extensions, we recommend that you archive your files in the BPR_HOME/cnr_ep/conf directory.
To upgrade the Network Registrar extensions from BACC 2.6.2.7 to BAC 4.0:
Step 1 Run the pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac command.
Step 2 Stop the Network Registrar Server Agent when prompted.
The upgrade script automatically copies the upgraded extension point files to the required directories. When complete, it prompts you to restart the Network Registrar Server Agent.
Step 3 To verify if the output information indicates BAC release 4.0, enter:
# pkgparam CSCObac VERSION
Step 4 Go to the BPR_HOME/lib directory. If the upgrade was successful, the directory content appears similar to the list of installed files for the DPE upgrade with the addition of the libbprextensions-2x.so file.
Step 5 If a second check is required to verify upgrade success, go to the CNR_HOME/extensions/dhcp/dex directory and verify that these files appear:
-rwxr-xr-x 1 root bin 60904 Oct 29 2003 libdexextension.so
-rwxr-xr-x 1 root other 1530628 Jul 22 12:43 libbprextensions-2x.so
-rwxr-xr-x 1 root other 1560748 Aug 11 12:49 libbprextensions.so
Depending on the components installed, the directory content shown in this procedure may differ from the output featured above.
Upgrading the KDC
Note The BAC 4.0 KDC requires a new license. Before you start the BAC process watchdog, ensure that the correct license and certificates are installed.
To upgrade the KDC from BACC 2.6.2 to BAC 4.0:
Step 1 Run the pkgadd -d BAC_Solaris/CSCObac.pkg -a BAC_400_Solaris/bacadmin CSCObac command.
Step 2 Manually start the BAC process watchdog to complete the upgrade process.
Step 3 To verify if the output information indicates BAC release 4.0, enter:
# pkgparam CSCObac VERSION
Migrating the RDU Database
The RDU database migration script lets you migrate your RDU database from BACC 2.6.2.7 to BAC 4.0.
Migrating involves two distinct phases:
1. Phase 1—This phase is performed after BAC in installed and is executed via the migrateDb.sh tool.
2. Phase 2—This phase is executed when the RDU is first started up after the first phase of migration is complete.
The migration script (migrateDb.sh) is automatically installed when you run the BAC 4.0 installation program (pkgadd). Migration is accomplished by reading from the original database and writing it into a new database. For this purpose, you must allocate additional disk space for accommodating the newly created database.
The status of the first phase of migration is recorded in a migration log file, which is stored in the migrated database directory. The migration.log file identifies the version of the database that is being migrated and provides status messages for the migration process.
Note Migration deletes any outstanding jobs stored in the database, such as reliable batches that did not finish execution or pending Configuration Regeneration Service (CRS) jobs.
Backwards Compatibility
You can use the 4.0 RDU with a migrated database to operate with earlier versions of Solaris DPEs and Network Registrar servers for gradual online migration.
Migration preserves the device record revision numbers used in DPE synchronization. As a result, DPE repopulation is not triggered after the RDU database upgrade, ensuring the least disruption until you upgrade the specific DPE.
Note This BAC release provides multivendor support via Option 43 and its suboptions. When using this option, ensure that you modify templates used in earlier releases to be compatible with the template grammar that BAC 4.0 uses.
Migration Performance
A large BAC RDU database can be several gigabytes in size, and may take an extended length of time to migrate. The length of time that database migration takes depends largely on your hardware. Using faster disks improves the time significantly.
Migration automatically compacts your database that may be fragmented. However, this BAC release stores additional data for every device. You can expect the size of the database to increase after migration by as much as 10 percent.
The migration process is optimized for speed and database compactness. As a result, migration requires a large amount of process heap size (memory). For example, migrating a 7-million device database requires approximately 1,024 MB of process heap size. Because the migration process is limited to 4 GB of heap space, migration is effectively limited to a database size of approximately 25-30 million devices.
The -Xmx parameter in the migrateDb.sh script determines the maximum process heap size for migration. The default setting of 3,072 MB for this parameter is sufficient for migrating a 20-million device database. You may need to fine-tune this setting to suit your environment. For example, to migrate smaller databases running on low-end systems with less memory, you can reduce the value of the maximum heap size setting. For databases that exceed the maximum supported scale, you may need to increase this setting.
To change the heap size parameter, in the migrateDb.sh script edit the value for the -Xmx parameter.
Licensing After Migration
The licensing scheme changes significantly in this release. You cannot use the license keys from earlier versions of BAC to provision your network using BAC 4.0. Any existing license keys are automatically deleted during database migration. To configure BAC licensing, you must obtain the license files via a license claim process and install them using the administrator user interface. For details, see the Release Notes for Broadband Access Center 4.0.
During migration, device counters are recalculated based on the number of devices in each provisioning group found in the database. New counters are recorded in the new database and used for licensing.
RDU Extension Migration
During database migration, custom extensions are reset to 4.0 defaults. Custom extensions must be updated to operate in the 4.0 environment. If you require custom extensions after migration, you must add them using the administrator user interface. For details, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
Migration of Duplicate Class of Service and Node Name
This BAC release does not support duplicate names across technologies for Class of Service and nodes. If BAC detects duplicate names during database migration, the duplicate entries are automatically renamed in the following format:
•Class of Service—{Technology_Name}_{Original_ClassOfService_Name}
•Nodes—{Node_Type}_{Node_Name}
For example, if BAC encounters a gold Class of Service for a computer and a DOCSIS modem, either the computer Class of Service is renamed Computer_gold or the DOCSIS modem Class of Service is renamed DOCSISModem_gold. The appropriate warnings are issued to the console and migration log, and all properties containing the specific Class of Service value are automatically updated.
Verifying Database Integrity
We recommend that you perform a dry run of the migration process on a staging (nonproduction) system, instead of on a live system during RDU downtime. These steps may not be practical during live migration, because in the case of a large database, verification can take an extended length of time.
To verify the database:
•Before migration, run the verifyDb.sh tool on a backup snapshot.
Note To verify the database before migration, use the verifyDb.sh tool from the BAC installation corresponding to the version of the database. You cannot verify a nonmigrated database with the BAC 4.0 version of verifyDb.sh.
For example, enter:
# /opt/CSCObpr/rdu/internal/db/bin/verifyDb.sh -dbdir /disk1/backup
This pathname is specific to the BAC installation version before migration.
•After migration, run the verifyDb.sh tool on the migrated database.
For example, enter:
# /opt/CSCObac/rdu/internal/db/bin/verifyDb.sh -dbdir /disk2/target
For details on the verifyDb.sh tool, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
RDU Migration Workflow
Migrating the RDU database consists of two phases:
1. Phase 1—This phase is executed after installation via the migrateDb.sh tool.
2. Phase 2—This phase is executed when the RDU is first started up after the first phase of migration is complete.
Table 5-2 describes the process of migration using examples that assume that:
•BAC is installed in the default home directory (/opt/CSCObac).
•The backup of the previous version of the RDU database is located in the /disk1/backup directory.
Table 5-2 RDU MIgration Workflow
|
|
|
Step 1 |
Select two disk partitions: one for the migrated database, and another as a temporary storage directory for the database transaction logs. Note For performance reasons, we recommend that you configure these disks on a fast I/O system, such as a RAID array with battery-backup write cache or a RAM disk. For details on migrating using a RAM disk, see Migrating Using a RAM Disk. The partitions that are used in the examples in this procedure are: •Volume /disk2/target—Used to write the migrated database data. The available disk space for the migrated database should be at least 120 percent of the size of the original database (which is the bpr.db file in the backup directory). •Volume /disk3/target—Used as the temporary storage directory. The available space on the temporary storage disk must be at least 2 GB. For performance reasons, however, we recommend that you locate this directory on a different disk from the backup database and the target database location. |
Solaris documentation |
Step 2 |
Run the migrateDb.sh tool on the backed-up database. The migrateDb.sh script resides in the BPR_HOME/migration directory. For a description of all arguments that this tools supports, see Using the migrateDb.sh Tool. For example:
# /opt/CSCObac/migration/migrateDb.sh -dbdir /disk1/backup
-targetdbdir /disk2/target -targetdblogdir /disk3/target &>
/var/run/migration-console.log &
•-dbdir—Specifies the location of the database backup that is to be migrated; in this case, /disk1/backup. •-targetdbdir—Specifies the target location where the migrated database should be placed; in this case, /disk2/target. This directory is created automatically during migration and must not exist before the script is executed. •-targetdblogdir—Specifies the target location for the temporary migration transaction log files; in this case, /disk3/target. This directory is created automatically during migration and must not exist before the script is executed. Note New database log files are created in this directory and later destroyed automatically during migration. Once migration is complete, all the necessary files are automatically copied from this directory to /disk2/target. After migration, you can delete this directory. |
Cisco Broadband Access Center Administrator Guide 4.0 |
Step 3 |
Observe the migration progress using the migration.log file. For example:
# tail -f /disk2/target/migration.log
|
Solaris documentation |
Step 4 |
Verify if the migration is complete using the migration.log file. If you find any warnings or notices, use the grep command-line tool. For example:
# tail /disk2/target/migration.log
Tue Oct 16 15:36:20 EDT 2007: Phase 1 of RDU database migration to
BAC 4.0 completed with 1 warning(s) and 2 notice(s).
# cat migration.log | grep "WARNING"
Tue Oct 16 15:57:23 EDT 2007: WARNING: Duplicate Class of Service
name [cg814wg_chn_n05] detected for [CableHomeWanMan] technology.
Class of Service object was renamed to
[CableHomeWanMan_cg814wg_chn_n05].
# cat migration.log | grep "NOTICE"
Tue Oct 16 19:06:23 EDT 2007: NOTICE: A deprecated property
[/dhcp/client-policy/response/boot-file] was found on object with
oid [2882304375712137210]. Property will be declared as custom
property.
Tip You may also find it useful to examine the device statistics printed at the end of the migration.log file.
|
Solaris documentation |
Step 5 |
Restore the migrated database into the target directories for the 4.0 RDU. This process copies the migrated database to the RDU BPR_DATA and BPR_DBLOG directories. For example:
# /opt/CSCObac/rdu/bin/restoreDb.sh /disk2/target
Note Once the migration process is complete, you can delete the content of /disk2/target and /disk3/target directories. |
Cisco Broadband Access Center Administrator Guide 4.0 |
Step 6 |
Start the RDU process from the BAC watchdog process command line, and look for messages on successful initialization in the rdu.log file. For example:
# /etc/init.d/bprAgent start rdu
|
Cisco Broadband Access Center Administrator Guide 4.0 |
Step 7 |
Verify if the second phase of migration has started. For example, rdu.log should include similar messages:
bac-test.example.com: 2007 10 17 02:36:28 EDT: %BAC-RDU-6-0695:
[Starting Phase 2 of RDU db migration].
|
Solaris documentation |
Step 8 |
Observe the progress of the migration. For example, rdu.log should include similar messages:
bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695:
[Progress report for selection process...].
bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695:
[Selection process stats: Read a total of 400000 DOCSISModem device
records].
bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695:
[Selection process stats: Read a total of 400000 device records].
bac-test.example.com: 2007 10 10 02:50:36 EDT: %BAC-RDU-6-0695:
[Selection process stats: Ran selection on 398228 eligible
devices].
|
Solaris documentation |
Step 9 |
Verify if the second phase of migration is complete. For example, rdu.log should include a similar message:
bac-test.example.com: 2007 10 17 03:28:58 EDT: %BAC-RDU-6-0695:
[Completed Phase 2 of RDU db migration].
bac-test.example.com: 2007 10 17 03:28:58 EDT: %BAC-RDU-6-0695:
[RDU db migration has been finalized].
Also, you can check if the BPR_DATA/rdu/DB_VERSION file indicates the database version as 4.0. |
Cisco Broadband Access Center Administrator Guide 4.0 |
Note Migration preserves the device record revision numbers used in DPE synchronization. As a result, DPE repopulation is not triggered after the RDU database upgrade, ensuring the least disruption until you upgrade the specific DPE. |
Step 10 |
Verify the RDU operations by logging in to the administrator user interface. From Servers > RDU, you can check the RDU version and device count statistics. |
Cisco Broadband Access Center Administrator Guide 4.0 |
Using the migrateDb.sh Tool
Table 5-3 describes the arguments that you can use with the migrateDb.sh tool.
Table 5-3 Arguments for migrateDb.sh Tool
|
|
|
|
|
-dbdir dir |
Specifies the location of the database backup that is to be migrated |
P |
|
None |
-dblogdir dir |
Specifies the location of the database logs that are to be migrated |
|
P |
The directory that the -dbdir option specifies |
-targetdbdir dir |
Specifies the target location where the migrated database will be placed |
P |
|
None |
-targetdblogdir dir |
Specifies the target location in which the migrated database transaction log files are stored temporarily during migration |
P |
|
None |
-cachesize value |
Specifies, in MB, the size of the memory cache. This paramater is optional. If you use this parameter, you must not exceed the 100-MB limit, unless you reduce the value of the -Xmx variable in the migrateDb.sh script by double the increase in the cache size. For example, if you set cache size to 200 MB, you must reduce the value of -Xmx thus: (200-100)*2 = 200 MB |
|
P |
100 MB |
-cmtsv value |
Specifies the CMTS DOCSIS version that is to be used during service selection. The service is selected based on the minimum version that the CMTS and the cable modem supports. The DOCSIS version that the cable modem supports is determined by the value of the dhcp-client-identifier option. The acceptable values are: •1.0 •1.1 •2.0 |
|
P |
1.1 |
-help |
Specifies usage for the tool |
|
P |
None |
You can use a number of arguments, as described in the following section, to specify the Class of Service and DHCP Criteria for promiscuous devices. These arguments are optional, provided the default objects, as specified here, exist in the database. The first phase of migration uses these objects to select the service for the devices granted promiscuous access. During the second phase of migration, the standard selection process for each device is performed according to the policies found in the RDU database. Any discrepancies are addressed in favor of the configuration found in the database. However, the migration process is most efficient if few discrepancies are encountered.
Tip While it may not be possible for you to specify these policy objects accurately if devices of the same type use different promiscuous policy objects, migration will be more efficient if you specify the most frequently used promiscuous objects.
|
-pcospc value |
Specifies the name of the most frequently used Class of Service for promiscuous computers |
|
P |
unprovisioned-computer |
-pcosmta value |
Specifies the name of the most frequently used Class of Service for promiscuous MTAs |
|
P |
unprovisioned-packet- cable-mta |
-pcoschwd value |
Specifies the name of the most frequently used Class of Service for promiscuous CableHome WAN-Data devices |
|
P |
unprovisioned- cablehome-wan-data |
-pcoschwm value |
Specifies the name of the most frequently used Class of Service for promiscuous CableHome WAN-MAN devices |
|
P |
unprovisioned- cablehome-wan-man |
-pcoscpe value |
Specifies the name of the most frequently used Class of Service for promiscuous custom CPE |
|
P |
unprovisioned- customcpe |
-pdcpc value |
Specifies the name of the most frequently used DHCP Criteria for promiscuous computers |
|
P |
genericCPE |
-pdcmta value |
Specifies the name of the most frequently used DHCP Criteria for promiscuous MTAs |
|
P |
genericCPE |
-pdcchwd value |
Specifies the name of the most frequently used DHCP Criteria for promiscuous CableHome WAN-Data devices |
|
P |
genericCPE |
-pdcchwm value |
Specifies the name of the most frequently used DHCP Criteria for promiscuous CableHome WAN-MAN devices |
|
P |
genericCPE |
-pdccpe value |
Specifies the name of the most frequently used DHCP Criteria for promiscuous custom CPE |
|
P |
genericCPE |
Migrating Using a RAM Disk
The RAM disk is a Solaris feature that allows you to mount a portion of the RAM as a disk volume. Disk I/O operations on such volumes are considerably faster and can be useful when you have large databases on systems with sufficient memory.
The procedures described in this section are optional and describe how to create and use different RAM disks to migrate your database instead of a regular disk volume, such as a fast RAID array with battery-backed write cache:
•Creating RAM Disk Volumes for Migration
•Using the RAM Disk Volumes for Migration
Creating RAM Disk Volumes for Migration
The following procedure creates three volumes for migration and assumes that the size of the original database is 9 GB. Adjust the volume sizes as required for your database and according to what the available memory permits.
Using the following procedure, you can create three RAM disks that you could use for migration:
•/ram-disk1—To contain the source database
•/ram-disk2—To contain the migrated database directory
•/ram-disk3—To contain the temporary migration transaction logs
Step 1 Ensure that enough memory is allocated to the RAM disk in the /etc/system file. This figure is a percentage of the total RAM on the system. Assuming a 64-GB RAM, this setting dedicates 32 GB to the RAM disk.
For example:
set ramdisk:rd_percent_physmem=50
Note If you also set the segmap_percent parameter, which determines the quantity of memory allocated to the OS I/O buffer cache, make sure that there is sufficient memory for both settings and some space is left for the OS operation.
Step 2 Reboot the system.
For example:
Step 3 Create three RAM volumes.
For example:
# ramdiskadm -a volume1 10g
# ramdiskadm -a volume2 12g
# ramdiskadm -a volume3 2g
Step 4 Create new file systems on each volume.
For example:
# newfs /dev/ramdisk/volume1
# newfs /dev/ramdisk/volume2
# newfs /dev/ramdisk/volume3
Step 5 Mount the volumes.
For example:
# mount /dev/ramdisk/volume1 /ram-disk1
# mount /dev/ramdisk/volume2 /ram-disk2
# mount /dev/ramdisk/volume3 /ram-disk3
Step 6 Verify the mount points and their size.
For example:
Using the RAM Disk Volumes for Migration
To use the RAM-disk volumes that you have created for migration:
Step 1 Copy the backup of your database to /ram-disk1.
For example:
# mkdir /ram-disk1/backup
# cp /disk1/backup/* /ram-disk1/backup/.
Step 2 Perform the first phase of migration according to the procedure that Table 5-2 describes. Remember to use a command similar to the one described here instead of the one mentioned in Step 2 of the table.
For example:
# /opt/CSCObac/migration/migrateDb.sh -dbdir /ram-disk1/backup
-targetdbdir /ram-disk2/target -targetdblogdir /ram-disk3/target
&> /var/run/migration-console.log &
Step 3 To ensure that the second phase of migration is executed with the database of the RAM disk:
a. Install the 4.0 RDU such that the database directory and the database logs directory (defined by the BPR_DATA and BPR_DBLOG variables, respectively) point to the volumes on the RAM disk.
b. After the second phase of migration is complete, stop the BAC process watchdog, using the /etc/init.d/bprAgent stop command from the BAC process watchdog command line.
c. Back up the database using:
BPR_HOME/rdu/bin/backupDb.sh -nosubdir /ram-diskX/migrated-db/
–BPR_HOME—Specifies the home directory, which is by default /opt/CSCObac.
–X—Specifies the RAM disk to which the RDU database is migrated.
d. Edit the bpr_definitions.sh file that is found in the home directory (by default /opt/CSCObac) and change the BPR_DATA and BPR_DBLOG locations to new directories located on permanent storage drives.
e. Recover and restore the database to the new RDU locations. Run the recoverDb.sh and the restoreDb.sh scripts, respectively, using:
BPR_HOME/rdu/bin/recoverDb.sh
where BPR_HOME specifies the home directory, which is by default /opt/CSCObac.
BPR_HOME/rdu/bin/restoreDb.sh /ram-diskX/migrated-db/
–BPR_HOME—Specifies the home directory, which is by default /opt/CSCObac.
–X—Specifies the RAM disk to which the RDU database is migrated.
For details on using these scripts, refer to the Cisco Broadband Access Center Administrator Guide 4.0.
f. Start the process watchdog, by running the /etc/init.d/bprAgent start command.