SQL Server Consolidation Frequently Asked Questions and Answers

The goals of the SQL Server Consolidation project are:
– Minimize licensing cost by consolidating servers.
– Reduce operational and maintenance costs.
– Modernize SQL Server version.
First step of the consolidation is to collect data(current situation), with regards to the applications that are dependent on SQL Server databases and the latest version which they support and process and effort of migrating applications to use new SQL Server on different system. To get this information, will need to involve application team or vendors, asking them right questions.

Some of the high level and common questions asked related to SQL Server Consolidation include:
– What is the latest SQL Server version this application supported by application or Vendor? like SQL Server 2008 R2, 2012, 2014, 2016.
– Is the application using any specific feature that is dependent of the Edition? Like transparent data encryption or online reindexing?, etc
– If possible, what are the recommended hardware values for this application? for CPU, Memory and disk IOPS?
– If we migrate to a newer version of SQL Server, do we also need a change in the application? like a service pack or update?
– If we migrate the database to a newer version, are there any backward compatibility requirement? Examples could be older SSIS packages, old syntax requiring us to run in an old compatibility mode.
– If we decide to place the database in a high available environment using Always ON, is there any specific requirement from the application side?
– Is there any specific recommendation or pointer for running the application in a virtual environment?
– Is this application using external code in the database in the form of CLR?
– Are there any specific database properties that we need to know of? Examples could be cross database chaining, read committed snapshots, etc.

Any considerations for or additional data needed before moving with consolidation?
– Performance baseline of the existing servers and application response times. This can be achieved by running performance monitor counters for a week or so and prepare some graphs showing the current resource usage.
– Although it is always preferred to go with latest SQL Server version, but due to application requirements, it is not possible in which case, we can go with multiple SQL Server instances installed side by side and each running different version. It is important to keep in mind that this will cause additional complexity to the consolidation as we need to keep in mind some challenges related to having a common collation suited for the databases, performance of one instance can impact other instances on the server, having different versions will need separate license for each version, shared components failing from time to time, OS patching or other tools updated on the server can impact other instances or applications, etc.

Can all older databases be consolidated?
Technically yes, but depends on migrating to which version of SQL Server to which version, but we can use stage servers to migrate first and then to final version. Important thing is to check with the application team or vendors regarding the support to the SQL Server version and edition. From operations side, we can run upgrade advisor or upgrade assistent to get analysis of the current database and see which objects will be impacted due to migration. It is always advised to run tests in a UAT environment just to make sure the application is working as expected.

Is is suggested to implement high availability? Is it feasible or beneficial without causing too much additional admin or support overhead?
Having High Availability like AlwaysON Availability groups or other technologies is always a good practice, and this will also depend on the SLA. We could create set of databases, the ones that need HA and the ones that don’t High availability and may be we can consider have 2 servers, 1 standalone with Standard Edition and 1 cluster with Enterprise edition. The SLA will determine how much time you have to recover incase of an error. Having HA allows you to recover in minutes, not having it might force you to recover in hours and doing manual work, it would be good to align the strategy with the business need. There are small applications that can be down for 8 hours without causing a big issue, for these you could just resort to take backups in a remote location and also to tape and then use a RAID with hot swapping, but if the application can’t be down for more than 30 minutes, then HA might be an obligation.

This is applicable on below versions of SQL Server

SQL Server 2005
SQL Server 2008 R2
SQL Server 2012
SQL Server 2014
SQL Server 2016

Hope this was helpful.

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, SQL Server Frequently asked questions, SQL Server Trainings.

 

How to View the Data Encrypted Using Always Encrypted in SQL Server 2016

SQLServerF1

