Please see the Requirements and Limitations Section.
Please see the Roadmap.
Initially SQL Clone will be a standalone offering.
All clones created will have the same data as when the image was taken from the source - it’s a 2-stage process. A data image is taken from the live source or a backup (this takes about the same time as a backup). Multiple clones can then be created, each using the image (which can be on a file share) and a local differencing disk.
Yes, the clone is a real database in every sense - it just has most of the mdf and ldf files stored on a network share (i.e where the snapshot is). Obviously this means the network link's stability and latency will affect the database's performance.
This isn't currently supported within the system, the Activity Monitor in SSMS (or running `sp_who`) can tell you about current usage of a database.
Currently, data images can only be deleted when it has no clones created from it. In fact, you will only be able to see the delete icon for a data image on Web client if this is the case.
The application does actually attempt to do this but it currently fails. We are looking to fix this.
When SQL Clone creates a clone database, it adds an Extended Property to the database object named as "IsSQLCloneDatabase" with the value "1". You can take advantage of this mark to find all clone databases under a SQL Server instance, for example with the below query:
CREATE TABLE #TempCloneDatabases (DatabaseName VARCHAR(MAX)); INSERT INTO #TempCloneDatabases EXEC sp_MSForEachDB 'Use [?]; SELECT db.name AS DatabaseName FROM sys.extended_properties AS prop JOIN sys.databases AS db ON db.name = DB_NAME() WHERE prop.[class_desc] = "DATABASE" AND prop.name = "IsSQLCloneDatabase" AND prop.value = 1'; SELECT DISTINCT * FROM #TempCloneDatabases ORDER BY DatabaseName; DROP TABLE #TempCloneDatabases; |
Open transactions will not be applied, the clone will have the uncommitted state.
The image creation process involves copying .mdf and .ldf files, so it shouldn't pose any problems. Also the image would be in the same state as the database it was created from.
By default, clones are stored under the local app data folder of the account which the SQL Clone Agent service is running under (precisely "%localappdata%\Red Gate\SQl Clone\clones"). You can override the default clones storage folder during agent installation. However, note that this should only be used at initial installation time since it will break any existing clones.
We expect this to be problematic, but we haven’t tested this yet.
It's currently not available but PowerShell support is in our Roadmap to currently be released as part of SQL Clone 1.0 (as you can see on SQL Clone Roadmap).
It's currently a little way down our backlog - the more it's requested, the sooner it will happen.
We don’t have any near-term plans to provide database downgrade functionality within this product.
It should be possible to achieve this in a script combining our SQL Compare command line, BCP and the Powershell scripting in SQL Clone.
Not currently. The 'instant' technology SQL Clone uses is 64-bit only.
SQL Clone beta is completely incompatible with technical preview version and there is no migration path available. The suggested way here is to delete all the snapshots and clones, uninstall SQL Clone technical preview and install SQL Clone beta.
Yes, there are two key features missing in SQL Clone beta that were available in technical preview version: