MODULE 3: UPGRADING SQL

SERVER TO SQL SERVER 2017

=================================================
Needs addressed by upgrading SQL Server instances, services and databases to a new
version of SQL Server
- Replace existing server hardware
- Collapse existing SQL Server instances onto a single server
- Use features found only found in the new version
- Continue to receive support and security patches for SQL Server from Microsoft
- Move a SQL Server instance to a different edition of the same version

OBJECTIVES
==========
- Strategies for upgrading SQL Server instances, services and databases to SQL Server
2017
- Strengths and Weakness of different migration strategies
- Ugrade existing instance to SQL Server 2017

LESSON 1: UPGRADE REQUIREMENTS

==============================
OBJECTIVES
==========
1. Draw an upgrade plan
2. Versions and Editions suitable for upgrading to SQL Server 2017
3. In-place and side-by-side strategies for upgrade
4. SQL Server 2017 Data Migration Assistant
5. Distributed Replay Utility

CREATING AN UPGRADE PLAN

=========================
1. Assess the system to be upgraded
------------------------------------
Considerations before upgrade:
- Features aleady intalled
- Usage characterisitics of the features installed
- Support for installed features by SQL Server 2017
- Performance characterisitics of the existing hardware
 Existing applications:
Application testing to ensure it works ok with SQL Server 2017 - issues discovered from
this test might require application changes

2. Check you upgrade path

--------------------------
Direct upgrade to SQL Server 2017 is not possible between all previous versions and
editions

3. Select an Upgrade strategy

-------------------------------
Inplace or side-by-side upgrades

4. Check hardware resources

---------------------------
Hardware resources must be capabale of supporting upgrade and application's
performance characterisitics

5. Identify acceptance criteria

-------------------------------
Clear acceptance criteria is required to determine whether an upgrade was successful and
whether rollback to a previous version
Rollback is affected by the upgrade strategy chosen
If it failed, rollback to the old with little data loss

SUPPORTED VERSIONS AND EDITIONS

===============================
a. Direct Upgrades
------------------
Direct upgrade and minimum patch levels:
- Version: 2008. Minimum patch level: SP4 or later
- Version: 2008 R2. Minimum patch level: SP3 or later
- Version: 2012. Minimum patch level: SP2 or later
- Version: 2014. Minimum patch level: -
- Version: 2016. Minimum patch level: -

b. SQL Server 2005

-------------------
Limited upgrade is available;
- Direct upgrade is not possible
- SQL Server 2017 can restore database engine and SSAS db from SQL Server 2005
- SQL Server 2017 can attach database data and log files from SQL Server 2005
 c. Versions before SQL Server 2005
----------------------------------
Inplace upgrades are not supported for versions before SQL Server 2005
To upgrade;
- Upgrade to an interim version where upgrade is supported e.g SQL Server 2000
instance can be upgraded to SQL Server 2008 R2 SP2 then eventually upgraded to SQL Server
2017

NB: Editions
------------
Upgrades are permitted only between compatible editions of SQL Server
You can move from a lower featured edition to higher feature edition but not vice versa e.g.
SQL Server 2008 R2 Standard Edition -> SQL Server 2017 Standard/Enterprise Edition
SQL Server 2008 R2 Enterprise Edition -\-> SQL Server 2017 Standard Edition ✘ not allowed

IN-PLACE UPGRADES VS SIDE-BY-SIDE UPGRADES

==========================================
In-place Upgrade
----------------
Occurs when the installed version of SQL Server is replaced with a new version
Highly automated method of upgrading SQL Server
It is harder to rollback to previous operating state
Organisations using this method of upgrade weigh out the tradeoff between straightforward
upgrading and harder rollback
Client applications might also fail after an upgrade, hence it is important to perform
regression testing on applications and remedy situations ASAP
Advantages:
- additional hardware resources are not necessary
- connected applications don't need to be reconfigured to work with the new server
Restrictions:
- upgrade is only possible for supported versions
- all server components must be upgraded as part of an in-place upgrade e.g. when the
database engine is upgraded to SQL Server 2017, SSAS cannot remain on the same version
- SQL Server 2017 is 64-bit only and cannot be upgraded from a 32 bit version

