We have a sql database on AZURE, which is geo replicated to another server in different location.
We had incorrect pricing tier on this DB (which also transfered to the geo replica). In order to change it, i had remove DB from failover group and then delete replication link.
Now when i want to recreate the link, it says that DB with this name already exists (which of course does, i deleted the link but not the replicated DB).
Is there any way to recreate link on the existing DB or is the best practise to just delete the replicated DB and create it anew?
Azure Geo Replication Failover is a feature designed for automatically managing replications on database failures.
If it were a manual exception, such as incorrect pricing or schema errors, it would not correct/reflect by default because those databases are read-only, as shown below.
Solution:
1.Delete the database on the replica and re-add the database from the primary server again; it will automatically configure the latest database features; there is no need to delete the link.
Step2:
Create a new replica link from primary to failover again
Related
Copying a database in the Azure Portal is never ending.
Usually, when I copy a 250GB database, it completes in just under an hour.
Today, when I copy, it never seems to finish, it has been over two to three hours now.
And in the server activity logs, the last entry just says an update occured
Any idea on how to see more progress, percent complete, or any other way to see what might be locking it? Nothing of use can be seen in the activty log json.
You can use SYS.DM_OPERATION_STATUS to track many operations including copy in SQLAZURE..
Documentation states
To use this view, you must be connected to the master database. Use the sys.dm_operation_status view in the master database of the SQL Database server to track the status of the following operations performed on a SQL Database:
Below are the operattions that can be tracked
Create database
Copy database. Database Copy creates a record in this view on both the source and target servers.
Alter database
Change the performance level of a service tier
Change the service tier of a database, such as changing from Basic to Standard.
Setting up a Geo-Replication relationship
Terminating a Geo-Replication relationship
Restore database
Delete database
You can also try sys.dm_database_copies in master database for info about copy status ..This has percent_complete field and below is what documentation has to say about this
The percentage of bytes that have been copied. Values range from 0 to 100. SQL Database may automatically recover from some errors, such as failover, and restart the database copy. In this case, percent_complete would restart from 0.
Note:
This view has info only during the duration of copy operation..
I have a Cloud hosted Database, maintained by a different company. Here is my scenario:
I would like to bring down the entire database, schema and data, and keep my Local database updated real-time(sql server 2008r2).
I cannot setup replication inside SQL server, I do not have permissions on the cloud server.
I cannot use triggers.
I cannot use linked servers
They would provide me a copy of backup (nightly)and access to the transacrion logs every 1 hour
How can I use these to update my entire database.
Thanks in advance
I have set up an Azure database instance which supposedly replicates into a 'read only' secondary database using standard geo-replication. In the Azure portal I can see the status of the replication is 'online' and 'Secondary type' is 'Offline', which appears to be normal.
My question is, is there a way for me to see the actual contents of the secondary database, to ensure the replication is actually working as planned?
I cannot 'Manage' the database in the portal. I can connect to the instance in SQL Management Studio, where I can see the database but expanding tables / stored procedures shows nothing (a bit like connecting to a secure database using the non-secure connection string). I am also not able to run any queries against it as it gives me 'Connection to an offline secondary database is not allowed.'
I've searched this site an did a web search for an answer but can't seem to find one. Am I supposed to blindly rely on the fact that Azure is perfoming the replication correctly (with no way to double-check), or am I missing something here?
Many thanks in advance for any light you are able to shed on this.
Standard Geo-Replicated Secondary DBs are offline copies that do not accept client connections (so there is no way to query the data directly). If you need a readable Geo-Replicated Secondary then you must use the Active Geo-Replication available for Premium DBs.
Even though you can't query Standard Geo-Replicated DBs directly, you can use the DMVs in the Master to determine if the continuous copy is working correctly.
On the Master try the following:
SELECT * FROM sys.dm_database_copies
SELECT * FROM sys.dm_Continuous_copy_status
I hope this helps!
For more information about Standard Geo-Replication, Active Geo-Replication Or Checking the activity of continuous copy use the following links.
Standard Geo-Replication: https://msdn.microsoft.com/en-us/library/azure/Dn758204.aspx
Active Geo-Replication: https://msdn.microsoft.com/en-us/library/azure/dn741339.aspx
Continuous Copy DMV Blog: http://www.sqlservercentral.com/blogs/pie-in-the-sky/2014/12/25/monitoring-geo-replication-in-sql-azure-using-dmvs/
I tried to repro your situation and I think I understand the confusion.
When the Secondary Type = "Offline" then it is a standard Geo-Replicated Secondary. The Primary Databases page is confusing, but when you click on the link to the secondary should show that it is offline.
As far as understanding if the continuous copy is working, run the script below against the Primary (I was mistaken last time, Sorry).
SELECT * FROM sys.dm_Continuous_copy_status
You should see the linked server, database, and Replication State.
As before if you need to read from your secondary, you will have to created a premium active-Geo Replicated Secondary.
Hope This helps!
I had a transactional replication in SQL server 2012. people changed the data inside the subscription database. so changes has been added to subscription from:
1- my publication
2- people who inserted their own data directly into subscription database.
I wana rebuild my replication, is there any way to rebuild replication using my subscription database which have users data?
Thanks,
Babak
The short answer is in the documentation under the subheading "Databases at the Subscriber".
But the longer answer is that you should design your replication topology in such a way so as to make the subscription database completely expendable. That is, if you have data that the users are entering directly into that database, either put it in separate tables (and put those tables on separate a separate filegroup) or, better, put those tables in a separate database completely and create views/synonyms to those tables in your subscriber database.
I have SQL Server 2008 installed on my machine and also Reporting Services Configuration Manager. When I connect to SQL Server, I found two databases already there.
ReportServer
ReportServerTempDB
I know ReportServer is to store reports, data sources, snapshots, subscriptions, etc. But what is ReportServerTempDB for? Why is it created? Is that necessary (for our use)?
Read the documentaion on report server database
The databases are created together and bound by name. By default, the database names are reportserver and reportservertempdb, respectively.
Report Server Temporary Database
Each report server database uses a related temporary database to store
session and execution data, cached reports, and work tables that are
generated by the report server. Reporting Services does not re-create
the temporary database if it is missing, nor does it repair missing or
modified tables. Although the temporary database does not contain
persistent data, you should back up a copy of the database anyway so
that you can avoid having to re-create it as part of a failure
recovery operation. If you back up the temporary database and
subsequently restore it, you should delete the contents. Generally, it
is safe to delete the contents of the temporary database at any time.
However, you must restart the Report Server Windows service after you
delete the contents. If you delete the temporary database, you can
create a new database, and then run the Catalogtempdb.sql script to
add the table structure. The temporary database must have the same
root name as the primary report server database.