Forum Discussion

Rob_dos_Ramos's avatar
15 years ago

Deleting Vault Store partition

 Hi All

Storage Deletion is running very slowly and I am running out disk space. I need to delete one of the partition. Storage deletion is running far to slowly on our site so I need to make a plan. 

If I delete the data directly from the drive will it leave the indexes in the searches? Is there a way I can delete the data directly from the drive is there a way I can delete the index entries? 

Thanks.

Rob
  • what version of EV are you running? because its possible in EV8 that those items are shared, regardless of how old or what their retention is, so if you were to just blow away a vault store partition, you'd end up breaking other peoples email.

    Honestly you'd be best off getting new storage and being a bit more aggressive about the Storage Expiry, because it isn't going to get any easier or lighter from here

9 Replies

  • Hi Rob

    I highly advice against deleting things on your own from the filesystem.
    You create an inconsistency you would later have to clean up using EVSVR.

    How did you delete the items in the Partition?
    At which rate is Storage Deleting running?

    /Michel
  •  Hi MichelZ

    Thanks for the fast reply.

    I have not deleted anything yet. If I try and delete the partition via the EV console it states that it cannot be deleted because it is not empty. Storage deleting is deleting 1600 items per hour. So during our weekend storage expiry run it will delete about 2 million items. Before we upgraded to version 8 we where doing about 4 million items per weekend run. 

    Right not if there is a way to delete the data and then run a tool to get rid of the idexes I am willing to take that chance as I am running really low on disk space. 


  • You're best off letting EV handle the deletes- otherwise you're going to create a good deal of work for yourself in the long run.  If Storage Expiry is the bottleneck I would reccomend that you review the SQL Maintenance plans you have in place for the EV databases, particularly the Vault Store databases.  In my experience most performance problems with Storage Expiry fall back on SQL. 
    This technote is very detailed and can be helpful if you don't already have a regular maintenance plan in place. 
    http://support.veritas.com/docs/332255

    The key thing to take away is:

    It is recommended that the following SQL maintenance procedures be performed weekly for all EV, CA, and DA databases in the order listed:
    -Rebuild Indexes
    -Update Statistics
    -Shrink Databases

    Hope it helps!
  •  Thanks for Reply Jolaine

    I ran a connectivity test on the vault store and the connection to the SQL server and the result it gave back was "bad". Could this be the problem? 

    Rob


  • Connectivity could be bad for a few reasons. Speed of the network, Contention on the SQL server because it is busy. Slow Disk performance on the SQL server causing slowness in accessing the data on the SQL server

    Do some data gathering on the SQL server with PerfMon to see whats causing it to operate slowly would be my first step

    If it is Paging then maybe you need more memory in the SQL server
    If it is very high disk transactions then you need more spindles to handle the IO to give the throughput needed

  • Do you guys know of a way to force delete a Vault Store Partition from the VAC? The one Partition in our vac was created and closed well out of our retention category
  • what version of EV are you running? because its possible in EV8 that those items are shared, regardless of how old or what their retention is, so if you were to just blow away a vault store partition, you'd end up breaking other peoples email.

    Honestly you'd be best off getting new storage and being a bit more aggressive about the Storage Expiry, because it isn't going to get any easier or lighter from here
  • We are running version 8

    Been going through the SQL and the Update Stat has improved the performance by 25% which is great but it still not the same rate that we where doing storage deletion.

    We are running sharing in the whole Journal group so it might be that. Will have to dig a little more to figure out the problem.