The VLDB repair rebuilds the VLDB database. It recursively walks the eDirectory tree down from the management context container, and records information about the Volume objects it discovers in a repair database. On completion, VLDB repair activates the repair database, which replaces the current active database. If there are two replica sites, the replica automatically gets synchronized to the active repaired database.
Until the repair database is activated, all VLDB requests (that do not explicitly specify that they are referencing the repair database) act against the existing database. Thus, clients can access DFS junctions even while the VLDB is being repaired for those volumes that still have correct entries in the VLDB.
Make sure you perform the VLDB repair as an administrator user with sufficient eDirectory rights to access the necessary objects in the eDirectory tree. Otherwise, VLDB Repair cannot scan the entire tree within the DFS management context, and the repair is done only for those areas where you have sufficient rights. Problems that occur as a result of logging in with a username with insufficient rights (and any other errors such as crashed servers or eDirectory problems) are logged in the repair log. Administrators should review the system log to look for errors. DFS modules log error conditions to the repair log file (located at /var/opt/novell/log/dfs/vlrpr.log on Linux and sys:\etc\vlrpr.log on NetWare).
In iManager, select.
Select any server with an NSS volume that is located in the DFS management context that you want to manage.
This action locates the DFS management context, lists the servers in that context that host instances of its VLDB service, and reports the current status of the VLDB service on each replica.
Select the check box next to the VLDB replica site that you want to manage.
IMPORTANT:If you have two replica servers, run the VLDB repair from only one of the servers.
Selectto open the page.
Select one of the following repair levels, then click OK:
Replace the VLDB with Its Last Saved Copy: The repair option restores the last saved copy of the database. It uses the automatically created backup file that it creates whenever it writes out the database. On completion of the repair, restart the VLDB service.
Copy the VLDB from the Context’s Second Replica Site: You can use this feature only if you have the VLDB service running on more than one server. The VLDB service gets a copy of the database from another server that is currently running the service. On completion of the repair, restart the VLDB service.
Rebuild the VLDB by Walking the eDirectory Tree: When you rebuild a database, the VLDB service walks the eDirectory tree, looks at volume and server objects, and then completely rebuilds the database from scratch.
Monitor the status of the rebuild periodically until it is done. This can take from a few minutes to a few days, depending on the repair level you chose.
During the repair, the status reports that it is. If the option is selected, on completion of repair, DFS automatically reloads the VLDB service on the replica server, then activates the VLDB, changing the state to . If there is a second replica site, its copy of the database is automatically synchronized to the repaired database.
Review the repair log to look for VLDB repair errors: