just curious to see if anyone out there has previously encountered an issue with the Repository.xml file reaching its hard limit of 2GB? The result of this is that EV fails 1000's of indexes before stopping, then it won't come back online.
I have a fairly good idea how to deal with it, although I'm still figuring out the details, but before I go down a particular path, I'd be interested to hear about any lessons learned if you have any?
How many volumes are on that indexing server as the repository.xml contains an entry for each index volume? Have you tried to rename the file and start indexing service? This should allow the file to be rebuilt.
There have been rare occassions where there a numerous volumes per user archive that are not valid and contain no items. These can be removed to reduce the amount of entries that are contained within the xml file.
I have gone through rebuilding the repository.xml file, also re-installed indexing, this is affecting 3 out of 4 servers, the problem is due to the infrastructure design it seems; the indexes are stored on relatively small LUNs and so every few months the customer closes off the open indexes and opens new ones on the next LUN, hence, for even small indexes, there are many index volumes and so they've reached the limit of the repository.xml file. From memory I recall seeing 196,000 volumes before it stopped adding any more.
Support suggest adding an index server group and moving indexes there to rebuild them in to single volumes and then move them back, but I am looking for some ideas to try to get indexing back online without adding more servers as doing so will take quite some time and expense
Unfortunately, the only resolution is to reduce the number of volumes that the indexing server manages so that the contents of the xml are reduced. The best option would be the group and rebuild the archives. Then after many have been completed you could rebuild the repository.xml