Ultimate SQL Server 2005

Ultimate 70-431 Study
Guide
SQL Server 2005:
Implementation and Maintenance
Created By: Cbrzana

http://www.proprofs.com [ULTIMATE 70-431 STUDY GUIDE] Page | 1
Table of Contents
Installing SQL Server 2005 ....................................................................................................................... 2
Configuring Log and Data Files ................................................................................................................. 9
Creating Partitions................................................................................................................................. 12
Configuring Database Mail..................................................................................................................... 13
Recovery Models ................................................................................................................................... 17
Configuring Server Security Principals.................................................................................................... 18
Configuring Database Securables........................................................................................................... 20
Configuring Linked Servers .................................................................................................................... 22
Creating Indexes.................................................................................................................................... 24
Working with T-SQL ............................................................................................................................... 28
Implementing Views .............................................................................................................................. 31
Working with XML Structures ................................................................................................................ 34
Creating Functions, Stored Procedures, and Triggers ............................................................................. 42
Working with Flat Files .......................................................................................................................... 47
Backing Up and Restoring Databases ..................................................................................................... 52
Moving Databases ................................................................................................................................. 61
Using Transact-SQL to Manage Databases ............................................................................................. 64
Automating Tasks with SQL Server Agent............................................................................................... 69
Monitoring and Troubleshooting SQL Server Performance .................................................................... 78
Implement Database Mirroring ............................................................................................................. 90
Implement Log Shipping ........................................................................................................................ 95
Managing Replication ............................................................................................................................ 99
Working with Service Broker ............................................................................................................... 125
Creating Full-Text Catalogs .................................................................................................................. 130
Installing SQL Server 2005

Upon inserting the installation disk, you
are asked to choose an action from a list
of several possible choices. You can view
software/hardware requirements, Install
the Upgrade Advisor (which scans your
server and provides a detailed report of
any compatibility issues prior to
installation), install SQL Server and its
components, browse the contents of the
CD, etc.
Prior to actually installing SQL Server,

your computer must have the .NET
framework 2.0 installed, as well as the
SQL Native Client installation wizard.
Note that SQL Server 2005 Express
Edition does NOT install the .NET
framework for you; you need to download it from Microsoft.
Once you initiate the install, the process

will automatically install and configure the
SQL native Client if not already installed.
*Note: You can also use the new .NET

Framework 3.0 if you so choose.
Once the prerequisites are installed, a System Configuration Check is performed. This is simply a process
that checks your system prior to SQL Server installation to prevent any potential installation problems.
As shown in the screenshot, IIS

was not installed on my PC. This
isn’t enough to prevent the
installation of SQL Server, but it
will limit some functionality until
IIS is installed.
After you click “Next”, you are prompted to enter the name and company fields (registration
information). Select “Next” to pick which components to install.
Tip: if you want to install the AdventureWorks database and Books Online: Choose Advanced, and elect
to download and install the SQL Server Books Online, Sample Databases, and Sample Code locally. It is
likely you will want all 3 choices anyway, so now is a good time to install them.
After selecting “Next”, you are required to name the database instance. Since you can install multiple
instances on the same physical server, every name must be unique. There can only be 1 default name
per server (which is your computer name), but
there can be multiple named instances.
Click “Next”, and you are then

prompted to configure the
service accounts. “Best”
practice is to configure a
domain user account, but
assuming your PC is not on a
domain, choose “Use the built-
in System account” |local
system, and select “SQL Server
Agent” to start at the end of
setup. Click “Next”.
There are two types of Authentication in SQL Server 2005: Windows Authentication Mode and Mixed
Mode.
Windows Authentication Mode allows you to

use the user and group accounts available in
the Windows domain for authentication.
Mixed Mode is useful if you have users

outside the company, or applications that
can’t use Windows authentication. The user
first enters username/password. If password
is not valid, only then does SQL Server check
the Windows account information for
authentication.
The next step is self-explanatory, and can enable the submission of Error Reports and Feature Usage:
Collation settings relate to how SQL Server handles non-Unicode data in relation to sorting and
comparison. Generally, it is best to
leave the default settings as-is.
Exceptions to this rule are when the
primary language differs from the
computer SQL Server is being
installed and the SQL Server instance.
Another exception is when the
instance will replicate to other
instances with different languages.
After all of these options are selected,

installation is ready to begin. Click
“Install” to finalize the process:
Post-Installation
After installation, you should download the latest service packs/updates for SQL Server. This update is
especially important if running Vista, since there are compatibility issues with SQL Server unless running
with SP2 or higher.
http://technet.microsoft.com/en-us/sqlserver/bb426877.aspx
After updating SQL Server, you can also install optional databases. The two most popular databases,
referenced in most any SQL Server book, are the Northwind and Pubs databases. To download them,
use the following link: http://www.microsoft.com/downloads/details.aspx?FamilyId=06616212-0356-
46A0-8DA2-EEBC53A68034&displaylang=en.
Once you download and this .msi, you will see a set of scripts in
whichever drive you chose to use. After double-clicking these files, they
will load in SQL Server Management Console. To create the databases,
simply execute the scripts. To verify that the installation completed
successfully, right-click Databases in the Object Explorer and select
“Refresh”, then expand the databases item. You should see the two
databases listed:
Upgrading to SQL Server 2005
You can upgrade from SQL Server 7.0 Service Pack 4 and SQL Server 2000 Service Pack 3 (direct
upgrade from SQL Server 6.5 is not available). You can either perform an in-place upgrade (immediately
overwrites the previous version of SQL Server) or side-by-side migration (install SQL Server 2005 while
retaining the old version).
In-Place upgrades should only be performed if the resources to host multiple database environments
are not available. Using side-by-side migration allows you to verify and test the new version of SQL
Server before moving the old database files over.
Options to move to the new database instance include:

 Detach/Attach a database (once you attach to 2005, you can’t move it back to an older version)
 Copy Database Wizard
 Backup/Restore
 Manual Schema Rebuild + Data Export/Import
All of these methods are discussed in greater detail later in this study guide.
Configuring Log and Data Files

Any SQL Server 2005 database will have two file types: data files and log files. A data file or a log file can
only belong to a single database.
 Data Files hold data and objects (tables, indexes, etc).

 Log Files hold the transaction log used for tracking/recovering the database’s transactions.
Data Files
Data Files can be further broken down into two separate types:
1. Primary Data Files are always included in a

database; they contain startup information for
the database and contain pointers to the other
files in the database. They can also hold
objects/user data. The “suggested” extension for
primary data files is “.mdf”. Each database can
only have one primary data file.
2. Secondary Data Files are optional and user-defined. These contain objects and user data. When
administering secondary data files, you can place secondary files on different physical disk drives
for a boost in performance. The “suggested” extension for secondary data files is “.ndf”. Each
database can have zero or more secondary data files.
Best Practice:
To reduce disk access contention, you should place all data and objects in secondary files and keep just the database catalog in the primary file.
Log Files
You must have at least a single transaction log for every database, but you are allowed multiple log files
per database to provide for faster recovery. The “suggested” extension for log files is “.ldf”.
Filegroups
A filegroup is simply a logical structure that allows the grouping of data files for management of multiple
files as a single logical entity. For a performance boost, you can divide database objects across several
filegroups, and place the filegroups on different disk subsystems.
 Primary Filegroup: contains the primary data file and any secondary data files that aren’t
explicitly stored in another filegroup.
 User-defined Filegroup: Created to group secondary files, assign database objects to groups.
Every database has a default filegroup

(named PRIMARY), and unless a filegroup is
specified, the object is assigned to that
filegroup.
To alter the database’s default filegroup, issue the T-SQL statement:
ALTER DATABASE [target database] MODIFY FILEGROUP [filegroup name] DEFAULT
Configuring Data Files and Log Files
PRIMARY: Specifies a primary filegroup
NAME: The logical name of the filegroup
FILENAME: The path to the filegroup
SIZE: The size of the file.
MAXSIZE: The maximum size you will allow the

filegroup to grow
FILEGROWTH: Specifies the automatic growth

interval for the file.
LOG ON: Specifies information for the logfile.
To edit a filegroup:
To edit a filegroup, specify the database you
want to alter, issue the “ADD FILE”
command, specify parameters like you would
normally, and then specify to which filegroup
you want to add the datafile to.
Configuring Database Files with RAID Systems
Using RAID subsystems provides for improved performance, fault tolerance, and more storage capacity.
- RAID 0: Disk striping, best performance for read/write operations; no fault tolerance.
- RAID 1: Disk mirroring, provides fault tolerance; improves read performance, but can degrade
write performance.
- RAID 5: Disk striping with distributed parity. Improved performance over RAID 1, but more
expensive.
- RAID 10 (RAID 1+0): A mirror of a striped set (combines both speed and fault tolerance)
For a comparison on RAID levels, visit: http://msdn2.microsoft.com/en-us/library/ms178048.aspx
Overview of Best Practices
- Do not put data files on the same drive as the OS files.

- Place transaction log files on a different drive than the data files.
- Place tempdb database on a separate drive (RAID 10 or RAID 5 system).
Creating Partitions
Partitioning allows you to split a table across multiple filegroups, depending on how you configure the
partitions. Partitions allow you to place a subset of a table/index on a filegroup. This creates more
efficient disk I/O, and provides for easier management of very large tables.
Partitioning requires the following steps:

 Create partition function
 Create partition scheme (mapped to a function).
 Create the table/index on the partition scheme.
Creating a Partition Function

Partition functions define the boundaries for partitioning the data in a table/index.
CREATE PARTITION FUNCTION [FunctionName] (input_parameter_type)

AS RANGE [ LEFT | RIGHT]
FOR VALUES (boundary_values)
Difference in RANGE LEFT and RANGE RIGHT (using 1000 and 2000 as example values):
RANGE LEFT = -infinity to 1000, 1001 to 2000
RANGE RIGHT = -infinity to 999, 1000 to 1999
Creating a Partition Scheme

CREATE PARTITION SCHEME [SchemeName]
AS PARTITION [FunctionName]
TO (filegroup1, filegroup2, etc)
Partitioning Tables and Indexes

Add this clause while creating a table/index:
ON [schemeName]([columnName])
Querying Partitions
SQL Server allows you to query partitions so that you can determine the partition number that a
particular value would be placed in.
Use the function called $PARTITION to query partitions:

SELECT $partition.[functionName] (value) AS [PartNum]
This would return the partition number that the (value) would be placed in.
Configuring Database Mail

Database Mail allows you to send messages from SQL Server2005. Database Mail replaces previous
version of SQL Server’s mail agent, SQL Mail. New features found in Database Mail include:
 Support for multiple email profiles/accounts

 Asynchronous messaging
 Cluster-awareness
 64-bit compatibility
 Improved security
 Mail auditing
 Usage of SMTP (eliminates need for Extended MAPI)
Setting up Database Mail

First, you must enable Database Mail (it is disabled by
default):
1. On the machine running SQL Server 2005, open

SQL Server Surface Area Configuration.
2. Select “Surface Area Configuration for Features”.
3. Once the dialog box opens, select the SQL Server

2005 instance you want to configure, and then
expand the Database Engine Node.
4. Select the Database Mail Node.
5. Check the “Enable Database Mail

Stored Procedures” checkbox.
6. Click “Apply” and then “OK”. You

are now done with Surface Area
Configuration.
As an alternative to enabling Database Mail, you can execute T-SQL code, or more specifically, a stored
procedure. Ensure you are logged in as a sysadmin, and run:
To disable Database Mail, run the following code:
The second step in configuring Database Mail is to ensure that Service Broker is enabled in the msdb
database (enabled by default). To enable this, stop the SQL Server Agent and run the following:
The third step is necessary only if the SMTP server requires authentication. If this is the case, you need
to ensure that the SQL Server service (default) account credentials can access the server.
Database Mail Architecture

There are four components to Database Mail:
1. Configuration components: includes two sub-components:

a. Database Mail account, which includes the SMTP server name, authentication type, and
e-mail address.
b. Database Mail profile, which is a collection of Mail accounts. Used by applications to
send e-mail to profiles (and accounts can later be added/deleted without code re-write).
2. Messaging: the Database Mail host database (msdb)
3. Database Mail executable: DatabaseMail90.exe, a separate executable from SQL Server to

minimize impact. Connects to the database engine via the SQL Server service account
credentials.
4. Logging and Auditing: Log information is stored in the host database (msdb). Query the
sysmail_event_log view to see the log.
Using the Database Mail Configuration Wizard
This wizard allows you to perform actions including account

management, profile setup, and security.
1. Expand the Management Node, right click Database

Mail, and choose “configure Database Mail”.
2. This will give you the welcome screen for the

Database Mail Configuration Wizard. Click Next, and
select “Set up Database Mail by performing the
following tasks” is selected (which is the default).
Click Next.
3. Enter the Profile name, a brief description, and then

“Add” a new SMTP account.
4. Fill in the Account information, click

okay, and review your settings.
5. Specify database users or roles that

can access the database profile.
Public Profiles can be accessed by
all users; Private Profiles can only
be accessed by a specific user of a
mail-host database.
6. You now have Database Mail

configured!
To verify that Database Mail is setup correctly, go back to the Management Node and right-click
Database Mail. Select “Send Test Email…” Specify the recipient’s email address, and click “Send Test
Email”. You should receive an email similar to the following:
To view the Database Mail log, simply expand the Management Node, right-click Database Mail, and
select “View Database Mail log”:
Recovery Models
A recovery model is a configuration option that controls how the transaction log records actions, and
has both data recovery and performance implications. There are three recovery models for databases:
1. Full Recovery Model: All operations are logged, log is never truncated. Allows you to restore a
database to a point in failure.
2. Simple Recovery Model: Most operations are minimally logged; truncates log at each
checkpoint. Cannot back up or restore the transaction log. Not appropriate if you can’t afford
loss of recent changes.
3. Bulk-Logged Recovery Model: Minimally logs bulk operations (SELECT INTO, BULK INSERT);
intended to be used only during large bulk operations.
Configuring the Recovery Model:
In SSMS, expand the database node, right-click the database you want to configure, select properties.
Then, select the Options page:
To configure the recovery model in T-SQL:
ALTER DATABASE <database_name>

