Microsoft SQL Server

Administration

By: Mohamed ElEmam

Email: Mohamed.ElEmam.Hussin@gmail.com
 SQL Server Administration

• How Data is Stored: Pages & Extents

Pages

• 8KB in Size or 8192 Bytes

• Header is 96 Bytes

• 128 Pages = 1 Megabyte | 128,000 = 1 Gigabyte

• Smallest Unit of allocation; there are no half pages

Extent

• A set of 8 Pages

• 1 Page = 8KB | 8 Pages = 64 KB

• 16 Extents per MB | 16,000 Per GB

Allocation Bitmap Pages: The internal “directory” of information on pages

• GAM (Global Allocation Map)

• Which extents are available for allocation

• Covers a 4GB interval of data

• SGAM (Shared Global Allocation Map)

• Which mix extents have at least one page to allocate

• Covers a 4GB interval of data

• PFS (Page Free Space)

• Used to track how much free space is on pages

• Tracks other attributes as well

• Covers a 64MB interval of data

Index Allocation Map (IAM)

• Special internal page on a data file that tracks all extent allocations for tables, indexes,
and partitions

• Basically, lets SQL Server know what extent belongs to what specific entity

• Covers a 4GB interval of data

-----------------

• PFS, GAM and SGAM help SQL Server determine where free space is and how much so
that it can allocate it appropriately without having to scan all the pages

• IAM pages and indexes help SQL Server fulfil queries

• The take away is that these few pages help keep an internal “directory” for SQL Server
to be able to find what it needs quickly and pull back as few pages as necessary

• It’s all about reduction of cost to the system

----------------

Data Files

• Stores data from tables and indexes in pages

• File extension is .Mdf for first file and .Ndf for additional files

• Use separate physical disks when available/appropriate

• Separate from Log and TempDB Files; consider this a requirement

• Make sure Data files are equally sized

• Make sure that you pre-size your data files in advance

• Log file extension is .Ldf

File Groups

• Logical Container for Database Files

• Allows for separation of data and indexes

• Used for Table Partitioning

Transaction Logs

• Transactions: (insert, update, delete)

• Committed Transaction: (Completed transaction)

• Uncommitted Transaction: (transaction in processing phase)

• rollback: (Incomplete transaction)

• Must put the log file on a separate disk and with good performance like RAID 10 or 5
why? Because any transaction first enter the RAM then log file and if its committed
transaction it will be written on data file so the log file is the processing the
transactions
 2 Types

• Explicit

• Implicit: the defult of SQL Server

TempDB

• Multiple files allow for multiple threads to use TempDB

• Reduces “System” Page Contention (GAM, SGAM, PFS)

• These internal pages help SQL Server allocate/track space for objects such as
tables. Therefore when contention is reduced, performance is increased.

• Start with 4-8 files, do not exceed 8 unless needed

• Pre-size them equally according to your workload

Instant File Initialization – IFI

• Prevents database files from “Zeroing Out” or “Zero-Filling” upon creation and growth

Why is it useful?

• Makes Database file creation and growth faster

• Creating database files faster means that rebuilding TempDB is faster

• Occurs with Server restart or SQL Services restarting, potentially

speeding up Cluster failovers

• performance boost

• Does not affect Log Files, only applies to Data files

• Does not work with databases that use Transparent Data Encryption (TDE) and a few
other rules

DML & DDL

• DML – Data Manipulation Language

• SELECT, INSERT, UPDATE, DELETE

• DDL – Data Definition Language

• CREATE, ALTER, DROP

Backup and Recovery Fundamentals
Recovery Models

• Full - allows for point-in-time recovery for all transactions and requires T-Log
maintenance
• Simple - minimally logged operations
• Bulk-Logged - Bulk operations are not logged, but others are, point-in-time recovery
except for bulk load operations, requires T-Log maintenance
• **Best practice is to run a T-log backup when switching between bulk load and Full
recovery models**

Backup Types

• Full - does a backup of all database pages and "marks" them as backed up
• Differential - does a backup of all database pages that have changed since the last full
backup
• T-Log - does a backup of the transaction log; requires that at least one Full backup has
been done before hand
• FileGroup - does a backup of specific filegroups
• File - backs up a specific database file

Backup Options

• COMPRESSION
• COPY_ONLY (use when need backup for development - not in the chain-)
• DIFFERENTIAL
• MIRROR TO
• STATS = X (replace X with a number)
• NOINIT | INIT (Appends to backups - Overwrites)
• ENCRYPTION (SQL 2014+ and above)

Restore Options

• WITH RECOVERY vs. NORECOVERY