Side-by-side Upgrade
--------------------
Databases are migrated from the existing SQL Server instance to a new SQL Server 2017
instance
Migrations are carried out using;
 - database backups
- detach and reattach of data files
- data transfer between databases using the Copy Database Wizard
- BCP
- SSIS or another ETL tool
Less risk than an in-place upgrade because the original system stays in place - can be
restored back to production should an upgrade issue arise
Side-by-side upgrade routes
1. One server
The new instance (SQL Server 2017) is installed alongside the instance to be
upgraded on the same machine.
2. Two servers
New instance is installed on a different machine from the existing instance

NB:
Both routes require sufficient hardware resources provided for both instances.
A side-by-side upgrade is an alternative where there is no in-place upgrade path

Issues
- Configuration of server-level objects and services on the new instance - SQL Server
Agent jobs, logins etc.
- Time taken to copy all the user databases to a new location
- Disk space to hold all the data being transferred
- For one server side-by-side upgrades, some SQL Server versions cannot be
installed side-by-side on the same machine

IN-PLACE SIDE-BY-SIDE

Mostly automated -you can modify the More granular control over process
features and editions if need be.

System data upgraded - shared components Use to perform test migration - can be used
as a test bed. Create a side by side copy,
take data out from live and test it before
moving to production.

No additional hardware - major advantage of Relatively straightforward rollback - although

this strategy might require some considerations to move
changes made in test bed to the production
environment in a case where this is required
for a ollback. You can use replication to sync
changes between the production and side by
side test bed. You could alsO use scheduled
integration packages - ETL
 Front-end code points to the same names - Can leverage failover/switchover - the
the name of the server & instance do not switchover requires we switch app names to
change the new instance or server name.

Quicker deployment

******************************************** WORKING WITH MULTIPLE VERSIONS AND

INSTANCES OF SQL SERVER https://aka.ms/U0r658
******************************************************************

Hybrid Options
---------------
Strategy that is a combination of some features from an in-place upgrade and side-by-side
upgrade
e.g Rather than copying all the user databases, after installing the new version of SQL
beside the existing version and migrating all the server level objects
you can detach user databases from the previous instance and reattach them to the new
instance
After databases have been attached to the new instance, they cannot be reattached to the
old instance.
This holds true even if the database compatibility settings have not been upgraded

Rolling Upgrade
----------------
This is more complex approach that maximises uptime and minimizes risk that is used
when upgrading an instance wthat employs High Availability functionality.
HA Features it is dependent on
- Always-on availability groups
- Failover clustering
- Mirroring
- Log shipping: process of automating the backup of transaction log files on a primary
database server and then restoring them onto a standby server
- Replication
- Reporting Services scale-out

******************************** CHOOSING A DATABASE ENGINE UPGRADE METHOD

https://aka.ms/Kpn43d
*****************************************************************************************
DATA MIGRATION ASSISTANT
========================
This is a Downloadable tool that is used to identify areas in the application that might be
affected after an upgrade
It runs a set of rules against a database to determine if behaviour has changed for the
features in use
It generates a report with the following severity ratings
1. High
issue is a breaking change that will cause problems
2. Warning
issue can cause problems after migration
3. Information
for information only
The report provides the following information
- The affeted database object, the affected line(s) and suggested resolution
- List of issues affecting SQL Server 2017 and future versions - features that are still
supported for SQL Server 2017 but are marked for deprecation
Generated reports can be exported to csv or html
High severity issues must be resolved before proceeding with upgrade
Data Migration Assistant only check compatibility of code in database objects - user defined
functions, stored procedures etc.
Data Migration Assistant does not asses the compatibility of SQL statements generated by
users and applications