SET RECOVERY [FULL | SIMPLE | BULK_LOGGED]
Configuring Server Security Principals

Principals include anything that can request SQL server resources; i.e. groups and processes.
SQL Server authenticates all connections, and all connections must specify the mode of authentication
as well as the credentials.
Authentication Modes
Windows Authentication: Uses Active Directory accounts; recommended authentication mode.
Mixed Mode: Windows logins and SQL Server logins are used. Used when non-Windows users require
access.
To configure your authentication mode:

In SSMS, right-click the server, select properties, select the Security page:
Once you make a change to the authentication mode, you must click ok and restart the server. To
restart the server, right-click it and select “restart”.
SQL Server Logins

Logins are the server principals that assign access to users to access SQL Server.
To configure in SSMS:
Expand the security node, right-click logins, select New Login.
To configure in T-SQL:
Windows Login: CREATE LOGIN [domain\User] FROM WINDOWS
SQL Server Login: CREATE LOGIN [loginname] WITH PASSWORD= ‘password’
SQL Server Login can also use:

MUST_CHANGE – Login should change password at next login.
CHECK_EXPIRATION – SQL Server checks the Windows expiration policy for the SQL Server login
CHECK_POLICY – SQL Server applies the local Windows password policy on SQL Server logins
To implement any of these, just add the command =ON.

Example:
CREATE LOGIN jsmith WITH PASSWORD= ‘testPass’, MUST_CHANGE=ON
To change a password:
ALTER LOGIN [loginname] WITH PASSWORD= ‘password’
Configuring Database Securables

Server securables are the entities that you allow or prevent security principals access to SQL Server. You
do this by mapping each database login that needs access to a database user.
Managing Database Users

Creating a database user for each login that needs access to the database is required if a user is to
access a database. The syntax is as follows:
CREATE USER [username] FOR LOGIN [loginName]
If a login name is not specified, SQL server will attempt to map a login name that is the same as the user
name.
To configure in SSMS: Expand the Databases Node, Expand Security, Expand Users. Right-click on Users,
select “New User…”
Note: Management of user/login mapping can be done in Security | Logins as well.
By default, if a login is not mapped to any database users, SQL Server looks for the GUEST account. All
databases have a GUEST user, but by default it is not allowed to connect to a database.
To allow guest connections:

GRANT CONNECT TO Guest
To prevent guest connections:

REVOKE CONNECT TO Guest
Orphaned Users
When database users exist, but there is no associated login mapped to that user, the database user is
called an orphaned user.
Database Roles
Much like fixed login roles, there are also predefined Database Roles, which eliminate the need to create
a new database user for every login you require.
A few of the more popular roles include:
 db_backupoperator: Backup database, backup log, checkpoint

 db_datareader: View information only (SELECT)
 db_datawriter: DELETE, INSERT, UPDATE
 db_securityadmin: Alter application role, create schema, view definition
 db_owner: Only member of db_owner can grant access to db_owner role; granted with GRANT
option: CONTROL
Creating Your Own Database Role
T-SQL Syntax:
CREATE ROLE [roleName]
You can modify the role with the ALTER ROLE

command.
Then, add members to a role:

EXECUTE sp_addrolemember [roleName], [username]
SSMS: Expand the Databases node, expand the Security node, right-click Roles, “New Role…”
Configuring Linked Servers

SQL Server allows you to access external datasources from local T-SQL code. External datasources
include other databases such as Microsoft Access, a remote SQL Server, a separate instance of SQL
Server, Oracle, etc.
Configure Linked Servers in SSMS
1. Open SSMS, expand the Server Objects Node, right-click on Linked

Servers node, select New Linked Server…
2. Specify the connection properties for the linked server. Assign it a

Linked server name, server type, provider, data source, etc.
3. Click OK, and close the window. Security configuration will be done shortly.
4. To validate that the connection is configured correctly, right-click the newly created linked
server, and select “Test Connection”.
You should see a similar popup
message as what is shown below:
Security for Linked Servers
When accessing a linked server, the external server often needs to authenticate the user that attempts
to access it. There are three security models that SQL Server has available:
1. Self-mapping: SQL Server attempts to connect to the external data source using the current
user’s login credentials. The same username/password must exist on the external system. This is
the default setting.
2. Delegation: Impersonates the Windows local credentials; uses the credentials of an

authenticated Windows user.
3. Remote Credentials: Allows you to map local logins to remote logins on the external data
source.
Creating Indexes
Indexes are useful in SQL Server if they can locate data quickly, regardless of the volume of data. A real-
world example is a large book that contains an index in the back, which lists topics and their
corresponding page numbers. Rather than scanning the book page-by-page, word for word, the use of
an index allows you to alphabetically search for a topic and the associated page number.
Databases are very similar to this analogy; rather than scanning an entire table for information, indexes
sort this information in some fashion to allow much faster data retrieval.
Index Structure
Indexes utilize what is known as a “B-Tree” structure (Balanced Tree).
Intermediate levels contain pointers to

corresponding leaf nodes.
Leaf nodes contain entries of data in

sorted order.
Creating Clustered Indexes

Clustered indexes sort and store data rows for a table based on the columns defined in the index. This
structure is similar to a filing cabinet; files are placed in folders alphabetically, and each folder stores the
individual files alphabetically. At this point, you only need to scan through a subset of the files to locate
exactly what you are looking for.
As a general rule, all tables should have clustered indexes (and each table can only have 1 clustered
index). The columns used for that index are known as the clustering key. In a clustered index, the leaf
levels contain the actual data pages.
A Few Index Options

ONLINE: When set to ON, the associated index are available for queries and modification during the
creation of an index. This is useful if you need to build/rebuild an index but need minimal downtime.
STATISTICS_NORECOMPUTE: When set to “ON”, statistics are automatically recompiled.

Creating an Index:
CREATE CLUSTERED INDEX index_name
ON dbo.TableName(ColumnName);
Disabling an Index:
ALTER INDEX index_name
ON dbo.TableName(ColumnName)
DISABLE
Rebuilding an Index:
ALTER INDEX index_name
ON dbo.TableName(ColumnName)
REBUILD
You can also perform these tasks in SSMS:

Expand the Tables Node | Expand the Table you want to Index | Expand the Indexes Node
Right-click on Indexes to rebuild,

reorganize, or disable all.
Right-click on a specific index to

manage only that index.
To create a New Index: Right-click Indexes | New Index
In the General page, you can specify

the name of the index, the type
(Clustered, Nonclustered, or Primary
XML), and the columns included in
the index.
In the Options page,

options include setting a fill
factor, allowing online
processing, automatically
recompute statistics, and
use row/page locks.
Creating Nonclustered Indexes

A nonclustered index is independent of the physical sort order of the data rows in the table. This is
similar to an index in the back of a book, where you search alphabetically in the back of the book for a
reference (page number) of the actual information you are looking for. Once you find that page number,
you then turn to the appropriate page to retrieve the actual data.
After creating clustered indexes, you can create multiple (up to 249) nonclustered indexes on the table,
since nonclustered indexes do not force a sort on the table. In a nonclustered index, the leaf nodes
contain pointers that reference the actual datapages.
To create a monclustered index, simply replace “clustered” keyword:

CREATE NONCLUSTERED INDEX index_name
ON dbo.TableName(ColumnName);
Creating a Covering Index

A covering index is an index whose values (columns) contain all the information a query requires. This is
useful because access to the data pages of the actual table is not required in this situation (since all the
data is already loaded in the index). Additionally, multiple nonclustered indexes can be used together
for any single query.
It is important to balance the number of indexes with the amount of index maintenance. It is important
to understand that for every write to a table requires one write to the index, which could quickly get out
of hand if the table has many indexes.
In general, indexes improve query performance but degrade performance on all data-manipulation
operations.
Included Columns: In SQL Server 2005, columns become part of the index at the leaf level only (values
do not appear at the root/intermediate levels). This helps save space by not consuming any of the 900-
byte limit for an index.
Working with T-SQL

This tutorial will cover some basic concepts required for the 70-431 exam. It is assumed you have a
general understanding of T-SQL and query constructs before reading this tutorial; a good book to use for
this is Beginning SQL Server Programming.
General Query Considerations

 Ensure queries use only the required tables; avoid creating “do-everything” queries and views.
 When joining tables together, you usually perform either INNER JOINS or OUTER JOINS.
o INNER JOINS only return values where there are matches in both tables
o OUTER JOINS return values from both tables and insert null values where there is no
match.
 Return only the columns that are necessary to satisfy the query. By limiting the columns
returned, you reduce network bandwidth consumption and increase your chances of utilizing a
“covering index”.
 Avoid using SELECT * when possible, and instead explicitly state the columns you desire.
Queries that Use Complex Criteria

When handling business logic in a query, you can utilize a T-SQL feature known as case expression, which
uses conditional logic in a T-SQL statement.
SELECT Column1, Column2

CASE FlagValue
WHEN 1 THEN [Expression]
ELSE [Expression2]
END AS ColumnName
FROM Schema.Table
Creating Queries with Aggregate Functions

Aggregate functions can be used to produce a variety of information, including sums, max/min values,
averages, etc. These functions operate on groups of rows rather than individual rows, and produces a
single row of output. If aggregated data is to be returned along with non-aggregated data, you must use
the GROUP BY clause.
SELECT Column1, AVG(Column2)

FROM Table
GROUP BY Column1
Creating Queries using PIVOT/UNPIVOT

PIVOT is used to present grouped rows for one column to become columns themselves. For example, an
average might be taken for two separate columns, which in turn is presented as two separate rows. If
you create a PIVOT on those rows, they would be presented as a single row, but two separate columns.
Follow these steps to use a PIVOT operation:
1. Select the data by using a derived table subquery.

2. Apply the PIVOT operator and specify an aggregate function to use.
3. Define which columns will be included in the output.
Creating Queries using Full-Text Search

An efficient way to perform searches against VARCHAR/NVARCHAR columns is to use full-text searches.
This feature must be enabled on the tables you want to query against.
CONTAINS searches for exact word matches and word-prefix matches.

FREETEXT searches in a “less exact” method to get more results (uses fuzzy match)
The following will return any matches that contain the exact word “Help”:
SELECT *
FROM Person.Address
WHERE CONTAINS (AddressLine1, ‘Help’)
The following will return any matches that contain the word “Help”, and the * denotes that Help can be
a prefix to another word (such as “Helpme”):
SELECT *
FROM Person.Address
WHERE CONTAINS (AddressLine1, ‘”Help*”’)
Note that quotation marks are needed to specify a prefix.
The following will return any matches that contain the word “Help” in any context (beginning or end of a
word):
SELECT *
FROM Person.Address
WHERE FREETEXT (AddressLine1, ‘Help’)
You can also use table-valued versions of CONTAINS and FREETEXT, which include a RANK column that
lists matches by order of relevance (higher values = more relevant):
CONTAINSTABLE and FREETEXTTABLE
Limiting Returned Results

To evaluate only a random subset of returned values, use the TABLESAMPLE command:
This command returns a random subset of datapages equaling the percentage you specify:
SELECT *
FROM TABLE
TABLESAMPLE (20 PERCENT)
Formatting Result Sets

It isn’t enough to simply query data; oftentimes you must also format the data so that it is meaningful to
the users interested in the data. Several options for data formatting includes user-defined functions,
system functions, and creating column aliases.
Some of the most commonly used system functions include:

CAST/CONVERT – Convert between data types (example: between datetime and string)
DAY/MONTH/YEAR/DATENAME – Returns the numeric value of the day, month, etc.
REPLACE – Replaces occurrences of a substring with another string
STUFF – Insert strings inside of other strings at the specified position
SUBSTRING/LEFT/RIGHT – Returns a portion of a string starting at a specified position
LTRIM/RTRIM – Removes any extra whitespace from the left/right of a string
STR – Converts numeric datatypes into strings
Note: When using a user-defined function (UDF), UDFs must be scoped by the name of the schema the
UDF belongs to. Example: dbo.functionName(parameters)
To query CLR User-defined types (UDTs), you can use the ToString method to return the values as a
string. Example: SELECT ContactNumber.ToString() FROM ContactInfo
Creating Column Aliases

By default, the output of a query will display a set of columns with their actual names. These names are
not always user-friendly, or may not exist if you combine values from multiple columns. To give the out
column a different name, specify the AS keyword after the column name.
Example: SELECT FirstName + ' ' + LastName AS EmpName

Implementing Views
A view is nothing more than a SELECT statement that is assigned a name and is stored as an object in
SQL Server. Views act as virtual tables and provide several benefits: they give developers a standard way
to execute queries, they provide an additional level of security, and they provide for performance
improvements for certain types of queries.
In general, you should only create views when there is a clear advantage of having one. By creating
unnecessary views, you simply take up space and administrative time managing the views.
To Create a View
CREATE VIEW ViewName

WITH <viewAttribute>
AS SELECT [Statement]
There are three different options you can specify in the WITH clause:
1. ENCRYPTION specifies that SQL Server encrypt the definition of the view (not visible to anyone,
so keep the original source somewhere for later reference).
2. SCHEMABINDING prevents you from dropping any tables, views, or functions referenced by the
view without first dropping the view.
3. VIEW_METADATA returns metadata about a view to client-side data access libraries.
After a view is created, it can be used like any other table in a database. Keep in mind that a view does
not have any data in it (the query optimizer substitutes the reference with the definition of the view).
Ownership Chains
Since views can reference various objects, there is always a potential for permission conflicts. 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.
Suppose Mary grants permission on the view July2003 to Alex.

