It's absolutely, positively AMAZING that a product that uses a back-end database to store mission-critical resources, like those every single one of your customers stores in vault, DOESN'T SUPPORT REPLICATION.
Nevermind supporting functional replication, which I can understand, but to not support replication for the simple and clear purpose of having a warm standby backup database, well that's just unconscionable.
Are you guys just galutes, or on drugs, or are you just plain lazy? Maybe you're barely able to make the technology work at all, limited as Vault is.
Be still my rolling eyeballs.
Steven Black
Replication: get it done, at least for backup.
Moderator: SourceGear
-
StevenBlack
- Posts: 13
- Joined: Sat Apr 05, 2008 7:20 pm
- Location: Canada
It is not possible to do replication with the current Vault database schema. We use encryption, which prevents the trigger from being published as part of SQL Server replication.
As protection, some of the schema, triggers, stored procedures, and user defined functions, are created with the "with encryption" flag."
We recommend users back up their Vault database(s) on a regular basis.
As protection, some of the schema, triggers, stored procedures, and user defined functions, are created with the "with encryption" flag."
We recommend users back up their Vault database(s) on a regular basis.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
-
Mike Dimmick
- Posts: 28
- Joined: Tue Feb 17, 2004 7:42 am
- Location: UK
- Contact:
Now that Vault 4.x uses .NET Framework 2.0 on the server, it should be possible to set up Database Mirroring on SQL Server 2005. Mirroring acts at a physical level rather than the logical level of replication so I believe should not suffer from this problem (I don't currently have a mirror set up).
One downside to mirroring is that for highest transactional security (recommended), both halves of the mirror have to report successful commit before a transaction is reported committed to the 'client' (in this case Vault's web services). For databases with a lot of write activity, the transfer of log records to the mirror server can prove to be a bottleneck. Also, the Full recovery model is required so you need to back up your transaction log regularly to ensure it doesn't grow unbounded.
At minimum you need SQL Server 2005 Standard Edition for database mirroring. You also need a third server instance to act as a 'witness' for automatic failover, but this can be SQL Server Express running on a client version of Windows if licences and money are tight. Or, you can simply use manual failover.
For systems where the delay in replication or mirroring is unacceptable, consider clustering. This requires a minimum of a shared disk array (e.g. SAN), Windows Server 2003 Enterprise Edition, and SQL Server 2005 Standard Edition. Here you only get one copy of the data (except that you've got redundancy in your SAN, right?) but two machines that can address that data (although only one at a time).
One downside to mirroring is that for highest transactional security (recommended), both halves of the mirror have to report successful commit before a transaction is reported committed to the 'client' (in this case Vault's web services). For databases with a lot of write activity, the transfer of log records to the mirror server can prove to be a bottleneck. Also, the Full recovery model is required so you need to back up your transaction log regularly to ensure it doesn't grow unbounded.
At minimum you need SQL Server 2005 Standard Edition for database mirroring. You also need a third server instance to act as a 'witness' for automatic failover, but this can be SQL Server Express running on a client version of Windows if licences and money are tight. Or, you can simply use manual failover.
For systems where the delay in replication or mirroring is unacceptable, consider clustering. This requires a minimum of a shared disk array (e.g. SAN), Windows Server 2003 Enterprise Edition, and SQL Server 2005 Standard Edition. Here you only get one copy of the data (except that you've got redundancy in your SAN, right?) but two machines that can address that data (although only one at a time).