Skip to main content

Best Practices on Clustering


  • Detailed planning is critical to the success of every SQL Server cluster installation. Fully plan the install before performing the actual install.
  • An expensive cluster is of little value if the supporting infrastructure is not also fault tolerant. or example, don’t forget power redundancy, network redundancy, etc.
  • Run only a single instance of SQL Server per node. Whether you have two or eight nodes in your cluster, leave one node as a failover node.
  • Cluster nodes must not be domain controllers, and all nodes must belong in the same domain and should have access to two or more domain controllers.
  • All cluster hardware must be on the Microsoft Windows Clustering Hardware Compatibility List, and certified to work together as part of a cluster.
  • Since clustering is not designed to protect data (only SQL Server instances), the shared storage device used by the cluster must incorporate fault tolerant technology. Consider log shipping or mirroring to further protect your production databases.
  • When initially installing Windows and SQL Server Clustering, be sure that all drivers and software are up-to-date, including the latest service packs or hot fixes.
  • Each node of a cluster should have identical hardware, drivers, software, and configuration settings.
  • Fiber channel shared arrays are preferred over SCSI, and Fiber channel has to be used if you include more than two nodes in your cluster.
  • The Quorum drive must be on its own fault-tolerant, dedicated, logical drive.
  • Once the cluster has been installed, test it thoroughly for every possible failure scenario.
  • Do not run antivirus or antispyware on a SQL Server cluster.
  • If you need to reconfigure any Windows or SQL Server clustering configuration options, such as IP addresses or virtual names, you will need to uninstall clustering and then reinstall it.
  • Monitor active production clusters on a daily basis, looking for any potential problems. Periodically test failover on production servers to ensure all is working well.
  • Once you have a stable SQL Server Cluster running, be very leery about making any changes to it, whatsoever.

Comments

Popular posts from this blog

Self Introduction and Responsibilities of a SQL Server DBA.

Hi, Self Introduction:                      I am Vang chew bigger , currently I am working with   Citronics , Here my role is SQL Server Database Administrator , I am having 3+ yrs Exp in SQL SERVER DBA with T-SQL, I have experience on SQL Server 2000, 2005 and 2008, I have a great experience on installation and configuration of SQL SERVER versions, and also applying the patches, hot fix, services packs and RTM’s accordingly, involved in upgrading on in place and side by side as per client requirement, and also Migrating the database on SQL SERVER 2000 to 2005 and 2008, Solid experience on configuring and maintenance of High availability SQL Server solutions, including Log shipping, Database Mirroring, Replication(Transactional and Merge) and SQL Server Clustering., having experience on performance tuning on server level, database level and query level, Responsible for working with application developers in identifying, resolving and proactively working to prevent performance or oth

SQL Server 2016 Windows Server 2016 Firewall Rule Step-By-Step.

SQL Server 2016 Windows Server 2016 Firewall Rule Step-By-Step. Opening Firewall in SQL Server 2016. Once the SQL Server is installed on the machine. We must enable the incoming traffic i.e., from the application to the SQL Server Database. For this purpose, we must create rule for SQL Server ports so that the application can connect to database & perform the CRUD operations on the tables. Now Let’s start Step-by-Step to enable it. 1.   Start System and Login (As Administrator); 2.   Open Control Panel. Click on Windows Firewall; 3. Now click on Advanced Settings; 4. Windows Firewall console open. If you click on Properties (right side) – you can disable firewall for all networks. We going to Inbound Rules (left side) for our rule creation; After Clicking on the Inbound rules. We will see the below screen.  Click on New

Shrinking a SQL Server Log File with Database in Always ON Availability.

Shrinking a SQL Server Log File with Database in Always ON Availability.                    Once we had a situation in our production server that the database which is in Always ON Availability group has been grown to the maximum size.  Many of them say that we can't shrink the log file as the database is in Always ON and we should take the downtime to perform the operation. But we shrink-ed the database log file to 5 GB from 180 GB. Steps are as below: --To Check the Number of pages allocated by the LogFile. DBCC LOGINFO --To check the file sixe sp_helpdb [SQLPantry] --To check the Log file Size DBCC SQLPERF(LOGSPACE) The above statement will show the logspace of all db at present situation. --To check the Log_reuse_wait description of a log file. select log_reuse_wait_desc,* from sys.databases The above statement will show the status of the log whether it has to be backuped i.e., LogBackup, Nothing, Active Transaction.  When ever there is status as Activ