For the SEP I have implemented this steps: http://www.symantec.com/business/support/index?page=content&id=TECH104792
so I wonder what is the equivalent steps for Enterprise Vault 8.0 SP4
SQL Server 2005 SP3 database maintenance plan ?
Solved! Go to Solution.
Your question is really for a DBA who manages your EV databases or any SQL databases.
From what I can see on the technote it is the same but backing up the EV databases of course. We use SQL maintanance plans too and it is the same steps.
Just a couple of things about that white paper:
It recommends shrinking the database and update statistis which is absolutely pointless.
Shrinking the database highly fragments the SQL indexes, takes a long time to complete, won't shrink it all that much and plus causes performance issues as it starts to grow and does the autogrowth part making the disk queue lengths go higher etc.
SQL Will re-use the empty white space that has been left behind from a deletion, so its not like you are going to grow bigger and not reclaim the white space at one point or another.
Also it says update statistics...if you rebuild your indexes, a full rebuild does an update statistics anyway, so its a waste of time
I found that in smaller companies, there is not really a DBA. There might be someone with experience, but the maintenance described in the article is the one to be followed. Leaving ou the reindexing can be beneficial, but this should be checked with Symantec Support to be sure.
I understand what you are saying Gertjan regarding smaller companies, however, Enterprire Vault is an Enterprise application/product and the core of Enterprise Vault is SQL, and for a company small or large to not have a DBA to support such application/product? I think that needs to be looked at first before thinking about buying/using such application/product. I know it's all about budget etc. but when something majorly goes wrong with EV relating SQL, Support will awlays ask for a DBA to deal with such issues, where/what would that company do? A good example is when an upgrade goes major wrong, I personally will not perform an upgrade if I don't have a DBA on standby to support me, regardless company large or small.
Actually Gertjan is pretty much on the money, you wouldn't believe the amount of calls i took when i was in support when they stated "I *AM* the DBA, how do i truncate a log file?"
LOL...me too....and there I was thinking....how the f**k did you get the DBA job in the first place.
Hence my point was, *DBA expert* is required to support enterprise product that uses SQL as the sore.
*edit core even.
Intersting thread this turned out to be. If there is a solution the OP used please mark it as resolved so others dont try to help where it is not needed .
That said I know this is one of those area's for debate that I have heard DBAs fight over (when they have had a few). At the end of the day, I completely agree that if SQL is in use there should be a DBA... and know that frequently there is not (IME in every size company short of an enterprise). I also know that in the instance that there is not one, SYMC will always reccomend the practices in these documents until someone (like JW2 or MSFT) shows that they are wrong AND the documenation is updated to reflect the "better" practices.
Although JW2 may be technically correct... i know a handfull of people who would argue with him about it (think Mac vs Windows PC but much more geeky). I would say that best practices released are really just good practices and the real best practices are those good practices you have applied and modified to fit your organizations needs.
When in doubt... follow the technote... it is what they will tell you to do anyhow.