Tag Info

New answers tagged

1

I resolved this in the end. It was my own fault. I had connected using the name of the cluster "SQL-CLUSTER" rather than creating a listener. Originally I had tried to create a listener but was getting errors so stupidly I'd just ignored them. The errors were because I'd not set up the network properly (I'm a DBA not a network technician :) ) Anyway, after ...


2

Shrinking a log file isn't generally a good idea unless you've had a large amount of unexpected log file growth - otherwise it'll only grow again, and a log file that grows can cause performance problems. You can shrink a log file that's in any of the recovery models, but you won't always see the effect of it, as less of the file will be able to be shrunk - ...


1

I've found that full backups are not supported on the secondary replica just read only backups. A full backup has to be performed on Primary replica. That will serve a base for the diff or T-log backups. A COPY_ONLY backup is supported on secondary replica. You can do transaction log backups on either primary or secondary databases. Check my answer - ...


0

Ok I found what I was missed and it was the cluster because there is only two nodes in the cluster so I add third node and it is working now.


0

What about putting the Distributor in an AlwaysOn Availability Group of it's own on two different servers and make the secondary a synchronous replica? Besides, there's real benefit in a high volume OLTP environment to not having the Distributor on the same SQL Server.


1

Instead of giving the name of the other node, I gave the IP address of the other node. Then everything went well. BUT what the reason was that it did not accept the name, I still do not know.


0

You can find here some design pattern for always on solutions http://blogs.msdn.com/b/sqlcat/archive/2013/11/20/sql-server-2012-alwayson-high-availability-and-disaster-recovery-design-patterns.aspx just note that for automatic fail-over you may want to have synchronous commit so you dont loose data. also to have automatic fail-over you must have node ...


4

in relation to your comment, I suspect a Ops related issue here instead of a SQL Server engine issue. These SAN devices usually work on the block layer and some manage transaction log/data file sync better than others, as well as other areas. You can show the ops team that no, SQL Server doesn't randomly corrupt data like this. You can restore backups ...


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.


4

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 ...



Top 50 recent answers are included