The first 3 views in the chain are owned by Mary, so Alex would
have no problem accessing those views. However, AcctAgeXZ
has an owner other than Mary, so AcctAgeXZ must have
permissions that allow Alex to view the necessary information.
Modifying Data Through Views

A view that allows you to make modifications to underlying data is referred to as an updateable view. In
updateable views, you can only modify data to a single table. Additionally, you cannot modify columns
that are derived through an aggregate function (AVG, COUNT, SUM, MIN, MAX). The view can also not
contain a GROUP BY, HAVING, or DISTINCT clause.
To restrict the changes that can be made via a view, use the WITH CHECK OPTION. This allows only
changes to data that are visible through the view. For example, suppose we have a table that allows any
value for a column called Salary, but the view only contains Salary equal to or greater than $40,000. A
new employee could be added with a salary of $35,000, but the view would not show that new
information. By using the WITH CHECK OPTION, that insert would not be allowed via a view.
Creating an Indexed View

An indexed view (also known as a materialized view), cause SQL Server to execute the SELECT statement
and then build a clustered index on the view’s results. This data is then stored within the database, and
as any changes are made to the tables, SQL Server propagates these changes to the view.
Restrictions to Indexed Views include:

1. SELECT statement cannot reference other views.
2. MUST use the WITH SCHEMA_BINDING option.
3. The first index on a view must be a UNIQUE CLUSTERED INDEX.
4. AVG, MIN, MAX, STDEV are not allowed.
5. All functions must be deterministic (example: getdate() not allowed).
6. The user that executes the CREATE INDEX statement must be the view owner.
7. The view cannot include text, ntext, or image columns.
8. The NUMERIC_ROUNDABORT option must be set to OFF. This is the default setting.
9. The following SET options must be set to ON when the CREATE INDEX statement is executed:
 ANSI_NULLS
 ANSI_PADDING
 ANSI_WARNINGS
 CONCAT_NULL_YIELDS_NULL
 QUOTED_IDENTIFIER
Unlike typical views, indexed views are directly used by the query optimizer (data is returned directly
from the view, rather than substituted).
Managing Views in SSMS
To see all of the views in a specific database: Expand the Database | Expand the Views Folder
To create a new view, Right-click the

Views Folder and select New View…
After selecting New View…, the query

designer appears as a new tab and you
are able to select the tables/columns
you want to include in your view.
Working with XML Structures

XML has several benefits when storing data:
 XML is self-defined, so applications don’t need to know the structure of the data.
 XML is stored hierarchically as a tree structure, which allows easy navigation/searching through
the data.
 XML is extensible; you can manipulate XML data by inserting, updating, or deleting nodes.
 Schema declaration provides data type information and structure validation.
XML Documents are XML structures that have a root, or parent, node.
XML Fragments are XML structures that don’t have a root, or parent, node.
There are three types of XML data representation:

1. Structured Data: All instances of the data follow the same structure.
2. Semistructured Data: Heterogeneous data structure where instances can look different, but
actually follow the same schema.
3. Unstructured Data: Data that does not conform to a schema.
Additionally, SQL Server can store XML data in two ways: as XML in a text column, and as an XML data
type column (new to SQL Server 2005).
Storing XML in Text Columns

XML data can be stored in (n)char, (n)varchar, or varbinary data type columns. These columns allocate a
maximum storage size of 2 GB. To specify this max size, use the MAX argument.
DECLARE @myXML AS nvarchar(max)

SET @myXML = ‘[XML value]’
Pros Cons/Limitations
Details such as comments and white space are Coding complexity + higher maintenance cost
preserved.
Reduces processing workload (processing of Manipulation, extraction, modification at the
XML occurs on a middle tier) node level is not possible
Best performance for document-level Searching XML data always requires reading
insertion/retrieval. the entire document (interpreted as text)
Does not depend on database capabilities XML validation, well-formedness, and type
checking must be performed at a middle tier
Storing XML in XML Data Type Columns

XML data can now be stored in its own XML datatype:
CREATE TABLE TestTable(firstColumn int, description XML)
VALUES (1, ‘[XML Value]’)
Pros Cons/Limitations
Same query processor/optimizer are used for Whitespace, comments, and other nondata
XML queries elements are not retained
Data stored/manipulated natively as XML Max storage is 2 GB
Document order/structure preserved Max allowed node depth is 128 levels
Performance improves for data-retrieval
Typing and Validating XML Data with XML Schemas

XML schemas define the structure and constrains the contents of XML documents. Schemas are
declared at the database level, and provide metadata that defines and constrains XML data types.
Generally, schemas are loaded using the OPENROWSET function:
DECLARE @schema XML

SELECT @schema = c FROM OPENROWSET (
BULK ‘SchemaName.xsd’, SINGLE_BLOB) AS TEMP(c)
CREATE XML SCHEMA COLLECTION MySchema AS @schema
Or, you can manually enter the schema using:

CREATE XML SCHEMA COLLECTION MySchema AS ‘Schema Definition’
Retrieving XML Data

To compose relational data into an XML representation, you use the FOR XML clause. There are several
options you can choose from:
 FOR XML RAW
 FOR XML AUTO
 FOR XML PATH
 FOR XML EXPLICIT
FOR XML RAW

A new XML element is created for each row found in the result set; an attribute is added to the row
element for each column in the SELECT statement (column name is the attribute name). You can make
the formatting be “element-centric” by adding the ELEMENT statement:
SELECT Column1, Column2, Column3
FROM Table1
FOR XML RAW(‘XMLFragmentName’), ELEMENTS
This would return (once for EVERY row in the result set):
<XMLFragmentName>
<Column1>Value</Column1>
</XMLFragmentName>
FOR XML AUTO

This creates nested XML structures; for every table specified, a new level exists in the XML structure.
The order for nesting is based on the column order declared in the SELECT statement. As in FOR XML
RAW, you can add the ELEMENT keyword to make the format element-centric.
SELECT Table1.Column1, Table2.Column2, Table2.Column3, Table1.Column4

FROM Table1, Table2
FOR XML AUTO, ELEMENTS
This would return:

<Table1>
<Column4Value</Column4
<Table2>
<Column2Value</Column2
<Column3alue</Column3
</Table2>
</Table1>
Note that elements are ordered based on the table, NOT the columns (Column4 is listed last in the
SELECT statement, but comes before Column2/3 in the XML result format).
FOR XML PATH

You can use some columns as elements and others as attributes with FOR XML PATH. Each column is
given an alias, and if no alias is given, it uses the default <row> value. Column aliases are declared via
various options:
‘elementName’, ‘@attributeName’, ‘elementName/nestedElement’, ‘elementName/@attributeName’,
text(), comment(), node(), and data().
SELECT Column1 ‘@StartDate’,

Column2 ‘Number/@text’,
Column3 ‘comment()’,
FROM Table1
FOR XML PATH (‘ForEachRow’)
This would return:

<ForEachRow StartDate= “Value”>
<Number text= “value” />

</ForEachRow>
Note that since “@StartDate” does not specify where to locate the attribute, it is added to the context
node <ForEachRow>.
Adding a Root Node

The examples above are all XML fragments, since they do not contain a root node. To represent an XML
document, you can declare the ROOT keyword in the FOR XML clause.
FOR XML RAW(‘NodeName’), ELEMENTS, ROOT(‘RootName’)
Supporting NULL Values in XML

By default, any NULL value is ignored in XML. If using element-centric formatting, you can specify to
capture NULL values using XSINIL:
FOR XML RAW, ELEMENTS, XSINIL
Returning XML as an XML Data Type Instance

By default, the FOR XML clause returns the resulting data as text. To return it as an XML data type, use
the TYPE keyword:
FOR XML RAW, ELEMENTS, XSINIL, TYPE
FOR XML EXPLICIT

In order for XML EXPLICIT to work, the query result set must follow a Universal Table. A Universal Table
requires specific columns, and column aliases must be formatted using a specific pattern. Additionally,
specific ordering of rows must be specified for the result set.
XML EXPLICIT Result Set Requirements Include:

Tag, Parent, ElementName!TagNumber!AttributeName!Directive
Tag must be the first column in the result set, and indicates the depth in the XML structure (starting at
1).
Parent must be the second column in the result set, indicates the node parent in the XMl structure.
ElementName is the name assigned to the XML element

TagNumber indicates the level the node must be located at.
AtrributeName indicates the name to provide to the XML attribute
Directive provides more information to the XML formatting and is optional:

hide specifies to not include the column in the result set
element generates the column as an XML element
elementsxsinil generates the column as an XML element and includes NULLs
cdata generates the column value as an XML comment
SELECT 1 as Tag,
NULL as Parent,
Column1 as [EName!1!AName1],
Column2 as [EName!1!AName2]
NULL as [EName!1!AName3]
FROM Table1
UNION ALL
SELECT 2 as Tag,
1 as Parent, Column3
FROM Table2
FOR XML EXPLICIT, ROOT(‘RootName’)
Returns (for each “EName”):

<RootName>
<EName AName1 = “Value” AName2 = “Value” />
<AName3 = “Value” />
<AName3 = “Value2” />
<AName4 = “Value3” />
</EName
</RootName>
If the FOR XML EXPLICIT is not specified, the Universal Table Structure is returned instead.
XML Methods
The XML data type has several methods used for querying data, extraction, modification, and shredding
into relational data. The methods are:
1. query () – Executes a query over XML and returns untyped XML result
2. value () – Extracts a value of SQL type from an XML instance
3. exist () – Determines whether a query returns a result
4. modify () – Used in updating/alter the content of an XML document
5. nodes () – Helps shred XML into relational data.
It is important to note that XML methods are considered subqueries and can not be used in the PRINT
statement or within a GROUP BY clause.
The query () Method

Using this method allows you to return portions of XML by supplying the method the path through the
XML that is desired.
SELECT XMLColumnName.query(‘/RootName/ElementName’) FROM Table
Returns:
<ElementName>Value1</ElementName>
<ElementName>Value2</ElementName>
The value () Method

This is similar to the query () method, except that it returns a SQL data type instead of an XML data type.
This method is used to extract values from XML data; individual attributes can be extracted by using the
@ sign in front of the attribute name.
SELECT Column1, XMLColName.value(‘(/RootName/@AttributeName)[1]’) AS Value

FROM Table
Returns:
Column1 Value
1 Name1
2 Name2
Note that the [1] specifies the ordinal, so if there were more than 1 attribute listed for the element, only
the first one would be used ([2] would pick the seconds attribute, etc).
The exist () Method

This method is used to perform an existence check against the data (returns 0, 1, or NULL).
SELECT EmployeeID, XMLColName.exist (‘/RootName/@ElementName’) AS Found
Returns (assuming the first employee doesn’t contain the attribute):

EmployeeID Found
1 0
2 1
The modify () Method

This method is used to update an XML document. You can change the content by using an XML DML
statement (insert, replace value of, delete).
You also specify where to insert the data if using the insert statement (before, after, into as first, into as
last). This tells SQL where to make the insertion once it finds the element/attribute.
UPDATE Table
SET EmpName.modify (‘replace value of (/RootName/@LastName)[1] with
“Smith”’)
WHERE EmployeeID = ‘FE122’
The nodes () Method

This method is used to identify nodes that will be mapped into a new row of a recordset. Nodes () is
used a source of a query in the FROM clause, and be queried either directly from an XML variable or by
using a CROSS APPLY directly to the table and XML column.
SELECT EmployeeID, Table.Loc.value (‘@Name’, ‘varchar(40)’) AS Name

FROM TableName CROSS APPLY TableName.nodes(‘/Root’) AS Table(Loc)
Returns:
EmployeeID Name
1 Sue
2 Mary
3 Joe
Indexing XML Data

XML data type instances are stored in a database as large binary objects (BLOBs). These can be up to
2GB, so queries and modifications can be a performance bottleneck if indexes aren’t used.
There are two types of XML indexes: primary and secondary.
Primary indexes are the first index placed on an XML column. When using a primary index, you avoid
needing to shred the XML at runtime.
CREATE PRIMARY XML INDEX IndexName

ON Table(XMLColumn)
Secondary indexes (PATH, VALUE, or PROPERTY) can be placed once a primary index is created. You
must specify one of these directives and associate the secondary index with a primary index.
CREATE XML INDEX IndexName

ON Table(XMLColumn)
USING XML INDEX PrimaryIndexName FOR [PATH | VALUE | PROPERTY]
PATH is useful for queries that specify path expressions.
VALUE is useful for queries that search for specific values without knowing the element/attribute they
would be located in.
PROPERTY is useful in queries that retrieve more than one value from individual XML instances.
Creating Functions, Stored Procedures, and Triggers

SQL Server provides 3 main types of programmable objects, known as triggers, functions, and stored
procedures. User-defined functions, or UDFs, allow you to capture commonly used code as a function
that can be called for use in multiple programs. Stored procedures are batches of code/T-SQL that can
serve as the interface for application access to a database without needing to hardcode data access. And
finally, triggers are used to automatically execute code or some action in response to preset database
events.
Implementing Functions
Functions are included in SQL Server and provide you the ability to execute some common functionality
throughout the application. For example, the function GetDate() outputs the current data. In SQL Server
2005, you have the ability to create your own pre-defined functions (UDFs).
UDFS can be broken down into two separate categories: scalar functions and table-valued functions.
Scalar Functions accept 0 or more input parameters and return a single value (of the desired type);
table-valued functions return a result set (table data type). There are also Inline UDFs, which are simply
functions that consist of a single statement (can be either scalar of table-valued).
Benefits of using UDFs include reduction of network traffic, fast execution, modular programming
(update once and changes applied wherever the function is referenced), and UDFs can be used within
queries/select statements.
General Usage of UDFs

 Within DML statements
 As defaults on columns
 As check constraints on columns
 Parameterize a view
 Replace a stored procedure that returns a single result set
Scalar Function Syntax (Example):

