Steps to Move SQL Server Agent Jobs Between SQL Server Instances

SQLServerF1

When migrating SQL Server databases or instance from one server to another server or while upgrading from lower version of SQL Server to higher SQL Server version, there are many tasks to move various objects from source SQL Server instance to destination SQL Server instance which include Logins, Server Roles, Linked Servers, Credentials, Jobs, Operators, etc. All these objects can be created before-hand before the go-live so that the amount of work can be reduced during the downtime window. These objects does not change often, so they are better created while preparing the server for testing itself. Below are some of the important steps to move jobs, alerts and operators from one SQL Server instance to another SQL Server instance. Also there are additional steps to take care once these objects are moved to the target server.

Steps to Move SQL Server Jobs, Alerts and Operators
– Open the SQL Server Management Studio, and then expand the Management folder.
– Expand SQL Server Agent, and then either right-click Alerts, Jobs, or Operators.
– Click All Tasks, and then click Generate SQL Script.
– Run the generated file against the destination SQL server instance.

Additional Tasks to Perform before Running the Generated Script
– Jobs created by the generated script may have old login as owner which is not present on the new SQL Server instance or can be left blank is based on logins, so logins must be moved before running the Jobs creation script.
– If any of the jobs names contain old instance name, then they must be replaced by the new instance name.
– If any of the jobs code contains old instance name, then they should be replaced by the new instance name.
– If any of the code inside jobs is dependent on a linked server or backup devices, then Linked servers and backup devices should be moved before creating jobs.
– Maintenance plans jobs must not be scripted because maintenance plans will be recreated from scratch on the new SQL server instance.
– Replication jobs should not be created because it is better to recreate the replication manually which will create the jobs as there could be considerable changes in replication from one SQL server version to another SQL server version.
– Alerts should be verified and any references to old server names or objects not present on new server should be changed accordingly.
– Operators should be verified and made sure all required dependent objects are already present on the new server, if not then they need to be first created. Any references to old server name or objects not present on new server should be removed.

This is applicable on below versions of SQL Server

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

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.

 

Migrating SQL Server Linked Servers from One Server to Another

SQLServerF1

In many environments it is common to notice Linked Servers in various SQL Server instances. These are server level objects comes under security objects. DBAs are responsible for creating linked servers between SQL Server instances or to other 3rd party products such as Oracl, MySQL, DB2, etc. In situations when SQL Server instance is migrated from one server to another server due to hardware upgrade or when upgrading or migrating lower SQL Server version to higher SQL Server versions, all dependent objects also are required to be migrated which include Logins, Jobs, Linked Server as well. If there are one or two linked servers, DBAs can check the configuration of the linked server and create them on the new server, but in cases where the number of linked servers or configuration is different, it is better to find an automated way of moving the linked servers.

Linked server can be used in scheduled jobs, DTS packages, stored procedures or views. If linked servers aren’t created on the destination machine, any component or other user objects depending on them will fail. Below script can be used to script out the linked servers on source or existing of old server and then create them on the destination or target or new server using the generated script. Important thing to keep in mind is that this will not automatically copy over any remote security connections, so you would have to apply the appropriate logins manually. This can be found under the security tab of the linked server properties.

set nocount on
select ‘exec master..sp_addlinkedserver
@server = ”’ + srvname + ”’,
@srvproduct =”’ + srvproduct + ”’,
@provider =”’ + providername + ”’, @datasrc = ”’ +
datasource + ”” from master..sysservers
Where srvname <> @@servername

What are Linked Servers in SQL Server?
Linked servers allows the SQL Server Database Engine to execute commands against OLE DB data sources outside of the instance of SQL Server or remote SQL Server instances. Typically linked servers are configured to enable the Database Engine to execute a Transact-SQL(TSQL) statement that includes tables in another instance of SQL Server, or another database product such as Oracle. Many types of OLE DB data sources can be configured as linked servers such as Microsoft Access, Sybase, MySQL, Excel, etc. Linked servers offer advantages such as provides the ability to access data from outside of SQL Server, provides the ability to issue distributed queries, updates, commands, and transactions on heterogeneous data sources across the enterprise, provides the ability to address diverse data sources similarly.

This is applicable on below versions of SQL Server

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

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.

 

Steps to Uninstall SQL Server Failover Clustered Instance

SQLServerF1

Due to various reasons DBAs may need to uninstall SQL Server instances. The reasons could be due to retiring the old server after migrating to a new server, the installation got corrupted due to various problems, after failure of installation, etc. Starting with SQL Server 008, the way to uninstall SQL Server clustered instance has changed, where the uninstallation has to be performed of each node of the cluster which SQL Server instance is part of. Sometimes there can be requirement to remove only one node in which case the uninstall has to be performed on only that particular node. Below are some of the important steps to be followed to uninstall SQL Server clustered instance.