• VERIFY ONLY - verifies that the backup is ok
• HEADERONLY - displays a list of backups on your backup file
• FILELISTONLY - displays the list of database and log files on your backup file (Logical &
Physical Name, Filegroup, and other great stuff)

Restoring Sequence

1. Take a backup of your Active/Tail Log

2. Restore your Full Backup (NoRecovery)

3. Restore your latest Diff (if available - NoRecovery)

4. Restore all your T-Logs (NoRecovery)

5. Restore your last T-Log the "Tail" (Recovery)

RTO, RPO, and your CIO

• RTO - Recovery Time Objective

• How long will it take you to recover after a disaster?
• RPO - Recovery Point Objective
• How much data are you willing to lose? Or how much can you recover? Or how often
does your data change?
• CIO - The person that will fire you if you fail on this!

DR vs HA

• Disaster Recovery <> High Availability

• For example:
• Mirroring, Log Shipping vs. Backups
• Availability Groups vs. Backups
• Clustering vs. Backups

Basic Backup Code

Backup Database [DatabaseName]

TO [Disk/Device] = N'NameOrPath'
WITH [OPTIONS]

-------------------------------

Backup Database DBTest1

TO Disk = N'C:\Backups\DBTest1_01012013.bak'
WITH COMPRESSION, COPY_ONLY

--------------------------------

Backup Database DBTest1

TO Disk = N'C:\Backups\DBTest1_DIFF01012013.bak'
WITH DIFFERENTIAL

Log Backup Code

Backup Log DBTest1

TO Disk = N'C:\Backups\DBTest1_Log01012013.trn'

Basic Restore Code

RESTORE DATABASE [DBName]

FROM [Disk/Device] = N'NameOrPath'
----------------------------------------

RESTORE DATABASE DBTest1

FROM DISK = 'C:\Backups\DBTest1_01012013.bak‘

----------------------------------------

RESTORE DATABASE DBTest1

FROM DISK = 'C:\Backups\DBTest1_01012013.bak'
WITH NORECOVERY

RESTORE LOG DBTest1

FROM DISK = 'C:\Backups\DBTest1_Log01012013.trn'

SQL Server Security

SQL Server Security Overview
• Principals - Object that is authenticated and given access
• OS - Windows Logins
• Instance - Server Logins, Server Roles
• Database - DB Users, DB Roles
• Securable -objects that are given access to
• OS - NONE
• Instance - DBs
• Database - Tables, views, schemas, procedures, etc
Principals are given access to securable

Ports
• Managed with Configuration Manager
• SQL DB Engine - 1433 TCP
• Dedicated ADMIN (DAC): 1434 TCP
• SQL Server Browser 1434 UDP
• SSAS – 2383 TCP
• MSDTC & SSIS via SSMS - 135 TCP
• Mirroring/Availability Groups 5022
 • Also needed for Failover Clustering
SQL Server Named Instances – by default uses dynamic ports but this can be changed.

Server Logins
• Security at the DB Engine or Instance Level
• Can be of two kinds:
• SQL Server Login (Only works within SQL)
• Windows Login
Server Roles
• Custom Server Roles – SQL 2012+ (grant=access allowed, deny=no access, with
grant= can give access to another user)
• Server logins are mapped to Server Roles for permissions
• Roles allow giving permissions based on job function
Logon Triggers
• Server Trigger that Fires during Logon
• For Auditing or Logon Time Restrictions
Database Schemas
• Logical container and owner of objects such as tables, functions, stored
procedures
• Can create schemas to group similar objects that belong to different
departments for example HumanResources, Sales, etc
• Can give permissions at the schema level which helps separate permissions
further
• Schemas are also useful for data warehousing environments where you want to
keep the same object names
Database Users
• A login at the database level
• Must be mapped to a server login otherwise the DB User is considered
"Orphaned"
Database Roles
• Same as server roles but at the Database level
• Could always create custom roles
Data Control Language (DCL)
• GRANT – gives a principal access to a securable
• REVOKE – takes away permissions given to a principal on a securable
• DENY – denies access to a principal on a securable; this overrides any GRANT
• WITH GRANT – allows the principal access to a securable and allows the principal
permissions to GRANT access to other principals. Be careful with this!
SQL Orphanage
• SQL Server Logins have SIDs (Security ID)
• This SID is created when the Login is created and is unique on each server
because it is randomly generated
• Problems occur when you move databases to other servers since they may
already have the same SQL Login, or if it is created it will have a different SID
• So the DB User is no longer mapped to the Login
Fixing Orphaned Users
• Use sp_change_users_login
• Use sp_help_revlogin - for many logins that need to be fixed, especially useful
for migrations
Database Cross Ownership Chaining
• Disabled by default
• Can be enabled at DB or Instance level
• "When an object is accessed through a chain, SQL Server first compares the
owner of the object to the owner of the calling object. This is the previous link in
the chain. If both objects have the same owner, permissions on the referenced
object are not evaluated."
Contained Database Security
• Database user has no Login on server therefore cannot have orphaned users
 • Database is considered an independent working entity that is "contained" and
