I have two SQL Server databases with the same version.
there is a Oracle bus service between the two SQL Server database.
I want transaction replication between two database,two database located in different cities.
How do I configure Transactional Replication between the two Database?
You can use CDC, but if you want to replicate an entire SQL database real-time then either use mirroring (which will become phased out) or Always on Availability Groups (recommended by MS going forward). An ESB is for message-oriented communication, not for replication.
Related
The question: Is it possible to point a view in database A running on Azure SQL Database service to tables/views on a SQL server running in a VM? I've tried external tables but come up short.
Scenario:
Two applications that is exchanging data, from two different vendors.
We've got three databases in total. One for each application and an integration database with views that both applications use either directly or through views.
The issue now is that we want to migrate to Azure and would prefer to use the Azure SQL Database service as much as possible, but one of the applications is not ready for it and therefor it's database has to be hosted on either a managed instance or in a VM.
The issue now is that there's view's in database A (running on Azure SQL Database service) that points to views and tables in the integration database, which again references tables in database B (running on SQL Server on the VM).
The short answer is "no". You can use external tables to query other SQL Azure databases, but there is no exact analogue for linked servers in Azure SQL Database. You can use SQL Azure Managed Instance (which supports SQL-SQL linked servers but not arbitrary linked servers).
There is a workaround, however. You can run SQL Server in an Azure VM and have it point to SQL Azure as a target as well as the other sources you want to connect. Then you can push data to/from Azure SQL DB using the SQL Server in a VM. You don't have the same management overhead in this approach since you don't really need to host data in the SQL Server if you don't want to do so. Note that this will be slower than doing direct connections to SQL Azure, but you can try to do this for a period of time if it would help you during a migration.
I have DB in my SQL Server. I want to replicate the same DB with all the Views inside it into Azure and sync the same SQL Server DB with replicated DB on Azure on daily basis.
I have no idea about Azure.
You can migrate a SQL Server 2005 or later database to a single or pooled database in Azure SQL Database. For best performance during the import process, it’s better to drop indexed views and recreate them once finished. For more details, you may refer to this article: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-cloud-migrate.
You can set up Azure SQL Data Sync by creating a hybrid sync group that contains both Azure SQL Database and SQL Server instances. For more details on how to achieve this, you may refer to this document: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-get-started-sql-data-sync.
Note: Does SQL Data Sync fully create and provision tables?
Views and Stored Procedures are not created on the destination database.
You can use SQL Data Sync to sync the base tables of your views but SQL Data Sync cannot sync views. Sync data from views is quite complex and not always achievable and for that reason SQL Data Sync does not do it.
Use the step-by-step procedure described here to configure the synchronization. You need to make your SQL Server instance a "hub", your SQL Azure Database a "member" on the sync configuration. Configure the "Sync frequency" parameter/field to occur every X days or X hours.
We have a BizTalk setup, its databases are setup on a failover cluster to achieve the HA (High Availability). Client have an application database that also needs to achieve the HA, usually I'd suggest to put on the same instance with BizTalk database but client DBA insists to use the AlwaysOn feature.
BizTalk Server does not support the alwayson due to some DTC complications, having said that, is it possible to enable the AlwaysOn feature on the same SQL Server to satisfy the customer needs while not disturbing the DTC requirement by BizTalk? Or it simply has to be two sets of SQL Server deployment?
Since Always On feature does not support MSDTC, BizTalk does not support Always On since it relies on MSDTC. See link msdn link (at the bottom of page). Your other database for which you need always on, put it on a separate SQL instance. It may share the same cluster node as BizTalk server SQL instance.
I have couple of kiosks running at client's location which access an online MS SQL server 2005 to process data, but the internet connectivity is unreliable. I am fine with installing SQL server on the kiosk itself and sync it once a week to the central server. Since there are lots of kiosks, it needs to be a merged sync.
Any better ideas for caching?
What are the tools for merge sync?
It sounds like you are looking for replication. Replication is a set of technologies for copying and distributing data and database objects from one database to another and then synchronizing between databases to maintain consistency. Using replication, you can distribute data to different locations and to remote or mobile users over local and wide area networks, dial-up connections, wireless connections, and the Internet.
Here is a replication overview: http://technet.microsoft.com/library/ms166367.aspx
We have Merge (Push) replication set up between the databases in our different offices. Each database carries the complete set of data, so that the users in each office only need to connect to the database server in their office. When users want to go off-site they need to pull a subset of data to a local (on user's laptop) SQL Express database. Is it possible to use SQL Server 2005 replication to pull this subset from one of the Subscriber databases and then later replicate their local changes back?
Edit: We do not want the users in regional offices to replicate against our main publisher database, but against the Subscriber databases. Each Subscriber must therefore act as a Publisher for the users in that office (maybe even using transactional replication in stead of merge replication)
Yes, but make the offsite users' SQL Server 2005 Express Edition a merge replication subscriber (i.e. pointing at your Distributor).
Ref.