DISTRIBUTED REPLAY UTILITY

==========================
This a tool for testing client code
mitigates the hassle of manual testing, as depending on the size and complexity of
application this might not give an accurate representation of activity
Operates by replaying the client application activity captured from SQL Server instance
(production instance) against a target SQL Server instance (test instance); Reporting any
warnings or errors encountered.
Distributed Replay Utility applications
- performance tuning for hardware and software
- assessing client code compatibility with SQL Server 2017
Takes a file of trace data captured by the SQL Server Profiler as its input.
SQL Server Profiler records all the client activity from the source instance

NB:
Results from the utility are only as representative as the content of source trace data files.
Consideration of how long the trace that captures client activity needs to run to capture a
representative workload and trade this off against the size of the captured data
 SQL Server Profiler trace data file are preprocessed before being used by the Distributed
Replay Utility

Distributed Replay Utility is made up of two components - server and client

Can be installed during server installation
An installation has one server and 1 or more clients - upto 16 clients
Server and client can be installed on the same machine
Distrubution of replay across multiple clients results in a better simulation of activity on the
source system
This means workloads from source systems with high levels of activity which would not be
possible to replay using a single client can be replayed
At the end of replay, admin will have to assess the output from each client looking at the
commands that generated error messages.
The errors could indicate an incompatibility in the client code for the target server

******************************** SQL SERVER DISTRIBUTED REPLAY

LESSON 2: UPGRADE OF SQL SERVER
SERVICES
========================================
Some SQL Server features required additional work when uprading depending on whether
the option is an in-place or side-by-side strategy

Upgrading Analysis Services

============================
Supports in-place upgrade: yes
Supports side-by-side upgrade: yes
Characteristics:
- In-place upgrade of Analysis Services can be carried out automatically using the SQL
Server setup utility
- A side-by-side upgrade of Analysis Services requires that the databases be backed up
from the source instance and restored on the target instance; backup and restore
- The target Analysis Services must use the same server mode (Tabular or
Multidimensional) as the source instance

Upgrading Database Engine

=========================
Supports in-place upgrade: yes
Supports side-by-side upgrade: yes
Characteristics;
- In place upgrade of the database engine can be carried out automatically using the
SQL Server setup utility
- Side-by-side upgrade requires a transfer of the user databases from the source to the
target instance using;
- database backup
- detach and attach of data and log files
- Objects that are stored in system databases e.g msdb and master must be transferred
to the target server
- Logins
- SQL Server Agent jobs
- Server-level triggers
- Integration Packages stored in MSDB
- Reporting Services encryption keys
 - After an upgrade, admin should update statistics on all user databases using
sp_updatestats So that the new database instance knows;
- the indexes present,
- what objets are present and
- how to build query plans effectively.

Upgrading Data Quality Services

===============================
Supports in-place upgrade: yes
Supports side-by-side upgrade: yes
Characteristics;
- Similar to upgrade characteristics to upgrading the Database Engine as it is a user
database
- All upgrade methods require that the following additional steps are done to update
DQS
- Upgrade each computer where the Data Quality is installed
- Upgrade the schema of DQS using the command-line utility dqsintaller.exe

Upgrading Integration Services

===============================
Supports in-place upgrade: no
Supports side-by-side upgrade: yes
SQL Server Integration Services upgrade is always side-by-side
- in a one server scenario, the new version of SSIS components instead of being
replaced in the old version, are installed in addition to the old version
The behavior of upgrade for SSIS is different depending on whether;
- SSIS and the database engine are installed on the same machine
- Database engine and SSIS are upgraded at the same time
When the database engine and SSIS are on the same machine and are upgraded
together;
- Upgrade process will remove the system tables used to store SSIS packages in the
earlier versions of SQL Server and replace them with the SQL Server 2017 versions of these
tables
When the database engine is upgraded, old versions of the table continue to be used in
SQL Server 2017
Regardless of whether SSIS and the database engine are upgraded at the same time or
not, upgrade process will not;
- remove earlier versions of Integration Services service
- Migrate existing SSIS packages to the new format used by SQL Server 2017
 - Move packages from file system locations other than the default location
