Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
LMS Database Troubleshooting
This document applies to CiscoWorks LAN Management Solution 3.1 through Cisco Prime LAN Management Solution 4.1.
LAN Management Solution uses Sybase-like embedded databases from SQL Anywhere. Each of the main applications in LMS contains at least one database. Assuming all of the LMS is installed (including the Health and Utilization Monitor add-on), a server will have the following database engine processes. NOTE: LMS 4.x will have all of these databases installed except where noted:
LMS Application (Device Management Function)
Resource Manager Essentials (Inventory, Config and Image Management)
Campus Manager (Network Topology, Layer 2 Services and User Tracking)
Health and Utilization Monitor (Device Performance Management)
Changing the Database Password
By default, the LMS installer will set all of the databases password to a random value. If there is a need to access the database directly (for troubleshooting purposes), or if you notice errors in the logs pertaining to database login failures, you made need to change the database password. These login failures typically look like:
java.sql.SQLException: JZ00L: Login failed.
Examine the SQLWarnings chained to this exception for the reason(s).
To change the database password for any of the SQL Anywhere databases in LMS use the dbpasswd.pl command. This command is found in the NMSROOT/bin directory. NMSROOT is the path into which LMS was installed. By default, this is C:\PROGRA~1\CSCOpx on Windows and /opt/CSCOpx on Solaris and the LMS appliance (LMS 4.1 only). You can either change the password on all databases, or change the password on a specific database. To change the password on all databases, use the following command:
Solaris and the LMS appliance:
NMSROOT\bin\perl.exe NMSROOT\bin\dbpasswd.pl all
NOTE: On the LMS appliance (LMS 4.1 only), you must enter the root shell mode in order to perform any of these commands. To enter the root shell, connect to the appliance as the sysadmin user (this username can be changed at installation time), then enter the command shell. When prompted, enter the root shell password password.
NOTE: Daemon Manager must be shutdown prior to changing the database passwords. To shut down Daemon Manager, run the following command:
Solaris and the LMS appliance:
net stop crmdmgtd
To change the password of individual databases, you must specify the datasource name (DSN). You can use the listdsn argument to dbpasswd.pl to get a list of all DSNs. To save you some time, the following table lists the DSN for each of the databases in LMS.
opsxml (LMS 3.x only)
Run the dbpasswd.pl command with the dsn argument to change an individual database password. For example, to change the RME (Inventory, Config and Software Image Management) database password, run the following command:
If an LMS server crashes or is not properly powered off, a database's transaction log may become corrupted. It is certainly also possible for the database itself to be corrupt; however, since LMS uses transactions, there is a bigger chance that only the transaction log will be corrupted. Typically, it is apparent that transaction log recovery needs to be done if the pdshow command reports that the database engine is in a "Never started" or "Failed to start" state (although the latter could indicate more serious database corruption).
To recover when a database transaction log becomes corrupted, first shutdown Daemon Manager. See the steps in the section on changing the database password on how to shutdown Daemon Manager.
Once Daemon Manager is shutdown, delete the database's transaction log if it still exists. The transaction logs will be found in the database directory. This is NMSROOT/databases/DSN where DSN is the database datasource name. See the table in the section on changing the database password to get a list of datasource names. For example, the CMFDEngine (Common Services database) transaction log will be in NMSROOT/databases/cmf. The log file will be named DSN.log (e.g. cmf.log). These log files are binary, and should not be opened.
Once the database transaction log has been deleted, the database must be forced closed (i.e. indicating that there are no more pending transactions). This is done using the dbsrv10 command. For example, to force the cmf database closed (thus allowing it to start properly), use the following command:
It may be that a database file itself becomes corrupted. The can happen after a server crash, or if a file system runs out of disk space (or a variety of other causes). There is no one symptom of this. The most obvious symptom is that pdshow reports the database as "Failed to start" (though in rare cases, this could be a symptom of transaction log corruption). You may also note assertion errors in the /var/adm/CSCOpx/log/daemons.log (on Solaris and the LMS appliance) or NMSROOT\log\syslog.log (on Windows) files. You can also check for most types of corruption by running validation on the database DSN. For example, to validate the cmf database, run the following command:
Reinitializing a database will destroy ALL data associated with that database. If you need to reinitialize the cmf database, you will lose ALL data in ALL LMS applications. Therefore, it is highly recommended that you perform regular CiscoWorks data backups so that you can restore your data if you encounter database corruption.
Below are the commands to reinitialize each of the databases. If you reinitialize multiple databases, you must do so in the right order. The list below is in the correct order. If you reinitialize the cmf database, you should reinitialize ALL databases. Before reinitializing the database, you must shutdown Daemon Manager. See the instructions above in the section on changing the database passwords on how to shutdown Daemon Manager.
Note: All three of the DFM (Fault Management) databases (dfmInv, dfmEpm, and dfmFh) should be reinitialized at the same time. DFM (Fault Management) also uses another datastore which must also be deleted. After reinitializing the DFM SQL Anywhere databases, delete the DFM.rps and DFM1.rps files under NMSROOT/objects/smarts/local/repos/icf.