That helped, thanks for that. I'm in the same boat with the inbound data (writes back to onPrem), for me I'm probably inclined given the sensitivity of the data to run it through a validation pipeline and feed it through as if it were input via original source. It could be wasteful but in the end, it can be a good point for telemetry to track the injection process in a finite way.
--- Regards, Scott Barnes http://www.riagenic.com On Tue, Jul 11, 2017 at 12:01 PM, Greg Low (罗格雷格博士) <g...@greglow.com> wrote: > 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 <1300%20775%20775>) office | +61 419201410 > <0419%20201%20410> mobile│ +61 3 8676 4913 <(03)%208676%204913> fax > > SQL Down Under | Web: www.sqldownunder.com |http://greglow.me > > > > *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ > 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> > 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 <1300%20775%20775>) office | +61 419201410 > <0419%20201%20410> mobile│ +61 3 8676 4913 <(03)%208676%204913> fax > > SQL Down Under | Web: www.sqldownunder.com |http://greglow.me > > > > *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ > ozdotnet.com] *On Behalf Of *Scott Barnes > *Sent:* Monday, 10 July 2017 2:25 PM > *To:* ozDotNet <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 > > >