Steps to Un-Install SQL Server Clustered Instance
Browse to the SQL Server installation media folder and from the root setup media folder, double-click setup.exe by choosing Run-as-Administrator. If the media if present on network share or DVD disk, then copy the media to local drive.
Launch the SQL Server Installation Wizard which will bring the SQL Server Installation Center. To remove a node to an existing failover cluster instance, click Maintenance in the left-hand pane, and then choose “Remove node from a SQL Server failover cluster”.
The System Configuration Checker will run a discovery operation on the server. click OK.
After that Setup Support Files gets installed and then the System Configuration Checker verifies the system state of the system before Setup can continue further. After the check is complete successfully with all green, click Next to continue.
On the Cluster Node Configuration page, use the drop-down box to choose the name of the SQL Server failover cluster instance to be modified during this Setup operation. The node to be removed is listed in the Name of this node field.

The Ready to Remove Node page displays a tree view of options that were specified during Setup. To continue, click Remove.
Monitor the remove operation for successful completion. In case of any errors, review the setup logs and take appropriate action and then start from the first step of the uninstall process again.
Once the remove node operation completes, verify from control panel and SQL Server Configuration Manager to make sure the instance has been removed.
Reboot the node
Perform the same operations on other nodes from where the SQL Server instance has to be uninstalled or removed.
Delete any folders or files related to previous SQL Server instance, if not required any more.
Reinstall the failover instance if required and apply Service Pack/Cumulative Update if applicable.

SQL Server 2005 or before, uninstall has to be initiated from the control panel on active node and go through the uninstall wizard and choose the node which was to be removed. Other shared components are to be removed on both the nodes from control panel.

This is applicable on below versions of SQL Server

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

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.

 

Important Steps to Repair SQL Server Failover Clustered Instance

SQLServerF1

Installation Repair option was provided starting with SQL Server 2008 which is helpful in many cases during installation failure. Instead of uninstalling and reinstalling multiple times, repair option allows to fix any installation problems thus avoiding lot of duplicate work. Also the repair option comes handy during installation of service packs or CUs where repair can be used to fix any major problems left after main SQL Server install. SQL Server 2005 also had repair option which can be invoked from control panel, but it was very limited and often not very helpful. Below are some important steps which can be followed to perform repair of SQL Server Failover Clustered Instance.

Steps to Repair SQL Server failover Cluster instance
– Starting with SQL Server 2008, cluster installation has changed where installation setup has to be run on all the nodes which will be part of SQL Server Failover cluster instance. So, even Repair must be run on each individual cluster nodes that is affected or damaged.
– Launch the SQL Server Setup program from SQL Server installation media by choosing Run-as-Administrator.
– Initially there there are few setup rule check performed and then the Setup will show the SQL Server Installation Center page. SQL Server Installation Center was introduced starting SQL Server 2008 which has many options related SQL Server setup.
– Click on the “Maintenance” option in the left-hand side, and then click on “Repair” option which will start the repair operation.
– Setup will run some Setup support rules and some file routines are run to ensure that the system has all the prerequisites installed and that the computer passes Setup validation rules. Click OK or Install to continue.

– On the Select Instance page, choose the SQL Server instance which has to be repaired, and then click Next to continue.
– The repair rules will be run to validate if repair can proceed further or not. To continue, click Next.
– Ready to Repair page appears which indicates that the repair operation is ready to proceed. so click on “Repair”.
– The Repair Progress page shows the status of the repair operation. Monitor for successful completion of the repair operation.
– Repeat the same operations on the other nodes as well.
– Connect to SQL Server instance from SQL Server Management Studio and verify you are able to  connect.
– Verify SQL Server Errorlogs and Event Viewer Application and System logs to make sure there are no errors.
– Check the setup summary log file to make sure there are no errors reported during repair operation for any component which has been repaired.
– If the repair fails, then the only option that will be left with is to reinstall the SQL Server failover instance.

This is applicable on below versions of SQL Server

SQL Server 2008 R2
SQL Server 2012
SQL Server 2014

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.

 

Uninstalling SQL Server Service Pack for Clustered Instance

SQLServerF1