- Update SQL Agent job steps that call the dtexec utility with the file system path for SQL
Server 2017 version of dtexec

Upgrading Master Data Services

==============================
Supports in-place upgrade: yes
Supports side-by-side upgrade: yes

- Follows upgrade criteria for updating the Database engine as it is user database
- All upgrade methods require the following additional steps;
- Upgrade the schema of the MDS database using the Upgrade Database Wizard in
Master Data Services Configuration Manager
- any customizations of objects in the MDS are overwrriten by this upgrade
- Install SQL Server 2017 Master Data Services web application
- After schema upgrade, old versions of MDS web app will no longer be able to
conncet to Database
- Upgrade any clients using Master Data Services Add-in for Excel to the SQL Server
2017 version
- Clients using the old version of the add-in will no longer be able to connect

- An inplace upgrade of MDS can be executed without upgrading the database engine
hosting it

Upgrading PowerPivot for SharePoint

====================================
PowerPivot is an excel add-in which can be used to perform powerful data analysis and
create sophisticated data models.
- It can handle large volumes of data (millions of rows) from various sources - and all of
this within a single exel file.
- Servers hosting workbooks require SharePoint, Excel Services and an installation of
Power Pivot for SharePoint
- Analysis Services in Power Pivot maode provide hosting of Power Pivot data in
SharePoint farm.

Supports in-place upgrade: partially

Supports side-by-side upgrade: yes

- Servers running Analysis Services in SharePoint mode can undergo side-by-side or in-
place upgrades
 - PowerPivot for SharePoint Add-In is always installed side-by-side with ealier versions and
cannot be upgraded in-place

- When Power Pivot for SharePoint is upgraded to SQL Server 2017, admin must install or
upgrade SharePoint components in the SharePoint server or server farm.
- Upgrade prerequisites and procedure for Power Pivot varies depeding on whether you
are using SharePoint 2010 and SharePoint 2013. But in summary;
- Upgrade all servers running Analysis Services in SharePoint mode (at a minimum, the
PowerPivot instance must be upgraded)
- Install and configure SQL Server 2017 Power Pivot for SharePoint Add-in on all
servers in the SharePoint farm.
In a multiserver when the upgrade is completed on one server, the other servers are
unavailable until they are upgraded.

- The upgrade will not upgrade Power Pivot workbooks that run on the SharePoint servers,
but workbooks created by previous versions of Power Pivot for Excel will continue to function
ok.
- The exception to this, is workbooks using scheduled data refresh. These workbooks
are required to use a version of PowerPivot for Excel that matches the server version.
- These workbooks must be manually upgraded or use the auo-upgrade for data
refresh feature in SharePoint 2010.

Upgrading Replicated Databases

==============================
- Suports inplace upgrade: yes
- Supports side-by-side upgrade: yes'

- Transactional Replication: automated periodic distribution of changes between

Databases. Data is copied, in near real-time, from the primary server to the receiving databae.
- Offers excellent backup for frequent, daily database changes
- Merge replciation: complex type of replication that allows both the Publisher and
Subscrber to independently make changes to the database.
- changes are synchronised by merge agents that sit on both servers and a
predetermined confict resolution mechanim.
- Such conflicts arise becuase merge replciation does not require a realtime
connection between the publisher and subscriber - servers may change values at irregular times
- Useful for mobile users who are not always connected to a publisher but still need a
database they can around and make changes to.

NB:
- Two server side by side upgrade of databases involved in replication requires the
following;
- reconfiguration of replication
 - providing a new snapshot to be delivered to subscribers
- To avoid the above strenous tasks, the server and database names on the new server
must match those of the old server. This can create complexity in the upgrade plan.

