Tag Info

New answers tagged

0

I do not believe that there is a way to rename it (safely). You will need to rebuild the AG. If you do it during an outage window where you can eliminate or minimize data changes then you should be able to do it without having to perform new backups / restores.


3

First, let's clarify terms. AlwaysOn is a Microsoft marketing term which includes both SQL Server Availability Groups and SQL Server Failover Cluster Instances. You should stop using AlwaysOn and be specific for all future communications. If you are referring to FCIs: the configuration should be completely transparent to your application. They should ...


0

Creating a listener creates (permissions must allow, otherwise the entry will be made by the network team) a DNS entry, and has a dependency to an IP address. It logically follows that each listener needs its own IP address, because how else will traffic know where to be directed? See Failover Cluster Manager>[Cluster Name]>Services and applications> ...


0

Got all the answers to my question mentioned above. If anyone facing the same problem I would like to point them to the answer : Here's the answer to all the questions why explicit commit takes time : [A commit transaction (FlushToLSN/StartLogFlush) can trigger similar behavior, even when the block is not full, so a commit transaction does not have to wait ...


1

Just add it as you would normally do on the primary node. Make sure that all the nodes have the same disk configuration and enough disk space.


0

This is easiest to explain if you think about having multiple Availability Groups in your environment rather than just one. Each AG listener would have its own name and IP, and it could be failed over independently to either physical node. In that environment, there are a few different parts: The physical nodes - each of which has its own IP address Each ...


2

Sadly, sys.dm_hadr_availability_replica states is not a reliable indicator of replica health. Here's the Connect item on one of the bugs we've run into where that DMV stops refreshing - note in the comments that log_send_queue_size in the DMV sys.dm_hadr_database_replica_states shows 0 even when there's log data to be sent. Note that the Connect item is ...


4

The Availability Groups feature requires an underlying WSFC. You can use FCIs in combination, but it is not required (and in fact often overkill, depending on what you are trying to accomplish and whether you have underlying redundancy as well). WSFC is the underlying Windows Server Failover Cluster. FCI is just the terminology for a single SQL Server ...


1

Finally found a tutorial here: http://www.derekseaman.com/2014/10/sql-2014-always-ag-pt-12-kerberos.html The problem for me was that I needed to register the SPN for the Availability Group against the Managed Service accounts that are used to run the SQL Database Engine (step 8 in the link). Once I did that and restarted all 3 servers in the cluster ...


0

You must use Windows Domain logins and create them in every instance, As the SID is manage by active directory you will be able to access in all replicas members of availability group if the login exist in the primary replica. another option you must use a certificate.


0

AlwaysOn supports multiple replica databases, so you can have one replica as your HA database, and another replica as your DR database. AlwaysOn is great in that one technology potentially provides your HA and your DR. The HA database would typically be in the same datacentre, and be set to synchronous commit with automatic failover. The DR database would ...


5

When using AlwaysOn Availability Groups does each SQL Instance need to use the same service credentials? No, SQL Server service accounts can be different. We have a 3 node cluster running AlwaysON and on all the servers SQL Server is running with a different account. e.g. If you have one server in NY and other in LD, then Active Directory Accounts ...



Top 50 recent answers are included