I want to replicate my SQL Server 2016 SP1 production database to an AlwaysOn replication in another database of the same type.
I understand the replication will be read-only, but what happens when users make changes to the source DB?
For example, if I add a view to the source DB, does that view immediately get created in the replication?
What about User permissions, Logins, Stored Procedures, Indexes, even entire tables? If those are created on my source DB, do they instantly replicate over to an AlwaysOn replication?
If these all do replicate, is there anything which doesn't replicate over using an AlwaysOn?
If these all do replicate, is there anything which doesn't replicate over using an AlwaysOn?
Everything stored in the database is replicated. Tables, Indexes, Views, Proc, Users, Roles, etc. Everything that would be included in a Database Backup is replicated.
Everything stored outside the database is not replicated. Logins, SQL Agent Jobs, SSIS Packages, Instance Configuration settings, etc.
Related
In my SQL Server database I need to mantain the tables linked and in sync with the tables of an MS Access .mdb file.
Lets say I update something or add something in the MS Access database via my own application.
I want those changes reflected in the SQL Server database.
I need a way to push the updates to the SQL Server database, or a way to update the SQL Server database with the new data when I connecto to it.
Trying to be clear: source must be the .mdb file database and destination must be the SQL server database. I need to keep them in sync.
Both databases have the same tables.
I have read a lot of posts, even this one: From SQL Server how do I read from an MS Access database to UPDATE data in one or more table columns? that seems to be the solution, but I can figure out the steps.
The official tool for this is:
SQL Server Migration Assistant for Access (AccessToSQL)
It has a migration feature that, when run, will replicate (adjust) the table schema in the database in SQL Server to match that of the Access database.
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.
plz give me detail of Contained Database = true in Sql Server 2012
how to use and why ?
How to Migrate to a Partially Contained Database:
USE [master]
GO
ALTER DATABASE [Accounting] SET CONTAINMENT = PARTIAL
GO
What are Contained Databases in SQL Server 2012:
A contained database is a database that is isolated from other
databases and from the instance of SQL Server that hosts the database.
SQL Server 2012 helps user to isolate their database from the instance
in 4 ways.
Much of the metadata that describes a database is maintained in the database. (In addition to, or instead of, maintaining metadata in
the master database.)
All metadata are defined using the same collation.
User authentication can be performed by the database, reducing the databases dependency on the logins of the instance of SQL Server.
The SQL Server environment (DMV's, XEvents, etc.) reports and can act upon containment information.
Recently we installed a new Sql Server 2008 server for a client and we had to move all the databases for them. Apparently they forgot about one application that uses replication with local Sql 2000 Desktop Edition instances. Now we're trying to get the replication running again.
Currently we get the error: The server '...' is not configured as distributor.
2 questions about that:
Is there a way to detect the type of replication used by just looking at the DB schema?
I'm guessing we don't need to run the replication wizard again since that changes the database schema which should be already ok. What do we need to do to manually hook up everything?
Apparently you made a fresh SQL Server installation, and not an upgrade, which would have been the recommended approach.
It seems that you can use both main types of replication now: merge replication and transactional replication (see this article)
Since you have a fresh installation, creating the publication from scratch is a must.
I recommend following the usual steps when setting up replication:
If at your subscriber you also need to make schema or data modifications then choose merge replication. If your subscribers are read-only or you don't need schema/data altered there, choose transactional replication.
Create your publication in SQL Server 2008. The distributor should also be this instance (because of replication rules between different versions of SQL Server - the distributor has to be the no earlier than the publisher). Choose your articles, snapshot agent schedule, security settings.
Initialize snapshot.
Re-create your MSDE 2000 subscription. Note that all agents should run at the Distributor.
You have to figure out your security settings. Especially how your subscribers connect to the publisher (SQL credentials or integrated security if in a domain).
So, recreating your publication shouldn't be very hard.
If you previously had merge replication setup then a real problem could be data at the subscribers that hasn't been uploaded to then publisher yet. So you have a bunch of subscribers all with their own modifications. In this situation you either discard the data or manually backup each subscriber and synchronize it after subscription initialization.
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.