SQL Server Patching Steps for Standalone Instance


Before patching change starts you need to perform below steps :

1.     Log Onto the Standalone SQL Windows box.

2.    Check for Missing msi and msp files . Please check below link how to find out missing files and fix it

https://support.microsoft.com/en-in/help/969052/how-to-restore-the-missing-windows-installer-cache-files-and-resolve-p                                                                                  OR

You can use MSI-Moksha.exe  tool  to find out missing msi and msp files ,also you can repair the missing files by using this tool itself .

3.     If there are any – repair the missing files.

4.     And Make sure that above steps are completed successfully.

5.     During maintenance Window perform below steps :·       

 Put SQL windows box into maintenance mode·       

 Run the patch executable·        

Make sure all rules have passed. If not take corrections·       

 Accept the license term on next page and proceed·       

 Select all SQL server features that needs to be Upgraded·       

 Files in use will be checked on next page – hit next when checking complete·        

Verify the list of features that will be upgraded and hit Upgrade·     

Wait until it completes and make sure it’s successful. See the Summary. txt error log located at C:\Program     Files\Microsoft SQL Server\100\Setup Bootstrap\Log and check the detail logs for troubleshooting if failure   happens

6.       Reboot SQL window box if required

7.       Perform SQL Health check

8.     Once above steps are completed successfully you can remove the SQL Box from MM(Maintenance Mode).

9.   Validate in the Monitoring Tool ( if you have any ) to make sure the corresponding Patched Instances are being correctly monitored.
Once above all steps are completed successfully Connect to SQL Instances that were patched and run below SQL to see SQL Version is at correct level: 

SERVERPROPERTY(‘Edition’) AS ‘Edition’,
SERVERPROPERTY(‘ProductVersion’) AS ‘ProductVersion’,
SERVERPROPERTY(‘ProductLevel’) AS ‘ProductLevel’,
SERVERPROPERTY(‘ResourceLastUpdateDateTime’) AS ‘ResourceLastUpdateDateTime’,
SERVERPROPERTY(‘ResourceVersion’) AS ‘ResourceVersion’

Back-Out Plan :
If any issues with Patching perform below steps
Log onto Standalone SQL windows box

  • Open Add and Remove Programs from control panel
  • Check the Show Updates box on add remove programs window 
  • Go down the page and locate (Sp info), check the box to mark it and hit remove
  • Follow the wizard until the feature is completely removed
  • Reboot if required
  • Perform SQL Health check.

Best Practice Steps After SQL Server Installation

