Restoring indexes of the journal archive

[ZeNick]

Dear forumers,

During my holidays, someone had the good idea to click the "Rebuild index" in the "Advanced" tab of the journal archive properties. I let you guess the result...

I restored all the index folders relative to this archive presents in 4 locations:

...\Index3\1C3D86...._16841217
...\Index6\1C3D86..._5308419
...\Index7\1C3D86...
...\Index8\1C3D86..._10985960
...\Index8\1C3D86..._23042654

After restarting the EV services, the Index in Index7 was scanned and the event said that it was full and needed to create another index, that is normal.
The problem is that it created a new folder ...\Index8\1C3D86..._5308550 and started to rebuild it instead of considering the other restored folders.
I guess that it should have jump to the folder ...\Index6\1C3D86..._5308419 as the range number is very near.

How can I force EV to take in consideration the other restored folders?

I have EV8 SP3 on WS2003SP2

Many thanks for your help as I can't wait until the end of June the completion of the rebuild...

[Liam_Finn1]

First you need to stop the rebuild process. This can be done by going into SQL to the EnterpriseVaultDIrectory database
In the table IndexVolume you need to fine the name of the index you want to stop the rebuild on bu using the IndexFolderName. Once you have identified the correct index you need to change the colume Rebuilding which will be set to True, set this to False

Close SQL

Stop the Indexing service
Next restore the index folders for this index back to your server
Start the indexing services again

[JesusWept3]

This is a tricky one, restoring the indexes WOULD normally work, but what you actually did was rebuild, which deletes all the index volumes from the database that way when you actually run the restore and you do an update, sure it will see the first, roll over, but it will then go to a random Indexing location thats open, and the problem with that is, it probably isn't where your indexes were located

the best thing you can do is try and get an older copy of your EnterpriseVaultDirectory database, restore it to a temp sql server and get the copy of the IndexVolumes for that journal index and reinsert them in to your active database

otherwise the next best thing you can do is restore your physical indexes to one index volume, close all the index locations and then when the index rolls over, it can only go to the open index location

[ZeNick]

Hello,

Thank you for your answer.
Regarding Jesus's answer, your second idea seems interesting but I'm not sure to understand this: "restore your physical indexes to one index volume". Could you please develop?

I also though about another way to resolve this, could you please tell what you think about it?
- Stop the index rebuild
- Copy the content of the old 1C3D86..._5308419 to the newly created one (or rename the newly created one with the name of the old one)
- restart the index rebuild

Thank you for your help.

[ZeNick]

Just for information, the manipulation I mentioned in my previous post didn't worked, it would have been to easy...

I've deleted the newly created folder ( ...\Index8\1C3D86..._5308550) and restarted the indexing service. The result was that exactly the same folder has been created.

Then, I suppose that there may be a problem with the first part of the index (...\Index7\1C3D86...) .
When I look at the properties of the journal archive in the "Index Volumes" tab, it appears the following informations :

Range                            Status             Location                     Total Items     Failed Items     From Date                        To Date
1 - 5308549                  Normal           F:\Indexes\Index7      5308460        87                        31/12/1979 17:00:00     19/02/2009 15:03:59
5308550-5315395      Rebuilding     F:\Indexes\Index8      8640               0                          06/05/2004 16:34:33     19/02/2009 16:23:35

It's strange that the range of Index7 is from 1 to 5308549 whereas Total Items are 5308460.
It also appears that there are 87 Failed Items in this index but there are no "IndexMissing.log" file in this index.

Do you any idea about the next steps I should follow?
Can I launch an update of the Index7 while the Rebuild of the Index8 is running?

Many thanks for your help and advices

[Liam_Finn1]

Yes you can do an update or repair of index 7 while index 8 is rebuilding.

However I think it would be best to wait until index 8 is finished. Then do a repair on index 7 and at the same time dtrace indexserver and indexbroker so if there are any further errors while fis=xing the missing items you have a DTrace to offer to support if needed.

Doing the DTRace while index 8 is rebuilding will just mean you get all the index 8 and index 7 traces in one file and that will mean a pain in the butt to track the repair process of index 7

[ZeNick · Accepted solution]

Finally, I found the solution.
Here are the steps:

- Stop the indexing service
- Restore all the index volumes for the archive
- restart the indexing service
- Wait for a new index volume to be created (the previous one should appear as Full in the event log)
- Stop the indexing service
- Go to the SQL table "IndexVolume" and search for the newly created index volume
- replace the data in the column "IndexRootPathEntryId" with the Id of the index folder containing the restored index volume that should have been considered
- replace the data in the column "folder name" with the name of the restored index volume that should have been considered
- restart the indexing service and check that the modifications are appearing in the "Index Volumes" tab of the archive's properties.
- Check the event log and if a new event saying that the index is full appears, restart the steps with the next index volume.

Bye!