One of the important responsibility of the SQL Server Database Administrators(DBAs) is to plan and install SQL Server and its patches like Service Packs, Cumulative Updates, Hotfixes, etc. Although how much ever planning and testing was done prior to installation of the SQL Server patches, some times there could be unexpected issues or problems which will affect the applications or certain functionality and there comes a need to rollback the installation changes or to revert back to the before state. Older versions of SQL Server did not had much flexibility in rolling back the service pack changes by uninstallation, but the latest versions of SQL Server provides feature to uninstall SQL Server patches which may be service packs, CUs or Hotfixes. Below are some of the important steps to follow to uninstall SQL Server service packs or other patches starting with SQL Server 2008 R2.

Steps to Uninstall SQL Server Patches on Clustered instance. This is also applicable for standalone instances.
– On Passive node, open Programs and Features” options in Control Panel and click on “View installed updates”
– Highlight the SQL Server 20xx Service Pack x or related patches and click “Uninstall”
– Uninstall Service Pack wizard will start.
– Click “Next” which will run update rules then select the features for which you need to remove the Service Pack and click “Next”

– Go through the wizard and then verify the Summary and click “Remove”
– Monitor for the uninstallation to finish successfully.
– Reboot the node
– Failover SQL Server instance on to the node where the patch has been uninstalled.
– Test the application to make sure it works fine.
– Remove the patches from other passive nodes as well and reboot the nodes.

For older versions of SQL Server 2005 or before, you cannot uninstall using the above method. If the server is a VM, then you may restore the snapshot of VM before the patch install, but this needs to be tested before hand. The only supported and reliable method of rolling back SQL Server patches on SQL Server 2005 or prior is to follow the below steps

– Backup all the system and user databases. Make note of instance level configuration settings, jobs, logins, etc.
– Detach all user databases and copy to another location.
– Uninstall SQL Server 2005 instance
– Reboot the server
– Install new SQL Server 2005 instance with same name
– Apply the service pack or CU to same level to the same when the SQL Server instance was working fine.
– Restore Master and MSDB databases and restore Model database as well if required.
– Restore all user databases or attach the user databases using mdf and ldf files which were copied to another location before.
– Verify logins, jobs, instance level configuration, etc.
– Test the application to make sure everything works fine.

 

This is applicable on below versions of SQL Server

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

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.

 

Installation of SQL Server Patches on Clustered Instance

SQLServerF1

It is very important to regularly apply patches to the SQL Server instance using latest service packs or Cumulative Updates which contains important fixes specific to the SQL Server instances and applications. There needs good planning before applying the service pack or cumulative update to a SQL Server instance and also a series of steps need to be followed for applying the patches. Missing any of the steps may sometimes result in serious problems. Most often or not the installation of the patches completes successfully without any problems, but when it fails we should be in a position to be able to roll back the changes. In this article we will see the steps that are required to be followed before applying a service pack or Cumulative update or a hotfix to a particular SQL Server Cluster instance. Below are some of the important steps which are to be performed while applying service pack or cumulative update or hotfix for critical SQL Server instance on clustered instance. This is more often or not applicable to the standalone SQL Server instances as well. Also we will look into steps to verify or validate that the patches are installed properly and SQL instance is working fine after the patch installation.

Steps to Install patches to SQL Server Clustered Instance
– Copy the Service Pack or Cumulative Update or Hotfix to all the cluster nodes to which SQL Server can failover to.
– Run the patch by choosing Run-as-Administrator option on passive node. If there are multiple passive nodes, then start by running on one of the passive node.
– Follow the patch install wizard and start the installations and monitor for its successful completion.
– Reboot the node where the patch has been successfully applied.
– Stop all the applications from connecting to the SQL Server instance.
– Failover the SQL Server instance on to the node which has been patched.
– Test the applications to make sure there are no issues.
– Run the patch by choosing Run-as-Administrator option on the new passive node. Repeat the same on each remaining passive nodes.
– Reboot the nodes after patch has been applied on each node.
– Test the application.

Steps to Verify or Validate the installation of Service Pack or CU or hotfix for SQL Server
– Open cluster manager and verify that all the SQL Server and SQL Agent cluster resources, Disk resources, Network Name and IP address resources are online.
– Connect to SQL Server instance from SQL Server Management Studio and check the version and build number to ensure that the latest patch version is reflected.
– Check SQL Server error log to make sure there are no errors in errorlog.
– Check Event Viewer on all cluster nodes to make sure there are no errors after patch installation.
– Check the SQL Server patch installation log file to make sure there are no errors reported.
– Test the applications throughly.

This is applicable on below versions of SQL Server

SQL Server 2008 R2
SQL Server 2012
SQL Server 2014

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.

 

Important Prerequisites Before Installing Service Pack to SQL Server Instance

SQLServerF1

