07-14-2013 01:45 AM
Hello,
Is there any particular recommendation/precautions to be taken in order to increase the disk space of the SQL Server that is hosting the Enterprise Vault as well as the increasing the disk space of the EV Server?
Basically, I need to increase the disk space of both servers EV/SQL. They are virtualized servers.
Thanks,
Solved! Go to Solution.
07-14-2013 03:08 AM
Assuming your OS's can stand to have drives extended.. then the best course is to stop all SQL Server services, and all EV Services.
Do a full backup of both machines.
Expand the drives
Bring SQL back online
Bring EV back online
One other consideration with EV is that you might want to consider splitting some of the additional things (Cache, Index, etc, etc) on to DIFFERENT drives. So don't just extend the ones you have, but create new ones too.
07-14-2013 01:47 AM
Article:TECH70262 | | | Created: 2009-01-05 | | | Updated: 2013-06-18 | | | Article URL http://www.symantec.com/docs/TECH70262 |
07-14-2013 01:54 AM
Thanks for you reply, the provided document doesn't address on how increase the disk space of the EV Server nor the SQL server. Its a general guidance on how implement/monitor..
07-14-2013 02:18 AM
There isn't really anything specific when it comes to increasingthe space allowed for your SQL Server.. nor your EV server.
The only things to think about on your EV server is WHY do you need to increase it. Is it because you need more vault store partition space to store more archived data? Is it because you need more server cache space for buiding Vault Cache for users? Is it becuase you're running low on your OS drive, because of temporary files?
I mean, it would help if you gave information related to your user populate, activities and archiving types in EV, and the current sizes you have for different aspects of EV (and SQL)
07-14-2013 03:02 AM
Hi Rob,
Thanks for you reply.
Yes, both of the server giving low disk space. the SQL Server gives on the C:\ Drive 4.9 GB out of 40 GB and the EV Server gives on both the C:\ 10 GB out of 40 Drive where the OS installed as well as the E:\ 39.4 GB out of 150 GB where the EV vault/partitions/Cache/
Cache
Data
DB
Ev Forms
Index
PST
07-14-2013 03:08 AM
Assuming your OS's can stand to have drives extended.. then the best course is to stop all SQL Server services, and all EV Services.
Do a full backup of both machines.
Expand the drives
Bring SQL back online
Bring EV back online
One other consideration with EV is that you might want to consider splitting some of the additional things (Cache, Index, etc, etc) on to DIFFERENT drives. So don't just extend the ones you have, but create new ones too.
07-14-2013 03:23 AM
Thanks Rob for your advise, Is there any procedure/documentation on how to split the Cache from current drive to different drive?
Is there any other recommendations related to the drive split such as Index / EV Form etc etc...
I will plan that on Friday and I will update this thread.
Highly appreciate your responses.
Regards,
07-14-2013 03:58 AM
Well, moving the cache location is pretty straight forward, you just point it to a new disk / folder on the properties of the server in the VAC.
Indexing should be separate also. If you have full indexing enabled and you have 1 Tb of archived data (or plan for that) then your index volume will need to be 'roughly' 12-15% of that.
Lots of information in the planning guide that comes on the media.
07-15-2013 05:59 AM
You can take help from for Indexing space issue:
Index Storage has consumed all available disk space in Enterprise Vault (EV).
07-15-2013 08:07 AM
If you add more disks to the Enterprise Vault server, you can move the indexes from one location to another:
http://www.symantec.com/docs/TECH51450
Also, if you are running out of space in the C:\ drive, make sure that the TEMP directory for the vault service account is off of the system drive:
http://www.symantec.com/docs/HOWTO56890
For the SQL server side, review the maintenance plan and make sure that the plan is truncating the transaction logs. I have seen customers running out of space on SQL because the transaction logs were not being truncated properly. I'm not sure if you have had a chance to take a look at this TN, but just on case here it is:
http://www.symantec.com/docs/TECH74666
I hope this helps.