Always Encrypted is a new feature introduced with SQL Server 2016. This has been introduced to secure sensitive data in a better way which can port very well with SQL Azure databases data as well. Although there have been other features available prior to SQL Server 2016 for encryption like TDE, SSL and cell level encryption, but the new Always Encrypted feature ensures critical data is not visible to anyone, either SQL Server DBAs, System Administrators, Network Administrators or hackers listening on the network between client and server. This is achieved by Always Encrypted as it encrypts the data both at rest and and also in motion. Important components of Always Encrypted feature as listed below,
Column Master Key – It is an encryption key that protects the column encryption keys. We must have at least one master key before encrypting any columns.
Column Encryption Key – It is the encryption key that actually protects our encrypted columns data.

Most important thing, which allows us to view or work with the Always Encrypted data is the Connection string.
Connection string – For a client driver to understand that column encryption is in use, the connection string must have the attribute Column Encryption Setting = enabled;
As, we must have seen different connection strings which are used to connect to SQL Server from applications and has different options depending up on the type of authentication, additional parameters in case of any database mirroring features being used. So, for Always Encrypted as well, we need to use this additional parameter in the connection string to work with the Always Encrypted data which is Column Encryption Setting = enabled;
Another useful thing with Always Encrypted is that the application code does not need to changed to access this encrypted data, once we use this parameter in the connection string.
We can find the Column Master Key and Column Encryption Key metadata under DatabaseName -> Security -> Column Master Key Definitions -> Column Encryption Keys.

At this point, this feature is not supported by all client libraries. The only provider that currently works with Always Encrypted data is the ADO.NET 4.6, so we will need to ensure that the .NET Framework 4.6 is installed on any machine that will run the client application that interfaces with Always Encrypted data.
– It is important for many developers to be able to view We can use SQL Server Management Studio (SSMS), so when connecting to SSSMS, we can go to Options which will bring additional tabs, then we need to use additional Connection Parameter where we need to specify “column encryption setting=enabled” and once we make the connection successfully to SSMS, we now will be able to view the data.
– But when we try to read the Always Encrypted data, we may receive erros, where encrypted data could not be decrypted, because on the system we are launching the SSMS may not have the certificate which can decrypt the data.
We need to get the certificate installed on the local system with both public and private keys, after which we will be able to successfully view the encrypted data.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2016

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

New Always Encrypted Feature in SQL Server 2016

SQLServerF1

It is important for every organization to protect their important customers or company’s data and ensure that no one should be able to view or update the data. There are many security mechanisms in SQL Server which will ensure only authorized users can see the data or make changes to it, like logins and database users to restrict the permissions on what they can do with the data. However, still there are many ways, where in unauthorized users still try to gain access to the data, like tapping the network between SQL Server and client system, trying to hack someone else account and gaining access, etc. So, only having security at login/database user level is not enough, so there are other mechanisms available like SSL certificates to encrypt the data that gets transmitted over the network, encryption of data at individual cell/column level or table level or at database level. Prior to SQL Server 2016, database/cell level encryption, still lets the database administrators or other users with high permissions to still gain access to the encrypted data, as the encryption keys are mostly stored in the database and are managed by the DBAs. This feature will be helpful for Microsoft to promote the SQL Azure databases more to the customers showcasing that their data will only be accessible to the clients, but no one else.

Starting with SQL Server 2016, new feature Always Encrypted has been introduced to safeguard the sensitive data from high privilege users as well as unauthorized users. Always Encrypted feature has been designed to protect sensitive data, such as credit card numbers or national identification numbers which are mostly stored in SQL Azure Database or on-premise SQL Server databases. Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to the Database Engine like SQL Database or SQL Server. Due to this, Always Encrypted provides a separation between those who own the data (who can view it) and those who manage the data (DBAs, but should have no access to sensitive data). This ensure that on-premises database administrators, cloud database operators, or other high-privileged, or unauthorized users cannot gain access to the encrypted data. This will help in for comfortable delegation of on-premises database administration tasks to third parties or to reduce security clearance requirements for the DBA staff.

