The documentation changes associated with this new function follow. NetView Management Console User's Guide (SRL GC31-8852-01) ---------------------------------------------------------- The entire section entitled NetView Management Console Topology Server Databases has been rewritten as follows: 3.1.6 NetView Management Console Topology Server Databases The topology server databases are used to save server information between restarts of the server. The server information contained in these databases includes: * Resource data for all resource types * Operator data for all operators that have logged on * View data for all saved views * Command data for all customized commands When the topology server starts, it will load the data from the first server database directory that contains a loadable database. Table 49 lists the four server databases, in the order that they are searched for loadable databases. ---------------------------------------------------------------- | Table 49. Topology server databases | ---------------------------------------------------------------- | Name | Location | ---------------------------------------------------------------- | Current | For Windows: %BINDIR%\TDS\server\db\current\ | | | datab | | | For UNIX: $BINDIR/TDS/server/db/current/ | | | datab | ---------------------------------------------------------------- | Backup | For Windows: %BINDIR%\TDS\server\db\backup\ | | | datab | | | For UNIX: $BINDIR/TDS/server/db/backup/datab | ---------------------------------------------------------------- | Custom Backup | For Windows: %BINDIR%\TDS\server\db\ | | | custom_backup\datab | | | For UNIX: $BINDIR/TDS/server/db/ | | | custom_backup/datab | ---------------------------------------------------------------- | Default | For Windows: %BINDIR%\TDS\server\db\default\ | | | datab | | | For UNIX: $BINDIR/TDS/server/db/default/ | | | datab | ---------------------------------------------------------------- The default database contains the initial (default) server information. When the server is started for the first time after installation, the default database is loaded (the current and backup databases do not contain server information when the server is loaded for the first time after installation). The current and backup databases will contain the most recent copy of the server information once the server has been stopped or checkpointed. Generally, both the current and backup databases contain identical server information, but there are some cases in which only the current database is updated with server information. See 3.1.6.1 Writing Server Information to the Topology Server Databases for more information. The custom_backup database is used to save a customized version of the server information at a known level of customization. This database is not continuously updated by stopping or checkpointing the server. Use this database to protect your server information from undetected database corruption. Subtopics: * 3.1.6.1 Writing Server Information to the Topology Server Databases * 3.1.6.2 Handling Corrupted Topology Server Databases * 3.1.6.3 Creating and Importing Customized Backup Copies of the Topology Server Databases 3.1.6.1 Writing Server Information to the Topology Server Databases Writing server information to the topology server databases is also known as checkpointing. Server information is written to the topology server databases either manually or automatically. The default database is never written during a database checkpoint, and serves as a bootstrap database if one or all of the other databases become corrupted. The other databases are written based on the type of checkpoint requested. Server information is written to the topology server databases automatically for the following reasons: 1. The autoCheckpointInterval or autoCheckpointDaily properties of the server properties file have been enabled. An explanation of these properties is contained in the server properties file. For more information on the server properties file, see "Customizing the Server Properties File" in topic 2.2.1.1. All server information is checkpointed to the current database. If the checkpoint completes successfully, the current database is then copied to the backup database. Note: The default setting for these properties result in automatic checkpoints at 1 AM every day. 2. A view is customized and saved to the topology server. Only the files that changed as a result of the view customization will be written, and they will be written only to the current database. 3. The command profile editor batch utility is run. Only the files that changed as a result of the command customization will be written, and they will be written only to the current database. 4. The topology server is shutdown. All server information is checkpointed to the current database. The backup database is not copied until the server is restarted. If the current database is successfully loaded during the ensuing server startup, the current database is then copied to the backup database. To manually write information to the topology server database, use either the tserver utility -c command or the tserver utility -cc command. The tserver utility -c command manually checkpoints all server information to the current database. If the checkpoint completes successfully, the current database is then copied to the backup database. The tserver utility -cc command manually checkpoints all server information to the custom_backup database. The custom_backup database is used to save a customized version of the server information at a known level of customization. The custom_backup database is meant to override the default database when the current and backup databases become corrupted. For more information on how to use the custom_backup database, see "Creating and Importing Customized Backup Copies of the Topology Server Databases" in topic 3.1.6.3. If your installation has a large number of customized views or commands, it is recommended that the tserver utility -cc command be used whenever you make significant changes to the customized views or commands. This allows you to restore the server information to a known good copy of the database that contains your recent customizations if the current and backup databases become corrupted. 3.1.6.2 Handling Corrupted Topology Server Databases It is possible for one or more of the topology server databases to become corrupted. A database corruption can cause the server to fail to start, or can cause the server to behave abnormally once it has started. One or both of the server processes (the topology data server and/or the topology communications server) might end as a result of corrupted databases. The reasons for topology server database corruption include, but are not limited to: * The topology server process is incorrectly stopped. For example, stopping a topology server process by closing the topology server window instead of using the tserver stop command. Abruptly stopping the topology server in this manner prevents it from properly updating the databases before it stops. * The file system used by the topology server runs out of space, preventing the topology server from updating its databases. * The topology server encounters an internal failure, which results in the topology server stopping abnormally. The default and custom_backup (if created) databases are not likely to be corrupted. Most database corruptions are the result of a corruption in the in-storage copy of the database. The in-storage database is only written to the current and/or backup databases. As a result, the default or custom_backup databases represent your recovery databases. If you suspect a database corruption problem, perform the following steps: 1. If the server is running, stop the server. 2. Make a backup copy of the current and backup database. You may want to recover these databases if the problem turns out not to be a database corruption problem. 3. Restart the topology server. The topology server will attempt to detect database corruption on initialization. If database corruption is detected, the server will attempt to restore from the next loadable database. See Table 49 for the database recovery order. 4. If the server successfully starts, then your database has been recovered. If the server does not start, stop the server and continue with the next step. 5. Erase the current database. 6. Restart the topology server. This automatically copies the backup database to the current database. If the server successfully starts, then your database has been recovered. If the server does not start, continue with the next step. 7. Erase both the current and backup databases. 8. Restart the topology server. At this point, the database has been recovered from either the default database or the custom_backup database (if you are using a custom backup). If the topology server successfully starts, then the problem was that the original contents of both the backup and current database directories were corrupted. If you previously saved a copy of the databases, you can optionally use the saved copy to restore the topology server databases, as described in "Creating and Restoring a Permanent Copy of the Topology Server Databases" in topic 3.1.6.3. If the topology server does not start, then the problem is not due to corrupted databases. Refer to the IBM Tivoli NetView for z/OS Troubleshooting Guide and locate the section "Diagnosing NMC and GMFHS Problems" to continue problem determination. 3.1.6.3 Creating and Importing Customized Backup Copies of the Topology Server Databases If you plan to make a large number of view or command customizations, you should create a customized backup copy of the database to insure that your customizations are not lost in the case of server database corruption. Note: If possible, you should always perform customizations on a test, or non-production, server. The following procedure requires that the server be stopped and restarted. To create a customized backup copy of the server databases, perform the following steps: 1. Start (or restart) the server BEFORE any customizations are done, if possible. Having a freshly started server reduces the risk of any corruption to the in-storage database; a server that has been active for many weeks or months may have an in-storage corruption that has not yet been detected. 2. Perform the customizations. 3. Enter the following command and wait for the command to complete successfully before proceeding to the next step: tserver utility -cc 4. Stop the server. 5. Delete all files in the current database directory; do not delete the directory itself. 6. Copy all files from the custom_backup database directory to the current database directory. 7. Start the server. Verify that the server does not issue an error message that indicates the database is corrupted. To import the custom_backup database directory to other servers, perform the following steps: 1. Stop the server which the database is to be imported to (the import server). 2. Copy the custom_backup directory from the test server to the custom_backup and current directories on the import server. 3. Restart the import server.