Hi,

We have faced this situation twice wherein we had our broker-pers corrupted. This has happened twice already. Whenever the hardware crashes and the broker-pers gets corrupted due to a partial binary write by wME, is there a fast and effective way to recover the same? Is there any alternative recovery mechanism for the same?

TIA
wmfan

It has happened to us and we were not able to recover it.

You can schedule nightly backup of the data directory (in NT it could be C:\wment41\data\awbrokers\default). You will have to stop the ES before taking backup. I recommend to do it nightly batch.

If the broker-pers file is corrupted just replace the contents with the backup.(Make sure you stop the ES before copying)

Ofcouse if it is development server, you will loose one day worth of work.

If you don’t do it, it is mess. You should have your adl files and stop/start the adapters in all the resources to recreate teh client groups etc.

hope this helps
-Ramesh

Just like Ramesh I have run into the situation where the Broker-pers file has gotten corrupted. The only recovery we were able to do at that point was to send the corrupted file to wM support and they sent us back the equivalent of an adl file that could be viewed in a text editor.

One BIG warning to using backups though. It is not necessary to backup the broker-pers to save design-time development work. There is no design-time development information stored in the broker-pers file. For design-time information such as event types and other configuration the broker-guar is used.

Now to the warning. If you backup a broker-pers on a nightly basis and then use it to recover after a corrupted broker-pers, then you will run the risk of redelivering any persistent events that were stored in the broker-pers file at the time of backup. You should be able to handle any such duplication of data in your process without corrupting your resources.

Worst of all, trying to recover from backed-up broker-pers file will cause you too loose any eventes that were queued at the time of corruption.

My recommendation is that you stay away from persistent storage. Use guaranteed for canonical events and volatile for everything else (within reason).

Rgs,
Andreas Amundin
www.amundin.com

Also it is important to note that that there are some subtle dependencies between the three files (Broker-pers, Broker-guar, Broker-guar.log). Sometimes you can swap out Broker-pers files and sometimes doing so will cause corruption/failure in the Broker-guar file. The only sure recovery mechanism if replacing any of the files is to replace all of the files with a set of all three backed up at the same time (and while the broker server is off).

Additionally, even though as developers we shouldn’t use the persistent storage, wM does so internally for several items up to and including enterprise v 4.6, so it is used, even if we don’t use it. Persistent storage should not be used, btw, because at high volume levels there is a bug that can cause data corruption in the persistent store. The two-phase commit mechanism of the guar file seems to protect it from a similar fate at high volumes (the information is buffered through the Broker-guar.log file before entering the Broker-guar file).

Enough for now. Very busy! Sowwy!
-greg

I too have been bitten by the persistent bug. In my case, I believe it was a patch that caused the problem. Unfortunately, I don’t remember the patch number. Here are the details I do remember:

Version 4.1
Patch installed newer files:
Adapter40JNI.dll dated 10/16/01 in the bin directory
adk40.jar dated 10/16/01 in the lib directory

Restoring the originals corrected my ongoing corruption problem.

Is there some event that causes the corruption issue? It seems strange that the Broker-pers would go corrupt randomly.

Adding to Dan’s question, is there a way to prevent Broker-Pers from getting corrupted?

The way to best avoid it is to never use the Persistent storage type when creating client groups. If you have client groups that use Persistent, change them to Guaranteed or Volatile. Advantage FAQ has a discussion on changing the storage type of a client group.

Other people may have experienced differently, but I’ve not encountered corruption problems IF I avoid using Persistent for the client groups I create. As Greg pointed out, wM uses Persistent in many places (VI uses it extensively) but I haven’t seen any trouble caused by that. But as I said, someone else may have seen something–perhaps they can share their experience?

Perhaps it’s more prevalent with 4.1.1? I’ve been working with 4.1 only.

The only time the broker-pers have been corrupted in my experience is when the server has been shut down ungracefully. Both times it involved sudden loss of power to the server.

Andreas
www.amundin.com