I am looking for "Master Data Management" in Azure and seeing SQL Data Sync (Preview) looks similar to the MDM functionalities, not sure though. Any leads here would be appreciated.
Azure SQL Database (PaaS) does not have a Master Data Management solution, but you can vote here for this feature to be included as part of the service in the future. SQL Server on-premises does have Master Data Services (MDS) as solution for master data management, and you can install this on an Azure VM.
If you are looking for Master Data Management functionality that is native to Azure, then I would recommend you take a look at CluedIn. CluedIn is a recommended MDM solution from Microsoft themselves (you can see the reference here: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/data/cluedin)
Azure Data Sync has some of the capabilities you would want as part of an MDM project, however it does not have features you would expect from an MDM system like:
Deduplication
Entity Enrichment
Data Cleaning Tools
Business Glossary
Related
I have 2-3 source systems which are on-prem databases. I am planning to use Logic Apps to connect to these source systems. As per the Azure documentation we need to install a On-Prem Gateway on a local computer.
I am skeptical of this methodology as it demands dedicated system, so not sure if this works in actual production scenario.
Please can you suggest what is the right way to do it.
Here is how to connect to on-premise data sources:
If the services are accessible over the internet then you call service endpoint over HTTP or HTTPS from azure logic apps. This article will help you with details steps to be followed: https://learn.microsoft.com/en-us/azure/connectors/connectors-native-http
If it is not accessible over the internet then this article will help with step by step process: https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-connection
Before you can access data sources on premises from your logic apps, you need to create an Azure resource after you install the on-premises data gateway on a local computer. Your logic apps then use this Azure gateway resource in the triggers and actions provided by the on-premises connectors that are available for Azure Logic Apps.
Also check this for reference.
You may also want to consider the costs.
To simulate a device I want to use a Logic App to fill a Azure Database for PostgreSQL with test data.
I found the two connectors PostgreSQL and SQL server but unfortunately both don't work for me. The PostgreSQL connector does only support onpremise databases and neither the autodetection nor the manually input of the connectionstring works with SQL Server.
Would great if somebody could give me a hint how to write data into a Azure Database for PostgreSQL from a Logic app.
Unfortunately, there is no connector available for this as of today.
The current alternatives would be
Use Azure Functions (which can be called from Logic Apps if required)
Create Custom APIs and a Custom Logic App Connector
Also, there is a feature request on UserVoice that you may upvote to gain traction.
I am working on a POC that needs the data to be moved to Azure so that Azure Search Service always provide me the latest data.
Here is my situation:
SQL Server deployed on-premises has a database that has few tables that always gets updated by user inputs. Tables are having millions of records and new records gets added/old data gets updated every day depending upon transactions
Planning to leverage Azure Search Service capabilities to search the data in my website
What is the best way to achieve the functionality regarding data sync between an on-premises SQL Server database and Azure? Any good architecture direction would help me in my decision making.
What is the best way to achieve the functionality regarding data sync between an on-premises SQL Server database and Azure?
I'd say the best option given the information you have provided is to use Azure SQL Data Sync.
You can setup a sync group and have Azure pull your data at regular intervals from your on-prem database to an Azure SQL database.
We are looking at setting up a high availability solution for a web application using Azure.
Azure SQL database has the Geo-Replication options to sync data to secondary copies of the database in a separate region.
If there is a failure in the primary region does the Azure SQL database automatically fail over to the secondary or is this something that has to be
done manually or by a custom monitoring tool not provided by Azure?
Thanks for your help
Gavin
It is provided by Azure automatically
Reference:
https://azure.microsoft.com/en-us/blog/fault-tolerance-in-windows-azure-sql-database/
we're close to migrating our legacy MS Access app to SQL Server for our internal warehouse management system. Our customers are often asking us for access to the data for e-commerce integration and general reporting. Once the migration is complete I would like to provide open access to the data via web services and odata. However I don't want to host these services as we are on a slow ADSL connection which won't cope with the traffic.
My question is, can I replicate (one-way) to a remote DB hosted by shared-hosting companies such as Hostgator? I see they have shared windows hosting with unlimited MS SQL DBs. Are there any special requirements on the hosted-side? For instance do I need to explicitly set-up replication on hosting db or is it managed on the client-side?
If this is possible then I might be able to run all our web services and reporting apps on the host's servers, and only the replicated data need travel over WAN. What sort of control is there over replication? Such as bandwidth throttling, replication periods etc? For instance when & how often does replication take place?
I'm new to SQL Server in general and some of the topics are a little overwhelming.
Thanks for your help.
You could try setting up transactional replication with a push subscription with the distributor on your side. The relevant bit is how the distribution agent connects to the subscriber. distrib.exe supports both trusted and SQL authentication, so you should be good to go either way.