Post SQL Server Installation Steps :

  1. Add the SQLServerMSSQLUser$ServerName$InstanceName group to the Root path with Full Control of D, and List Folder Contents Permissions for Data, Log and Tempdb Drives.
  2. Add the SQLServerMSSQLUser$ServerName$InstanceName group with Full Control of SQLData folder on Data and Tempdb Drives.
  3. Add the SQLServerMSSQLUser$ServerName$InstanceName group with Full Control of SQLLogs folder on Log Drive.
  4. Remove the AD Service User Account from the Root Path. (This decouples the Service Account explicitly and relys on the group)
  5. Add the SQLServerMSSQLUser$ServerName$InstanceName, SQLServerSQLAgentUser$ServerName$InstanceName, or other group accounts to any Backup, or processing folders as needed.
  6. In the Local Security Policy, add the SQLServerMSSQLUser$ServerName$InstanceName group to the Perform Volume Maintenance Tasks and Lock Pages in Memory objects.
  7. Verify the Antivirus( Macaffe) team excluded Data, Log, Tempdb, any Backup file paths, and the SQL Server Binaries folders from AntiVirus Scans.
  8. Verify backup is excluding mdf, ndf, and ldf files.
  9. Remove Builtin\Administrators and Builtin\user logins.
  10. Enable All Login Auditing in the SQL Server Security Settings
  11. Enable TCP/IP and change default port from 1433.
  12. Enable remote DAC connections.
  13. Enable as required xp_cmdshell, SQLCLR, and OLE Automation for the SQL Server Instance.
    a. Configure xp_cmdshell proxy account as required.
  14. Enable DatabaseMail and configure default public and private accounts.
  15. Configure SQL Error Log retention for 99 log files
  16. Configure SQL Agent job to perform nightly log rollover.
  17. Configure SQL Server Maintenance Plans for system and user database backups, CHECKDB, index maintenance, statistics updates, backup cleanup, and history cleanup.
  18. –Move MSDB Database files to SQLData and SQLLogs respectively.
  19. Reconfigure Tempdb with data files equal to 1/2-1/4 the physical CPU’s on the server based on load characteristics. Set data files to the same size based on load characteristics in 4096MB increments for Datafiles, and 1024MB increments for Log files. Set AutoGrowth to 1024MB for data files and 512MB for Log file.
  20. –Enable Trace Flag 1118 on SQL Server 2000/2005/2008/2008R2/2012/2014 and SQL Server 2016 for Tempdb.
  21. Set Model database to SIMPLE recovery, 2048MB default datafile size and 1024MB default logfile size. Set AutoGrowth to 1024MB for data files and 512MB for Log file.
  22. Set Max Server Memory based on installed RAM and installation type (Newer Servers are all 64bit, but enable AWE as needed on 32 bit servers).
    a. 8GB RAM = 6144 Max Server Memory
    b. 16GB RAM = 12228 Max Server Memory
    c. 32GB RAM = 28672 Max Server Memory
    d. These are base values that will later be adjusted based on the Memory\Available MBytes counter being > 150 on the Server( based on your environment ).
    e. Memory configuration on clustered Instances should account for multiple instances on a one physical node in case of fail over.
    f. In general, you should calculate Max. Server Memory using the formula: Max. Server Memory for a SQL Server Instance = (Total RAM available to the OS) – {(OS: memory pool, filesystem cache, PTE, desktop heap, Driver Images etc…) + (Non-buffer Pool region of SQL Server allocated to Multi Page Allocators, Worker Threads, COM, Extended SPs, Backup Buffers, CLR, Linked Server…) + (SQL Server Agent, Replication Agents, Bulk Copy, SSRS, SSAS, SSIS, and Full Text) + (Log shipping file copy depending on the size of log backups) + (Other SQL Server instances running in the box) + (Other applications running in the box (Antivirus, Monitoring Softwares, Compression softwares etc…) }
  23. Set max degree of parallelism sp_configure option based on the number of physical CPU cores installed and anticipated workload
    a. For OLTP, generally set to 1/2 or 1/4 of the physical cores available on the server.
    b. Adjusted up or down based on wait stats and load.
  24. Set cost threshold of parallelism sp_configure option based on the anticipated load.
    a. General default value of 5 is low for most OLTP workloads and should be increased.
    b. Base value of 20-25 used for most server installs.
  25. Add AD login (standard for environment and locked out in AD by default) for patching and emergency server access to Local Administrators Group.
  26. Set SA user password to standardized password that is changed quarterly on all servers and maintained in password safe.
  27. Install the SQL Server Performance Dashboard Reports
  28. Create default alerts for severities 16 through 25.
    SQL Server’s alerting system has the ability to notify operators whenever major things break inside the database. These include running out of space in log files, backup failures, failed logins and other things DBAs just need to be aware of. Don’t rely on this as your only SQL Server monitoring system, because it only sends alerts when it’s too late to take proactive action, but still, it’s better than nothing.

The below script will set up an alert for severity 16. Copy this and repeat the same thing for 17-25, but change ‘Database Team’ to be the name of your default operator. Notice that @delay_between_responses is set to 60 – that means if it sends out an alert, it won’t repeat that same alert for 60 seconds. This is useful because when a database runs out of drive space, for example, all hell will break loose for a minute or two, and you don’t want hundreds of emails and pages per minute.

USE [msdb]
EXEC msdb.dbo.sp_add_alert @name=N’Severity 016′,
EXEC msdb.dbo.sp_add_notification @alert_name=N’Severity 016′, @operator_name=N’Database Team’, @notification_method = 7

Sql Server Migration

Side-by-side migration

A side-by-side upgrade/Migration consists of installing SQL Server Latest Version and moving the databases from the old instance to the new instance. The side-by-side method gives us a chance to test the effects SQL Server 2Latest Version will have on the application before moving from the older version. The new instance can be installed on a second server, or we can use the same server provided it meets the installation requirements. Migration provides access to two instances of the system, letting us verify and compare the two systems. During migration, both the old and new systems remain online until migration to the new instance is complete. At the end of the migration, all applications are directed to access the new instance and the old instance is manually removed.

Once we have installed the new instance of SQL Server Latest Version, there are three methods for moving the databases to the new instance:

1) Copy database Wizard
2) Database Backup and Restore
3) Detaching and Attaching

