Yep, it might well do that. Other option to consider might be SQL Server replication to an Azure SQL DB (if that’s not supported yet, it’s about to be).
But the one that I’ve used very successfully when I need a read-only copy of some of the on-premises data in the cloud is: * Create the Azure SQL DB * In the on-premises SQL box, create a linked server to the Azure SQL DB * Use a SQL Agent job (or similar) to just push the required info up into the Azure SQL DB via the linked server. We also found a few tricks while doing this. For example, if we had to merge the data from on-premises to the Azure SQL DB, instead of doing a MERGE command, we just did INSERT commands instead. Then at the cloud end, we created an INSTEAD OF trigger to replace the INSERT with a merge. We routinely ended up with better performance overall. I’d never do it that way in an on-premises box but in this case the latency was the thing I needed to avoid, and it’s easier to just push info up and sort it out at the other end, rather than trying to work it out from the on-premises end. Hopefully we’ll soon get support for External DataSource and External Table objects in on-premises SQL. They are already there in Azure. They make this experience much better again. Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775) office | +61 419201410 mobile│ +61 3 8676 4913 fax SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/> |http://greglow.me<http://greglow.me/> From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Scott Barnes Sent: Tuesday, 11 July 2017 9:49 AM To: ozDotNet <ozdotnet@ozdotnet.com> Subject: Re: AZURE SQL Data Sync Greg, Awesome response firstly. Secondly, The intent of its use is to essentially provide a continuum strategy to moving legacy (Asp.net webforms) towards the cloud. The first part of the strategy is to move on-prem hosting into VM instance based hosting (cloud). In doing this there is a residual database(s) that on-prem cannot be moved into the cloud itself. Example. OnPrem there are two databases first being "Financial" and second being "Employee". There is also a website that reads/writes to both of these databases depending on a variety of contexts. However, the Financial database is quite large but the website only uses say 10% of its total structure for a specific set of needs (think of it as being 100 tables but only 5 get actually used). One can move the Employee/Website from OnPrem into Cloud-Based Hosting and therefore remove the residual hosting of these two from OnPrem. One can also create a copy of the "Financial" Database (initial creation is empty) based on the actual used "parts" of the said database (5 tables). The website gets its Connection context updated to point at the VM. The intent then is to use Data Sync to essentially push/pull data from onPrem to the cloud as data either is populated real-time or based off a scheduled interval (either option). An objective for Azure SQL Data Sync is that its role in this strategy is to act as a transport to ensure OnPrem data is kept up to date in the cloud so that website(s) can look at the Azure SQL instance for read/writes as if the OnPrem were also moved. Constraints on writes can also easily be avoided by using a background agent that manually feeds writes to the database, so one could also just assert that the Data Sync takes a volatile database onPrem and just pushes "snapshots in time" of said data into the cloud. From what i've read this looks like its in Azure SQL wheel house... but given the volatility in Azure's weekly product management its important to not assume :) --- Regards, Scott Barnes http://www.riagenic.com On Mon, Jul 10, 2017 at 8:34 PM, Greg Low (罗格雷格博士) <g...@greglow.com<mailto:g...@greglow.com>> wrote: Hi Scott Up to a few months back, I would have said “run away fast”. But now not so sure. This was a “product” that stayed in “preview” mode for so very long. Blog posts had long ago stopped and many of us for years had been asking if it was another product that was just silently dropped without actually being put to death. But I met with Lindsey Allen last year and when we were discussing it, she said that it was going to GA. I was not expecting that. And sure enough, there has been some life back in the blog, etc. lately, and some updates did occur to the code. It’s moved across into the new Azure portal. It’s still quite a distance from being what I’d really consider a strong product but I hope it succeeds as there is a real need for it. One of the biggest limitations is the number of replicas involved. What are you looking to use it for? Often there are better alternatives. Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775<tel:1300%20775%20775>) office | +61 419201410<tel:0419%20201%20410> mobile│ +61 3 8676 4913<tel:(03)%208676%204913> fax SQL Down Under | Web: www.sqldownunder.com<http://www.sqldownunder.com/> |http://greglow.me<http://greglow.me/> From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com>] On Behalf Of Scott Barnes Sent: Monday, 10 July 2017 2:25 PM To: ozDotNet <ozdotnet@ozdotnet.com<mailto:ozdotnet@ozdotnet.com>> Subject: AZURE SQL Data Sync Anyone have experience using Azure SQL Data Sync? Any "If they only put this on the back of the brochure" moments that left you with buyers remorse? --- Regards, Scott Barnes http://www.riagenic.com