CREATE FUNCTION [FunctionName] (@VariableName int)
RETURNS VarChar(100)
AS
BEGIN
[FunctionDefinition]
END
To view functions in SSMS: Expand Databases Node | Expand a database | Expand Functions node
Table-valued Function Syntax (Example):

CREATE FUNCTION [FunctionName] (@Variable int)
RETURNS Table
AS
RETURN
(
SELECT columnName
FROM tableName1
WHERE columnName1 = @Variable
)
Implementing Stored Procedures

Stored Procedures are simply stored batches of T-SQL code that are assigned a name and executed on
within SQL Server. These should serve as the primary interface that applications use to access any data
within a database. This allows you to control access to the database, as well as eliminate the need to
hard-code SQL statements within an application.
Stored Procedures can contain almost any T-SQL command that would normally be used (with the
exception of USE, SET SHOWPLAN_TEXT ON, and SET SHOWPLAN_ALL ON), and can modify data, return
scalar values, or return result sets. Additionally, user permissions can be assigned to stored procedures
without needing to grant access to the actual data. Permissions to stored procedures are limited to the
operations the stored procedure(s) are defined to perform.
Benefits of using Stored Procedures Include:

 Fast, pre-compiled and stored in the database
 Reduce network traffic
 Enhance security (assign permissions to the stored procedure and not the data)
 Modular programming saves time in administration/upkeep
 Definition of the stored procedure can be encrypted
Creating a Stored Procedure Syntax:

CREATE PROCEDURE Schema.ProcedureName
AS
<TSQL Statements, logic, & code>
To view/manage stored procedures in SSMS:

Expand the Databases Node | Database | Programmability |
Stored Procedures
Stored Procedures can be configured with three different options:
1. ENCRYPTION tells SQL Server to encrypt the content of the stored procedure.
2. RECOMPILE forces SQL Server to recompile the stored procedure every time it is executed.
3. EXECUTE AS provides a security context for the sproc (uses the permissions of an account).
To call Stored Procedures, you should always specify the EXECUTE command followed by the stored
procedure name and any necessary input parameters. The only exception to this rule is if the statement
is the first one in a batch.
Syntax to assign access to a Stored Procedure:
GRANT EXECUTE ON <stored_procedure> TO <database_principle>
Implementing Triggers
A trigger is a T-SQL or CLR batch of code that automatically runs in response to an event within the
database. The two triggering events are referred to as Data Manipulation Language (DML) and Data
Definition Language (DDL) events.
DML Triggers
DML triggers are not standalone objects, thus they cannot be executed directly. By attaching a DML
trigger to a specific table or view, you can automate certain tasks based on pre-defined events. These
events can include INSERT, UPDATE, and DELETE activity.
Triggers fire in two different modes:

1. AFTER triggers fire once SQL Server completes all actions successfully. These type of triggers can
only be configured on tables.
2. INSTEAD OF triggers causes SQL Server to execute code in the trigger rather than the
operation that caused the trigger to fire. These type of triggers can be created on tables and
views. Only one INSTEAD OF trigger can be defined for each UPDATE, INSERT, and DELETE event.
Exceptions on Triggers
 Databases can’t be created, altered, dropped, backed up, or restored in triggers
 Structural changes can’t occur on the table that caused the trigger to fire
 Triggers only fire in response to logged operations
 Triggers can’t run on system tables or DMVs
There are two tables that are associated with triggers: INSERTED and DELETED. These are viewed using
the OUTPUT clause.
INSERTED stores each row that was inserted into a table (no rows in DELETED).
DELETED stores each row that was deleted from the table (no rows in INSERTED).
During an UPDATE, INSERTED stores the “after” image, DELETED stores “before” image.
Syntax to Create a DML Trigger:
CREATE TRIGGER [TriggerName]
ON [Table | View]
WITH [Option]
{FOR | AFTER | INSTEAD OF}
[INSERT, UPDATE, or DELETE]
AS
The ON clause specifies the table or view that the trigger is created against. If the view or table is
dropped, the trigger is also dropped.
The WITH clause can specify to use ENCRYPTION or an execution context.
After the AS clause, you specify the code to be executed if the trigger is fired.
Recursive/Nested Triggers
Recursive Triggers are triggers that cause themselves to fire (the actual trigger itself sets off an action
that would fire the trigger, thus creating an infinite loop). This is disabled by default
(RECURSIVE_TRIGGERS database option is set to OFF).
Nested Triggers are triggers that cause indirect recursion. For example, an event fires a trigger, which
performs an action that cause another trigger to fire, and that trigger causes the original trigger to fire
again (and the loop continues). This is disabled via the NESTED TRIGGERS option set to 0.
DDL Triggers
The main purpose of DDL triggers are to audit and regulate actions performed on a database. For
example, when the trigger is fired, you can create a table and log the attempted action in a new table.
Syntax to Create a DDL Trigger:

CREATE TRIGGER [TriggerName]
ON [ALL SERVER | DATABASE]
WITH [Option]
{FOR | AFTER }{EventType}
AS
[SQL Statement]
EventType can be a wide range of events; to view the entire list, search for “Event Groups for Use with
DDL Triggers” in BOL. Examples of events include CREATE TABLE, ALTER TABLE, and DROP TABLE.
To create a new trigger in SSMS:

Expand down to the Table Node | Expand a table | Right-click Triggers and select New Trigger…
Once you select New Trigger…, a template appears and you

can swap out placeholder values with actual information. To
do so, select Query | Specify Values for Template Parameters
Working with Flat Files

A flat file is a non-hierarchical file that contains data meant for a single table in a database. Flat files are
useful because the format between the source and destination can easily be defined.
Source File Location: The source of the data is important since it is a major factor in the
speed/complexity of a data import. It is important to remember that the process is only as fast as the
slowest component involved.
Import Mechanism: Mechanisms include bcp, BULK INSERT, OPENROWSET, or SSIS. Each has their own
strengths/weaknesses.
Data Destination: Includes which database server, the database, and the data structure. What level of
uptime is needed? Which recovery model is being used? Does the table have clustered/non-clustered
indexes, constraints, or triggers? Is the table a source for replication?
Ensuring Minimal Logging

 Database recovery model is set to Bulk-Logged
 Table is not set for replication.
 TABLOCK hint is used.
 Destination table meets population/indexing requirements.
Running the bcp Utiliity

BCP, or bulk copy program, is a program that is launched from the command line and is an external
program from SQL Server. BCP can be used to either import into or export out of SQL Server.
Two limitations of BCP

1. bcp has limited data-transformation capabilities; if you need the data to go through complex
transforms/validations, do not use bcp.
2. bcp has limited error handling capabilities. You can either set bcp to either error out of the load,
or to log the row and error and then error out. bcp can not natively recover and retry a failed
load.
General Syntax
bcp databaseName..tableName in “FlatFileDirectoryLocation” -T
-T specifies that the import uses a trusted connection (use the permission of the Microsoft user
executing the command)
bcp Hint Parameter

Using the “-h” parameter can have a big impact of performance and logging overhead.
TABLOCK hint = bcp performs a table lock and allows the bulk-logged recovery model to use minimal
logging.
ORDER hint = specify the records in the data file to be ordered by certain columns (useful only if the sort
matches the destination’s clustered index)
Note: Minimal security permissions required are SELECT/INSERT. To suspend constraint checking, trigger
execution, etc, requires ALTER DATABASE.
BULK INSERT
BULK INSERT is the T-SQL “equivalent” to the bcp utility. BULK INSERT runs inside the SQL Server process
space and is executed from a query window/query batch. All of the caveats are the same, and BULK
INSERT uses almost all the same parameters (but is less cryptic).
Parameters
FIELDTERMINATOR – specifies the column delimiter (equivalent to –t)
ROWTERMINATOR – specifies the row delimiter (equivalent to –r)
FIRSTROW – specifies the first row in the flat file that will be inserted into the table (equivalent to –F)
Note: Minimal security permissions required are INSERT and ADMINISTER BULK OPERATION permission.
To suspend constraint checking, trigger execution, etc, requires ALTER TABLE permissions.
Integrated Logins use privileges of the user account.

Mixed Mode uses SQL Server service account if the SQL Server login does not map to a Windows
account.
Importing Bulk XML Data

Using the OPENROWSET function, you can import data from a file and make it appear as if it were a
table (without having to load the data into a table first).
INSERT INTO Documents (XmlCol)

SELECT * FROM OPENROWSET(
BULK ‘C:\Location\xml.txt’,
SINGLE_BLOB) AS x
This bulk imports the contents of ‘C\Location\xml.txt’ file as a single_blob and inserts the blob into the
XmlCol of a single row in the documents table.
Using the SSIS Import/Export Wizard

Extraction, Transformation, and Loading (ETL) tool that provides, among many other things, the ability
to import and export data.
To start in SSMS:
Expand the Databases Node | Tasks | Import Data/Export Data
You can also start SSIS Import/Export Wizard

through BIDS or DTSWizard.exe (located in
C:\Program Files\Microsoft SQL
Server\90\DTS\Binn).
On this welcome screen for the

Import and Export Wizard,
select Next.
This screen allows you to choose the datasource, server name, and method of authentication to use for
the source of the import/export.
The following screen specifies the destination of the import/export.

Next, you specify which tables and views are used for the import/export. This can be done by copying all
the data from the tables/views, or writing a query to specify and restrict only certain information.
The next screen (not shown) allows you to Save the package as well as immediately execute it. By saving
the package, you can use it as a base for other packages, use it to document data, and reuse.
Backing Up and Restoring Databases

Having a duplicate copy of data that can be recovered is vital, and SQL Server allows a variety of options
in doing so. Components of a backup include the backup type, backup schedule, initialization of a media
set, creation of a backup device, and backup permissions.
Permissions
Using the principle of least privilege, the SQL Service account requires read/write permissions for any
directories/devices involved in the backup/restore process. Additionally, a user requires the
db_backupoperator role to backup a database, log, or checkpoint (no other access is required).
Backup Types
There are four main backup types:
1. Full Backups
2. Differential Backups
3. Transaction Log Backups
4. Filegroup Backups
Additionally, you can perform Mirrored Backups and Partial Backups (explained later).
Full Backups
These capture all of the data stored in the database. This can be used by itself to restore the entire
database up until the point that the full backup is completed. The internal process involved in a full
backup includes:
1. Lock the database, blocking all transactions.

2. Place a mark in the transaction log (at the end).
3. Release the lock on the database.
4. Backup all pages.
5. Lock database again, again blocking transactions.
6. Place a mark in the transaction log (at the end).
7. Release the lock on the database.
8. Extract all transactions between the two log marks and add it to the backup.
This process ensures that transactions aren’t left out during the backup process (which prevents data
inconsistency).
BACKUP DATABASE [DatabaseName] TO DISK = ‘[DirectoryOrDeviceName]’

WITH INIT
Differential Backups
These capture all of the changes to the database since the last full backup. Differential backups are used
in conjunction with full backups; if a full backup does not exist, you can not perform a differential
backup.
BACKUP DATABASE [DatabaseName] TO DISK = ‘[DirectoryOrDeviceName]’

WITH DIFFERENTIAL
Transaction Log Backups

Transaction log backups are allowed only after a full backup has been performed, and does not work
with the simple recovery model. This backup type backups the active log, and acts independently of
differential backups.
BACKUP LOG [DatabaseName] TO DISK = ‘[DirectoryOrDeviceName]’ WITH INIT
Filegroup Backups
Rather than backing up entire databases, you can backup a database over time by filegroup. This is
especially useful for very large databases that otherwise could not be backed up over the course of a
single night/maintenance window.
Filegroup backups do not work with the simple recovery model. Also, you can perform full or differential
backups against filegroups.
Full:
BACKUP DATABASE [DatabaseName] FILEGROUP = ‘FilegroupName’ TO DISK =
‘[DirectoryOrDeviceName]’
Differential:
BACKUP DATABASE [DatabaseName] FILEGROUP = ‘FilegroupName’ TO DISK =
‘[DirectoryOrDeviceName]’ WITH DIFFERENTIAL
Mirrored Backups
To specify additional locations to backup the database (mirror the copies), use the following syntax:
MIRROR TO [BackupDevice]
WITH FORMAT
You can do this with up to 3 mirrored locations (or 4 locations total). The WITH FORMAT is required
when performing a Mirror backup, which writes a new media header to each media set and overwrites
any previous header.
Partial Backups
To perform a backup that skips and read-only filegroups, use the following T-SQL:
BACKUP DATABASE [DBName] READ_WRITE_FILEGROUPS
TO DISK= 'Location\File.bak'
Backing Up Data in SSMS

To Initiate a Backup in SSMS: Right-click a database | Tasks | Back Up…
Select a Backup type as Full,

Differential, or Log. You can also
specify to backup the Database
or just a subset of particular
filegroups.
Backup set will expire specifies

when the backup will be marked
as expired (either after a certain
period of time or at a preset
date).
Destination specifies a backup device. To create a Backup device, refer to the instructions on the next
page.
Creating a Backup Device

In Object Explorer:
Expand the Server Objects Node | right-click Backup Devices | New Backup Device
Assign the device a name, and specify whether it is a tape drive or a file. Tape will be grayed out if there
are none present.
Going back to the backup dialog box, select “Add” in the Destination section to specify the backup
device to use for the current backup:
There are also a good number of options that you can choose while creating the backup:
Options include the ability to append to a media set or overwrite a media set; verify a backup when it is
complete; and unload/rewind a tape after backup is complete.
Note: validation can also be done via T-SQL
Validating a Backup
SQL Server 2005 provides the ability to check the status of a backup file. This should be done periodically
to ensure that the backup files are created correctly.
RESTORE VERIFYONLY FROM [BackupDevice]
Restoring a Database
Full/Differential:
RESTORE DATABASE [DatabaseName] FROM DISK = '[Location]'
WITH REPLACE, NO RECOVERY
REPLACE indicates that you want to overwrite the existing database.