separate from the server
**WARNING**
• Contained DB users will have access to databases with guest user enabled

High Availability & Disaster Recovery

• Replication (Table level )

• Log Shipping (DB level )
• Database Mirroring (DB level )
• Always-On Failover Clustering (Server level )
• Always-On Availability Groups (group of DBs level )
• SQL Azure (Azure level )
https://www.sqlshack.com/sql-replication-basic-setup-and-configuration/

Replication Types:
• SNAPSHOT: replicates entire set of data
• TRANSACTIONAL: starts from a snapshot replication and as time passes
replicates only the changed data
• MERGE: starts from a snapshot replication and then each database is updated
separately until databases are compared and differences between them are
transferred

Transactional Replication (Table level)

Transactional replication is the automated periodic distribution of changes between
databases. Data is copied in (or near) real-time from the primary server (publisher) to
the receiving database (subscriber). Thus, transactional replication offers an excellent
backup for frequent, daily databases changes.
Article: basic unit of SQL Server Replication. Article can consist of tables, stored
procedures, and views.
Publications: A Publication is a logical collection of articles.
Publisher: is a database instance that makes data available to other locations through
SQL Server replication to be replicated
Distributor: transfers a publication.
Distributor Agent:
Subscriber: A database instance that receive data from a publication.

Push Replication: distributor push the publication to Subscriber

Pull Replication: Subscriber pull the publication from distributor

Publication types:
Snapshot publication:
The Publisher sends a snapshot of the published data to Subscribers at scheduled intervals.

Transactional publication:
The Publisher streams transactions to the Subscribers after they receive an initial snapshot of
the published data.

Peer-to-Peer publication:
Peer-Peer publication enables multi-master replication. The publisher streams transactions to all
the peers in the topology. All peer nodes can read and write changes and the changes are
propagated to all the nodes in the topology.

Merge publication:
The Publisher and Subscribers can update the published data independently after the
Subscribers receive an initial snapshot of the published data. Changes are merged periodically.
Microsoft SQL Server Compact Edition can only subscribe to merge publications.

Database mirroring
SQL Server database mirroring is a disaster recovery and high availability technique that involves
two SQL Server instances on the same or different machines. One SQL Server instance acts as a
primary instance called the principal, while the other is a mirrored instance called the mirror. In
special cases, there can be a third SQL Server instance that acts as a witness
Using SQL Server database mirroring has multiple benefits: a built-in SQL Server feature,
relatively easy to set up, can provide automatic failover in high safety mode, etc. Database
mirroring can be combined with other disaster recovery options such as clustering, log shipping,
and replication

Always-On Concept
• Simply put, it is a marketing term that encompasses two similar Technologies:
• Failover Clustering
• Availability Groups

Always-On Availability Groups

• Allows for High Availability/Disaster Recovery of a group of databases defined as
an “Availability Group”
• Allows for scale out for databases in the AG
How is it different than Fail-over Clustering?
• Does not require Shared Storage
• Databases are duplicated, therefore storage footprint increases; but also
provides another copy of the DB
• Each server has separate system databases, and different security
• Each server can be accessed separately
• Replicas can be made “Read-Only” to offload read requests (close to Load-
Balancing)
• Automatic Page Repair

Pre-Requisites
• SQL Enterprise Edition – this may change with 2016
• TCP Port 5022 Must be opened
 • Servers must be in a domain
• Servers must be part of a WSFC
• SQL 2012+ and Availability Groups must be enabled in SQL Config Manager
• Any database participating must be in the Full-Recovery Model
• Must pass cluster validation by running ALL Tests **

Always-On Failover Clustering

• WSFC – Windows Server Failover Clustering
• Node – Physical/Virtual Server that is part of a Cluster
• Basically a piece of “hardware” that powers the services
• FCI – Failover Cluster Instance (SQL Installed as a Service in the Cluster)
• High Availability option for Services
• Services are hosted in a WSFC and a particular Node from the cluster provides
the hardware resources for those services
• Requires shared storage
• SQL 2012+ allows for TempDB to be placed on local storage
• Allows for Instance-Level protection (High Availability)
• Can be done across sites (Multi-Subnet)
• Can host Multiple FCIs, can be combined with Availability Groups
• Databases are not protected, they are on shared storage and used by the FCI
• Instance can only be hosted on one Node at a time; it’s not load balancing
Popular uses for Clustering
• Virtualization with Hyper-V
• Making storage highly available
• SQL Server