- SQL Server supports replication of data between nodes running different versions of SQL
Server.
- This means that nodes can be upgraded independently without halting activity across
the SQL Server replication topology.

NB:- Some limitations to the above rule apply;

- A distributor must be running a version >= Pusblisher version and similarly, the
Publisher must be running a version <= to its Distributor
- Subscribers to a transactional publication must be within two versions of the Publisher
version. e..g if Publisher is running SQL Server 2017, the subscribers must be running 2014 or
2016
- There are no version restrictions for subscribers to a merge replication

- When log reader agent is running for transactional replication, any activity on the
database must be stopped, to allow the log reader agent to process any pending operations
before stopping it to complete the upgrade process.

For merge replication instances, the Merge Agent and Snapshot Agent must be run for
each subscription following an upgrade

Upgrading and Migrating Reporting Services

=========================================
- Supports in-place uograde: yes
- Supports side-by-side upgrade: yes

NB:
- One server side-by-side upgrades are only supported for Reporting Services running in
native mode
- An in-place upgrade cannot be used to switch a Reporting Services installation
between native and SharePoint mode

- Steps to carry out before upgrade;

- Backup reporting sevices encryption keys
- Backup of customizations to Reporting Services virtual directories in IIS.
- Remove invalid/expired SSL certificates from IIS. The presence of invalid SSL cert will
cause the installation of Reporting Services to fail.
 - The upgrade process is different depending on whether you are running Reporting
Services in native mdoe or SharePoint mode
- Reporting services running in SharePoint mode, require that the Reporting Services
Add-in for SharePoint is upgraded after the Reporting Services service has been upgraded.

- Reporting services using scale-out deployment - deployment includes more than one
report server - all memebers of the scaled-out deployment group must be removed before
upgrading them. As servers are upgraded, members of the scaled-out deployment group can
then be added back individually.

Upgrading SQL Server Management Tools

=====================================
- Support for in-place upgrade: no
- Support for side-by-side upgrade: yes
- The management tools are the recommended way of managing SQl Server 2017. SQL
Server management tools include;
- SQLCMD
- SQL Management Studio
- SQL Server Profiler
- Mananment tools are always installed side-by-side hence an in-place upgrade is not
supported
- Older versions of the management tool(s) can be removed using Control Panel in
Windows

Upgrading using Setup

=====================
In-place upgrade of SQL Server 2017
-----------------------------------
- SQL Server setup: In SQL Server Installation Centre, use "Upgrade from a previous
version of SQL Server" in the Installation Section.
- Features cannot be added/removed during an in-place upgrade.

Uograding to a different edition of SQL Server 2017

---------------------------------------------------
- SQL Server setup includes support for changing the edition of an installed instance of
SQL Server.
- In SQL Server Installation Centre use Edition Upgrade located in the Maintenance
section
- Remember upgrade paths*
 NB:
You can also use the command-line interface of setup.exe to carry out an upgrade or
edition change of SQL Server.
LESSON 3: SIDE-BY-SIDE UPGRADE:
MIGRATING DATA AND APPLICATIONS
================================================================

UPRGADING DATA AND APPLICATIONS

===============================
- Side by side upgrade involves moving or copying an instance from an older version to
SQL Server 2017
- An important consideration for the admin is to synchronise the original and migrated
versions of the database;
- changes made by client applications after the migration cut off point will not be
reflected in the SQL Server 2017 version.
- By restricting client applications from accessing the database, there will likely be a period
of partial loss of function or downtime for the applications.
- it important to determine the duration of loss of function that is acceptable for the
organization

Database File Metadata

----------------------
- SQL Server database files contain metadata that links them to specific version and
patch level of SQL.
- When the version of SQL Server hosting a database is upgraded, the database
metdata must be updated and changes applied - e.g. the addition/removal of metadata items.
- SQL Server will automatically carry out the metadata updates when a database is
restored or database file is attached to a new instance. However,
- Upgrading from a previous version to a newer version is the only supported path