It is very important for regularly update the SQL Server instance using latest service packs or Cumulative Updates with important fixes specific to the SQL Server instance and application. There needs some planning before applying the service pack or cumulative update to a SQL Server instance and also a series of steps need to be followed for applying the patches. Missing any of the steps may sometimes result in serious problems. Most often or not the installation of the patches completes successfully without any problems, but when it fails we should be in a position to be able to roll back the changes. In this article we will see about some important pre-requisite steps that needs to be followed before applying a service pack or Cumulative update or a hotfix to a particular SQL Server instance. Below are some of the important prerequisite tasks which are to be taken care before installing service pack or cumulative update or hotfix for critical SQL Server instance on standalone or clustered instance.

– Patches which may be Service Pack or Cumulative Update or Hotfix are first need to be applied on test SQL Server instance and then application needs to be tested to make sure it works fine without any problems.
– Run DBCC CheckDB on all the system and user databases and make sure there is no corruption on any of the databases.
– Backup all System and User database before applying the patches. The timing of the backups are important as all the backups(FULL, DIFF, LOG) should be stored and available for few days. Also, before hand it would be great to know how much time does it take to restore the databases in case of any problems. This can be tested on a test server to get a rough idea.

 

– Also backup Analysis Service databases and important configuration files. Backup Reporting Services encryption keys and important configuration files.
– Ensure there is sufficient free space in all the drives including C:\ drive on both the nodes.
– Download and keep the Service Pack or Cumulative Update or Hotfix file on all nodes of cluster and extract the contents of the file to a folder. Double check that the downloaded patch version, build, platform(x86, x64) etc.
– Make sure you have a valid domain account which has local administrator permission on all the cluster nodes.
– Coordinate with all teams(Application team, SysAdmin team, Network Team) Before starting the installation, so that application can be stopped before starting the patch installation and reboot of the servers can be performed by the System Administrator.
– Communicate to all stake holders about the estimated downtime and reboot of the servers which may cause restart of other services installed on that servers too.

This is applicable on below versions of SQL Server

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

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.

 

Basics of SQL Server Upgrade Advisor and its Usage

SQLServerF1

One of the first and important steps to perform before performing upgrade or migration of SQL Server instance from lower version to a higher version is to run the Upgrade Advisor which generates a detailed report with objects and list of issues that could arise after upgrading to the higher version of SQL Server instance. Once we know the objects and the issues we can take corrective actions before or after the upgrade is complete which will keep the new upgraded SQL Server instance stable and consistent.

What is SQL server upgrade advisor? 
SQL Server Upgrade Advisor analyzes the legacy instances and produces reports detailing upgrade issues by SQL Server component. The resulting reports will show the detected issues or problems and also provide some guidance on how to fix the reported issues or some work around for the reported issues. These reports can be reviewed by using Upgrade Advisor or can be exported for further analysis, for example to Excel document. In addition to analyzing data and database objects, Upgrade Advisor can also analyze Transact-SQL scripts and SQL Server Profiler or SQL Trace files. Upgrade Advisor can be run from either a local server or from a remote server. Report generation and analysis is CPU intensive, so it is better to always try to run it remotely when working with production database servers.
SQL Server upgrade can analyze Database Services, Analysis Services,  Integration Services, Reporting Services, DTS packages. Report will also contain deprecated items that won’t run on the higher version of SQL server and which MUST be fixed.

Advisor can be freely downloaded from Microsoft site and we should download the upgrade advisor version to which you want to upgrade to. Example, if you have SQL Server 2005 instance installed and want to upgrade to SQL Server 2008 R2 instance, then you must download SQL Server 2008 R2 upgrade advisor.

This is how upgrade advisor looks like and some options to choose and the final report generated.

Upgrade Advisor Initial Screen

Upgrade Advisor Initial Screen

Components to be Analyzed

Components to be Analyzed

Upgrade Advisor Report

Upgrade Advisor Report

 

This is applicable on below versions of SQL Server

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

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.

 

Steps for Side-By-Side Migrate or Upgrade plan for SQL Server 2014

SQLServerF1

SQL Server legacy versions are no more fully supported by Microsoft. Most of the organizations have already migrated to the latest versions of SQL Server long back, however there are few servers or applications which still use older versions of SQL Server like SQL Server 2000 SQL Server 2005 due to compatibility issues with latest versions of SQL Server versions. There may be lot of cost involved to upgrade legacy applications to work with latest versions of SQL Server, but it is high time to either move to another application or upgrade the application to work with latest SQL Server versions. There are two different methods available to migrate or upgrade an SQL Server instance to SQL Server 2014, which are In-Place Upgrade and Side-by-Side upgrade. It is always better to prefer Side-by-Side upgrade which is more safe method and also we can move to new hardware instead of using the old hardware to run the new SQL Server instances. Below are the important steps to keep in mind while upgrading from SQL Server 2005 or SQL Server 2008 R2 or SQL Server 2012 to SQL Server 2014 instance using side-by-side method.

