Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

EV8 Database problem

Created: 19 May 2009 • Updated: 22 May 2010 | 24 comments
This issue has been solved. See solution.

We have a small enviroment and we have one server that is running SQL 2005 and EV8.0 together. We have a small c partion for the program files and a large D partion for all the data. When setting up the SQL server and the EV setup we created databases on the D partiton and pointed the vault stores to this place. Today I have noticed that we are running out of space on the C partiton and we found that there is a database under the SQL program files folder. Does anyone know what this database is for and can it be moved to the D partition? I hope this makes sense...

Thanks.

Todd Anderson

Comments 24 CommentsJump to latest comment

TonySterling's picture

Hey Todd,

You can track down the database by looking in the properties of the database in the SQL management console.

Most likely it can be moved using standard sql steps to move databases.

Cheers,

Todd Anderson's picture

There is nothing that needs to be changed in the EV configuration?

TonySterling's picture

nope, not if you are staying on the same sql server. 

TonySterling's picture

Also, what is the name of the file?  Do you know that it is an EV database?

Todd Anderson's picture

Thanks Tony...one last thing, Is it a bad idea to have SQL and EV running on the same server with only 425 users, can we expect bottlenecks down the road?? Should I take the time to move SQL to another server now before I get to much further into this project?

Thanks

Todd

Todd Anderson's picture

Yes, the file name is EVVSExpressVaultStore_1.mdf

TonySterling's picture

I always recommend SQL to be on it's own server.  There was a post earlier today about someone with performance issues where EV mbx and jrnl was on the same SQL server.  :)

Might as well do it now before it grows into a problem.

TonySterling's picture

Ah, OK.  Yep that is an EV DB all right.  :)  Just make sure that the EV services are stopped and then use the steps in the msft article to move it.

Todd Anderson's picture

Thanks Tony for your help...I did see that post and I that is why I wanted to get your opinion on it...We have about a third of the users but I think it might be a good idea to not take any chances and just setup a seperate SQL server now.

Todd.

Todd Anderson's picture

Tony,

If we do decide to move SQL to its own server, what are the biggest things I need to watch out for? Do you know of a guide posted anywhere?

Thanks,

Todd

TonySterling's picture

There is this technote:

http://support.veritas.com/docs/273272

How to move an Enterprise Vault (EV) SQL directory and store databases from one SQL server to another.

and Paul posted a great comment here:

https://www-secure.symantec.com/connect/forums/ev-...

He mentions these technotes

http://support.veritas.com/docs/287521
http://support.veritas.com/docs/281261
http://support.veritas.com/docs/293852
http://support.veritas.com/docs/293475

Regards,

Todd Anderson's picture

Okay we successfully moved the databases and it all seems to be working except the fingerprint database. We have tried to run the sql script utility change the fingerprint DB but we keep getting this error in SQL...Any Ideas???

Could not find the corresponding record to update SQL server name for the input fingerprint database.

Todd Anderson's picture

One other thing, it appears as if the Journaling task is not working properly. The mail is going to the journal mailbox and it shows them all in a pending state..What could be the problem with this?

TonySterling's picture

for Fingerprint is this what you used?

http://support.veritas.com/docs/313277

How to move a Fingerprint Database

For the journaling, are your Vault Stores in Backup mode?

TonySterling's picture

Duh!  I just realized if the Fingerprinting is working right you might have issues with the journaling  if it is waiting on that.  :)

Todd Anderson's picture

Yes, we used the doc 313277...This is what we are trying to use anyway...When we enter the SQL command to run we get that error.

Todd Anderson's picture

I think the problem may be that we are not sure what names the script is looking for.

Here is the command we changed.

SELECT @vaultStoreGroupName = N'Express Vault Store',
@fingerprintDBName = N'EVVSGExpressVaultStoreGroup_1_1', -- The name of the database that has been moved to a different SQL server
@newSQLServerName = N'EVSQL' -- The name of the new SQL Server

TonySterling's picture

What is the name of your vault store group, fingerprint db and sql server?

It doesn't say to change the vaultstore group name but I would think you need to.

TonySterling's picture

Also, this will give you the name of the Fingerprint DB.

use enterprisevaultdirectory
select * from FingerprintCatalogueDatabase

Todd Anderson's picture

Tony, We got it to work...I was missing the word "group" in the name, silly how little things can hold you up...After changing the name and restarting the services the Journaling task is now working correctly. The only errors I see now are for a Failure Audit error in the application log. Would you know what this is about?

TonySterling's picture

Can you post that up for me?  i will take a look.  :)

Todd Anderson's picture

Ok Tony sorry for not getting back to you earlier, but I opened a support ticket with Symantec and they had just called me back. We got it all resolved...Do you know if I will need to rebuild the indexes? The reason I ask this, is when i try and do a PST Migration using the wizard I get the error cannot find archive.

SOLUTION
TonySterling's picture

No, the indexes wont need rebuilt.  I would recommend a new thread with your pst migration error details.

Regards,