Database Compatibility level

----------------------------a
- This is a user modifiable attribute that indicates the version of the database engine with
which a SQL Server database is designed to be compatible with.
- For SQL Server 2017, this means partial support for backward compatibility with
previous versions of the database engine.
- Databases relying on features that have been deprecated or removed can be used
in SQL Server 2017 without modification
Compatibility Level: 140 Database Engine Version: SQL Server 2017
Compatibility Level: 130 Database Engine Version: SQL Server 2016
Compatibility Level: 120 Database Engine Version: SQL Server 2014
Compatibility Level: 110 Database Engine Version: SQL Server 2012
Compatibility Level: 100 Database Engine Version: SQL Server 2008 or 2008 R2
 *Compatibility Level: 90 Database Engine Version: SQL Server 2005.
- automatically converted to compatibility level 100 when restored or attached to
SQL Server 2017 instance.
- When a database is restored or attahed to a new instance, the compatibility level
remains the same until it is changed.
- The compatibility level can be moved up or down at any time.

MIGRATING SQL SERVER DATABASES

==============================
- The following steps must be performed on the user databases that are required for a
side-by-side upgrade
- Get potential upgrade issues: Run Data Migration Assistant (covered in Lesson 1) and
make code or design changes as necessary
- Ensure db is consistent: Run DBCC CHECKDB to ensure the database is in a
consistent state
- Log and Data file autogrowth: Confirm that the data files and log files are set to allow
autogrowth. This is to allow for additional space required during an upgrade. - can be disabled
after upgrade completes.
- Database statistics: Confirm that the database statistics are up to date either by
enabling AUTO_UPDATE_STATS, running sp_updatestats or running UPDATE STATISTICS
commands.
- Backups: Ensure that the backups are current & valid backups.
- After the above steps are followed and the SQL Server 2017 instance installed and
prepared, the side-by-side migration can be completed using one of the following methods
- Backup and Restore
- Detach/Attach data files
- using the Copy Database Wizard
- These methods can be used in scenarios when an inplace upgrade is not supported
- e.g. when moving from 32 bit to 64 bit versions

USING BACKUP AND RESTORES TO MIGRATE

DATABASES
==============================================
- SQL Server 2017 support backup and restores from the following versions; SQL Server
2005, 2008, 2008 R2, 2012, 2014 or 2016.
- Both the backup and restore operations can be carried out using
- SQL Server Management Studio wizards
- TSQL Commands
- Windows Powershell scipts
- Third party backup management tools
 - Advantages
- File sizes: Backup are smaller than the data files they contain;
- free space is not backed up
- only the active tail of the log file is backed up
- SQL Server can compress the backups as they are taken (Standard and Enterprise
editions only)
- A compression utility can be used before the transfer
- Downtime: Incremental transaction log backups can be applied to the new SQL Server
2017 instance while it is in NORECOVERY mode (after the initial full backup has been
restored). This can reduce downtime during the upgrade process.
- Rollback: The original database remains unchanged and available for rollback if a
problem is found with the upgrade.
- Disadvantages
- Storage: Sufficient storage capacity is required to store both the database backup and
the database files after they have been restored.
- Migration Duration: If the database is not in Full Recovery Mode or the admin opts not
to use incremental backups, the downtime for an upgrade includes the time taken to run a final
backup of the old version and restore the backup to the new instance; as well as the duration
taken to transfer the the backup to the new hardware in a two server upgrade.
- Client activity: As the source database remains after the backup process, client
application connections and activity must be managed to prevent data changes that will not be
reflected in the new database.

***** Check out Copy Databases with Backup and Restore ****
https://docs.microsoft.com/en-us/sql/relational-databases/databases/copy-databases-with-
backup-and-restore?view=sql-server-ver15

USING DETACH AND ATTACH TO MIGRATE DATABASES

