cancel
Showing results for 
Search instead for 
Did you mean: 

Moving DA databases

Matthew_J
Level 4

We want to move our Discovery Accelerator databases from one SQL server (SQLOLD\Vault) to a new SQL server (SQLNEW\Vault).  We don't use Compliance Accelerator at all, just DA. I'm trying to work out a plan for moving them, and am a little confused about the difference between the steps outlined in this article:

https://www.veritas.com/support/en_US/article.TECH51129

OR, just logging in to http://daserver/EVBAAdmin as the vault service account and changing the pointers/DSN's there.  Am I confusing two separate configurations?  We are JUST moving the DA databases right now, and leaving the actual enterprise vault databases in place where they are.

The part that has me confused is that right off the bat, the "AcceleratorManager.exe.config" has a DSN line that references a db that doesn't exist  ("Initial Catalog='EVConfiguration').  We do not have that db in our SQLOLD\Vault instance, so is this file really where the config is coming from for DA?

Under the EVBAAdmin site, there are two DB's configured, one called "CustodianManager" and another that was configured with a custom name related to our organization (call it "Company_Name" for a generic description) and both have DSN's listed that point to them in the correct location on the existing SQL server (SQLOLD\Vault).

To just move the DA databases, can I simply stop EVAMS services, detach and move the DB's, log in to http://daserver/EVBAAdmin as vault service account and update the DSN's/pointers, and restart EVAMS services? 

[EDIT]: OK, my bad.  We DO have the EVConfiguration database on our SQLOLD\Vault server.  Is this db a part of Enterprise Vault, or is it a part of DA?  If we are not moving the EV databases yet, can I leave the .config files alone and simply change the database DSN's in http://daserver/EVBAAdmin after moving "CustodianManager" and "Company_Name" customer databases?  Or do I need to also move EVConfiguration, and modify the five .config files in the program installation dir?

 

1 ACCEPTED SOLUTION

Accepted Solutions

TechMerc
Level 4
Partner Accredited Certified

In answer to your additional question:

As I mentioned, the Configuration DB is a part of DA, and you'll likely want to move that to the new SQL server, particularly if you're retiring it. DA can't work without that database.

I have my own method of moving DA databases which I find to be much simpler.  It's basically this:

  1. Shut down DA services and copy the databases to the new server
  2. Uninstall and reinstall DA
  3. Point the browser to the EVBAAdmin page to perform initial configuration.  This is the point where it either configures a new config database or attaches to an old one.  Enter the new SQL Server name and Config database name and check the 'Existing Database' check box.
  4. After you restart services, you should see your custodian and customer databases on the page.
  5. Edit each of the databases (custodian and customer) and change the SQL server name.

You should be good to go after that.

View solution in original post

9 REPLIES 9

TechMerc
Level 4
Partner Accredited Certified

I'd HIGHLY recommend going with your method.  Despite the publish date on that article, the steps there haven't worked for me since around Version 7.5.  That method is very invasive and prone to all sorts of issues.  I really don't know why they stick with such over-complication of what's an otherwise very simple procedure.

With regard to your point of confusion, the line is referring to the DA Configuration database, which is the DB that holds the references to your customer and custodian databases.  The reason it doesn't show in EVBAAdmin is because that webpage accesses the Config database to get its info on the other databases.  If you don't have a database called 'EVConfiguration', then look for something similar like 'EVDAConfig' or the like.  Either way, your config file will have the proper Configuration Database name in that Initial Catalog line.

Best of luck!

TechMerc
Level 4
Partner Accredited Certified

In answer to your additional question:

As I mentioned, the Configuration DB is a part of DA, and you'll likely want to move that to the new SQL server, particularly if you're retiring it. DA can't work without that database.

I have my own method of moving DA databases which I find to be much simpler.  It's basically this:

  1. Shut down DA services and copy the databases to the new server
  2. Uninstall and reinstall DA
  3. Point the browser to the EVBAAdmin page to perform initial configuration.  This is the point where it either configures a new config database or attaches to an old one.  Enter the new SQL Server name and Config database name and check the 'Existing Database' check box.
  4. After you restart services, you should see your custodian and customer databases on the page.
  5. Edit each of the databases (custodian and customer) and change the SQL server name.

You should be good to go after that.

View solution in original post

TechMerc: Thank you for the info, that makes sense now that the EVConfiguration DB is part of DA.  The name does not lend itself to being for DA, but that may be our fault for having our DA databases and EV databases mixed on the same instance. 

One more question before I tackle this today.... we have 10.0.4 with CHF3 installed on top.... I have the installer for 10.0.4 DA, and the installer for CHF3... I assume I will need to install 10.0.4, then install CHF3 on top, before I do any of the configuration wizard?

 

TechMerc
Level 4
Partner Accredited Certified

Yeah, whenever I do installs, I tend to make it a point to change the Config DB name simply because it can get confusing like that.  We normally change it to EVDAConfig as a best practice.

You are correct regarding installing CHF3 on top.  I'm not sure if there's a schema change with the CHF, but it's always a good practice to get all the binaries up to where they were prior to configuring.

There's definitely a schema change for CHF3, I can confirm that I had to update the CustodianManager and other customer DB as part of the install process.  Additionally, when I installed CHF3 on our vault server, I neglected to put the EV databases in simple recovery mode and our log files blew up to enormous growth (10 gigs per hour or so) after the CHF3 update.

Anyway, that's unrelated to all this.  But, thank you very much for your help TechMerc, I really appreciate it.

TechMerc
Level 4
Partner Accredited Certified

Any time!  Hope the move goes smoothly for you.

To follow up, the move did go mostly smooth but I did have to roll back and restart the process once due to the main customer DB not wanting to restore onto the new server (I'll get to that in a minute).  I did just about the exact steps you mentioned.  I stopped all services, backed up the db's from the old SQL server, restored them to the new SQL server.  Once I was satisified there, I took a snapshot of the DA server, then I went in and uninstalled the DA server components from the DA server.  Then I started the 10.0.4 DA install, let it finish, and then installed the CHF3 update.  Once that was done, I loaded the EVBAAdmin site, selected existing database, and pointed it to the new location.  After that, all I had to do was modify the CustodianManager db properties and the main customer db properties in the EVBAAdmin to point them to their new locations, and I also had to change the "Full Text index" location for the main customer DB in the properties.

The one problem I ran into, when restoring the backup of the main customer DB was that it was complaining about files that were already there (A folder related to full-text indexing).  First, I thought that maybe I had left a case with analytics enabled, so I backed out of everything, restarted the services, loaded the DA client and went to investigate and found that there were no cases with analytics enabled.  I went ahead and closed all of the cases we had, since they were no longer in progress, and deleted a bunch of research items out.  I stopped services again and backed up the DB again, and tried the restore and had the same problem.  So, I went ahead and checked the "Restore with overwrite" option, and that did the trick.  I don't know if we had attempted to load this DB before on this instance and left some stuff behind or what, but it restored fine after that and we are up and running.

Thanks again for your help TechMerc. 

TechMerc
Level 4
Partner Accredited Certified

It's always something, isn't it? Smiley LOL

Thanks for the follow-up.  It's good to know how things worked out.  Congratulations on the successful move!

Have you tried the same process for the EV databases?