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.

 

Moving SQL Server Databases from One Server to Another Server

SQLServerF1

One of the very common task for DBAs is to move or migrate databases from one SQL Server instance to another SQL Server Instance. The moving of the databases between SQL Server instances are regularly performed due to various reasons which include databases refresh from production to UAT or Development or Test environments, migration of databases during upgrades, hardware replacements, etc. It is very important to understand the various methods available to move the databases between the SQL instance and steps required to move to safely and successfully move the databases. Also, it is important to have options to quickly and reliable way of rolling back the changes in case of any issues. Below are some of the methods and steps required for moving or migrating SQL Server databases between SQL Server instances.

Backup/Restore: This is very reliable method of moving or migrating SQL Server databases from one instance to another instance safely. This method also leaves the existing databases on old server thus the rollback is easy during the downtime window. In this method Full, DIFF and LOG backups of the databases are performed on the source SQL instance and the backup files are copied over to the destination SQL instance and restore all the backups in order with norecovery option and restore the last log backup using with recovery option which brings the database online.  It is important to plan the type of backups to be performed on which times and prepare the sequence to restore the backup files. The amount of time taken to move the databases can be long if the size of the databases is big for which the backup, copy and restore of Full backup should be performed before the downtime and during the downtime, differential or log backup can be performed which will be small in size and can be moved quickly and restored quickly which will reduce the amount of downtime. This method is most widely used method for database refresh and migrations.

Detach/Attach: This is a good method, but involves lot of risk this not widely used. In this method, the databases are detached on the source SQL instance, the .mdf, .ndf, .ldf files are copied to the destination SQL instance and attached to the destination SQL instance. This method may take less time for moving the databases compared to the Backup/Restore, but has more risk of databases being unavailable on source server for long times. Also, if the databases contain any additional files like FullText or FileStream, then those files are to be copied as well and can become complex. In this method all connections to the source database has to be disconnected before the start of the task and will only be able to connect after all the steps are completed. This method can be used for small and non-critical databases.

Logshipping/DatabaseMirroring/AlwaysON: In this method, logshipping or database mirroring or AlwaysON Availability Groups is setup before-hand between the source and destination SQL instances and during the downtime the logshipping or database mirroring is stopped and removed and final log backup is performed on source and copied over to destination SQL instance and restored with recovery option which brings the SQL instance online. This involves very less downtime and the destination server can be prepared for migration well before and can continue even if the migration is post-poned for some days. This method is commonly used for migrating critical SQL instances from lower version to higher version or for migrating critical databases from one server to another server with less downtime.

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.

 

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.

 

Steps for Side-By-Side Migrate or Upgrade plan for SQL Server 2008 R2

SQLServerF1

SQL Server 2000 or SQL Server 2005 are legacy versions which 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 2008 R2, 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 2000 or SQL Server 2005 to SQL Server 2008 R2 using side-by-side method.

– As a first step it is important to understand which objects would be affected after upgrading to SQL Server 2008 R2. We can get this information by running the SQL Server 2008 R2 Upgrade Advisor against the SQL Server 2000 or SQL Server 2005 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 2000 or 2005 instance. This may involve disconnecting all users or forcing applications to read-only activity.
– Transfer data from the legacy instance to the SQL Server 2008 R2 instance. This can be done by backup/restore of databases from SQL Server 2000 or SQL Server 2005 to SQL Server 2008 R2. 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 2008 R2 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 2008 R2 like database mirroring, Auditing, BI, etc, so check if any of the new features are worth to be implemented to High Availability, Security, Stability, etc.

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 35