Always Encrypted features mainly uses two types of keys which are, column encryption keys and column master keys.
Column master keys – are to protect the keys used to encrypt column encryption keys. It is important for the Column master keys should be stored in a trusted key store. The information about column master keys, including their location, is stored in the database in system catalog views.
Column encryption keys – are used to encrypt sensitive data stored which is stored in the database columns. All the values which are in a column can be encrypted using a single column encryption key. The encrypted values of column encryption keys are stored in the database in system catalog views. We need to store column encryption keys in a secure/trusted location for backup.

Another important component of the Always Encrypted feature which plays a key role is Always Encrypted enabled driver which ensures the transparency of encryption to client applications. This Always Encrypted enabled driver calls a server i.e., makes a roundtrip for each query with parameters to retrieve information on how to encrypt query parameter and whether they should be encrypted. This driver then calls a key store provider to decrypt the encrypted column encryption key value. The resultant plaintext column encryption key values are cached. Query results containing data from encrypted columns are accompanied by encryption metadata to enable transparent decryption. So, when an Always Encrypted enabled client driver queries encrypted columns, SQL Server sends the information about encryption settings for the queried columns, including encryption type information. The encrypted value of column encryption keys are used to protect the data in the queried columns, and also the location of the corresponding column master keys. The driver uses that information to, contact the key store containing each column master key and decrypt the column encryption keys, encrypted with the given master key. If for some reason, Always Encrypted is not enabled on the client side, the driver returns encrypted values and the values have the varbinary(max) data type.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2016

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

New Enhancements to T-SQL in SQL Server 2016

SQLServerF1

Transact-SQL is the key to interact with SQL Server, it acts as medium of communication between SQL Server and DBAs or Developers. Although SQL Server provides great GUI features to administer SQL Server, but underlying, the actions performed on GUI are translated into T-SQL queries or commands. Over a period, with many releases of SQL Server, there have been lot of changes, new additions supporting new features, enhancements to TSQL to support existing features and new commands introduced to support the requirements of Developers and DBAs. So, just like any other SQL Server release, even with SQL Server 2016, there have been some great enhancements which are worth talking or knowing about which include TRUNCATEE TABLEE with partitions, NO_PERFORMANCE_SPOOL, DROP IF EXISTS, T-SQL queries for new features like JSON and temporal tables, enhancements to FORMATMESSAGE, etc.

Truncatee Tablee – Everyone must be aware of the functioning of this command, which will remove data from entire table, although what happens internally is a different story, but from user perspective, all the data in the data will not be found anymore. Now, starting with SQL Server 2016, there has been improvement made to this command, where in now we can truncate only one partition, instead of entire table. This will be beneficial in making the maintenance easier with large partitioned tables and this operation will be faster too compared to deleting all the data from a partition.
– Another enhancement is that now ALTER TABLEE can now alter many columns, while the table remains online for which we can use WITH ONLINE = ON|OFF options.
– There has been new query hint NO_PERFORMANCE_SPOOL added, which will prevent spool operators from being added to the query plans. This is to help improve the performance when many concurrent queries are running the spool operations.

– Starting with SQL Server 2016, MAXDOP option has been added to use with DBCC CHECKTABLE, DBCC CHECKDB, and DBCC CHECKFILEGROUP, which will limit the degree of parallelism as per the requirement of the DBA in specific environments to reduce the load of integrity checks and to can avoid using resource governor for this purpose.
– There has been improvement in the FORMATMESSAGE where we can now supply our own message string. In prior versions of SQL Server, FORMATMESSAGE used to construct a message from an existing message in sys.messages, but now with this new enhancement, we can supply our own messages too, which are not part of sys.messages.
– There have been new T-SQL commands added for supporting new features like JSON, Temporal tables, session context, etc.
– Another new and useful enhancement is introduction of DROP IF EXISTS, which simplifies the checking of table using longer queries through an IF condition.
– The maximum index key size for NONCLUSTERED indexes has been increased to 1700 bytes.
– Another enhancement include, support for Advanced Analytics Extensions, which allow us to execute scripts written in a different supported language such as R. Transact-SQL starting with SQL Server 2016 now supports R by using the sp_execute_external_script stored procedure, and with the external scripts enabled Server Configuration Option.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2016

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

