β11-11-2011 05:02 PM
Hello
We are trying to delete orphaned archives from our environment and have hit a hurdle.
Environment: Enterprise vault 9.0.1, SQL 2005 SP2, Centera - Basic Mode.
Settings: 2 Retention categories - 1 being used for all archives, another modified by me for this specific purpose, both have "Prevent archives from deletion" Unchecked, they are'nt locked. Both inherit expiry from site level. Difference being the one in production has retention of forever and one I modified has retention of 1 day.
Site properties have Process vault stores set to "Never" on storage archives and "Users can delete items" is not enabled/checked.
Issue: We are unable to delete archives, DTRace lines from Storage Delete Component being:
Solved! Go to Solution.
β11-12-2011 06:56 AM
β11-11-2011 07:23 PM
β11-12-2011 04:24 AM
Hi, I would say I am 60% sure as I mentioned that based on old configuration details I had.
I will re-check and confirm rest 40%.
β11-12-2011 06:56 AM
β11-13-2011 06:08 PM
Your Centera is not in basic mode so that is your issue:-
16148 23:13:26.206 [248] (StorageDelete) <8848> EV:M CVaultStoreEMCCentera::SetPool -- Compliance Device mode: True
I do not know what sort of access you have to your centera but if you have Centera Viewer and you can connect you want to run the command show security all and that will tell you what mode your centera nodes are in.
From your DTRACE you can see that there is an expiry on the CLIP:-
ClipGetExpiryDate -- Clip-Id: ECLDOU0DLI1PEe0M9M7BLFO8QVEG4126IM62SL0DFAH6UV25LSOK6, Expiry date: 2958190.018449
β11-14-2011 08:34 AM
Thanks a lot guys for your review and you are right that DTrace does shows compliance.
However the replica IP address it shows (snipped in the DTRace uploaded) - are pointing to old centera nodes - we have configured EV to point to new centera which is in Basic mode.
So - just wondering why storage service is pointing to old centera for deletions and if anything could be done to bypass/workaround this..
β11-14-2011 08:41 AM
Please ignore my previous response. I see why Enterprise vault is pointing to old centera..
Basically we have three partition for the vault store - two of which are closed. One of them is being reported in these DTRace logs.
So the next question will be why Enterprise vault is trying to delete archives from a closed partition?
β11-14-2011 08:44 AM
Also, if someone knows or have a sample of successful deletion DTRace log lines which I can look for in my side of DTRace to see any items is getting deleted from original Partition/Centera
β11-15-2011 08:35 PM
Ajay,
So the next question will be why Enterprise vault is trying to delete archives from a closed partition?
So if you are deleting archives and the items were archived in what you call your old partition then why would it not try to go to that Centera as that is where those archived items are right?
That partition in the partitionentry table will have an ip address List and replica ip address list which will be pointing to your old Centera. Are you saying that all the data that was on your old centera is on your new centera and you want the deletes to be performed on there? Not quite following what you are saying here.
Also, if someone knows or have a sample of successful deletion DTRace log lines which I can look for in my side of DTRace to see any items is getting deleted from original Partition/Centera.
Below are some important snippets from a deletion of an archive on my test system whose 5 items were stored on a Centera:-
CDeleteVault::DeleteSavesets Information: Total [5] savesets were found.
{CVault::DeleteItemFromCenteraStorage} (Entry)
{CVault::DeleteItemFromCenteraStorage}|Store Identifier: 0VTUI6RF62170e5VC20ILJV1OA8G416EFV2PG90VF7RUH3TUB4EJ1
CVaultStoreEMCCentera::ClipDeleteCentera -- Calling FPClip_Open|Clip-Id: 0VTUI6RF62170e5VC20ILJV1OA8G416EFV2PG90VF7RUH3TUB4EJ1|VaultStoreId: 107225EC78D98914FA558B36CBC20137F1210000evalias|VaultId: 189741B0CD7D15B45A92E295246C30D5D1110000evalias|SavesetId: 201111141237896~201110260609020000~Z~10F5DDD0E16BB480A7608AB4D17ACD21
{CVault::DeleteItemFromCenteraStorage} (Exit) Status: [Success]
{CDeleteVault::DeleteArchive}|Archive emptied
{CDeleteVault::DeleteArchive}|Index deleted
{CDeleteVault::DeleteArchive}|Storage database records removed
{CDeleteVault::DeleteArchive}|Archive deleted from Directory
β11-16-2011 12:48 AM
Thanks Paul - You got my point correct.
Basically all centera storage data was copied from old device to new device. The old device still exist though but in compliance mode. And new device being in Basic mode.
I am thinking if I point all partitions in vault store group to the new centera device - it should look for savesets/clip IDs in the new centera and delete from there accordingly?
Thanks for the sample success lines.
β11-16-2011 02:44 PM
Yeh it is not something I have ever tried myself and cannot repro to test but it sounds logical enough that if you but the IP details of your new centera into the sql columns for your closed partition then it should go to your new centera.