A reader asked:
We have five dedicated replicas servers on campus. I’ve always been told in the past that when running a DSRepair we needed to do all servers holding replicas at the same time. Is this true? Can they be done one by one sequentially?
And here are the responses from Forum experts Jim Henderson and Aaron Burgemeister …
Jim: It’s not *always* true – in some cases, if you’re fixing a problem that can be replicated from one server to another, locking the DIB on all servers in the ring simultaneously prevents the problem from syncing from server A to server B while repair is running on Server C.
There is no “rule of thumb” for this – it all depends on what exactly you are trying to fix. It is important to understand *what* you are trying to fix and *why* it is a problem. I see this a LOT with customers – they run DSREPAIR, but often cannot tell me why they are running it.
Please see the Cool Solutions article at:
for some guidelines on using DSRepair appropriately and for an understanding of what exactly it is that the tool is intended to be used for.
Aaron: Here are some quick, general, mildly-qualified rules of thumb for DSRepair …
1. If you are not trying to fix things but want to see if things are “strange,” use iMonitor. Some permissible use of DSRepair for monitoring include time sync, report sync status, and check external references; however, ALL of these can be done from within iMonitor and should be. Remember: monitor != repair … you don’t check your oil level by draining it all out, you use the dipstick).
2. If you are going to do a repair, you shouldn’t use the Unattended option unless you have a really good reason, and those essentially don’t exist anymore. If you need to fix something try to fix that one thing instead of throwing your entire database through the DSRepair blender. Usually, things will be okay if you run the repair but some rare situations could cause pain and suffering you will not want to deal with. Don’t hammer nails with shotguns … find problems and troubleshoot them specifically if at all possible.
3. Few things require all replicas to have repairs run at once. When they do, the databases have to be locked – so logins would not normally be permitted. If you have a problem that big, chances are you are either on the phone with Novell support or you have that shotgun out again. The only issue that comes to mind requiring this scenario is a transitive vector issue, which is a pain to troubleshoot in the first place (maybe it’s just me).
As I help others with definite problems on a daily basis, I avoid running repairs unless necessary, and it rarely is. Exceptions include timestamping obituaries,
fixing transitive vectors, running a normal repair, etc.
Jim: DSRepair is not a maintainence tool, it’s a fix tool. Using it properly requires that you understand the problem first – don’t use it for a shotgun approach to troubleshooting, as you will nearly always get yourself in deeper by doing that.
That’s why I wrote the article I referenced – and that’s based on discussions with the engineer who maintains DSRepair these days. I agree about 10,000% that unattended full repair just should not be used; it is truly the sledgehammer of the repair options – and if you’re to the point of using a sledgehammer, you really should be on the phone with support.