New SESSION_CONTEXT() Support in SQL Server 2016

SQLServerF1

There are many application which have requirement to store and retrieve session context information from SQL Server. Session context information is very useful in cases which can be used to store information specific to each user or their current state of the application. This is required in some applications to control the logic in Transact-SQL statements. Prior to SQL Server 2016, application developers used to rely mostly on CONTEXT_INFO function or sometimes on TSQL session variables, but both these have their own disadvantages like, Transact-SQL variables, scope is limited to that current Transact-SQL batch, stored procedure, trigger, or user-defined function. SQL/Application developers were using the CONTEXT_INFO function for retrieving the session context for the current session. Also, CONTEXT_INFO allows to retrieve session context values for all current sessions and batches from the context_info columns in the sys.dm_exec_requests or sys.dm_exec_sessions dynamic management views. Inorder to run queries against these views, required SELECT and VIEW SERVER STATEE permissions on the SQL Server instance, but these permissions were not required anymore when we use the CONTEXT_INFO function.

But this CONTEXT_INFO function has its own limitations too like, It is a single and a binary value, therefore is very difficult to work with because we will need to convert the data from binary to human readable format and also the involves the complexity of storing multiple values in a single binary representation, which will be difficult to use, another limitation include the size supported was only 128 bytes for the connection which was not liked my many developers, this CONTEXT_INFO also has another security concern too as it allows the users to overwrite the data at any time, and also this does not work well with SQL Azure databases. So, upon the feedback from the developer community, Microsoft has introduced new built-in function called SESSION_CONTEXT() starting with Microsoft SQL Server 2016. This is not a new innovation by Microsoft, but there are equivalents in other RDBMS like Oracle.

The way SESSION_CONTEXT function is different from CONTEXT_INFO is that the SESSION_CONTEXT uses key-value pairs to store the session data and the keys are of SYSNAMEE type where as the values are SQL_VARIANT type. Now, the size of the data that can be store has been increased/set to 256 KB, which is significantly greater than the size of data allowed with CONTEXT_INFO. Also, the security concerns has been addressed, wherein we can set the key as read only, so the value will not be able to be changed once it has been established. Also, as this has been introduced after SQL Azure was launched, Microsoft has kept the SQL Azure databases in mind and made this work similarly on both on-premise and on SQL Azure databases. We need to set the key-value pairs using the stored procedure called as sys.sp_set_session_context.
@key – is the key which is being set, and is of type sysnamee. The maximum key size allowed 128 bytes.
@value – is the value for the specified key, and it is of type sql_variantt. Setting this value of NULL will free the memory. The maximum size is 8,000 bytes.
@read_only – This allows zero or one. This is a flag of type bit. If 1 is set, then the value for the specified key cannot be changed again on this logical connection. If 0 (default), then the value can be changed.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2016

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

Changes to SQL Server 2016 Management Studio(SSMS)

With each new release of SQL Server, there are many new features that get introduced. Microsoft has put lot of effort in improving the SQL Server Management Studio as well with the new releases to support the new features that get introduced. Also, there has been lot of support improvements for Azure integration and management with SSMS. Previously there was not much, DBAs were able to make changes to Azure databases from SQL Server Management, but with the release of SSMS 2016, there has much much closer integration for managing SQL Azure instances and databases. For those who are not aware, we can download and install SQL Server Management Studio (SSMS) as separate individual download and install just SSMS on a client machine or on a server. Some of the new features support for SQL Server Management Studio(SSMS) include,

– Addition of human-readable error messages. With this, now when there is an error while performing an operation using SSMS, we get more meaningful error, which will be of great help in troubleshooting, instead of wondering or decoding on what the error is about, as like in some of the previous versions of SQL Server Management Studio.
– Stretch database wizard improvements which adds support for predicates.
– SQL Server 2016 management Studio now allows us to create ER Entity-Relationship Diagrams for SQL Azure Databases without the need for any external tool.
– Now we can see some new options when we right click on the SQL Azure database like “Open in Management Portal”, new “Reports” to view “Transaction Performance Analysis Overview”.
– New options supported when we right click on the user table like, Design(now we can design SQL Azure database tables from SSMS), option to choose selecting or edition top x rows, options for graphical interface to create and administer Full-Text indexes on SQL Azure database tables.