STANDBY specifies the database to be in a restoring state where writes are not allowed, but users can
issue SELECT statements.
WITH RECOVERY = Database accepts transactions
WITH NO RECOVERY = Databases remains in restoring state, marks database as needing additional
restores before it is available
Log Restoration:
RESTORE LOG [LogName] FROM DISK = '[Location]' WITH RECOVERY
When restoring filegroups, you do not need to specify which filegroup is involved in the restore (SQL
Server does this automatically).
Partial Restore: Ability to partially restore a database while the rest of the database is open for
requests. It is NOT possible to partially restore to a certain point in time (must be the most current
data).
Restoring a Corrupt Page

If corruption occurs on an index page, simply drop and recreate the index.
If corruption occurs on a data page, must either restore a backup or use the new feature PAGE_VERIFY
CHECKSUM.
ALTER DATABASE [DatabaseName] SET PAGE_VERIFY CHECKSUM

This is off by default since there is a small amount of overhead for reads/writes. This tells SQL Server to
calculate a checksum for the page on every read/write and verifies that the page is not corrupt. If a page
is found to be corrupt, the transaction is rolled back and logged in msdb.
To Restore a Specific Page:

RESTORE DATABASE [DatabaseName] PAGE = '[PageNumber]'
FROM DISK = '[Location]' WITH RECOVERY
Media Errors
If restoring from damaged backup media, you can specify to skip any damaged sectors and continue
with the restore process. This places the database in an emergency state, but allows you to issue SELECT
statements and verify the integrity of the database. You can then change to state of the database if
deemed intact and operational.
Use the clause

WITH CONTINUE_AFTER_ERROR
To Restore a Database:
Right-Click the database | Tasks | Restore | Database
Specify the database you will be restoring, the source of the restore, and the backup sets to restore (the
example uses the full backup performed earlier in this demo).
One point of interest is the Recovery state; this is where you specify what mode the database is in after
the restore (WITH RECOVERY, WITH NO RECOVERY, or WITH STANDBY).
Moving Databases
To move or copy a database, you have the option of detaching/attaching an existing database from one
location to another (on the same or different server). Once a database is detached, it is no longer
accessible from SQL Server, but no loss of data occurs.
The process of moving a database involves detaching an existing database, copying or moving the
datafiles to a new location, and then reattaching the database to point to the new location.
From SSMS:
Right-click database | Tasks | Detach
You can now choose to drop all current connections, as well as Update Statistics. Click “OK”.
At this point, you would navigate to the directory that held the datafiles and then move/copy them to
the location you want the database to be stored in.
Then, in SSMS:
Right-click Databases | Attached
On the window that appears, select “Add” and then navigate to the new directory location. Select the
.mdf file and click “OK”:
All of the file types and locations are listed now. Select “OK” to begin attaching the database.
You can also perform these tasks using T-SQL:
1. Detach the Database:

EXEC sp_detach_db ‘DatabaseName’, ‘true’
2. Then, move the datafiles to the new location.
3. Attach the Database:

CREATE DATABASE ‘DatabaseName’ ON
(FILENAME = ‘MDFLocation’),
(FILENAME = ‘LDFLocation’),
FOR ATTACH
Using Transact-SQL to Manage Databases

Common maintenance tasks include managing fragmentation and statistics, shrinking databases, and
performing integrity checks using T-SQL.
Index Fragmentation: Indexes lose their effectiveness over time due to fragmentation caused by
insertions/deletions of data in the index. The query optimizer may select indexes that have become
fragmented, which would decrease the query’s performance and defeat the purpose of using the
optimizer.
Internal Fragmentation is when pages are not as full as they could be (due to DELETE statements). This
decreases disk space efficiency and requires more pages for the same number of index rows.
Page Splits occur when SQL Server needs to place additional rows of data on an index page. The data is
logically ordered here, but not necessarily physically ordered. This is what is known as external
fragmentation.
External Fragmentation is always undesirable, whereas some level of internal fragmentation is desirable
for highly transactional databases.
To detect index fragmentation, utilize the sys.dm_db_index_physical_stats DMF. When the value is >
10, you have external fragmentation. In the avg_page_space_used column, if the value is < 75 you have
internal fragmentation.
You can either reorganize or rebuild your indexes. Reorganizing an index rearranges the physical leaf-
level pages to match the logical order of the leaf nodes. Rebuilding an index involves dropping the index
and then creating a new one.
ALTER INDEX [IndexName] ON {Table.Column}

REORGANIZE;
ALTER INDEX [IndexName] ON {Table.Column}

REBUILD;
Rebuilding an index also allows you to use the ONLINE option to make the table and associated indexes
available during the rebuild. Additionally, you can use the ALL option to rebuild all indexes on a table be
rebuilt with a single command.
 REORGANIZE if avg_page_space_used_in percent < 75 and >60

 REORGANIZE if avg_fragmentation_in_percent > 10 and < 15
 REBUILD if avg_page_space_used_in_percent < 60

 REBUILD if avg_fragmentation_in_percent > 15
Managing Statistics
Statistical information is generated by SQL Server regarding the distribution of values in a column. This
statistical data is used by the query optimizer to determine whether using an index would improve
query performance. The optimal query plan could be inaccurate if the statistics aren’t current.
AUTO_UPDATE_STATISTICS option set to ON automatically updates statistical information (typically

when 20% of the data rows of an index have changed).
Manually creating statistics can be done using the following T-SQL command:
CREATE STATISTICS st_Name

ON DB.Table (Column)
WITH FULLSCAN;
You can also replace “CREATE” with UPDATE or DROP to perform the appropriate action.
Viewing Column Statistics Information

 sp_autostats stored procedure displays the AUTOMATIC_UPDATE_STATISTICS setting for an
index and statistics
 sys.stats view displays a row for each statistic
 sys.stats_columns view displays a row for each column that is part of sys.stats
 STATS_DATE function displays the date the statistics for an index were last updated.
 DBCC SHOW_STATISTICS statement displays the current distribution statistics for a target on a
table.
Shrinking Files
Certain operations in SQL Server such as large deletions or data loads might leave database files larger
than they typically need to be. A DBA can shrink files to remove any unused pages, and in turn regain
disk space.
Shrinking Database Files Automatically

Set the database option DATABASE AUTO_SHRINK ON to allow the database engine to periodically
examine the database’s space usage and reduce the size accordingly. This is set to OFF by default since
the shrinking process consumes system resources.
You can also configure this option via SSMS:

Right-click a database | Properties | Select the Options Page | Change Auto Shrink to True
Shrinking Database Files Manually

My controlling when the shrink is performed, you greatly reduce the chance of consuming essential
system resources.
DBCC SHRINKDATABASE (DatabaseName, <target_percent>)

DBCC SHRINKFILE (FileName, <sizeToShrinkinMB>)
When shrinking the transaction log, the size of the virtual log files contained within the transaction log
determine the reduction in size that is possible. In other words, you can’t shrink the transaction log to a
size smaller than the virtual log file.
To shrink databases/files via SSMS:

Right-click a database | Tasks | Shrink | Select Database or Files
If you select Database, you see the

following (left). The Shrink Database dialog
box displays the currently allocated space,
and the available free space. Additionally,
you can specify the Maximum free space in
files after the shrinking.
You can also shrink files via SSMS

(screenshot not shown).
Using DBCC CHECKDB

The DBCC CHECKDB command performs a variety of checks on the database to verify the allocation,
structural integrity, and logical integrity of all objects within the database.
DBCC CHECKDB (‘DatabaseName’) WITH ALL_ERRORMSGS;
Actions performed in DBCC CHECKDB include:
 DBCC CHECKALLOC: checks the allocation of all pages in a database.

 DBCC CHECKTABLE: checks the integrity of all the pages and structures that make up the table
or indexed view.
 DBCC CHECKCATALOG: performs consistency checks between system metadata tables.
 Validates Service Broker data
 Validates contents of every indexed view
DBCC CHECKDB Best Practices:
 Use the PHYSICAL_ONLY option for frequent checks on production systems

 Full integrity checks should be issued periodically so you don’t limit the check (DBCC CHECKDB
with no options specified)
 Use repair options to specify that DBCC CHECKDB should repair an issue if one is found
o REPAIR_ALLOW_DATA_LOSS
o REPAIR_FAST (for backwards compatibility)

o REPAIR_REBUILD
Note: Only use the repair options as a last resort; the recommended action to take is to perform a
restore from backup to correct any errors. Repair operations do not take into consideration any
constraints that are placed on the data.
Automating Tasks with SQL Server Agent

Overview of SQL Server Agent
Jobs: Series of actions that contain steps/actions to be performed within SQL Server (T-SQL command,
OS command, vbscript, etc). Ability exists to run jobs locally or on multiple remote servers.
Schedules: Individual objects that lay out when a job runs. In SQL Server 2005, you can create a single
schedule and then apply it to multiple (different) jobs, rather than creating a separate schedule for each
job.
Alerts: Automatic response to an event (SQL Server error, performance conditions, WMI events). Once
alerts are fired, messages can be sent to operators and/or a job can run.
Operators: A specified contact, which is used for notification within SQL Server, database mail, etc.
Configuring SQL Server Agent

The first step in configuring jobs, schedules, and alerts is to ensure that the SQL Server Agent process is
running. For local machines, you can do this by opening SQL Server Configuration Manager and setting
the start mode of the SQL Server Agent process to automatic:
If the machine you are configuring is a remote machine,

you can do the same through the services applet in
Administrative tools (not shown).
The next step is configuring SQL Server Agent itself. To
view a list of configurable options, in SSMS:
Right-click SQL Server Agent | Properties
General options include configuring SQL Server to restart if it stops unexpectedly, to restart SQL Server
Agent if it stops unexpectedly, the directory which the error log is stored, and which user to send a “net
send” message if an error occurs.
Advanced allows you to configure the

server to forward events to a “master”
server so that events can be centrally
managed.
“Idle CPU Condition” specifies that you
should only run jobs if the CPU
utilization is below a certain threshold.
*Note: Refer to the Database Mail tutorial for setting up Database Mail.
Once SQL Server Agent and Database Mail are enabled/configured, the next logical step is to create and
configure Operators. Operators will receive notifications if alerts are triggered.
To setup operators in SSMS:

Expand SQL Server Agent | Right-click Operators | New Operator…
Assign a name for the operator, specify the email address, the net send address (send a message across
the network to the specified machine and relies on the messenger service), pager email name, and the
pager schedule.
The Notifications screen simply

allows you to configure which
alerts the operator will receive.
Creating Alerts
To create an alert, in SSMS:
Expand SQL Server Agent | Right-click Alerts | New Alert…
Give the alert a name, assign it a type (SQL Server event alert, performance alert, WMI event), assign it a
severity level, etc.
On the Response page, you configure

what job you want to run if the alert
occurs. You can create the job from this
menu if you choose.
The Notify Operators checkbox allows you to specify which operator(s) to send a message to if this alert
is triggered. Creation/viewing of operators is also available from this menu.
On the Options page, you can elect to send the alert error text within the email, pager, and/or net send
message. You can also add additional text if you choose.
Delay between response

allows you to set an interval
between the different types
of alerts.
Creating Jobs
Jobs are the actual tasks that are performed within SQL Server Agent. To create a new job, in SSMS:
In the General page, you specify the name of the job, who the owner of the job is, the category (to easily
organize jobs; this is especially useful if you manage a large number of jobs), and a brief description of
what the job does. The Enabled
checkbox provides an easy way to
enable/disable jobs.
The next page is contains the Steps,

which are the actions that are
performed within a job. To create a
new step, click New…
Here you can assign the step a name, the type of step (many options including vbscripts, OS commands,
replication commands, etc), which database to run the step in, and then the specific command
(generally T-SQL). Click on Parse to check the syntax of the Command.
On the Advanced page, you can

configure which action to take on
the success of the action, specify
how many retry attempts the job
attempts, the action to take on a
failure, where to store the errors
(file or table), and which user to
run the job as.
Configuring a Job Schedule

In SSMS, expand SQL Server Agent | Expand Jobs | Right-click the Job | Properties | Schedules page
Click New… to create the schedule.

You can also select an existing
schedule and edit an existing schedule
Enter a name for the schedule,

the schedule type (recurring,
one time, when SQL Server
Agent starts, or when CPU is
idle), the frequency, duration,
etc.
In the Notifications page, you can specify which type of message is to be sent once the job completes.
The options are as listed below:
Monitoring and Troubleshooting SQL Server Performance

There are various tools that can help in monitoring performance, both proactively and reactively, in SQL
Server 2005. These tools include SQL Server Profiler, Windows Systems Monitor, the Database Engine
Tuning Advisor (DTA), and SQL Server 2005 Dynamic Management Views (DMVs) and Functions (DMFs).
Using SQL Server Profiler

This profiling tool can trace database activity to identify performance problems and bottlenecks. This
tool captures only SQL Server events, and does not trace possible network issues or operating system
conditions.
To Launch SQL Server Profiler:

Start Menu | Programs | SQL Server 2005 | SQL Server Performance Tools | File  New Trace
-Or in SSMS-
Tools | SQL Server Profiler
The next screen is the Trace Definition dialog box:
This dialog allows you to specify the name of the trace, which template to use, have the results saved to
a file or to a table, and a specific time to stop the trace. When saving to a file, you can adjust the
maximum size of the trace so that they are manageable sizes. This uses file rollover, where once one
trace file meets the max size, a new file is created.
If you click the Events Selection tab, you see the following:
This screen allows you to modify and fine-tune exactly what it is you will be performing a trace against.
The screenshot above is the default settings while using the Tuning template.
To create a filter, click the Column Filters button. Simply select the column you want to filter on and
enter the appropriate filter criteria. If a column is being filtered in any way, the blue filter icon will
appear to the left of the column name (shown below).
To run the trace, simply click the run button. Once a trace is running, you can control the trace by
pausing/stopping the trace. If pause is selected, the data is no longer gathered within Profiler until it is
resumed.
Saving a Trace as T-SQL