– As a first step it is important to understand which objects would be affected after upgrading to SQL Server 2014. We can get this information by running the SQL Server 2014 Upgrade Advisor against the SQL Server 2005 or SQL Server 2008 R2 or SQL Server 2012 instance which will generate an report with list of any warnings or issues.
– As part of the up-gradation process, stop all write activity to the SQL Server 2005 or 2008 R2 or 2012 instance. This may involve disconnecting all users or forcing applications to read-only activity.
– Transfer data from the legacy instance to the SQL Server 2014 instance. This can be done by backup/restore of databases from SQL Server 2005 or SQL Server 2008 R2 or SQL Server 2012 to SQL Server 2014. To reduce the amount of downtime, one can look into options like Log Shipping or Database Mirroring or AlwaysON Availability Groups.
– Create supporting objects in system databases like SQL Server Agent jobs, security settings(Logins, Server role permissions), Instance level configuration settings, Database options and DTS packages (legacy mode) to the new SQL Server 2014 instance.
– Create new maintenance plans to mimic the old maintenance plans on server.
– Run validation scripts to verify integrity of new data (rebuild indexes, checkdb ..etc).
– Test the new instance to verify that applications work without any problems.

Also there are some new features available in SQL Server 2014 like In-Memory OLTP, Advanced AlwaysON Availability Groups, Advanced BI, etc, so check if any of the new features are worth to be implemented to High Availability, Security, Stability, etc.

Also, it is not possible to directly upgrading from SQL Server 2000 to SQL Server 2014, so in that case, first upgrade needs to be performed from SQL Server 2000 to SQL Server 2005 or SQL Server 2008 R2 and then to SQL Server 2014.

This is applicable on below versions of SQL Server

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

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.

 

Steps for Side-By-Side Migrate or Upgrade plan for SQL Server 2012

SQLServerF1

SQL Server legacy versions are no more fully supported by Microsoft. Most of the organizations have already migrated to the latest versions of SQL Server long back, however there are few servers or applications which still use older versions of SQL Server like SQL Server 2000 SQL Server 2005 due to compatibility issues with latest versions of SQL Server versions. There may be lot of cost involved to upgrade legacy applications to work with latest versions of SQL Server, but it is high time to either move to another application or upgrade the application to work with latest SQL Server versions. There are two different methods available to migrate or upgrade an SQL Server instance to SQL Server 2012, which are In-Place Upgrade and Side-by-Side upgrade. It is always better to prefer Side-by-Side upgrade which is more safe method and also we can move to new hardware instead of using the old hardware to run the new SQL Server instances. Below are the important steps to keep in mind while upgrading from SQL Server 2005 or SQL Server 2008 R2 to SQL Server 2012 using side-by-side method.

– As a first step it is important to understand which objects would be affected after upgrading to SQL Server 2012. We can get this information by running the SQL Server 2012 Upgrade Advisor against the SQL Server 2005 or SQL Server 2008 R2 instance which will generate an report with list of any warnings or issues.
– As part of the up-gradation process, stop all write activity to the SQL Server 2005 or 2008 R2 instance. This may involve disconnecting all users or forcing applications to read-only activity.
– Transfer data from the legacy instance to the SQL Server 2012 instance. This can be done by backup/restore of databases from SQL Server 2005 or SQL Server 2008 R2 to SQL Server 2012. To reduce the amount of downtime, one can look into options like Log Shipping or Database Mirroring.
– Create supporting objects in system databases like SQL Server Agent jobs, security settings(Logins, Server role permissions), Instance level configuration settings, Database options and DTS packages (legacy mode) to the new SQL Server 2012 instance.
– Create new maintenance plans to mimic the old maintenance plans on server.
– Run validation scripts to verify integrity of new data (rebuild indexes, checkdb ..etc).
– Test the new instance to verify that applications work without any problems.

Also there are some new features available in SQL Server 2012 like AlwaysON Availability Groups, Contained Databases, Advanced BI, etc, so check if any of the new features are worth to be implemented to High Availability, Security, Stability, etc.

Also, it is not possible to directly upgrading from SQL Server 2000 to SQL Server 2012, so in that case, first upgrade needs to be performed from SQL Server 2000 to SQL Server 2005 or SQL Server 2008 R2 and then to SQL Server 2012.

This is applicable on below versions of SQL Server

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

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.

 
1 2 3 4 5