We have a large number of client databases with the same schema and does anyone knows how to create duplicates (like snapshot in SQL Server CE) from a provisioned client database, where the duplicates also can be synchronized with the server, since it takes really a long time to provision each client separately.
Thank you.
Create a backup of an existing provisioned database, restore on client, run PerformPostRestoreFixup before you sync the restored database for the first time.
Related
So for my Azure cloud-hosted application, I am using two databases, primary and secondary, respectively. The old data in the primary db is set up to be moved to the secondary db after it is not needed anymore. As a result, the secondary db with the bulk amount of data over a period of time takes a long enough time to be accessed through the SQL queries which is undesired.
So I have stored the secondary db's older data in azure cold storage and now I am trying to figure out a way to access it through SQL queries from the cold storage itself. But even though, through SSMS, connection to Azure cold storage is possible, I am not getting any option to run SQL queries since I am connected to Azure storage account, not a database engine.
Is there any solution to this? Or ANY workaround?
My aim is to store that unnecessary secondary db data in the Azure cold storage and access it from there through SQL queries whenever needed.
Any suggestion is welcome. Thanks in advance.
I want to migrate my SQL Server Databases to AWS EC2 instances or AWS RDS using DMS Service of AWS?
How can I do that? What will be the architecture for the same? How to secure Databases in AWS?
What is the difference between both approaches? Can anyone provide architecture for both the approaches?
We're in the middle of moving our on-prem SQL Servers to AWS EC2 right now. For us, we're adding replicas to existing Availability Groups. When the time comes, we'll fail over the AG and tada! we'll be in AWS. But even if we didn't have AGs, I'd still do this with backup/restore over DMS. From the little bit that I looked at DMS, you need either CDC or a rowversion column on every table you want DMS to work with. Which seemed like a lot to me.
In case you're not acquainted with moving a database with backup/restore, here's the bones of it.
Copy a full backup to the target system
Restore that backup, being sure to specify with norecovery to allow it to accept more backups
Copy/restore a differential backup, again specifying with norecovery
Copy/restore transaction log backups. You'll keep doing this on a periodic basis until you're ready to do your cut over.
When you're finally ready to turn off the source database, take a log backup of the source, specifying with norecovery. This will create what is called a tail of the log backup and will stop anything from being able to write to the source database. Copy/restore that last log backup over and you're migrated.
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 database on an SQL Server instance hosted on Azure Windows VM. There are two things I need to achieve.
Create a real-time duplicate of the database on another server. i.e. I need my database to make a copy of itself and then copy all of it's data to the duplicate at regular intervals. Let's say, 2 hours.
If my original database fails due to some reason, I need it to redirect all read/write requests to the duplicate database.
Any elaborate answer or links to any articles you deem helpful are welcome. Thank you!
You can have a high availability solution for your SQL Server databases in Azure using AlwaysOn Availability Groups or database mirroring.
Basically, you need 3 nodes for true HA. The third one can be a simple file server that will work as the witness to complete the quorum for your failover cluster. Primary and Secondary will be synchronized and in case of a failure, secondary will take over. You can also configure read requests to be split among instances.
If HA is not really that important for your use case, disaster recovery will be a cheaper solution. Check the article below for more info.
High Availability and Disaster Recovery for SQL Server in Azure Virtual Machines
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-sql-server-high-availability-and-disaster-recovery-solutions/
SQL Server 2008R2 Transactional Replication - Move SubscriberDB - Push Subscription
I have a requirement to move a subscriber database to a new server outside of a system outage i.e. I cannot stop new transaction from loading into the publisher database.
So far I have attempted to stop the distribution agent and let all un-replicated commands replicate to the subscriber database at Server1. Then backup and restore the subscriber database to Server2. I have then created a new subscription from Server2 to the existing publication.
This works but only transactions created from that point forward are replicated to the Server2 subscriber database. I also require all the old transactions built up at the distributor database destined to only go to Server1.
Is there a replication command available to update the destination of existing transactions at the distributer to the new subscriber.subscriber_DB?
There is 1 publication with multiple articles. The publication is currently only subscribed to by one database at Server1.
You're working too hard. Create a subscription on the new server as though you didn't have an existing subscription at all. There are many ways to do this; pick your favorite. I see in your response to another answer that snapshots are a no-go. I have had a lot of success using the "initialize from backup" option (here, "backup" refers to a backup of the publisher). Once the subscriber is in sync after initialization, you're done. You're now clear to "migrate" to the new server.
Due to the distribution agent being specific to each subscribing server, you can't really have a new subscriber take over where an existing subscriber left off. The only way this would work is if you backup/restore to Server2, temporarily stopped transactions on the publisher, backup/restore log to Server2, create subscriptions with "replication support only", and then re-enable transactions.
Can you not just add subscriptions to the same publication for the new subscriber and kick off the snapshot agent? That will independently sync Server2 while Server1 continues to stay in sync. You should then be able to switch to Server2 seamlessly and remove the subscriptions to Server1.
One note of warning though. I would check the sync_method in syspublications table (or run sp_helppublications) of your publication database to make sure snapshots won't lock the tables in your publisher (by default with SQL Server 2005+, this shouldn't be an issue). Otherwise, what I just suggested will cause blocking on the publisher until the snapshot finishes.
Also, this is a good reference to understanding how to do snapshots one at a time if you setup replication through the GUI using default settings. This will be useful for distributing the snapshots over a larger period of time to reduce publisher server load if you have a lot of data to replicate (gigabytes rather than megabytes).
http://www.replicationanswers.com/TransactionalOptimisation.asp