To save a trace in its T-SQL form, select File | Export | Script Trace Definition
Once this is generated, you can now store the trace as a stored procedure that SQL Server Agent calls to
periodically run the trace.
Saving a Trace’s Contents as T-SQL

To save the queries that were generated during the time the trace was running:
File | Export | Extract SQL Server Events | Extract Transact SQL events
Gathering Showplan Data

During analysis of a SQL system, it is common to find a query in a production system that performs
poorly, yet cannot be reproduced in a test environment. By saving showplans, you record the query as
well as the plan that was generated for the execution of the query.
To include showplan information in a trace:

Use the blank template, and expand the Performance event | Select the desired Showplan box
Creating a Replay Trace

Replay traces allow you to capture a workload and then replay it on a test system. To do this, you must
synchronize a backup of the database with the replay trace (otherwise many errors would occur). SQL
Server authentication also must be used since replay traces cannot handle Windows authentication.
Working with System Monitor

System Monitor, or PerfMon, is included with Windows and can measure a variety of resource metrics.
In order to capture data and use it for later analysis, you need to create a counter log. To create a
counter log, launch System Monitor and select Counter Logs. If you right-click Counter Logs | New Log
Settings and enter a name for the log, you can define the counter log next. You can also add objects
(CPU, Memory, Disk, etc) and counters (% utilized, % free, etc).
Database Engine Tuning Advisor

The Database Engine Tuning Advisor (DTA) is the replacement for older versions of SQL Server’s Index
Tuning Wizard. DTA allows you to utilize the query optimizer to automatically receive recommendations
on indexes, indexed views, or partitions.
DTA utilizes what is known as a workload file as an input and then tests that input using the query
analyzer to identify areas of improvement. This workload file can be in several different formats
including a trace file, a trace table, or a T-SQL script (the most common is the trace file).
To generate a workload file from a trace file:

Launch SQL Server Profiler | Select the Tuning trace template | save the results to a file
Configuring DTA to Analyze a Workload File

There are three steps involved in analyzing a file:
1. Launch DTA and connect to the server.
2. Select a workload file to analyze.
3. Specify any tuning options.
To launch DTA:
In SSMS, select Tools |Database Engine Tuning Advisor
Once DTA is open, you must specify a workload to analyze, as well as the database to be used for the
analysis:
Now that a workload file is specified, select the Tuning Options tab to customize what you are tuning:
To limit the time DTA performs its tuning, select the Limit tuning time checkbox and specify a time limit.
*Note: DTA can have a performance impact on the system and take a very long time to complete.
If you select the Advanced Options button (not shown), you will see the following dialog box:
Here you can define the maximum size that the recommendations can be, and also specify whether or
not to use online recommendations.
To start analysis of a workload file, click the Start

Analysis button:
As Analysis is in progress, you can view details on each step. You will notice while running analysis that
the longest step is the Performing Analysis action.
Once Analysis is complete, you can view one of several different reports to view any of the DTAs
recommendations. Once the analysis session is complete, you can save the recommendations for later
reference.
Additionally, you can apply the recommendations to a database immediately. This is not recommended
since changes are not integrated with your source code control system, and recommended changes
should be first tested in test/implementation servers.
Using Dynamic Management Views and Functions

Dynamic Management Views and Functions provide capabilities including database, query, I/O, and
hardware-level statistics.
Prefix Purpose
dm_db Provides general database stats
dm_exec Query stats
dm_io I/O stats
dm_os Hardware-level information
Database Statistics
db_index_usage_stats (DMV): Find the # of seeks, scans, lookups, or updates in an index
db_index_operational_stats (DMF): Determine how heavily a index is being used (modifications, scans,
and lookups)
db_index_physical_stats (DMF): Returns row size and fragmentation information
sys.dm_db_missing_index (DMV): Set of views that track the number of timesan index could have been
used, and helps identify areas that could benefit from indexes.
Query Statistics
These statistics are broken down into 2 categories: connections to the instance and queries running
from within the engine.
dm_exec_requests (DMV): Displays the # of requests per session

dm_exec_sessions (DMV): Displays the sessions within SQL Server
dm_exec_cached_plans (DMV): Retrieve information about query plans
dm_exec_query_stats (DMV): Detailed stats on performance of a query, how much resources the query
consumed, elapsed time, etc.
I/O Statistics
io_virtual_file_stats (DMF): breaks down the physical I/O written to each file by reads, writes, bytes
read, and bytes written. This ultimately helps identify if portioning/filegroups are necessary for
increased performance.
io_pending_io_requests (DMF): Contains a row for every request that is waiting for an I/O operation to
complete
Hardware Statistics
os_performance_counters (DMV): Provides all the counters that a SQL Server instance exposes in an
easily manipulated result set.
os_wait_stats (DMV): Displays how long processes have to wait before resources are allocated to them.
Correlating Performance and Monitoring Data
The true value in using all of the monitoring tools previously mentioned is when you use them in
conjunction with one another. These tools allow you to monitor and troubleshoot different layers of SQL
Server, so it is necessary to understand how to correlate that information effectively.
Examples:
To correlate System Monitor data with a Profiler trace, configure a trace that includes the “Start Time”
data column. Once the trace is done, select File | Import Performance Data in Profiler.
To correlate DMVs/DMFs with Profiler traces, you could identify queries that take several seconds and
then further break down their execution using DMVs/DMFs. For example, you could analyze
sys.dm_db_index_physical_stats to find that the optimizer is not using expected indexes because they
have become heavily fragmented.
Blocking and Deadlocking

Any database that allows multiple users and data modifications must have a way to maintain data
consistency. Locking and Blocking are desire in databases, but having them occur for an extended
period of time is undesirable and should be resolved.
Locking: Locks can be applied at a row, page, or table level. There are three types of locks:
1. Shared Locks: Allows shared access to the data; unlimited number of connections is allowed to
read the data. Data can’t be modified until the shared lock is released.
2. Exclusive Lock: Allows only a single connection to access the locked data. Used to ensure other
users can’t view the data until the modification is made.
3. Update Lock: Lock begins as a shared lock until the rows that need to be modified are located,
at which point turns into an Exclusive Lock. This “promotion” to an exclusive lock is the most
common cause of deadlocks.
Isolation Levels: In SQL Server 2005, there are five different levels which specify how transactions are
handled and the duration of the locks (described in the table below):
Isolation Level Description
READ UNCOMMITTED Read data that hasn’t been committed.
READ COMMITTED Prevents other connections from reading data

that is being modified until it is committed.
REPEATABLE READ Connection1 is not allowed to read data that
has been modified but not yet committed by
Connection2. No other connection can modify
data read by Connection1 until the transaction
completes.
READ SERIALIZABLE Isolation level same as REPEATABLE READ +
prevents new rows from being inserted within
the keyset range locked by a transaction.
SNAPSHOT Readers don’t block writers (and vice versa)
Blocking: When read operation place shared locks on rows, pages, or tables, and update operations
need to place exclusive locks on the same data. This is because an exclusive lock can’t be placed on a
shared lock. As a rule of thumb, any blocking that occurs for longer than 1 second creates contention,
lowers concurrency, and is typically a performance problem.
To determine the process that is being blocked:

Use the sys.dm_exec_requests DMV and check the blocking_process_id column. If the value is greater
than 0, check the SPID that is logged in that column to determine the cause of the block.
To terminate a process that may be causing severe blocking: member of the sysadmin fixed server role
must issue the command KILL [SPID], where SPID is the session ID that belongs to the blocking process.
Deadlocking is a combination of locks that can never be resolved. This requires at least 2 processes,
where each process is making a modification to the same data.
For example, process1 acquires a shared lock on data1, and needs an exclusive lock on data2. At the
same time, process2 acquires a shared lock on data2, and needs an exclusive lock on data1. Since both
processes are contending for the same data, a deadlock occurs.
SQL Server can detect a deadlock and in response applies an algorithm known as deadlock detection to
select one of the processes as the deadlock victim. This terminates the victim process, rolls back any
necessary transactions, releases the locks, and returns error 1205 to the application.
To obtain detailed information on deadlocks, use the Locks\Deadlock Graph event.
Resolving Database Errors

SQL Server 2005 allows you to connect to the server regardless of how busy the server is by using a
feature called the Dedicated Administrator Connection (DAC). The DAC is implemented as a TCP
endpoint in a SQL Server instance that is always attached to a UMS, or User Mode Scheduler (which
assigns threads to processors).
A member of the sysadmin role can

connect to the DAC to ensure that they
are never locked out of the system.
Only a single connection to the DAC
can exist at one time, and
backups/restores cannot be performed
via the DAC.
To connect to the DAC:

Specify ADMIN: and the name of the
instance.
Implement Database Mirroring

Database Mirroring is a new feature in SQL Server 2005 that provides automatic failover with no data
latency. With Database Mirroring, you can achieve almost 100% availability without the use of
expensive hardware. When a database is mirrored, a complete copy of a database is maintained
(database level, so you either mirror a complete database or nothing at all).
Database mirroring was initially available only for evaluation purposes, but then later became a
supported feature with no restrictions in Service Pack 1. To enable Database mirroring on the evaluation
version, the activation of trace flag 1400 was required.
Database mirroring works through the transaction log being copied to a mirrored server and then having
those log entries written to that server; this is known as “copy-on-write” technology. Since database
mirroring relies on the transaction log, on databases with the full recovery model can use database
mirroring.
Database Mirroring Roles

With database mirroring, there are two roles that must always be present, as well as a third optional
role. The roles are as shown in the diagram below (taken from sqlmag.com):
The Principal is the source of all transactions; applications read

to and write data to the principal.
The Mirror is the destination server that receives a copy of the
principal server’s transaction log entries. This database is in
recovery state, so it will not allow connections into it.
The Witness is the optional role; this server is used if you desire
automatic failover detection/failover. This server uses the High
Availability operating mode to perform this automatic failover.
A single witness server can service multiple numbers of
principal/mirror pairs (each entry has a row of information in
sys.database_mirroring_witnesses catalog view).
Preparing Database for Database Mirroring

There are four steps that must be followed in order to use Database Mirroring:
1. Set the database recovery model to the Full Recovery model.
*Note: Once a database is involved in mirroring, the recovery model can’t change.
2. Back up the primary database.
3. Restore that instance on the mirroring database using the NORECOVERY option.
4. Copy other database objects from primary to mirror servers (typically logins, SQL Server Agent
jobs, linked servers, etc).
Two ways to set the recovery model: through SSMS Database Options, or via T-SQL:
To see how to backup and restore a database, refer to the tutorial on Backup and Restore.
Establishing Endpoints
Endpoints are the objects used in SQL Server that allows the capability to connect to a database
instance. There are two types of endpoints: TCP or HTTP.
TCP Endpoints are needed for Database Mirroring (specify a payload of DATABASE_MIRRORING). You
can only specify one type of endpoint per database instance. By specifying the type of endpoint, the
endpoint will refuse any other type of request.
You must also specify a port number for the endpoint (default is 5022), and then configure the Listener
IP for that endpoint. If the principal, mirror, or witness roles are instances on the same server, they must
use different port numbers. The Listener IP is simply a range/list of IP addresses that the endpoint will
accept connections/requests from (default is ALL).
Additionally, you must specify authentication, encryption (optional), and specify the state of the
endpoint as STARTED.
Example T-SQL Command:
The “ROLE” clause is an additional layer of security that specifies what the endpoint will allow:
 PARTNER = Principal or Mirror
 WITNESS
 ALL = Principal, Mirror, or Witness

To configure the endpoints in SSMS:
Right-click database and choose Properties | select Mirroring page | Configure Security
Operating Modes
Operating modes dictate how the transactions are transferred between the principal and the mirror, as
well as the type of failover that is available (automatic versus manual). There are three different modes
that Database Mirroring can operate in:
1. High Availability
2. High Performance
3. High Protection
High Availability Operating Mode: Synchronous transaction log transfer and automatic failover.
In High Availability mode, SQL Server writes the transaction to the transaction log, which triggers the
copy of these rows to the mirror database. The mirror then sends an acknowledgement back to the
principal, the principal proceeds with processing any additional transactions.
Synchronous transfer incurs performance overhead, which increases as distance between the servers
increases.
High availability mode requires a witness server. When a failure on the principal occurs, the witness
reverses the principal/mirror roles, as well as the transaction flow. For this to happen, both the mirror
and the witness must “agree” that the principal is unavailable via heartbeat monitoring (ping).
High Performance Operating Mode: Asynchronous transaction log transfer and manual failover.
Does not require a witness server; transactions are first applied to the principal and then they are
copied over to the mirror (handled by a separate process). This introduces latency but increases
performance.
High Protection Operating Mode: Synchronous transaction log transfer and manual failover.
Configured the same as High Availability Mode, but does not use a witness server. Therefore, you must
manually promote the mirror to the principal upon server failure.
To configure the Operating Mode:

Right-click the database | Properties | Mirroring Page | Choose one of the Operating Modes
Transparent Client Redirection: Application connections that automatically use the mirror server
connection if the principal goes down (by caching the mirror connection until it is needed).
Failing Over a Database Mirror

For High Performance and High Protection operating modes, manual fail over is required. Issue the T-
SQL command :
ALTER DATABASE [MirrorDBName] SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
Since the mirror will be in NO RECOVERY state, you can not initiate failover via SSMS (unless connecting
as admin).
In High Availability mode, you can still manually force a failover. This is typically done for general
maintenance of a server. The T-SQL command to do this from the principal is:
ALTER DATABASE SET PARTNER FAILOVER
Removing Database Mirroring