=============================================
- Detaching data from an old instance and attaching it to the new SQL Server 2017
instance.
- Data files are upgraded when attached to the new instance.
- The old instance can be of version 2005, 2008, 2008 R2, 2012, 2014, 2016
- Advantages
- Speed: The detach and attach commands work rapidly. A great deal of the upgrade
duration goes to moving or copying files.
- Client applications: There is no risk of client applications making modification on the old
instance after the migrations is started. This is due to the fact the old instance becomes
unavvailble when the data files are detached. The cut-off point for the migration is clear.
- Rollback: If the data files are copied (rather than moved) an admin can rollback to the
old instance quickly without needing to wait for a database restore to be completed.
 - Disadvantages
- Migration Duration: Lengthy time taken to copy the data files if they are large.
Especially in a two server scenario where the data files must be copied across as network link
- File sizes: The reserved/free space for autogrowth and the consumed space in the
database and log files must be copied i.e. the entire data file, and not only portions that contain
data, is copied.
- Rollback: The update of a data file to SQL Server 2017 is not a reversible process.
Hence if the data files are moved rather than copied, restoring a backup is the only rollback
option.
- NB:-
In a scenario where the data and log files are held on a SAN volume, the time taken to
detach and copy the files across the network can be reduced by cloning the SAN volume the old
host and attaching it to the new host for SQL Server.
- cloning the volume requires more space but will keep the old volume unchanged and
available for a relatively straightforward rollback.

***** Check out Detach and Attach **** https://docs.microsoft.com/en-us/sql/relational-

databases/databases/database-detach-and-attach-sql-server?view=sql-server-ver15

USING THE COPY DATABASE WIZARD

==============================
- Tool offered by SQL Server Management Studio that allows an admin to copy or move
databases.
- Difference being that in a move the source database is dropped by the wizard at the
end of the process.
- The copy or move operation can be run immediately or scheduled for a future date using
SQL Server Agent.
- The copy database wizard works in two ways;
A. Detach & Attach
------------------
- The source database files are detached and duplicated and the duplicates are then
attached to the target server.
B. SQL Server Management Objects
--------------------------------
This method uses two steps;
1. The SMO API is used to generate scripts for database objects in the source
(tables, views, stored procedures etc). These scripts are applied to the target database to create
copies of the database objects.
2. A SSIS package is generated to transfer the data from the source database to
the target database. The package can optionally be saved for reference or modification.
 Advantages of SMO
------------------
- The wizard provides options for creating server level objects (Logins, SQL Agent
Jobs, SSIS packages) when copying a database between two instances.
- The source database remains available during the copy operation.
- Storage space is required to only store the source and target databases. No
storage space is required for database files or backups.

Disadvantages of SMO
--------------------
- Slower than Detach/Attach or using a Backup
- The process of copying the data is vulnerable to network connectivity issues.
- As the source database remains available during the copy operation, it is
important that client applications are not permitted to make changes to the source database
during the operation - to ensure the source and target databases are in a consistent state.
Achieving the same manually
---------------------------
- To carry out steps similar t
o the Copy Database wizard manually;
- Write SMO scripts or script database objects using TSQL
- Create your own SSIS package to transfer the data or use an alternative tool
e.g. BCP.exe
- Regardless of whether it is done manually or using the wizards the same pros and
cons still apply.

***** Checkout Using the Copy Database Wizard

https://docs.microsoft.com/en-us/sql/relational-databases/databases/use-the-copy-database-
wizard?view=sql-server-ver15

TRANSFERRING LOGINS AND PASSWORDS

=================================
- A user security context in a SQL Server database is derived from two objects;
- Server level login: A login that controls the access to a server instance. Logins are
stored in the master system database. This could be;
- Windows principal (Windows user or Domain User (active directory group))
- SQL Server login.
- Database Level user: controls access to a database. Logins are mapped to database
users for access or granted access through membership of a databse user group or
membership of a server role. Database users and groups are stored in the database to which
they relate.
- When a database is migrated between SQL Server instances, the database users and
groups are copied along with it - as they are stored in the database.
 - Sever level logins are however not automatically transferred
