A question which is sometimes asked on the Symantec Connect forums is:
What happens when an archive is deleted? Is the white space used up again straight away or after some period of time?
This type of question, as you might be able to tell, comes straight from an Exchange Administrator. Microsoft Exchange has the concept of white space in its databases, and therefore it is assumed that Enterprise Vault operates in a similar way.
That’s not the way that it works.
Remember here we are talking about deleting the whole archive. A similar process to the one described below happens when you delete an individual item within an archive, but also remember what an end-user deletes is governed by the shortcut deletion policy and can be:
- The shortcut
- The archived item and the shortcut
And the whole ‘is a user allowed to delete items’ is a different conversation in itself (but, remember the setting is on the Site Settings in the Vault Admin Console).
These settings and policies aren’t used when an administrator deletes an archive from the Vault Admin Console.
It is also worth noting that Enterprise Vault doesn’t have any nightly maintenance routines though several of the background/maintenance type tasks can be scheduled for the night time, if required. (Eg Storage Delete, Collections/Migration, Archiving, etc)
In Enterprise Vault there are five areas to consider when deleting a whole archive:
- Storage space on disk on the Vault Store Partition
- Storage space in the Vault Store database or databases, and the Vault Store Group Database (aka Fingerprint database)
- Entries in the Journal Delete table
- Information in the Index for the archive
Let’s look at each one of these in turn:
Storage space on disk on the Vault Store Partition
When a whole archive is deleted from the Vault Admin Console, effectively every item in the archive gets ‘unarchived’. There is a whole process which has to be gone through for each item in order to delete it, before the archive itself can be deleted. This is why it often takes some time before the archive is actually removed.
Remember also archive deletions can only be done one at a time in the Vault Admin Console (You can’t multi-select) and that there is currently no API for deleting archives.
As each item is deleted the DVS* files will be removed from disk, on the Vault Store partition. This space on disk will then just be reused as needed to store new data.
Storage space in the Vault Store database or databases, and the Vault Store Group Database (aka Fingerprint database)
Again as each item is deleted, entries in the save set table and others will be removed. Entries will also be updated and / or removed from the fingerprint database (see “Sharing” below).
Entries in the Journal Delete table
Sometimes it seems odd when this is mentioned: There will also be an increase in the number of rows in the JournalDelete table in the Vault Store database. This table is used as part of the process to provide updates for the building and usage of Vault Cache and Virtual Vault. As part of the deletion process for an item, entries are added to the Journal Delete table, thereby potentially growing this table in SQL.
Information in the Index for the archive
I’ve never really been sure whether the individual items are removed from the archive, or the whole archive is removed after the archive is deleted. However, either way around, the index will be removed at the end of the archive deletion, freeing up some space there. Space freed up on disk in this manner will be reused for new data as required.
The amount of free space on disk from the Vault Store Partition which is recovered will depending on the sharing level of the Vault Store, and the amount of shared data. There are situations where deleting an archive will free up virtually no disk space on the Vault Store partition (for example an archive which contains mostly large items which shares a vault store with a journal archive and sharing is enabled within the vault store). For the most part though ’some’ disk will be reclaimed when an archive is deleted.
So in summary then you can see that deleting an archiving is a little bit more involved than you might first think. There are several components to take into account over and above the raw disk space taken up by the files on disk. All this can take time, and it can quite often seem that the archive deletion has gotten stuck doing the delete. There are a few ways to check whether the process has actually got stuck, which I wrote about here.
Have you experienced delays when deleting archives? Have you been surprised by how much or how little disk space was eventually recovered when deleting a large archive? Let me know in the comments below.