Fixing WPHOST.DB Files


Fixing WPHOST.DB Files

To discuss repairing a post office database (WPHOST.DB), it's best to look at some examples. The scenarios in this section will help you explore the different options for system maintenance on a WPHOST.DB file.

System Maintenance: Validate, Recover, and Rebuild

For scenario #1, a post office agent (POA) of a particular post office supporting 400 users is attempting to load. It will not load; instead, it produces a C022 error.

When the GroupWise POA of any post office loads, it first interacts with the WPHOST.DB file, and then loads the NGWGUARD.DB file. The question is which one of those files is to blame for the C022 error? Well, it's hard to tell. You might suspect that the WPHOST.DB file is damaged. If you rebuild the WPHOST.DB file, there's a 50% chance you'll fix the problem. Your WPHOST.DB file is 48MB, and in the past, rebuilding this file has taken about an hour; an expensive proposition when you only think the problem is the WPHOST.DB file!

A better solution is to use the Validate Database option from the System Maintenance tool (see Figure 22.1).

Figure 22.1. Validate Database is the first choice on the GroupWise System Maintenance menu


Tip

Chapter 7 discusses how the choices in the System Maintenance menu can be used.


The Validate Database routine runs a quick structural analysis of a WPHOST.DB file to see whether it is physically consistent. The validate routine usually takes under a minute.

One possible outcome when you run the Validate Database routine is to get the error shown in Figure 22.2.

Figure 22.2. An error can occur during validation of a WPHOST.DB file


If this error appears, you know that your theory was rightthe WPHOST.DB file is damaged, and rebuilding it is the appropriate course of action.

For scenario #2, Mary Smith's name has changed to Mary Jones. You changed her name, but in one post office's address book, Mary's name will not change to Mary Jones.

In this kind of a scenario, you should be less likely to immediately suspect gross structural damage to the WPHOST.DB file. It is more likely that, for some reason, Mary's change isn't being sent down to the post office. Perhaps there is a message-flow problem. The simplest course of action is the following:

  1. Synchronize Mary's object. Highlight it, select the Tools menu, and choose GroupWise Utilities, Synchronize.

  2. Watch the POA for the post office on which Mary's name did not change.

In this fictitious example, the POA reports a DBxx error (the xx represents any two characters) when trying to update Mary's object. The question becomes whether Mary's is the only object in this WPHOST.DB file that can't be updated. You need to determine whether you can change information about other users.

To troubleshoot this possibility, the administrator will do the following:

  1. Synchronize another user.

  2. Watch the POA for the post office on which Mary's name did not change.

Suppose that the POA didn't report an error when rewriting this other user object to the WPHOST.DB file. However, on further investigation in the POA log file, you do see other DBxx errors on user objects besides Mary's.

You can conclude that there is definitely a problem with Mary's object in this one WPHOST.DB file. The problem is not specific to Mary's object record, however. It is specific to the block of records in the same location in the WPHOST.DB where Mary's object record is. A few other users' object records are also located in that damaged block in the WPHOST.DB file, which accounts for the other DBxx errors.

You can assume that there is minor structural damage to the WPHOST.DB file at this particular post office that's getting the error.

Now, suppose that when you discover this problem, it's 10 a.m. on a Tuesday. To rebuild a WPHOST.DB file, the POA must be down so that you have exclusive access to the WPHOST.DB file.

Rebuilding the WPHOST.DB file to fix this problem is out of the question. It's not system-critical, because users aren't complaining. You've just stumbled across a problem that you know must be resolved eventually. Suppose also that at your organization you have a very involved procedure to follow if ever you must have downtime during business hours. You want to avoid that procedure.

The system maintenance routine to run in this scenario is called Recover Database.

Recovering a WPHOST.DB file does not require exclusive access to it. You run a Recover Database routine and, after doing so, synchronize Mary's object. There should no longer be errors when you're synchronizing Mary's object.

The Recover Database routine quite often does not fix WPHOST.DB damage. In the preceding case, all it did was remove the damaged block of records. Your synchronization of Mary's object was required to complete the fix, because the recover routine just cut out the mushy bad part of the database, but it didn't replace the records that were lost. This is because the Recover Database routine only extracts information from the same WPHOST.DB file that you are trying to recover. The Recover Database routine is working with an information source that you already know to be questionable. If you can use the Recover Database routine to help you get along, that's great, but it should be considered a Band-Aid approach to get you past business hours. After hours, you should rebuild the WPHOST.DB file.

The ultimate fix to your problem with a WPHOST.DB file is almost always to rebuild it. The reason you would use the other options under System Maintenance is that they are less intrusive (you do not have to bring the POA down). You must have exclusive access to the WPHOST.DB file to rebuild it or replace it. The POA is generally the only entity with this file open. However, bringing down the POA in some organizations is a big deal, so you must try to limp along with a damaged WPHOST.DB file. The validate and recover options are really stop-gap measures until you can rebuild the WPHOST.DB file.

General Notes on Repairing Post Office Databases

The great thing about GroupWise architecture is that WPHOST.DB files can always be rebuilt, and with a guarantee against data loss. This is because everything written to the WPHOST.DB file is guaranteed to have been written to its owning domain's WPDOMAIN.DB file. When rebuilding a WPHOST.DB file, GroupWise administration is doing so from the perspective of the post office's owning domain.

The system maintenance routines are not the best way to resolve all GroupWise directory problems, however. For example, if a user's record is missing or incorrect from a post office's address book, synchronizing the user might be a simpler fix. Synchronizing a user's object, or any GroupWise object for that matter, repropagates that object to all GroupWise directory databases. This is far, far better than rebuilding every database on the system just to fix one record.



NOVELL GroupWise 7 Administrator Solutions Guide
Novell GroupWise 7 Administrator Solutions Guide
ISBN: 0672327880
EAN: 2147483647
Year: 2003
Pages: 320
Authors: Tay Kratzer

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net