I restored a database (db1) which was subscribed to a publisher database. After restoring the db1, I lost the subscription to the publisher, and when I tried to create a new subscription, I get this error:
Subscription already exist for the database
Well that's one way. Another involves reading the Replication documentation.
Dropping a Subscription:
https://learn.microsoft.com/en-us/sql/relational-databases/replication/delete-a-pull-subscription
https://learn.microsoft.com/en-us/sql/relational-databases/replication/delete-a-pull-subscription
Bakup and Restore procedures for Repllication:
https://learn.microsoft.com/en-us/sql/relational-databases/replication/administration/strategies-for-backing-up-and-restoring-snapshot-and-transactional-replication
after struggling for a little. restored the db with new name say db2.
then created a subscription for the db2. which worked fine and dropped the db1. later re named the db2 back to db1. this worked for me and i was able to access the publisher again
Related
Currently, I have a problem that I cannot create replication on database restored from backup.
The production database is running transactional replication.
A backup was made and then database was restored on the test server under the same name.
Replication was running on the test server before.
Now I cannot create replication on the test server. When I try to create a publication I get the message: Sql server could not create publication "test".
Publication "test" does not exists. Object "test" does not exist or is not a valid object for this operation. Change database context to "Database name"
I have tried all the procedures available to clean up / drop replication but is not helping. As far as I know it was a normal full backup and a normal restore datatabse done.
I'm very new to Azure so please don't judge me too harshly.
So, in this project, I've got SQL Server on-premises 'production' database which is the 'master' data. I'm writing a small .NET application that is published on Azure and it is using tables and stored procedures on Azure database. My idea is to have the data in the tables on Azure database up-to-date with the on-premises 'production' database tables.
I've created Sync Group and Sync Agent and it looks like data is flowing accurately from the on-premises Sql Server tables to Azure database tables.
The only problem I have is that when some records on 'prodution' are deleted these records will not be deleted from the Azure tables.
I guess the questions are: What am I missing in synchronization and is it even the right approach to update the Azure database tables using the 'Sync to other databases' tool?
Thanks in advance!
Make sure you have elected the Azure SQL Database as the Hub in your sync group and the on-premise as a member database.
For the Conflict Resolution Policy of the Sync Group, make sure you have selected "Member wins".
According your problem description, since your Azure SQL Data Sync group has be created, we can get that:
Your on-premise SQL server DB is member database.
The Azure SQL database is Hub database.
The Sync Direction of your Sync must be "Member to Hub" or "Bi-directional Sync",
The only problem I have is that when some records on 'production' are deleted these records will not be deleted from the Azure tables.
For your question, I don't think Conflict Resolution Policy can help you solve it.
There isn't a good solution now, I only can give two suggestions for you:
Set Automatic Sync: Off. Sync the data from on-premises SQL
server to Azure manually. This can help your keep
the data in Azure SQL DB for a long time.
Create a new table in Azure SQL database, don't add the new table to
sync group. Copy the data from your synced table to new table. Using the new
table for test.
Hope this helps.
I'm setting up an Azure SQL DB for our Web App. We have enabled Point In Time Retention (PITR) and Long Term Retention (LTR). Our process is to keep backups for 1 year.
Periodically, we need to upgrade the DB by applying SQL scripts. Sometimes there is a problem with the upgrade scripts and the upgrade fails. We need to rollback the database to the previous version.
To rollback the DB I tried the restore feature. However, the restore feature seems to only create new DBs; therein lies the problem. Restoring to a new DB and removing the old one works great, but we lose all our backup history. It appears backups are tied to the DB (probably to the ResourceId).
So, how can I use Azure SQL DB and periodically restore a DB and still maintain all the back up history?
Unfortunately, restoring from a backup in Azure SQL Database always creates a new database. The secret here may be to rename the newly restored database with the name of the original database. You will even see that the restored database once renamed it then shows all the security recommendations, automatic tuning recommendations of the original database.
So delete existing database, restored the database, and rename it as the original database.
You can reference this document Recover an Azure SQL database using automated database backups , it gives the answer that all the recover are creating new database.
By default, SQL Database backups are stored in geo-replicated blob storage (RA-GRS). The following options are available for database recovery using automated database backups:
Create a new database on the same SQL Database server recovered to a specified point in time within the retention period.
Create a database on the same SQL Database server recovered to the
deletion time for a deleted database.
Create a new database on any SQL Database server in the same region
recovered to the point of the most recent backups.
Create a new database on any SQL Database server in any other region
recovered to the point of the most recent replicated backups.
If you configured backup long-term retention, you can also create a new database from any LTR backup on any SQL Database server.
improtant:
You cannot overwrite an existing database during restore.
"So, how can I use Azure SQL DB and periodically restore a DB and still maintain all the back up history?"
You can use Database replacement:
If the restored database is intended as a replacement for the original database, you should specify the original database's compute size and service tier. You can then rename the original database and give the restored database the original name using the ALTER DATABASE command in T-SQL.
Hope this helps.
I'm new to SQL Server and trying to automatically update tables in SQL Server from tables in MS Access.
I have an Access database of metadata that must be kept updated for sending records to other groups. I also have a database in SQL Server which also has these same metadata tables. Currently these tables in the SQL Server database get updated manually by exporting the Access tables as Excel files, and then importing them into the SQL Server tables.
It's not the most efficient process and could lead to errors in the SQL Server database if someone forgets to check that they are using the most recent data from Access. So I would like to integrate some of the tables from Access to my database in SQL Server. Ideally I would like for the tables in my SQL Server database to be updated whenever Access is updated or at least update the tables automatically in the SQL Server database when I open it.
Would replicating the Access tables be the best? I am using SQL Server 2014 Developer so I think I have this capability. From my understanding, mirroring is for an entire database not just pieces of it. However, I do not want to be able to alter the metadata from SQL Server and have it reflected in Access. I cannot tell if reflecting the tables would do this...?
I also looked at this post about writing multiple insert statements but was confused (What is the best way to auto-generate INSERT statements for a SQL Server table?). Someone else suggested importing all the data into SQL Server and then using an ODBC driver to connect the two, but I'm also not sure how this would update the database in SQL Server anytime Access is updated.
If you have any suggestion and a link to easy to follow tutorial I would really appreciate it!
Thanks
In Access, go to 'External Data', ODBC Database, and connect to the SQL Server database directly - make sure you select 'Link to the data source by creating a linked table' on the first page of the wizard. Now, this linked table is available in Access, but is actually the SQL Server table.
Get rid of the local Access tables, using the new linked tables in their place in whatever queries, forms, reports, etc that you have in Access.
Now, any changes to the tables you see in this Access db ARE changes to the SQL Server database.
We have transaction replication between two server (production and staging) which is running on SQL Server 2008 R2. The distributor is running on the staging server. Now my management is asking to create a copy of database on the production environment and replication few tables to that database. Is it possible to replicate twice? Could you please help me on this. If not possible through replication, is there any other way to do it?
You sure can. Create another publication, add the subset of tables to that, and subscribe the other database to the new publication. NB, this will create another copy of changes for this table at the distributor so take that into account.