Slipstream is a new installation method in SQL Server where SQL Server RTM + Service Pack + Hotfixes can be packaged together. This feature has been introduced from SQL Server 2008 SP1.
I Just wanted to share Supporting Command Prompt Installation Scenarios please find below :
We can perform Installing, upgrading, or removing an instance and shared components of SQL Server on a local computer by using parameters and syntax specified at the command prompt.
We can also perform Installing, upgrading, or removing a FCI failover cluster instance.
We can perform SQL Server edition Upgrade from one edition to another edition of SQL Server.
Installing SQL Server instance on a local computer by using syntax and parameters mentioned in a configuration file. we can use this method to copy an installation configuration file to multiple computers for installation.
This Command Prompt Installation is very helpful on Windows Server Core Machines where we have only Command prompt Available to see after logging to Server , as the Server Core installation eliminates services and other features which are not required for the support .
Below is how we should do to SLIP STREAM SQL 2014 and higher versions
Keep it ready with SQL Server 2014 media
Keep it ready with Needed SPs, CUs and Hotfixes that you want to Include
Keep all of the .exe files in one directory
There are two types of slipstream methods. 1) Simple Slipstream
2) Advanced Slipstream
Simple Slipstream (2014): This is command based installation which requires bit knowledge on installation parameters. Below are the parameters we have to know before starting with this installation.
– /Action =Install
/UpdateEnabled= True or 1 or False or 0
/UpdateSource=MU or UNC path or .\Myupdates
Advanced Slipstream (2014)
As you guys helped by copying the SQL 2014 RTM Media and SP3 + KB on Server . I have created a New Folder called UPDATES inside SQL 2014 Media and copied both SP3 , KB [ here I think we need to follow Proper Naming Format for .exe files like SQLServer20XX-kbxxxxxx-Architecture.exe ( Hotfix ) and SQLServer20XXSPX-KBXXXXXXX-x64-ENU.exe ( Service Pack ) ]
After performing above we need to do one more Important step is to Update DefaultSetup.ini File ( which exists in SQL 2014 Installation Media ) by providing the Location of Patches ( here we need to give Updates Folder Location )
In below Screen Shot we are Specifying the location where SQL Server setup will obtain checking in Product Updates TAB in Installation
UpdateSource = ” path of patches ” — It can be a local path or UNC shared path or if the patch folder is in Media folder it self we can give it like .\FolderName
Now Once we Start Installation by initiating setup.exe and going through next steps we can see the difference at Product Update TAB like below
By seeing this above can say that we have Embed all the 3 ( Media + SP + Hotfix ) to make SLIP STREAM Installation ..
Note : This SLIP STREAM Installation was introduced from SQL 2008 onwards but the process of doing Slip Stream in SQL 2008R2 is a bit more complicated compared with the latest releases
I had a change scheduled to perform In-place upgrade from SQL Server 2008R2 to SQL Server 2014.
SQL Server 2014 upgrade supports from following versions of SQL Server:
SQL Server 2005 SP4 or later
SQL Server 2008 SP3 or later
SQL Server 2008 R2 SP2 or later
SQL Server 2012 SP1 or later
I have downloaded SQL Server 2014 media directly from Microsoft site. Once the downloading is finished, double click the file to begin the installation.
After double clicking on SQL Server setup, the SQL Server Installation Center window will open. On the left side click Installation TAB it will show different installation options. For this change, we will click on “Upgrade from SQL Server 2005, SQL Server 2008, SQL Server 2008 R2 or SQL Server 2012”. This will itself launch the Upgrade wizard to SQL Server 2014 .
The Upgrade to SQL Server 2014 gives the steps it will follow on the left side of the wizard. Provide the product key and click “Next >”.
Review the license terms, click on “I accept the license terms”, and then click “Next >”.
The Global Rules TAB will check and let us know if there are any Rules failed to stop this Installation
Here I have SLIP STREAMED SQL 2014 Media with SP3 and HotFix So, that we can eliminate Multiple Reboots of Server and also SAVING TIME. From below ScreenShot we can observe the difference of Include SQL Server Product Updates checkbox ENABLED ( Service Pack 3 and HotFix which was added to Installation Media )
In Install Setup Files wizard the upgrade application will download, extract and install files which are needed to carry out the installation process. Click on “Next >” to continue.
Select the SQL Server instance to modify. Click on “Next >” to continue.
The next step is the feature selection. Here I have selected all of the features to be upgraded. Click on “Next >” to continue.
The Instance Configuration screen allows the installer to provide the instance ID and here we can also see other installed instances on the server. Here mine is a default instance MSSQLSERVER on SQL Server 2008R2 which will be upgraded to SQL Server 2014.
The Server Configuration screen lists the services which are getting installed, we can provide or change the service account name and the Startup Type. Click on “Next >”.
The Full-text Upgrade screen lists us the three Full-Text upgrade options (import, rebuild and reset).
The Ready to Upgrade screen shows all of the features, prerequisites to be installed or upgraded. At this point, we can still go back to make modifications or quit the process. Once all are set then click on “Upgrade” to begin the upgrade of the SQL Server 2014 components.
The upgrade progress bar shows the status of upgrade.
After completion of installation, click on “Close” to exit the Upgrade to SQL Server 2014 application.
We have to restart your computer for the changes to take place
Verify all Features which are showing as Succeeded in the Status column, then click Close.
Finally, restart your server. Once server is restarted, Connect to Instance and see the Upgraded SQL Server 2014.
DBA/Application teams regularly encounter SQL Connectivity difficulties while connecting from apps during daily operations with SQL Instances. I’ll go over a few checklist procedures for troubleshooting SQL Connectivity difficulties in this article.
When a client connects to SQL Server, it must first authenticate and then authorize itself. If the problem is due to authorization, the client will be able to establish a physical connection with SQL Server, but the problem will occur while authorizing with SQL Server, such as Login errors due to permission issues, and so on. If the problem is caused by a lack of authorization, the SQL Server Error log should be the first place to go for answers.
Isolating which component is causing the problem is a critical step in resolving SQL Connectivity issues: We can categorize connectivity concerns into the following categories:
A problem with the network A problem with SQL Server’s settings. A problem with the firewall An issue with the client’s driver A problem with the application’s settings. Issues with authentication and logon.
The following are some of the most common error messages generated by the programme when connecting to SQL Server:
Error 4: Error is Similar to this not exactly the same error
[Microsoft] [SQL Native Client 10.0] TCP Provider: The remote server forcibly closes the existing connection.
1.Gather information about the servers participating in the connection.
What is the total number of servers involved? Is this a web-based or thick-client application? Is the client establishing a connection to the application server, which then establishes a connection to SQL Server? Is the connectivity problem limited to one client box, or are several clients unable to connect? Make a list of all the servers’ names and IP addresses.
2. Check to see if SQL Server is accessible. A simple test is to use network ping to see if the server can be reached.
Ping <SQLServername> or Ping <IP address of SQL Server>If Ping fails to discover the SQL Server box, it means the client is unable to locate the SQL Server machine, and we will need the help of the Network team to debug this further.
3.Check to see if SQL Server is accessible. A simple test is to use network ping to see if the server can be reached.
4.Shared memory protocol is used for local networking on SQL Server boxes. The next step is to verify SQL Server’s protocols and make sure that TCP/IP and Named Pipes are enabled for remote connections:
5. To see if the client can connect to the SQL Server port, type: To see if the SQL Server port is accepting inbound connections, we can use the telnet programme.
For example: For instance, if the SQL Server’s host name is SQLprod and the port on which SQL is listening is 1433 telnet sqlprod 1433, and the client box is unable to contact the port on which SQL is listening, we will receive the following error:
If you see Filtered in the output, that means the port is blocked. For example, if the SQL hostname is aoindia and SQL Port is 1433:
The next step is to check with the Windows/networking team to see if the port can be opened. At the operating system level, ensure that inbound and outbound rules are created to allow the connection for SQL port.
7. Run the PortqueryUI software again after the port has been allowed, and make sure the status is LISTENING.
The Telnet tool can only be used to see if a TCP port is blocked. However, the PortQueryUI application can be used to check if a port is banned for both TCP and UDP.
8. Gather the application’s connection string information. If the application is web-based, the connection string information is usually found in the web.config file. Collect the following information: a. Data Source b. Initial Catalog c. Integrated Security d. Provider a. Data Source b. Initial Catalog c. Integrated Security d. Provider For example: Provider=SQLNCLI10; Server=myServerName\theInstanceName;Database=myDataBase; Trusted_Connection=yes; Few important details to be studied from connection string are: Type of authentication used (Windows/SQL), provider used (OLE DB or ODBC), Data Source field.
A simple test to see if the problem is caused by the application is to connect to the SQL instance from the client box using SQL management studio. However, the SSMS tool may not be installed on the client PCs in the majority of cases. We can construct a universal data link tool (UDL) to assess connectivity in this situation. Create a text document on the client system with the extension.udl and rename it. For example: test.udl Select the appropriate provider list in the udl file based on the application’s provider (Microsoft OLE DB for SQL Server) or SQL native Client provider and click next.
Click on test connection after entering the SQL Server name and default database:
If the connection is established via udl, it means that the application’s connection string configuration is incorrect.
Simulate the connectivity issue with the same settings as the connection string and see if you can duplicate the problem. Check with the application team to see if the connection string can be replaced with the one provided by UDL if the connectivity works from UDL. [To acquire the dynamically produced connection string, open the udl file in notepad.]
10. If the problem is caused by the client provider, see if a different provider can be used to connect to SQL. Select several SQL providers from the udl file and verify whether or not connectivity works. For example, If the problem is only with Microsoft OLE DB for SQL Server, see if the SQL native client can help.
11. If the data source name (commonly known as DSN) is used in the application connection string, create a user DSN with the ODBC Data Source Administrator tool (odbcad32) and test connectivity.
To launch ODBC administrator tool in 32-bit mode: C:\Windows\SysWOW64\odbcad32.exe
12. On the client PC, go to the registry location below and look for Last SQL Server connect HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client
Clear the entries for the SQL Server in question specified for lastConnect and delete them. [Before making any changes, make sure you have a registry backup.]
13. Use the SQL Server Client network utility to see if there are any client-side aliases:
To launch the tool:
Examine the alias tab for any orphaned alias entries. If there are any aliases established for the SQL Server instance we’re troubleshooting, make a backup of them and delete the entries.
To run the SQL Client Configuration Tool in 32-bit mode, follow these steps.: C:\Windows\SysWOW64\cliconfg.exe
14. Check to see if you can test connectivity using protocols like TCP and Named Pipes.
If the connectivity works after forcing the protocol, ask the application team if the connection string can be changed to force the protocol in the data source field.
To see if the SQL connection is using TCP/named pipes, do the following: run the following query:
select session_id, net_transport from sys.dm_exec_connections
Check if a client side alias can be formed if no changes to the connection string can be made and the connectivity works by imposing a protocol. Example: Create a named pipe alias using SQL Server client network utility if the connectivity only works with Named pipes protocol.
15. By forcing the SQL port, you can see if you can connect to the instance. For example:
If you can connect while forcing the port number, there’s a problem with SQL Browser. SQL Browser is in charge of matching the instance name to the SQL Server port. Then, to troubleshoot browser difficulties, verify if SQL UDP browser port 1434 is banned or not.
16. Check for connectivity by giving the SQL Server’s IP address rather than the hostname. For example:
If the instance hosting SQL has an IP address of 10.16.17.18 and SQL listens on port 5223, then:
Create a host file entry with the Server name and the IP address mapping to prevent DNS name resolution and involve the DNS team for name resolution issues if the connectivity works by hardcoding the IP address in the Server name.
17. If the connectivity problem persists after doing the aforementioned methods, the next step is to collect network traces using the Network Monitor programme.
I hope the techniques outlined above may assist you in resolving SQL Connectivity difficulties.
An way to isolating SQL high CPU concerns is summarised in the screenshot below:
Microsoft recommends the following CHECKLIST POINTS:
1. Check the overall CPU usage via the Windows task manager. Gather information on the number of logical processors on the box.
2. Check the SQL Server process CPU consumption in Task Manager. Is the SQL CPU always at or above 70%?
3. Collect the following information:
How do you usually realise your CPU is a bottleneck?
What is the problem’s impact? Are there any specific errors that your user application encounters?
When did the issue initially appear? Is there anything that changed around this period that you’re aware of? (Has your workload increased? Changes to the table’s dimensions? Is it time to update your app? (Is there a SQL upgrade?)
Is it possible to establish new connections to the server during the outage?
How long did the issue persist? Have you been able to come up with anything that appears to be helpful in resolving the issue?
During the issue periods, what system-level symptoms did you notice? Is the server console, for example, slow or unresponsive during the problematic periods? Is there an increase in overall CPU usage? If that’s the case, what percentage of CPU is used during the problem? What percentage of the CPU is expected to be used?
4. f a process other than SQL Server (sqlservr.exe) is producing the high CPU, contact the team in charge of that process.
5. Open Perfmon and add the counters listed below:
% Privileged Time
% Processor Time
% User Time
% Privileged Time
% Processor Time
% User Time
6. Engage the Windows team if Processor Privileged time exceeds 25%.
Processor Time = Privileged Time + User Time.
7. Verify that SQL is using a lot of CPU on the box by looking at the counters below:
Process (sqlservr): % Privileged Time
% Processor Time
% User Time
The CPU consumption by SQL Process is calculated by dividing the observed value by the number of logical processors.
If (Process (sqlservr) % Privileged time/No of Procs) is greater than 30%, make sure that KB 976700 for Windows 2008 R2 is installed.
This phase determines whether SQL Server is the source of the server’s high privilege time. Engage the Windows team if SQL privilege time is high, as determined by the calculations above.
8. Check the following sp_configure configurations for compliance with best practice recommendations:
For Max DOP recommended settings, see KB 2806535.
9. If you can’t connect to the SQL instance locally using SSMS, try connecting via Dedicated Admin Connection (DAC) with the following commands:
10. Using the following query, get the top 10 queries that use a lot of CPU:
r.blocking_session_id 'Blk by',
r.wait_time / (1000 * 60) 'Wait M',
r.total_elapsed_time / (1000 * 60) 'Elaps M',
Substring(st.TEXT,(r.statement_start_offset / 2) + 1,
END - r.statement_start_offset) / 2) + 1) AS statement_text,
Coalesce(Quotename(Db_name(st.dbid)) + N'.' + Quotename(Object_schema_name(st.objectid, st.dbid)) + N'.' +
Quotename(Object_name(st.objectid, st.dbid)), '') AS command_text,
FROM sys.dm_exec_sessions AS s
JOIN sys.dm_exec_requests AS r
ON r.session_id = s.session_id
CROSS APPLY sys.Dm_exec_sql_text(r.sql_handle) AS st
WHERE r.session_id != @@SPID
ORDER BY r.cpu_time desc
11. Examine the wait type of the queries in the report above. If the CPU is the bottleneck, most sessions will experience the following delays:
If most queries are waiting on CXPACKET, examine the “Max degree of parallelism” and “Cost degree of parallelism” settings in sp configure to see if they are set according to best practice recommendations.
12. To retrieve a list of the top CPU queries, run the SQL Standard report:
Right Click on the instance, go to reports> Standard reports
In the report, look at the top CPU demands. Compare the report to the list of the top CPU-intensive requests acquired in the previous phase.
13. Once the top CPU queries have been discovered, use the statement_text and command_text column output from step 10 to generate a list of all SQL tables involved.
Examine the following:
Examine the top CPU-driven tables for Index Fragmentation.
when was the last time the statistics were updated?
Rebuild the index if the fragmentation is greater than 30%. Update the statistics on the table if they haven’t been updated.
If there are only a few tables responsible for high CPU in the Top CPU queries, share the tables list with the application team, as well as the statistics and fragmentation reports.
Check if there are any select queries that are consuming a lot of CPU, and ask the application team if these may be temporarily stopped on high-performance OLTP servers.
14. If SQL is still using a lot of CPU after the database maintenance activity (such Index rebuild and Stats update), run the query specified in Step 10.
Examine the Top CPU query to see whether it has changed. If the query has changed, go to Step 13 and take the appropriate action. Continue to the following step if the query remains the same.
15. Using the following methods, gather the expected execution plans for the top CPU-intensive queries:
Query 1: From the output of the query mentioned in step 10, get the top CPU using session IDs.
Take note of the Plan handle and SQL handle from the following query:
select sql_handle,plan_handle from sys.dm_exec_requests where session_id=<session_id>
Obtain the query’s text:
–Replace the SQL Handle with the result of the query above.
select * from sys.dm_exec_sql_text (sql_handle)
Get the query’s estimated execution plan:
–Replace the Plan handle with the result of the query above.
select * from sys.dm_exec_query_plan (plan_handle)
Query 2: The query below records the inquiry’s total CPU time as well as the plan handle. The query’s plan handle is required to obtain the query’s expected execution time.
(select top 50
order by qs.total_worker_time desc) as highest_cpu_queries
cross apply sys.dm_exec_sql_text(plan_handle) as q
order by highest_cpu_queries.total_worker_time desc
16. With the application team, provide the estimated execution plan.
Look for a Operator that has a high cost.
Check the operator’s indexes and the predicted amount of rows.
Check the statistics and indexes on the table for the operator with the highest cost to ensure there are no stale statistics.
Check to see if the expected execution plan suggests creating a new index. Share the missing index details with the Application team if the plan provides an index recommendation.
17. The “Convert Implicit” function in the execution plan can also cause SQL Server to use a lot of CPU.
Examine the execution plans for queries that use a lot of CPU, as well as the Operator with a High Cost, to see if the Convert Implicit function is used..
The CONVERT IMPLICIT function implicitly converts the column “NationalIDNumber” to integer in the preceding snapshot, despite the fact that it is defined as nvarchar in the table definition (15). So, share the report with the application team and double-check that the data type provided and the data type kept in the database are the same.
18. Run the missing index query on the database that has a high CPU use report to see whether any missing indexes are recommended. Inform the Application team about the Index suggestion report.
19. Use the Database Engine Tuning Adviser to tune the top CPU-intensive queries to check if the database engine advises index creation or statistics creation.
On the Replication Backward Compatibility, the supported version for Transactional replication and the rules for the supported versions are rather straightforward and clearly described.
The Transactional Replication Rules are as follows:
–> Any version that is more than or equal to the Publisher version can be a Distributor (in many circumstances, the Distributor and Publisher are the same instance).
–> A Publisher can be any version that is less than or equal to that of the Distributor.
–> The type of publication determines the subscriber version:
>> The Subscriber of a transactional publication might be any of the two variants of the Publisher. A SQL Server 2012 (11.x) Publisher, for example, can have subscribers from SQL Server 2014 (12.x) and SQL Server 2016 (13.x), while a SQL Server 2016 (13.x) Publisher can have subscribers from SQL Server 2014 (12.x) and SQL Server 2012 (11.x).
>> All versions equal to or lower than the Publisher version that are supported according to the versions life cycle support cycle can be Subscribers to a merging publishing..
We can also put it another way, which is simple and brief.
When it comes to our environment, the client wants to set up high availability between SQL 2012 with Read/Write operations and SQL 2016 with Read operations.
Initially, we considered configuring AlwaysOn, but due to licencing concerns with the version that the client owned, this was not a viable option. Furthermore, because the data was required in near-real-time, we were unable to use typical backup/restore or log shipping methods ( As the Readonly mode is not supported because of two mixed Versions ).
We chose to go with Replication after much deliberation. As a result, the setup will be as follows:
As a Publisher, our client was using SQL Server 2012. We can utilise SQL Server 2012, 2014, 2016, 2017, or 2019 as a Distributor, and SQL Server 2008/R2, 2012, 2014, or 2016 as a Subscriber.
To learn more about Matrix over Replication, visit the blog.