I have a SQL server 2012 database on a server, which is a development database.
I want to create an another database on other machine which will be exact replica of the original one and as soon as any changes occur in schema and data it should get migrated to this second database.
I tried the log shipping method but in that case secondary database goes in Restoring mode whereas I want both the database active and functioning at the same time.
Performance or locks doesn't matter.
Any other easy way to do this? a utility that runs periodically automatically would also be great.
With log shipping the databases may be in readonly state most of the time, unless the periods when you run scheduled restore job.
Other options to consider - transactional replication, mirroring with readonly via snapshot or AlwaysOn Avalaibility groups with readable replicas, backup/restore (initial full backup/restore, then differential + trans logs) - but the last option is not for large databases.
Related
Currently working on customer releases for our product. First step is to compare the customer database with our current dev db. Apparently we need to shut off cdc to do this, which drops all of the system cdc tables. Is there any way to backup and restore these tables for after we've finished comparing the two db's?
Apparently we need to shut off cdc to do this.
Completely agree with #DavidBrown that it isn't necessary to disable CDC for comparing the databases.
CDC enabled database simply means that your database captures the data change automatically. It manages that changed data in a separate table therefore you can still compare your database with different database without disabling CDC.
In case if required, you can restore the CDC enabled database by referring this third-party tutorial.
Restoring a SQL Server database that uses Change Data Capture
What are the main differences between sql-server replication and availability groups in an Azure Iaas data solution? (sql server instances on a VM)
Are these the same concept?
SQL Server Replication copies data and replays changes using SQL Commands to replicas. Sometimes this is called "Logical Replication". Replication is typically not used for High-Availibility or Disaster Recovery, but can be used to create a readable replica of a production database or to copy selected data from a main database into one or more subscribers.
AlwaysOn Availibility Groups copies and applies the log records to syncronize databases. The changes are applied using the same transaction log redo process that's used in backup/restore and database recovery. Sometimes this is called "Physical Replication", as the database files on every replica are identical. AlwaysOn Availibility Groups can be used for High-Availitbiiy, Disaster Recovery, and to create Readable Replicas of a production database.
I want a solution that match the below scenario:
We have 2 databases with 1 being the main DB and the other being the secondary DB. I want a process (executable, powershell, anything...) that can update the changes that I make in Stored Procedures in the main DB. the main DB is the database that we will make the changes then I want a process that update (simple delete and create) the older SP in the secondary DB.
How I can make this possible in the most simply way? If you will say software to work with please take in account that I only want freeware.
It seemed like you are defining something called Mirroring if I didn't assume wrong.
Database mirroring maintains two copies of a single database that must reside on different server instances of SQL Server Database Engine. Typically, these server instances reside on computers in different locations. Starting database mirroring on a database, initiates a relationship, known as a database mirroring session, between these server instances.
One server instance serves the database to clients (the principal server). The other instance acts as a hot or warm standby server (the mirror server), depending on the configuration and state of the mirroring session. When a database mirroring session is synchronized, database mirroring provides a hot standby server that supports rapid failover without a loss of data from committed transactions. When the session is not synchronized, the mirror server is typically available as a warm standby server (with possible data loss).
https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server?view=sql-server-2017
Hope it helps
I have a windows server 2012 with SQL Server 2012 configured with Merge replication with three subscribers.
I want to take a full back up the merge replication in case of total sql server crush. I am not sure how to take it or which databases to take a back up? for how long? so that if some thing happens then I will just restore all the configuration back.
any idea?
thanks
You should take backups of these databases
The publication database at the Publisher
The distribution database at the Distributor
The subscription database at each Subscriber
The master and msdb system databases at the Publisher, Distributor and all Subscribers. These databases should be backed up
at the same time as each other and the relevant replication database.
For example, back up the master and msdb databases at the Publisher
at the same time you back up the publication database. If the
publication database is restored, ensure that the master and msdb
database are consistent with the publication database in terms of
replication configuration and settings.
For more information, refer msdn
To add to what ughai posted, all replication components should be scripted out as a part of a disaster recovery plan. They should also be rescripted if any publication and/or subscription property changes are made.
This is covered in the section Script the replication topology in Best Practicies for Replication Administration and in Scripting Replication.
It does seem like a need of a proper disaster recovery plan, from what you describe. You can create your own or maybe use a third party vendor in order to do that. We worked with cloudendure back at the time, I'm not sure as for their costs right now, maybe it's worth a look. What happens is that you've got a replica being formed and updated in 1 sec time intervals, replication of the data goes right onto the target location (the cloud), and we're aiming for near zero downtime so for whenever that happens, your replica will be loaded automatically onto your site.
I have installed SQL server database (mainserver) in one instance and SQL server database for RerportServer in others. what is the best way to replicate data from mainServer to report Server? Data in mainServer changes frequently and actual information in the ReportSever is very important.
And there is many ways to do this:
mirroring
shipping log
transactional replication
merge replication
snapshot replication
are there some best-practices about this?
Thanks
You need Transactional Replication for your case. Here is why you would not need the other 4 cases:
Mirroring
This is generally used to increase the availability of a database server and provides for automatic failover in case of a disaster.
Typically even though you have more than a single copy of the database (recommended to be on different server instances), only one of them is active at a time, called the principle server.
Every operation on this server instance is mirrored on the others continuously (as soon as possible), so this doesn't fit your use case.
Log Shipping
In this case, apart from the production database servers, you have extra failover servers such that the backup of the production server's database, differential & transactional logs are automatically shipped (copied) to the failovers, and restored.
The replication here is relatively scheduled to be at a longer interval of time than the other mechanisms, typically ranging from an hour to a couple of hours.
This also provides for having the failver servers readies manually in case of a disaster at the production sites.
This also doesn't fit your use case.
Merge Replication
The key difference between this and the others is that the replicated database instances can communicate to the different client applications independent of the changes being made to each other.
For example a database server in North America being updated by clients across Americas & Europe and another one in Australia being updated by clients across the Asia-Pacific region, and then the changes being merged to one another.
Again, it doesn't fit your use case.
Snapshot Replication
The whole snapshot of the database is published to be replicated to the secondary database (different from just the log files being shipped for replication.)
Initially however, for each type of replication a snapshot is generated to initialized the subscribing database, i.e only once.
Why you should use Transactional Replication?
You can choose the objects (Tables, Views, etc) to be replicated continuously, so if there are only a subset of the tables which are used to reporting, it would save a lot of bandwidth. This is not possible in Mirroring and Log Shipping.
You can redirect traffic from your application to the reporting server for all the reads and reports (which you can also do in others too, btw).
You can have independent batch jobs generating some of the more used reports running on the reporting server, reducing the load on the main server if it has quite frequent Inserts, Updates or Deletes.
Going through your list from top to bottom.
Mirroring: If you mirror your data from your mainServer to your reportServer you will not be able to access your reportServer. Mirroring puts the mirrored database into a continuous restoring state. Mirroring is a High Availability solution. In your case the reportServer will only be available to query if you do a fail over. The mirrored server is never operational till fail over. This is not what you want as you cannot use the reportServer till it is operational.
Log Shipping: Log shipping will allow you to apply transactional log backups on a scheduled event to the reportServer. If you backup the transaction log every 15 minutes and apply the data to the reportServer you will have a delay of 15+ minutes between your mainServer and Log server. Mirroring is actually real time log shipping. Depending on how you setup log shipping your client will have to disconnect while the database is busy restoring the log files. Thus during a long restore it might be impossible to use reporting. Log Shipping is also a High Availability feature and not really useful for reporting. See this link for a description of trying to access a database while it is trying to restore http://social.msdn.microsoft.com/forums/en-US/sqldisasterrecovery/thread/c6931747-9dcb-41f6-bdf4-ae0f4569fda7
Replication : I am lumping all the replication together here. Replication especially transactional replication can help you scale out your reporting needs. It would generally be mush easier to implement and also you would be able to report on the data all of the time where in mirroring you cant report on the data in transaction log shipping you will have gaps. So in your case replication makes much more sense. Snapshot replication would be useful if your reports could be say a day old. You can make a snapshot every morning of the data you need from mainServer and publish this to the subscribers reportServer. However if the database is extremely large then Snapshot is going to be problematic to deal with on a daily basis. Merge replication is only usefull when you want to update the replicated data. In your case you want to have a read only copy of the data to report on so Merge replication is not going to help. Transactional Replication would allow you to send replications across the wire. In your case where you need frequently updated information in your reportServer this would be extremely useful. I would probably suggest this route for you.
Just remember that by implementing the replication/mirroring/log shipping you are creating more maintenance work. Replication CAN fail. So can mirroring and so can transaction log shipping. You will need to monitor these solutions to make sure they are running smoothly. So the question is do you really need to scale out your reports to another server or maybe spend time identifying why you cant report on the production server?
Hope that helps!