Clustering

External Article

Migration Guide: Migrating to SQL Server 2012 Failover Clustering and Availability Groups from Prior Clustering and Mirroring Deployments

  • Article

This paper provides guidance for customers who prior to SQL Server 2012 have deployed SQL Failover Clustering for local high availability and database mirroring for disaster recovery, and who want to migrate to SQL Server AlwaysOn. It describes the corresponding SQL Server AlwaysOn scenario and the migration paths to SQL Server AlwaysOn. It also contains the important knowledge and considerations that you must know in order to successfully migrate to a HADR solution based on SQL Server AlwaysOn technology, which implements AlwaysOn Failover Cluster Instances for high availability and AlwaysOn Availability Groups for disaster recovery.

2012-04-13

2,738 reads

Blogs

From Data Custodian to Innovation Catalyst: The Evolving Role of the CDO

By

There was a time when the Chief Data Officer lived in the shadows of...

Down the Rabbit Hole: Dealing with Ad-Hoc Data Requests

By

"But I don’t want to go among mad people," Alice remarked."Oh, you can’t help...

Adding a Local Model to Ollama through the GUI

By

I saw some good reviews of the small gemma3 model in a few places...

Read the latest Blogs

Forums

Create an HTML Report on the Status of SQL Server Agent Jobs

By Nisarg Upadhyay

Comments posted to this topic are about the item Create an HTML Report on...

We Should Demand Better

By Steve Jones - SSC Editor

Comments posted to this topic are about the item We Should Demand Better

Estimated Rows

By Steve Jones - SSC Editor

Comments posted to this topic are about the item Estimated Rows

Visit the forum

Question of the Day

Estimated Rows

I have two calls to the GENERATE_SERIES TVF in this code:

SELECT   TOP 10 gs.value
FROM     GENERATE_SERIES(1, 10) AS gs
ORDER BY NEWID ()
OPTION (RECOMPILE);
go
DECLARE @a int = 10;
SELECT   TOP (@a) gs.value
FROM     GENERATE_SERIES(1, @a) AS gs
ORDER BY NEWID ()
OPTION (RECOMPILE);
In the actual query plans, what is the estimated number of rows for each batch?

See possible answers