– Database properties now have additional properties or settings like, in the options tab, there is a section for Azure which has options which allows us to change the database edition, the Service Level Objective and the maximum database size.
– There have been many other options enabled in SQL Azure database and table properties which allows us to manage or make changes to database or tables of SQL Azure database and tables, just like regular on premise SQL Server database or table.
– Improvement in the AlwaysEncrypted Powershell commandlet to add key encryption APIs.
– Some known issues has been fixed, like to turn off IntelliSense in the SSMS toolbar, if it has been disabled in the Tools,Options dialog.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2016

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

SQL Server 2016 Can Be Installed on Linux

As a SQL Server DBA, we never would have expected that Microsoft will someday support installing and running SQL Server instance on a linux machine, but it has come true as a surprise, as Microsoft confirmed in their official website about the same. Refer here for more information. Since the inception of SQL Server, it was never supported or possible to install SQL Server on a linux Operating System. Although, some baby steps on this was started, when SQL Server was supported to run on Windows Core. Since many years Microsoft had a firm stand on not supporting its applications on different Operating System platforms, but with changing world, Microsoft had to change its view as well. There has been mixed response from the SQL Server community regarding this move.

One of the main reasons sighted by Microsoft regarding this move was taking into consideration clients who preferred to use Linux operating System, but wanted to use SQL Server. As SQL Server was not supported to run on Linux, many organizations have moved away from SQL Server as they do not want to get stuck with Microsoft suite, which benefited oracle and other open source technologies like MySQL. With this move, now SQL Server will be picked up by many organizations which are running linux or other open source applications. Although this news has been received positively across the SQL Server and other platforms community, still there are many questions about the stability and performance of SQL Server running in linux operating system. Once we have more details on this and people start installing the SQL Server on linux, we get more details about the problems that arise while installing SQL Server in linux and trouble administering the SQL Server on linux. Also, it would be interesting to see how the performance would differ, while SQL Server running on Windows and linux systems with same hardware.

This will be a benefit for the SQL Server DBAs as they will now get an opportunity or even forcefully have to learn working with linux operating system, which mostly operates through commands better. Most SQL Server DBA’s get stuck with knowing only windows operating system, which makes it difficult for them to lean other RDBMS products like Oracle or MySQL as they can run on both Windows as well as linux operating systems. Oracle/MySQL DBA’s had more feasibility to learn SQL Server, than SQL Server DBA’s leaning Oracle or MySQL, now this will change. Also, this will change the mindset of the SQL Server DBA’s to understand the importance of managing or administering SQL Server and operating system though commands, rather than GUI. There is still a long way to go, as it is expected that there are many challenges on the way for the SQL Server to work seamlessly on linux operating as it works on Windows operating System. This will bring more customer adopt SQL Server product, thus opening more DBA jobs. Also DBA’s who like challenging tasks would love this move, as it is completely new and no or very little documentation will be ever on this, which makes their job more challenging and interesting.

Stay tuned for more information.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2016

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

Comparing Installation Options Available for SQL Server on Azure VM

SQLServerF1

In the below mentioned previous post, we have discussed about different installation options available for SQL Server on Azure VM
Different Installation Options Available for SQL Server on Azure VM
It is important to understand the differences in the three option mentioned in the above post.
– Create a SysPreppedImage of the SQL Server version of our choice on an hyper-v VM on out local environment and then Upload it to Azure.
– Create a virtual machine running Windows from the Azure portal and then install SQL Server on it.
– Provision a SQL Server virtual machine in Azure from the Azure portal.