If you no longer require database mirroring, or if a principal becomes so damaged that it would be easier
to reinitialize the environment, you can disable database mirroring. You can do this through SSMS or T-
SQL (on either the principal or the mirror):
From SSMS: right-click the database | Properties | Mirroring page | Stop Mirroring
T-SQL Command: ALTER DATABASE [DBName] SET PARTNER OFF
Implement Log Shipping

Log shipping is a feature of SQL Server 2005 that automates the backing up, copying, and restoring of
the transaction log from one database to another. By synchronizing the log from a primary server to a
secondary server, you can distribute query processing and use the secondary system as a warm standby.
Log shipping does not automatically failover from the primary database, so this must be done manually.
SQL Server Agent jobs are utilized for the processes involved in log shipping (which included the backup,
copy, and restore operations). Log shipping configuration features five components:
1. Primary Database – original database that is distributed to others

2. Secondary Database – distributed copy of the database
3. Primary Server – database engine that owns the primary database
4. Secondary Server – database engine that owns the secondary database
5. Monitor Server – instance that keeps track of the log shipping process/alerts
Figure 1 –
Log Shipping Setup (from Microsoft.com)
Log Shipping consists of three main processes:

1. Backup the transaction log of the primary database
2. Copy that transaction log to all secondary servers.
3. Restore the transaction log for each of the secondary servers.
Log Shipping Requirements

 Separate database instances/servers are required for the primary/secondary/monitor servers.
 Not supported on SQL Server 2005 Express edition.

 Previous versions of SQL Server can’t participate in SQL Server 2005 log shipping.
 Primary database can’t have the simple recovery model.
 The user configuring log shipping must have sysadmin access to all participating servers.
 The Agent account on the primary server should have read/write access to the network share
that is storing the log files.
 The Agent account on the secondary server(s) need read access to the network share that is
storing the log files.
Configuring Log Shipping Options

In SSMS, right-click the database | Properties | Transaction Log Shipping page
To enable the database as the primary database, simply check the initial checkbox. You can then
configure the Backup settings:
The Network path is simply directory that will store the backed up transaction log. The second box is
only used if you will store the transaction log locally (not recommended). Additional options allow you
to specify when to delete transaction log files, generate an alert if no backup occurs within a given
amount of time, etc.
To schedule the backup job, select “Schedule”:

Managing Replication
Replication is the technology in SQL Server that allows the distribution of data and database objects
from one database to one or more databases (and synchronizing those databases). Benefits of database
replication include increased availability and distribution of data-access workload.
Replication Architecture
Replication uses terminology similar to the publishing industry, as the components and processes are
the same for the most part.
Publications and Articles

An article is the most basic unit of replication, and represents a database object that is replicated.
 Tables
 Views
 Definitions/Execution of stored procedures
A publication is a group of articles. This simplifies management as it provides a point for subscribing to a
group of articles rather than subscribing to articles individually.
Publisher, Distributor, Subscribers

These are all different roles that a server can be in the replication process, and multiple roles can be
held by the same server.
The Publisher is the owner of the publication. Depending on the replication type, the publisher may be
the only role that can modify the data.
The Distributor manages the distribution database, which stores replication status data, metadata, and,
depending on the replication type, the actual data that is replicated. A Local Distributor is one that is
also a Publisher. In contrast, a Remote Distributor is one that is one a separate server than the Publisher
role.
The Subscriber is the server that receives the publication(s) and provides the data to end
users/applications. Depending on the type of replication, the subscriber would be read-only. In other
cases, the subscriber could update information and replicate those changes back to the Publisher.
Push and Pull Subscriptions

There are two ways for the Subscriber to obtain the publications; through Push subscriptions and
through Pull subscriptions.
Push Subscriptions involve a Distributor copying the data to the Subscriber.

Pull Subscriptions involve the Subscriber retrieving the data from the Distributor.
Push Subscriptions are good in scenarios with stable/permanent connections, and allow centralized
management of all replication agents. Pull Subscriptions are good for connections that are made on-
demand, and is also less resource-intensive on the Distributor if there are multiple Subscribers
(processing is on the Subscriber side).
Replication Types
There are three types of replication:
1. Snapshot Replication
2. Transactional Replication
3. Peer-to-Peer Replication
Snapshot Replication involves the server copying an entire set of data (the articles included in the
publication) to the Subscribers at scheduled times. This replication type should only be used with small
datasets that are somewhat static in nature.
Transactional Replication makes an initial complete copy of the data, and then all following transactions
include only data that has been modified (using the transaction log). This also allows data updates on
the Subscriber end, which introduces the idea of merge replication.
1. Initial full copy of data occurs and is sent to the subscriber.

2. As data changes occur, the changes are made on either server.
3. Replication process takes these changes, resolves any conflicts, and applies the changes to all
servers.
Peer-to-peer Replication allows multiple servers to subscribe to the same schema and data, and permits
simultaneous changes in multiple servers.
Replication Agents
Replication is performed through a collection of replication agents, which are agent jobs that run on the
different replication servers.
 Snapshot Agent – Runs in Distributor; prepares schemas and initial data files.
 Log Reader Agent – Runs in Publisher (for transactional replication); copies each transaction
that affects the publication to the distribution database.
 Distribution Agent – Runs in Distributor (push) or Subscriber (pull); delivers the initial snapshot
and contents of distribution database to Subscribers.
 Merge Agent – Runs in Distributor (push) or Subscriber (pull); handles conflict resolution.
 Queue Reader Agent – agent that reads the queue and applies transactions to the publisher
(only if using queued update subscriptions)
Configuring Replication
The first step involved in configuring replication is configuring the Distributor. Remember that a
Publisher can only use a single Distributor, but a single Distributor can service multiple Publishers. By
default, the Distributor server serves its own data (local Distributor), but it can also serve the data of a
remote Publisher.
Before configuring the Distributor, ensure that the server that will be hosting this role has ample disk
space and CPU/Memory.
In SSMS:
Connect to the Database instance you want to be the Publisher/Distributor.
Right-click the Replication folder and choose Configure Distribution
You will see the Configuration Wizard. Click Next.
Next you will see the screen where you select which instance/server will act as the Distributor. Keep the
default options and select “Next”.
On the Snapshot Folder page, enter the directory/UNC path that will contain the database snapshots.
You must use a UNC if you intend on using pull replication (in which case the Snapshot Agent needs
write permission and Merge/Distribution Agent needs read permission). Click Next.
The next screen is where you configure settings for the Distribution Database. You can specify the
database name and location of the data/log files. Click Next.
On the Publishers screen, you specify which servers will use this server as a Distributor. Note that you
can add either SQL Server Publishers or Oracle Publishers. Click Next.
This screen allows you to specify whether or not you want to configure distribution, as well as generate
a script file. This is useful for documentation and serves as backup in a recovery plan. Select the
checkbox to generate a script, and click Next.
For the Script File Properties, you can specify the File name/location of the script, whether or not to
overwrite a preexisting script, and the file format of the script. Click Next.
This screen is just a summary of the configuration options. Click Next.
The progress of the Distribution configuration will be displayed. Click Close to finish the process.
Configuring a Publication
Connect to the database instance that hosts the data you want to Publish.
Expand the Replication folder | Right-Click Local Publications | New Publication.
The New Publication Wizard appears. Click Next.

Select the database that contains the data you want to replicate, and select Next.
Select the publication type. Select Next.
On the Articles page, you specify which database objects you want to include in the publication. If you
select an object that depends on another object, those objects must also be included. Select Next.
You can now filter on specific rows that you want to retrieve:
The next screen configures the Snapshot Agent. You can specify whether to create a snapshot
immediately after configuration or at a later specified time. Select to Create the snapshot immediately,
and click Next.
On the Agent Security page, click

Security Settings to open the Snapshot
Agent Security dialog box. Choose the
type of account you want to use.
This screen allows you to create the publication and generate a script. Leave the default settings and
click Next.
Now you just select a publication name, and review the publication settings. Click OK.
The final screen completes the process. Click Close.
Subscribing to a Publication
In SSMS:
Connect to the Publisher database instance.
Expand Replication Folder | Local Publications Folder

Right-click the publication you will subscribe to | New
Subscriptions
On the New Subscription Wizard, click Next
This screen allows you to select which publication/Publisher to use. This is automatically selected for
you if you create a subscription from the Publisher. If you create a subscription from the Subscriber, you
must fill this information in manually. Click Next.
The Distribution Agent Location screen allows you to specify push subscriptions or pull subscriptions.
Leave the settings as-is and click Next.
The Subscribers screen allows you to specify the subscriber to the publication. Click “Add Subscriber”,
and select “Add SQL Server Subscriber”. Now select another instance of SQL Server (if one exists), and
connect to that instance (shown below).
Now that the second instance is

selected, you must specify which
database to use for the subscription.
Create a new database from the drop-
down menu, and create the database
like you would normally. Click Next.
On this screen, you configure the security context for the Subscription agent and the connections to the
Distributor/Subscriber. Click “…” to open the security configuration screen.
For this example, run the Distribution

Agent process under the Windows
account that you typically use to
connect to SSMS. You can leave the
other settings as-is.
On the Synchronization Schedule page, you choose the schedule that the agent will run. For Merge and
Snapshot replication, use “Run on Demand” or “Set a Schedule”. For transactional replication, choose
“Run continuously”. Click Next.
When initializing a subscription, the initial snapshot creates the schema and copies all data contained in
the publication. This could potentially be resource intensive, so you could specify to not initialize the
subscription immediately. For this example, keep the defaults and click Next.
This screen is similar to others you have seen for Distributor/Publisher configuration. Select “Generate a
script file…” and click Next. Retain the script defaults and click Next (screenshot not shown).
The Complete the Wizard screen is a summary of configuration options. Click Finish to complete the
configuration process.
And the Subscription completes successfully!
To verify the subscription configuration, back in the Publisher instance of SQL Server, expand the
Replication node | Local Publications | Choose the publication that you subscribed to | Right-click and
choose Properties:
NOT FOR REPLICATION Option

Triggers, foreign key constraints, check constraints, and identity columns can use this clause to prevent
replication in specific scenarios. Refer to Books Online for specific details on where you would want to
use this feature.
Configuring Replication Security

Permission required to configure the Publisher/Distributor = sysadmin
Permission required to enable publishing = sysadmin
Permission required to create publications/subscribe to a publication = db_owner
SQL Server 2005 also allows you to secure individual publications with publication access lists (PAL). This
is automatically created with the publication, and can be accessed through SSMS.
In SSMS:
Connect to the database instance that is the Publisher.
Expand Replication node | Local Publications Folder |Right-click Publication | Properties
Select the Publication Access List page
From this dialog, you can add individual

users/groups, as well as remove a single
user/group (or all users/groups).
Note: This can also managed by stored

procedures:
sp_help_publication_access
sp_grant_publication_access
sp_revoke_publication_access
Agent Publication Distribution Subscription Snapshot Share PAL

Snapshot dbo_owner dbo_owner Write
Log Reader dbo_owner dbo_owner
Pull dbo_owner dbo_owner Read Yes
Push dbo_owner Read Yes
Merge (Push) Public dbo_owner dbo_owner Read Yes
Merge (Pull) Public Public dbo_owner Read Yes
Queue Reader dbo_owner dbo_owner dbo_owner
Configuring Conflict Resolution for Merge Replication

In merge replication, conflicts may occur if two servers update the same data simultaneously. In merge
replication configuration, you must specify how these conflicts are handled in order to maintain data
integrity.
While creating articles for a publication that uses merge replication, you can specify these conflict
resolvers.
In SSMS:
Create a new publication | Choose Merge Publication | Select the Subscriber Types
Select the articles, and choose the Article Properties drop-down list
Select Set Properties of Highlighted Table Article
Select the Resolver tab | Use a custom resolver
The best way to become familiar with these resolvers is to refer to Books Online (BOL).
Monitoring Replication
In SQL Server 2005, you use SQL Server Replication Monitor (SSRM) to observe the replication activity on
your server(s).
To launch SSRM, Right-Click the Replication Node | Launch Replication Monitor
Alternatively, navigate to:

C:\Program Files\Microsoft SQL Server\90\Tools\Binn\sqlmonitor.exe
Replication Monitor Permissions

By default, only sysadmins can
monitor replication. However, a
sysadmin can assign a user to the role
of replmonitor.
In SSMS:
Connect to Distributor instance.
Right-click the user that will monitor
replication | Properties
Select the User Mapping page
Select the distribution database |
Select the Map checkbox | Select
replmonitor in the
Database Role Membership For: Distribution section.
To Add a Publisher, right-click on the

server | Add Publisher.
You can also view the Publisher settings (shown below)

If you have many Publishers, you can
group them by different names for
easier administration.
The refresh rate specifies how often

the replication information is
refreshed within the monitor.
Tracer Tokens: These allow you to measure the latency of the replication process (from Publisher to
Distributor and from Distributor to Subscriber). To access this, select a subscription, select the Tracer
Token tab, and click on Insert Tracer.
Configuring Alerts with SSRM

Replication monitor can have preconfigured events setup that will automatically generate alerts if a
certain condition/threshold is met.
To configure alerts:
1. Open SSRM
2. Expand Replication Monitor | My Publishers | [PublisherName]
3. Select the publication you want to set the alert for
4. Click on Warnings and Alerts tab
5. Click Configure Alerts
Working with Service Broker

Service Broker provides a native SQL Server infrastructure that supports asynchronous, distributed
messaging between database-drive services. Service Broker handles the coordination among
components required for distributed messaging, including transactional delivery and storage, message
typing/validation, event notification, routing, and security.
Messaging Overview
Messages are simply data input that is sent to another process/server that requires some form of
processing/return value. Messages are only valuable if a) there is a means to process the message, and
b) capability of an application to accept message input.
To enable Service Broker:

ALTER DATABASE <databaseName> SET ENABLE_BROKER
Service Broker Components