- The same logins in the source db must be created in the target db.
- when using the Copy Database Wizard SMO method, you optionally configure it to
create logins.
- Logins can be created using;
- TSQL CREATE LOGIN command
- SMO using the Login.Create method
- Scritps to create logins can be generated using SSMS
- Object Explorer: Security > Logins > On the login click Script Login as ... > click
CREATE TO .. > select an output method

SQL Server Logins

-----------------
- These are configured allow for SQL Server authentication and are stored in SQL
Server unlike Windows logins which stored in the active directory.
- The scripted logins generated by SSMS do not include the actual password's value -
random value is used instead. This is an intention design for security purposes.
- Options available for using the same password for SQL Server login in the source and
target systems.
- Using the login on the source system create a login on the target system using
CREATE LOGIN WITH PASSWORD TSQL command.
- Use the hashed password value from the source system to create a login on the
target with CREATE LOGIN WITH PASSWORD HASHED TSQL command

Contained Databases
-------------------
- Supported in SQL Server 2012, 2014 and 2016
- Contained database provides facilites that are normally at the instance level in the
database level (e.g. user authentication).
- Contained database users;
- users with passwords stored in the database
- can be used to break dependency between logins and database users.
- Containment levels determine which features to carry out at instance level and which
ones at database level
- Partial
- Full

Orphaned Users
--------------
- These are users with logins that are not linked to the SQL Server instance.
- Orhpaned users are allowed exist and have object permissions assigned to them but
cannot login directly to a database.
- Users can be orphaned for two reasons
1. The login was deleted after the user was created
 2. The database has been restored or attached from another SQL Server instance;
the linked login has not been created on the new instance.

Detecting orphaned users

-------------------------
- A report can be generated using a system stored procedure sp_change_users_login
- EXEC sp_change_users_login 'Report';
- sp_change_users_login with @Action parameter set to 'Report'

Repairing Orhpaned Users

------------------------
- involves associating orphaned users with a login that exists - must be already
created.
- SQL Server Logins: use sp_change_users_login.
- SQL Server Logins & Windows Logins: use ALTER USER WITH LOGIN tsql
command.
- An alternative can also be to create a SQL Server Login with SID (Security Identifier)
that matches that found in the users definition - use the sys.database_principals view to get this
information.
- CREATE LOGIN command can take a SID as an optional parameter

****** Checkout Troubleshooting Orhpaned Users https://docs.microsoft.com/en-us/sql/sql-

server/failover-clusters/troubleshoot-orphaned-users-sql-server?view=sql-server-ver15

UPDATE CONFIGURATION WITH SP_CONFIGURE

======================================
- Part of the upgrade process involves ensuring that the target instance's features are
configured in such a way that they are able to continue working with the client applications.
- The system stored procedure sp_configure can be used to view and ammend
configurations
- when executed without parameters sp_configure will display a list instance level
configuration settings.
- The default is a patial list of settings is returned - simple list
- To view the complete list, the advanced settings option must be set 1
- To make changes the ALTER SETTING permission must be granted

Enabling the Show Advanced Settings

-----------------------------------
EXEC sp_configure 'show advanced options' 1;
RECONFIGURE;

EXEC sp_configure
 Run these commands on both the source and target instance and compare to determine
which settings to change.

- The value of a configuration setting is changed by passing two parameters

- The first parameter is the setting to change and the second is the new value
- After the first statmenet issue RECONFIGURE or RECONFIGURE WITH OVERRIDE
to apply the settings.

*** Checkout Server Configuration Options https://docs.microsoft.com/en-us/sql/database-

engine/configure-windows/server-configuration-options-sql-server?view=sql-server-ver15