I would like to replace Database Mirroring with Basic Availability Group because mirroring is deprecated and I cannot use the mirror server for load balancing.
But I am not sure if the secondary replica of Basic Availability Group is readable.
Please let me know.
The whole purpose of replacing DB Mirr. with BAG is to have the secondary replica in readable state.
We are running SQL Server 2016 Standard Edition SP2-CU6.
Your responses will be highly appreciated.
No - SQL Server Basic Availability Groups do not support read-only secondary replicas.
See the Microsoft documentation for details and note the second bullet point under "Limitations".
Related
Any idea how I can turn off/bring down primary Azure SQL database / SQL Server in fail over group to replicate an actual scenario like a data center is down? I tried renaming but doesn't work. All I am trying to do is take one of the Azure SQL databases offline in the failover group. Any ideas how it can be done please?
You can use a forced failover which may result in data loss same as a server down or datacenter down scenario. Note that is not the same as a manual or friendly failover using the portal, on which case there is no danger of data loss.
You can use REST API to generate a a forced failover as explained on this documentation.
I want to know if it's posible to share SQL Server SESSION CONTEXT variables between different Azure Sql databases using Elastic Queries.
I searched in official documentation but i can't found any information about this feature is available or not.
SESSION CONTEXT exists locally to a single server instance in SQL Server. (It's tied to a session). SQL Azure is built using SQL Server but there are some parts of the mapping that are opaque to customers (they can change based on circumstances such as what Edition you use or what version of the internal software we are using to deliver the service).
Elastic Queries is a feature to let you query from one database (source) to one or more other databases (target(s)). In such a model, you have a SQL Server session to the source database, and the elastic query has a separate connection/session to each other database being touched.
I think the question you are asking is "can I set the session context on the source connection/session and have it flow through to all the target connections when running queries there?" (That's my best guess - let me know if it is different). The answer today is "no" - the session variables do not flow from source to target as part of the elastic query. Also, since today elastic query is read-only, you can't use elastic query to set the session context individually on each target database connection/session as part of the operation.
In the future, we'll consider whether there is something like this we can do, but right now we don't have a committed timeline for something like this.
I hope this explains how things work a bit under the convers.
Sincerely,
Conor Cunningham
Architect, SQL
Hey guys i am learning about MS SQL-Server clustering instances. I am wondering if you could add a cluster on a existing instance of SQL server 2012.
I mean is it the whole point of clustered instances: to create a new instance that supports disaster recovery?
I have no experience in clustering a SQL Server (I'm no DBA) so all I can give is a link (brentozar.com - An Introduction to SQL Server Clusters) with a good read.
The main things to take away from this excellent post, written by Kendra Little, and I quote:
Key Concept: A Windows Failover Cluster uses shared storage– typically, this shared storage is on a SAN. When a SQL Server instance is installed on the cluster, system and user databases are required to be on the shared storage. That allows the cluster to move the SQL instance to any server (or “node”) in the cluster whenever you request, or if one of the nodes is having a problem. There is only one copy of the data, but the network name and SQL Server service for the instance can be made active from any cluster node.
Translation: A failover cluster basically gives you the ability to have all the data for a SQL Server instance installed in something like a share that can be accessed from different servers. It will always have the same instance name, SQL Agent jobs, Linked Servers and Logins wherever you bring it up. You can even make it always use the same IPAddress and port– so no users of the SQL Server have to know where it is at any given time.
The link has a beautiful description of a use-case with 2 simple images but I don't want to incorporate the whole post in here. If the quote doesn't make things clear, surf to the link.
I need to perform replication on MS SQL Server 2005 Standard Edition. The goal is, that I have several databases (for example 4 instances of SQL Server) and each must act as publisher to other sites. I know, that merge replication model of subscriber - publisher - subscriber is possible, but it doesn't suit me. I need to maintain replication process between other machines when no matter which server is down, so all other servers will have actual data.
Is it even possible? And if yes, can You point me to something?
Thanks in advance.
It sounds like you're describing peer-to-peer replication. Read up on it here.
I am using two similar SQL database in two different servers one is local and another one is online. I want to transfer data at the end of the day from the local server to the online server.
what is the best method to automatically transfer data and protecting primary keys effectively.
Thank you
Use Red-Gate Data Compare. It's commercial, though.
(I'm just a satisfied customer and in no way related to Red-gate)
Open SQL Server Management Studio and connect to both servers, in the Object Explorer right-click on a server and choose Tasks, and select Import Data or Export Data, then it's a simple wizard to go from there.
SSMS can also do a schema compare (no need to pay for RedGate Comparison software) if needed.
Have you considered using Replication?
replication tutorial
I believe what you are trying to do is a Mirror database, updated daily, if that is the case:
Using Database Mirroring is a best practice (Instead of manually doing this yourself), I suggest:
Read about Mirroring here: Database Mirroring
Follow this guide: Setting Up Database Mirroring
Your local server should be the principal and your online will be the mirror
I highly recommend this approach , instead of manually scripting the data (see link to answer below), it will give you benefits such as automatic failover (when your local server crashes it will use the remote one) , you can read all about the benefits in the links above.
If you eventually want to do it manually for any reason, or you don't have the SQL Server Enterprise edition , then read my answer to this question:
sql-server-copying-tables-from-one-database-to-another