###BeginCaseStudy###
Case Study 3
Fabrikam, Inc
Background
Corporate Information
Fabrikam, Inc. is a retailer that sells electronics products on the Internet. The company has a
headquarters site and one satellite sales office.
You have been hired as the database administrator, and the company wants you to change the
architecture of the Fabrikam ecommerce site to optimize performance and reduce downtime
while keeping capital expenditures to a minimum. To help with the solution, Fabrikam has
decided to use cloud resources as well as on-premise servers.
Physical Locations

All of the corporate executives, product managers, and support staff are stationed at the
headquarters office. Half of the sales force works at this location.
There is also a satellite sales office. The other half of the sales force works at the satellite
office in order to have sales people closer to clients in that area. Only sales people work at the
satellite location.
Problem Statement
To be successful, Fabrikam needs a website that is fast and has a high degree of system
uptime. The current system operates on a single server and the company is not happy with the
single point of failure this presents. The current nightly backups have been failing due to
insufficient space on the available drives and manual drive cleanup often needing to happen
to get past the errors. Additional space will not be made available for backups on the HQ or
satellite servers. During your investigation, you discover that the sales force reports are
causing significant contention.
Configuration
Windows Logins
The network administrators have set up Windows groups to make it easier to manage
security. Users may belong to more than one group depending on their role.
The groups have been set up as shown in the following table:

Server Configuration
The IT department has configured two physical servers with Microsoft Windows Server 2012
R2 and SQL Server 2014 Enterprise Edition and one Windows Azure Server. There are two
tiers of storage available for use by database files only a fast tier and a slower tier. Currently
the data and log files are stored on the fast tier of storage only. If a possible use case exists,
management would like to utilize the slower tier storage for data files.
The servers are configured as shown in the following table:

Database
Currently all information is stored in a single database called ProdDB, created with the
following script:

The Product table is in the Production schema owned by the ProductionStaff Windows group.
It is the main table in the system so access to information in the Product table should be as
fast as possible.
The columns in the Product table are defined as shown in the following table:

The SalesOrderDetail table holds the details about each sale. It is in the Sales schema owned
by the SalesStaff Windows group.
This table is constantly being updated, inserted into, and read.
The columns in the SalesOrderDetail table are defined as shown in the following table:

Database Issues
The current database does not perform well. Additionally, a recent disk problem caused the
system to go down, resulting in lost sales revenue. In reviewing the current system, you found
that there are no automated maintenance procedures. The database is severely fragmented,
and everyone has read and write access.
Requirements
Database
The database should be configured to maximize uptime and to ensure that very little data is
lost in the event of a server failure. To help with performance, the database needs to be
modified so that it can support in-memory data, specifically for the Product table, which the
CIO has indicated should be a memory-optimized table. The auto-update statistics option is
set off on this database.
Only product managers are allowed to add products or to make changes to the name,
description, price, cost, and supplier. The changes are made in an internal database and

pushed to the Product table in ProdDB during system maintenance time. Product managers
and others working at the headquarters location also should be able to generate reports that
include supplier and cost information.
Customer data access
Customers access the company’s website to order products, so they must be able to read
product information such asname, description, and price from the Product table. When
customers place orders, stored procedures calledby the website update product quantity-onhand values. This means the product table is constantly updated at randomtimes.
Customer support data access
Customer support representatives need to be able to view and not update or change product
information. Management does not want the customer support representatives to be able to
see the product cost or any supplier information.
Sales force data access
Sales people at both the headquarters office and the satellite office must generate reports that
read from the Product and SalesOrderDetail tables. No updates or inserts are ever made by
sales people. These reports are run at random times and there can be no reporting downtime
to refresh the data set except during the monthly maintenance window. The reports that run
from the satellite office are process intensive queries with large data sets. Regardless of
which office runs a sales force report, the SalesOrderDetail table should only return valid,
committed order data; any orders not yet committed should be ignored.
Historical Data
The system should keep historical information about customers who access the site so that
sales people can see how frequently customers log in and how long they stay on the site. The
information should be stored in a table called Customer Access. Supporting this requirement
should have minimal impact on production website performance.
Backups
The recovery strategy for Fabrikam needs to include the ability to do point in time restores
and minimize the risk of data loss by performing transaction log backups every 15 minutes.
Database Maintenance
The company has defined a maintenance window every month when the server can be
unavailable. Any maintenance functions that require exclusive access should be
accomplished during that window.
Project milestones completed
• Revoked all existing read and write access to the database, leaving the schema
ownership in place.
• Configured an Azure storage container secured with the storage account name
MyStorageAccount with the primary access key StorageAccountKey on the cloud file
server.
• SQL Server 2014 has been configured on the satellite server and is ready for use.
• On each database server, the fast storage has been assigned to drive letter F:, and the
slow storage has been assigned to drive letter D:.
###EndCaseStudy###

DRAG DROP
The business requires a satellite office to have a local copy of the data to report against.
You want to implement a solution to support the requirements. You need to establish a new
Availability Group between the two servers.
Develop the solution by selecting and arranging the required code blocks in the correct
order. You may not need all of the code blocks.

Answer: See the explanation.

Explanation:

Box 1:

Box 2:

Box 3:

Box 4:

Box 5:

Box 6:

Box 7:

Note:
* The following table lists the basic tasks involved in creating and configuring an availability
group and indicates which Transact-SQL statements to use for these tasks. The AlwaysOn
Availability Groups tasks must be performed in the sequence in which they are presented in
the table.
(step 2) Create database mirroring endpoint (once per SQL Server instance)
CREATE ENDPOINT endpointName … FOR DATABASE_MIRRORING
(step 3) Create availability group
CREATE AVAILABILITY GROUP
(step 4) Join secondary replica to availability group
ALTER AVAILABILITY GROUP group_name JOIN
(step 5-6)
Prepare the secondary database
BACKUP and RESTORE.

Create backups on the server instance that hosts the primary replica.
Restore backups on each server instance that hosts a secondary replica, using RESTORE
WITH NORECOVERY.
(step 7)
Start data synchronization by joining each secondary database to availability group
ALTER DATABASE database_name SET HADR AVAILABILITY GROUP = group_name
Reference: Create an Availability Group (Transact-SQL)