Is there any special requirements for moving a vault database between two vault servers?
I've got the Lonely Coder Edition, which I was using for testing and importing my existing VSS DB, as well as a starter pack for the actual operation. As far as I can tell, it's a case of detach the default Vault DB from the main server, detach the Vault DB from the LCE server, copy the DB across to the Master server and reattach the database (or I could use the backup process, but lst time I tried that, I didn't get a whole lot of loving, so I think I'll go the sp_detachdb approach).
That way, I've got the correct Vault users etc installed with having to screw around with the permissions.
But what about the licencing? Is that info stored in the database? Do I have to deactivate the LCE licence prior to detaching, then copy, re-attach to main server, and activate the Start Pack licence?
I don't really want to screw this up - it's taken close to three weeks to get my data across (I've hit the 2Gb limit is MSDE, so time to move to a proper SQL Server machine to get the last couple of hundred meg imported).
- gaffa
Moving Vault databases between servers
Moderator: SourceGear
gaffa:
basically, everything related to vault operations is pretty much self contained within the sgvault database.
the steps would be:
1) detach
2) copy all files associated w/ the database (sgvault.mdf, sgvault.ldf, etc) to new sql server
3) attach database files
there, that wasn't so bad was it? :>}
now for the hardpart - please be careful here! -
1) edit web.config, change the server to the new sql server host name
2) make note of which sql authentication you are using
back on the new database:
1) drop the old sgvaultuser database user from sgvault database.
if using sql server authentication:
1) create new sgvaultuser login - the password MUST be your vault admin password (to match web.config)
2) create a new sgvaultuser database user for the sql login
3) grant db access to sgvaultuser; add the role member db_owner
if using windows authentication:
1) you will need to know the asp.net process configuration. for example, in iis 5 (assuming the process model is using the default ASPNET windows account), you would need to grant IISMACHINEHOSTNAME\ASPNET access to the database.
2) create a new database user for the windows login in step 1
3) grant db access to that account; add the role member db_owner
basically, everything related to vault operations is pretty much self contained within the sgvault database.
the steps would be:
1) detach
2) copy all files associated w/ the database (sgvault.mdf, sgvault.ldf, etc) to new sql server
3) attach database files
there, that wasn't so bad was it? :>}
now for the hardpart - please be careful here! -
1) edit web.config, change the server to the new sql server host name
2) make note of which sql authentication you are using
back on the new database:
1) drop the old sgvaultuser database user from sgvault database.
if using sql server authentication:
1) create new sgvaultuser login - the password MUST be your vault admin password (to match web.config)
2) create a new sgvaultuser database user for the sql login
3) grant db access to sgvaultuser; add the role member db_owner
if using windows authentication:
1) you will need to know the asp.net process configuration. for example, in iis 5 (assuming the process model is using the default ASPNET windows account), you would need to grant IISMACHINEHOSTNAME\ASPNET access to the database.
2) create a new database user for the windows login in step 1
3) grant db access to that account; add the role member db_owner
Jeff Clausius
SourceGear
SourceGear
Thanks Jeff.
Am I going to run into dramas regarding the licencing? I neglected to mention that I have two complete Vault systems here. I'm not just moving the database to a different server - I have a second Vault server as well, which will become the primary Vault server, and that one machine will host both the database and the web services.
On that basis, I shouldn't have too many dramas with the user - a couple of tweaks to get the passwords sorted... I'm just concerned about the licencing issues.
- Matt
Am I going to run into dramas regarding the licencing? I neglected to mention that I have two complete Vault systems here. I'm not just moving the database to a different server - I have a second Vault server as well, which will become the primary Vault server, and that one machine will host both the database and the web services.
On that basis, I shouldn't have too many dramas with the user - a couple of tweaks to get the passwords sorted... I'm just concerned about the licencing issues.
- Matt
gaffa:
if i understand correctly, you are saying you will have *two* vault databases and two vault web services located on the same machine? is this correct? maybe i've misread your posts.
in most cases this will work just fine. however, i'd recommend against **NOT** using any of the backup routines located within the admin tool. the admin tool assumes there is only one database, sgvault.
as for the licensing, if the two web services are distinctly going to two different databases, all will be well.
if i understand correctly, you are saying you will have *two* vault databases and two vault web services located on the same machine? is this correct? maybe i've misread your posts.
in most cases this will work just fine. however, i'd recommend against **NOT** using any of the backup routines located within the admin tool. the admin tool assumes there is only one database, sgvault.
as for the licensing, if the two web services are distinctly going to two different databases, all will be well.
Jeff Clausius
SourceGear
SourceGear
That's almost correct - two complete Vault systems, but on *separate* machines. (I bought the Lonely Coder edition solely for importing the VSS DB and testing of vault without time limits, and have also purchased the Starter Pack today).
Umm, too many negatives here - "i'd recommend against **NOT** using any of the backup routines "
Does that mean I use the backup process, or use the sp_detachdb stored procedure. Pretty sure you mean use the stored procedure (which is what I was planning to do).
- Matt
Umm, too many negatives here - "i'd recommend against **NOT** using any of the backup routines "
Does that mean I use the backup process, or use the sp_detachdb stored procedure. Pretty sure you mean use the stored procedure (which is what I was planning to do).
- Matt
'Umm, too many negatives here - "i'd recommend against **NOT** using any of the backup routines"'
doh! - its late... sorry about that.
basically, the admin tool will try to backup the 'sgvault' database. if you have two distinct 'sgvault' databases (due to named instances for example), then you'll be just fine. if you have two databases within one sql server instance, then DO NOT use the admin tool for backup purposes.
hopefully that clarifies things a little.
doh! - its late... sorry about that.
basically, the admin tool will try to backup the 'sgvault' database. if you have two distinct 'sgvault' databases (due to named instances for example), then you'll be just fine. if you have two databases within one sql server instance, then DO NOT use the admin tool for backup purposes.
hopefully that clarifies things a little.
Jeff Clausius
SourceGear
SourceGear