Installing SQL Server Latest Version in this side-by-side approach is no different from doing a fresh install. However, with a side-by-side upgrade, we need to worry is about how to migrate the database to the new instance.

Copy database Wizard: The Copy Database Wizard lets us move or copy databases and their objects easily from one instance to another instance, with no server downtime. We can use the Copy Database Wizard to copy our database to an upgraded instance of SQL Server Latest Version. We are given the option to make a copy of the database or completely move the database. We may also choose to copy the database by using the detach and attach method, or by using SQL Management Objects (SMO). If we use the detach and attach method from the wizard, we need to make sure that there are no users trying to access the database before running the wizard. If we use SMO, the database will remain online during the entire process. We can also choose to move any database-related objects, such as logins and jobs. We should point out that while we can copy logins using the Copy Database Wizard, for security reasons, the wizard creates the login on the destination server with a random password and then disables the login.

Using this wizard, we can do the following.
1) Pick a source and destination server.
2) Select databases to move or copy.
3) Specify the file location for the databases.
4) Create logins on the destination server.
5) Copy additional supporting objects, jobs, user-defined stored procedures, and error messages.
6) Schedule when to move or copy the databases.

NOTE: The Copy Database Wizard creates a SQL Server Agent job that executes an SSIS package. We need to make sure that we have Integration Services installed and the SQL Server Agent running on the destination server prior to executing the Copy Database Wizard.

Database Backup and Restore: Using the backup and restore method is a good way to copy the database to the new instance without impacting the availability of the current database. All we need to do is take a full backup of the current database, copy that backup to the new location, and restore it. SQL Server will upgrade the database during the restore process. The result will be a SQL Server Latest Version database that we will not be able to move back to an earlier release.
We need to copy any objects outside the database, such as logins and jobs, since we cannot restore system databases to a newer version of SQL Server.

Detaching and Attaching: We can prefer the detach and attach method when permanently moving databases to a new instance of SQL Server. By moving each file itself instead of a copy of the file at any given point in time, we can be sure that we have captured the exact state of the database as it existed on the previous instance. Since the database is detached, it will be inaccessible for any transactions, ensuring that no data will be committed on the old system during the upgrade. Detaching the database also helps to validate that all the connections have been reconfigured to point to the new system.
We can use the sp_detach_db stored procedure to detach a database. We should also set the database to single-user mode and immediately roll back any transactions before trying to detach the database.

T-SQL Script to Detach a Database:

USE [master]
EXEC master.dbo.sp_detach_db ‘DatabaseName’

To attach a database in SQL Server Latest Version, we should use the CREATE DATABASE statement with the FOR ATTACH clause. This statement and clause replace the sp_attach_db stored procedure that was previously used to attach a database. The sp_attach_db stored procedure has been deprecated and will be removed in a future release. We will also need to specify the locations of the data files that are going to be attached.

T-SQL Script to Attach a Database:

USE [master]
( FILENAME = N’C:\MSSQL\DATA\DatabaseName.mdf’ ),
( FILENAME = N’C:\MSSQL\DATA\DatabaseName_log.ldf’ )

We can detach and attach databases using the GUI in SQL Server Management Studio.
To detach a database using the GUI, we can right-click on the database we want to detach, select Tasks, and then select Detach from the context menu. This will bring up the Detach Databases screen. Select OK to detach the database.
To attach a database using the GUI, we can right-click on the Databases folder and select Attach from the context menu. This will bring us to the Attach Databases screen. Selecting Add will bring up the Locate Database Files screen, which will allow us to navigate to the data file we would like to attach. Once we have selected the data file, select OK to close the Locate Database Files screen and OK once again on the Attach Databases screen to close the screen and attach the database.

Note : Above are not only the methods to migrate database\Instance, its all based on Databases Size\Client Requirement\Downtime …etc.,

There so many other Methods to migrate the Databases like we can configure High Availability(Logshipping,Mirroring,Replication,AlwaysON) ,backpac, Import and Export, SSMA tool ..etc.,

As I said it all depends on Environment and discussion having with Client.

And the Latest one which I come to know when searching for Migration on Internet is DBATOOLS , its a Awesome way to migrate the Databases or Entire Instance very quick and easy method using Powershell.