Communication occurs between a source and a target, which in Service Broker are referred to as
endpoints. Endpoints are simply the physical databases; in other words, Service Broker sends and
receives data between databases. The endpoint that starts the message is the initiator, and the
endpoint that receives the initial message is the target.
Endpoints can be in the same database, in different databases on the same instance, or in databases on
different instances/servers.
Conversations are the exchanges of data/messages between endpoints; they manage the flow of
messages between initiator and target. Conversations can be:
 Monolog: Conversation from one endpoint to any number of targets (not currently available in
SQL Server 2005).
 Dialog: Conversation between exactly two endpoints.
Queues store messages in a table because messages are not always processed synchronously. When
apps send messages, an entry is added to the bottom of the table, while other applications read from
the top of the table and work their way down. Once a message is read, it is removed from the queue.
Services are an abstraction layer in Service Broker that allows queues to be placed between databases
and servers (separates applications from the physical storage).
Contracts are specified by services, and they specify what objects are allowed to be sent/received within
the messages. Furthermore, message format is constrained by a mechanism called the message type.
Message types define how the messages should be formatted.

Contracts define which message types are allowed within a conversation.
Image taken from: http://www.dotnetfun.com/articles/sql/sql2005/SQL2005ServiceBrokerBasicArchitecture.aspx

Creating Message Types

CREATE MESSAGE TYPE [MessageTypeName]
AUTHORIZATION owner_name
VALIDATION = [option]
VALIDATION specifies whether or not messages are validated when they are submitted. The options for
validation include:
 EMPTY – Forces the message body to contain no data

 NONE – Message body can contain any data in any format
 WELL_FORMED_XML – Message body must be well-formed XML
 VALID_XML WITH SCHEMA COLLECTION – Must be well-formed XML and conform to the
specified schema.
Creating a Contract
CREATE CONTRACT contract_name
AUTHORIZATION owner_name
([MessageTypeName] SENT BY INITIATOR,
[MessageTypeName SENT BY TARGET)
SENT BY can specify TARGET, INITIATOR, or ANY
Creating Queues and Services

SQL Server 2005 implements queues by using a feature called hidden tables. This prevents a queue from
being directly accessed by an application via INSERT, UPDATE, DELETE, or SELECT, but still allowing the
storage engine to treat it as any other table.
CREATE QUEUE <queueName>

WITH [option(s)]
Options include:
 STATUS = {ON | OFF} – Determines whether the queue is enabled.
 RETENTION = {ON | OFF} – Determines whether messages are automatically removed from the
queue after they are processed.
 ACTIVATION (STATUS = {ON | OFF},
PROCEDURE_NAME = <procedure>,
MAX_QUEUE_READERS = max_readers,
EXECUTE AS {SELF | ‘user_name’ | owner}
ACTIVATION specifies if a stored procedure is enabled to send notification when a new entry is
place in the queue (signifies that new work needs to be processed). If Service Broker determines
that messages are arriving faster than they can be processed by the existing procedures,
another copy of the sproc is launched (up to the max_readers value).
Creating a Service
Services define the endpoint (or queue) that a conversation will use as well as the types of conversations
(or contracts) that are allowed on a queue.
CREATE SERVICE service_name

[AUTHORIZATION ownerName]
ON QUEUE queue_name (contractName1, contractName2, …)
You can only specify a single queue, so for effective communication you should create a service for the
initiator and a service for the target. One or more contracts can be specified for the service.
Creating Conversations
Each message has a sequence number, which guarantees that messages are processed in order. Service
Broker has a mechanism that allows it to retry messages until they are successfully received.
Conversations implement this reliable ordered process for delivering messages via services.
BEGIN DIALOG [CONVERSATION] @dialog_handle

FROM SERVICE initiator_service_name
TO SERVICE ‘target_service_name’
ON CONTRACT contract_name
[WITH [Options]]
The unique identifier is placed in the @dialog_handle variable.
WITH options include:

 “RELATED_CONVERSATION =” – this allows you to create a logical process and link conversations
together.
 “RELATED_CONVERSATION_GROUP =” create a logical group
 LIFETIME – Specifies the max number of seconds the conversation is allowed to exist; any open
processing is rolled back if the dialog is not explicitly ended.
 ENCRYPTION – specified whether messages are encrypted
Routes: used to locate the service to receive the messages
CREATE ROUTE – adds a new route to the routing table for the current database; should specify three
components:
1. Name of the service for the route
2. Broker instance identifier of the DB to send the messages to
3. Network address of the broker that hosts the service
Sending and Receiving Messages

SEND and RECEIVE commands are used to place messages on a queue, and then take messages off the
queue.
To place a message on a queue:

SEND
ON CONVERSATION conversation_handle
[MESSAGE TYPE message_type_name (message_body_expression)]
To retrieve the contents of a queue:

SELECT column_list FROM queue_name
To take messages off the queue:

RECEIVE [ TOP (n) | column_specifier]
FROM queue
[INTO table_variable]
[WHERE {conversation_handle = value | conversation_group_id = value2}
Creating Full-Text Catalogs

Full-text catalogs are structures maintained outside of SQL Server that contain full-text indexes. Full-text
catalogs/indexes all you to manage queries issued against unstructured data.
The first step in creating a full-text index is to create a full-text catalog that will hold the indexes.
CREATE FULLTEXT CATALOG [CatalogName]

ON FILEGROUP [filegroupName]
IN PATH ‘rootpath’
[AS DEFAULT]
[AUTHORIZATION ownerName]
It is best practice to place the catalog on a secondary filegroup that is used exclusively for full-text
catalogs. This allows filegroup backup/restore of full-text catalogs, independent from the rest of the
database.
IN PATH specifies the location the catalog will be stored (since it is saved outside of SQL Server).
AS DEFAULT specifies that the catalog will be the default catalog when any full-text index is created (and
no catalog is specified).
AUTHORIZATION specifies the owner of the catalog.
Creating a Full-Text Index

Once a full-text catalog is created, you can now create one or more full-text indexes. Full-text indexes
can be built on char, nchar, varchar, nvarchar, varchar(max), text, ntext, image, varbinary,
varbinary(max), and xml columns.
Helper Services are used in full-text index creation, and include word breakers and stemmers, language
filters, noise word files, filters, and protocol handlers.
 Word breakers: routines that find the breaks between words, generate word list for every row
within a column that is being indexed
 Stemmers: conjugate verbs
 Language Files: use word breakers and stemmers to understand the words; handles multiple
languages without requiring translation
 Noise words: Commonly used words, not useful for search routines (the, a, an)
 Filters: Additional column used to mark a file as pdf, word, excel, etc. Loads up the binary
stream stored in the column, returns text within the document to the word-break routine.
 Protocol handlers: Identifies how to handle formatting of different file formats.
Syntax to Create a Full-Text Index:
CREATE FULLTEXT INDEX ON [TableName] (ColumnName)

KEY INDEX indexName
ON fullTextCatalogName
WITH CHANGE_TRACKING {MANUAL | AUTO | OFF [, NO POPULATION]}
KEY INDEX specifies the table’s unique column, and must be a single column in the table.
ON specifies which catalog to store the index in.
WITH CHANGE_TRACKING specifies how to propagate changes in the underlying columns to the full-text
index (a separate process is run to perform this update). If using the OFF option, you can also specify NO
POPULATION to prevent the index from being populated during index creation.
If using a column of type varbinary, varbinary(max), or image, you must add the clause TYPE COLUMN
columnName fileExtension.
Populating a Full-Text Index

To keep full-text indexes up to date, you must periodically populate them/merge them with changes to
the underlying columns. There are three modes for population: full, incremental, and update.
Full populations cause all rows from the table to be read and processed; this is resource-intensive and is
generally only down when the index is created.
Incremental populations automatically populates the index for rows that were modified since the last
population. This requires a timestamp column, which is used to determine when the last changes were
made.
Update populations use that changes that SQL Server tracks to process any inserts, updates, and deletes
since the last time a change-tracked index was populated.
To populate a full-text index:

ALTER FULLTEXT INDEX ON [TableName]
START {FULL | INCREMENTAL | UPDATE} POPULATION
STOP POPULATION
To rebuild/reorganize a full-text index:

ALTER FULLTEXT CATALOG catalogName
{REBUILD [WITH ACCENT_SENSITIVTY = ON/OFF]}
| REORGANIZE
| AS DEFAULT
REBUILD deletes the full-text index and recreates it; this is generally only done if the
ACCENT_SENSITIVITY needs to be changed.
REORGANIZE causes all indexes in the catalog to have all changes merged. This frees up disk space and
memory resources.
Querying Data Using a Full-Text Index

In order to utilize full-text search capability, you must specify T-SQL clauses in your statement; these
statements include CONTAINS, CONTAINSTABLE, FREETEXT, and FREETEXTTABLE.
FREETEXT: accepts one or more columns to search and a search argument. Searches using stemming
and for related words which the thesaurus identifies.
Example Query:
SELECT Title
FROM Production.Document
WHERE FREETEXT (Document, 'search term' );
FREETEXTTABLE: functions the same as FREETEXT, but returns a rowset that contains a rank column (1 –
1000, indicating how well the row matches the search criteria). Additionally, a KEY column is returned to
display the unique key used to identify the specific row.
CONTAINS: allows you to use precise or fuzzy matching algorithms (performing exact matches or prefix
searches). According to SQL Server BOL, CONTAINS can search for:
 A word or phrase.
 The prefix of a word or phrase.
 A word near another word.
 A word inflectionally generated from another (for example, the word drive is the inflectional
stem of drives, drove, driving, and driven).
 A word that is a synonym of another word using thesaurus (for example, the word metal can
have synonyms such as aluminum and steel).
To perform a “standard” CONTAINS search:

CONTAINS(Name, 'SearchTerm');
To perform a “prefix” CONTAINS search:

CONTAINS(Name, ' "SearchTerm*" ');
It is also possible to search using INFLECTIONAL and THESAURUS specifications. INFLECTIONAL searchs
for terms that stem from the search term; for example, the word “eat” would also find “ate”, “eaten”,
“eating”, etc. THESAURUS specifies to search for synonyms of the word as well.
To perform an INFLECTIONAL search:

CONTAINS(ColumnName, ' FORMS OF (INFLECTIONAL, SearchTerm) ');
To perform a THESAURUS search:

CONTAINS(ColumnName, ' FORMS OF (THESAURUS, SearchTerm) ');
*Note: Thesaurus file, located in $SQL_Server_Install_Path\Microsoft SQL Server\MSSQL.1\MSSQL\FTDATA, is empty by default.
Word proximity can also be specified in full-text searches. By specifying either the NEAR keyword or just
~, you specify that the rank is partly based on the proximity of words. For example,
CONTAINS(Column, 'mountain NEAR bike'); would return ranked results if “mountain” and
“bike” occurred near each other.
You can also specify the weight of search terms by using the ISABOUT clause. This manually assigns the
relevance for each search term used, based on the level of significance of a term.
CONTAINS(Column, ‘ISABOUT (Term1 weight(.8), term2 weight(.2)’ );
CONTAINSTABLE: functions the same as the CONTAINS function, but returns a rowset that contains a
RANK and a KEY column; simply specify CONTAINSTABLE.
References:
SQL Server 2005: Implementation and Maintenance Self-Paced Training Kit
Beginning SQL Server 2005 Programming
Microsoft SQL Server 2005 Administrator's Pocket Consultant

Ultimate SQL Server 2005

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ultimate SQL Server 2005

Caricato da

Copyright:

Formati disponibili

Ultimate 70-431 Study

Created By: Cbrzana

Installing SQL Server 2005

Prior to actually installing SQL Server,

Once you initiate the install, the process

*Note: You can also use the new .NET

As shown in the screenshot, IIS

Click “Next”, and you are then

Windows Authentication Mode allows you to

Mixed Mode is useful if you have users

After all of these options are selected,

Upgrading to SQL Server 2005

Options to move to the new database instance include:

Configuring Log and Data Files

 Data Files hold data and objects (tables, indexes, etc).

1. Primary Data Files are always included in a

Every database has a default filegroup

To alter the database’s default filegroup, issue the T-SQL statement:

ALTER DATABASE [target database] MODIFY FILEGROUP [filegroup name] DEFAULT

Configuring Data Files and Log Files

PRIMARY: Specifies a primary filegroup

NAME: The logical name of the filegroup

FILENAME: The path to the filegroup

SIZE: The size of the file.

MAXSIZE: The maximum size you will allow the

FILEGROWTH: Specifies the automatic growth

LOG ON: Specifies information for the logfile.

Configuring Database Files with RAID Systems

For a comparison on RAID levels, visit: http://msdn2.microsoft.com/en-us/library/ms178048.aspx

Overview of Best Practices

- Do not put data files on the same drive as the OS files.

Partitioning requires the following steps:

Creating a Partition Function

CREATE PARTITION FUNCTION [FunctionName] (input_parameter_type)

Creating a Partition Scheme

Partitioning Tables and Indexes

Use the function called $PARTITION to query partitions:

Configuring Database Mail

 Support for multiple email profiles/accounts

Setting up Database Mail

1. On the machine running SQL Server 2005, open

2. Select “Surface Area Configuration for Features”.

3. Once the dialog box opens, select the SQL Server

4. Select the Database Mail Node.

5. Check the “Enable Database Mail

6. Click “Apply” and then “OK”. You

To disable Database Mail, run the following code:

Database Mail Architecture

1. Configuration components: includes two sub-components:

2. Messaging: the Database Mail host database (msdb)

3. Database Mail executable: DatabaseMail90.exe, a separate executable from SQL Server to

Using the Database Mail Configuration Wizard

This wizard allows you to perform actions including account

1. Expand the Management Node, right click Database

2. This will give you the welcome screen for the

3. Enter the Profile name, a brief description, and then

4. Fill in the Account information, click

5. Specify database users or roles that

6. You now have Database Mail

Configuring the Recovery Model:

To configure the recovery model in T-SQL:

ALTER DATABASE <database_name>

Configuring Server Security Principals