03-09-2009 09:37 AM
I was wondering if anyone has any insight on moving these dbases between two servers and different sql versions. This is admist a 6.x upgrade to 8.0 as well.
Thanks,
Solved! Go to Solution.
04-02-2009 08:24 AM
03-09-2009 09:51 AM
Moving from SQL 2000 to 2005 is not much of an issue
I have done so on my environment
The one thing you need to watch for is when you connect the database to the new sql 2005 server make sure you set the compatability level to 90
This can be found under the properties of the database in the Options page
It is also a good idea to enable full text indexing and reindex the database as it will help with performance
03-09-2009 10:10 AM
Moving from SQL 2000 to 2005 is not much of an issue
I have done so on my environment
The one thing you need to watch for is when you connect the database to the new sql 2005 server make sure you set the compatability level to 90
This can be found under the properties of the database in the Options page
It is also a good idea to enable full text indexing and reindex the database as it will help with performance
Liam Finn
http://www.computerusersolutions.com
Isn't there something I need to do in order to change the server name within the vault dbase tables?
03-09-2009 10:27 AM
Sorry
I made the assumption that the new server would have the same name as the old server
Actually keeping the server names the same makes life so much easier
If you want to modify the server name then you need to make changes in the EnterpriseVault Directory database
In the table VaultStoreEntry there is a field called SQLServer. You need to update this field to the name of the new SQL server. You will need to do this for every vault which will have it's database moved to the new server
As always please remember to back everything up before making any such changes.
03-09-2009 10:34 AM
Since you seem to want to have the new SQL server with a different name. The i recommend not detaching and reattaching but backup the database to file then restore it on the other server. This way you always keep the old SQL server operational as a quick way to rollback to the old environment
Here is a tech note on all the steps
http://seer.entsupport.symantec.com/docs/273272.htm
03-09-2009 10:41 AM
Just the directory dbase?
03-09-2009 10:58 AM
If you read the tech note the steps are
Move the databases.
There is a reg key to be changed on each EV server (this tells them which server is the directory server
update the SQL table vis SQL or via the VAC your choice on this one. My preference is in SQL
Ensure that all of the System DSN connections listed in the ODBC Data Source Administrator relating to Enterprise Vault reference the correct Enterprise Vault server.
If you have an EVaudit database then you need to modify the system dsn for the Enterprisevaultdirectory database
It is all outlined in the tech note.. BUT
I highly recommend that you make life easy for yourself. Bring the new SQL server online with the same name as the old server. If you do this the transition is seemless and you will have no issues like fat-fingering the table enteries or anything else like that and you have no changes to make on the EV servers.
If you want to do it the way I recommend then what you need to do is
1: stop all ev services on all ev servers
2: backup all your SQL databases to .bak files
3: move the bak files to the new server
4: power off old SQL server
5: rename new server to the same name as old server
6: install SQL on new server
7: restore databsese from .bak files so as databases are restored with the same database name on the new server
8: set the compatability level on the databases
9: Starting with your Enterprise Vault Directory server (normally the first EV server you installed) bring the EV services back online
10: Check to make sure everything is running ok..then you are done
03-09-2009 01:39 PM
Hello Liam and CGuinn
We're investigating this also.
I learned from our DBA there is something called alias. Unfortunately, I do not have the exact paper with me (CET is 21:35) but will have tomorrow morning. Instead of having to adjust the registry and databases, you add an alias to each vault server, which points to the new SQL server. Kind of like dns alias.
EV now goes to SQL1
New SQL2008 machine will be called SQL2
Create Alias on EV server: SQL1 = SQL2
Move db's (using (as Liam said) backup/restore just in case.
Check EV after starting.
I ran this by Symantec Support, and according to them this indeed should work. Unfortunately, I have not yet been able to test, as our test-environment did not allow for 2 different sql versions. I'll try on VMWare somwhere in the next few weeks. The upgrade plan will be done in august/sept, when SP2 for 8 is out. (hopefully, fingers crossed and all that.
Gertjan
ps. Will post tomorrow when @ work the document
03-09-2009 05:36 PM
I have assisted a few customers in their upgrade to SQL 2005 and generally sent them the following information and I have had a 100% success rate with it so this will be a good starting point
03-10-2009 04:00 AM
Hello Liam and CGuinn
We're investigating this also.
I learned from our DBA there is something called alias. Unfortunately, I do not have the exact paper with me (CET is 21:35) but will have tomorrow morning. Instead of having to adjust the registry and databases, you add an alias to each vault server, which points to the new SQL server. Kind of like dns alias.
EV now goes to SQL1
New SQL2008 machine will be called SQL2
Create Alias on EV server: SQL1 = SQL2
Move db's (using (as Liam said) backup/restore just in case.
Check EV after starting.
I ran this by Symantec Support, and according to them this indeed should work. Unfortunately, I have not yet been able to test, as our test-environment did not allow for 2 different sql versions. I'll try on VMWare somwhere in the next few weeks. The upgrade plan will be done in august/sept, when SP2 for 8 is out. (hopefully, fingers crossed and all that.
Gertjan
ps. Will post tomorrow when @ work the document
Gertjan,
I have heard of this, I have never tried it but the concept is sound. The reason why i would not use this is that it adds more support overhead. The more areas you need to support the more chances of something breaking and the harder it is to troubleshoot. That why i recommended to CQuinn to keep the server names the same when the SQL servers are switched that way it is seemless changeover
03-10-2009 05:00 AM
Hello all,
I agree with Liam about the support overhead, but... (as always.)
This will be welldocumented, and the EV-admins and SQL admins will be aware. It will be written down in the Technical and Functional Design documents, so I foresee no support problems on that end.
I'd personally prefered using the offical Symantec Method, but this option has been ok'ed by support, and is in our environment easier to implement and maintain.
Thanks,
Gertjan
04-01-2009 01:20 PM
04-02-2009 04:23 AM
04-02-2009 05:31 AM
04-02-2009 05:38 AM
04-02-2009 05:47 AM
04-02-2009 07:28 AM
04-02-2009 07:34 AM
In the table VaultStoreEntry there is a field called SQLServer. You need to update this field to the name of the new SQL server. You will need to do this for every vault which will have it's database moved to the new server
04-02-2009 07:35 AM
Is this your live environment?
When did you do the move to the new SQL server?
Did you make the changes in the Enterprise Vault Directory database
In the table VaultStoreEntry there is a field called SQLServer. You need to update this field to the name of the new SQL server. You will need to do this for every vault which will have it's database moved to the new server
Liam Finn
http://www.computerusersolutions.com
http://www.enterprisevaultfaq.com
I did....it has the correct entry
04-02-2009 07:36 AM