SysPreppedImage of the SQL Server on Hyper-V VM and Upload to Azure is preferred when you want to use your own licenses for Windows Operating System and SQL Server, so that you only need to pay for Azure compute and storage costs incurred for hosting your VM with SQL Server on Azure. Since SQL Server 2008 R2, has introduced of performing a SysPrep image, and the steps are simple. In this DBAs can choose and install required SQL Server versions and patches and required Operating System versions and patches instead of depending up on the versions provided by Microsoft Azure. However this is the most time consuming task of the three methods as this involves buinding hyper-v VM and preparing SQL Server SysPrep image and then uploading the VHD files to the Azure and then use it to create the VM. This is preferred when you want to use your own licenses which you are have, to avoid using Microsoft licensing available for Windows OS and SQL Server from Microsoft on per-minute usage basis.

Create a virtual machine running Windows is preferred you want to use your own license of SQL Server, but use the license of Windows Operating System provided by Microsoft, however the licensing of the Windows OS usage, compute and storage usage of Azure VM are calculated on the per-minute basis. SO, In this case, we pay only for the per-minute for the Azure Compute, Storage, and Windows license but not for the SQL Server license. In this DBAs can choose and install required SQL Server versions and patches. This involves additional work of installing SQL Server, its patches.

Provision a SQL Server virtual machine in Azure is preferred when you do not want to use any of your own licenses, instead only want to dependent or use the Microsoft licenses, but this usage is mostly calculated on per-minute basis. In this we need to pay per-minute for a SQL Server license along with an Azure Compute, Storage, and Windows license. This allows us to install SQL Server at desired version and service pack level, thus reducing the time taken for SQL Server installation along with VM setup and these things can be done from Azure portal with simple clicks and providing the options. This is best suited for applications which are required for short time for testing and later can be shutdown, thus brings down the cost.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2008 R2
SQL Server 2012
SQL Server 2014
SQL Server 2016

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 

Different Installation Options Available for SQL Server on Azure VM

SQLServerF1

Cloud solutions has been gaining increased support and many customers moving their data on to cloud technologies or planning to move in future. Once management decides on moving the SQL Server on to Azure, there are two options either to choose Infrastructure as Service (IaaS) or SQL Azure database as service (PaaS). If the management decides to have more control on the SQL Server and decides to use the Infrastructure as service option(IaaS), then next step would be is to get the SQL Server installed and running on the Microsoft Azure VM. There are different ways in which we can get SQL Server installed and running on the Azure VM which depend on factors mainly like Licensing. Depending on the type of licensing we choose for, we can have below options for getting SQL Server on the Microsoft Azure VM.

– Create a SysPreppedImage of the SQL Server version of our choice on an hyper-v VM on out local environment and then Upload it to Azure.
– Create a virtual machine running Windows from the Azure portal and then install SQL Server on it.
– Provision a SQL Server virtual machine in Azure from the Azure portal.
SysPreppedImage of the SQL Server on Hyper-V VM and Upload to Azure – In this method, we can use the SQL Server SysPrep install which creates a SQL Server image, which can be used to complete and create a full SQL Server instance on any other servers. Once the SQL Server SysPrep image has been created on a hyper-v VM, next step is to upload the VHD file of the hyper-v VM to Azure Blob storage. Now we can use the uploaded VHD file and create an image from Azure Management portal.

Create a virtual machine running Windows – In this method, we can create a windows virtual machine from the Azure portal. There is an option available on Azure portal to provision a Windows Server image. Once the Windows VM is created, next step is to copy SQL Server installation media on to the newly created VM and install the SQL Server on our own.

Provision a SQL Server virtual machine in Azure – In this method, we can install SQL Server directly on a windows VM from Azure portal. This method is an easy way to get SQL Server installed on the new windows Azure VM on Microsoft Azure.

All the three methods mentioned above have their own advantages and disadvantages interms of licensing, cost, etc. Depending on the requirement, DBAs and management can choose the appropriate method best suited for their environment.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2008 R2
SQL Server 2012
SQL Server 2014
SQL Server 2016

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings

 
1 2 3 558