###BeginCaseStudy###
Case Study: 7
Fourth Coffee
Background
Corporate Information
Fourth Coffee is global restaurant chain. There are more than 5,000 locations worldwide.
Physical Locations
Currently a server at each location hosts a SQL Server 2012 instance. Each instance contains
a database called StoreTransactions that stores all transactions from point of sale and uploads
summary batches nightly.
Each server belongs to the COFFECORP domain. Local computer accounts access the
StoreTransactions database at each store using sysadmin and datareaderwriter roles.

Planned changes
Fourth Coffee has three major initiatives:
• The FT department must consolidate the point of sales database infrastructure.
• The marketing department plans to launch a mobile application for micropayments.
• The finance department wants to deploy an internal tool that will help detect fraud.
Initially, the mobile application will allow customers to make micropayments to buy coffee
and other items on the company web site. These micropayments may be sent as gifts to other
users and redeemed within an hour of ownership transfer. Later versions will generate
profiles based on customer activity that will push texts and ads generated by an analytics
application.
When the consolidation is finished and the mobile application is in production, the
micropayments and point of sale transactions will use the same database.
Existing Environment
Existing Application Environment
Some stores have been using several pilot versions of the micropayment application. Each
version currently is in a database that is independent from the point of sales systems. Some
versions have been used in field tests at local stores, and others are hosted at corporate
servers. All pilot versions were developed by using SQL Server 2012.
Existing Support Infrastructure
The proposed database for consolidating micropayments and transactions is called
CoffeeTransactions. The database is hosted on a SQL Server 2014 Enterprise Edition
instance and has the following file structures:

Business Requirements
General Application Solution Requirements
The database infrastructure must support a phased global rollout of the micropayment
application and consolidation.

The consolidated micropayment and point of sales database will be into a CoffeeTransactions
database. The infrastructure also will include a new CoffeeAnalytics database for reporting
on content from CoffeeTransactions.
Mobile applications will interact most frequently with the micropayment database for the
following activities:
• Retrieving the current status of a micropayment;
• Modifying the status of the current micropayment; and
• Canceling the micropayment.
The mobile application will need to meet the following requirements:
• Communicate with web services that assign a new user to a micropayment by using a
stored procedure named usp_AssignUser.
• Update the location of the user by using a stored procedure named
usp_AddMobileLocation.
The fraud detection service will need to meet the following requirements:
• Query the current open micropayments for users who own multiple micropayments by
using a stored procedure named usp.LookupConcurrentUsers.
• Persist the current user locations by using a stored procedure named
usp_Mobilel_ocationSnapshot.
• Look at the status of micropayments and mark micropayments for internal
investigations.
• Move micropayments to dbo.POSException table by using a stored procedure named
ups_DetectSuspiciousActivity.
• Detect micropayments that are flagged with a StatusId value that is greater than 3 and
that occurred within the last minute.
The CoffeeAnalytics database will combine imports of the POSTransaction and
MobileLocation tables to create a UserActivity table for reports on the trends in activity.
Queries against the UserActivity table will include aggregated calculations on all columns
that are not used in filters or groupings.
Micropayments need to be updated and queried for only a week after their creation by the
mobile application or fraud detection services.
Performance
The most critical performance requirement is keeping the response time for any queries of the
POSTransaction table predictable and fast.
Web service queries will take a higher priority in performance tuning decisions over the fraud
detection agent queries.
Scalability
Queries of the user of a micropayment cannot return while the micropayment is being
updated, but can show different users during different stages of the transaction.
The fraud detection service frequently will run queries over the micropayments that occur
over different time periods that range between 30 seconds and ten minutes.

The POSTransaction table must have its structure optimized for hundreds of thousands of
active micropayments that are updated frequently.
All changes to the POSTransaction table will require testing in order to confirm the expected
throughput that will support the first year’s performance requirements.
Updates of a user’s location can tolerate some data loss.
Initial testing has determined that the POSTransaction and POSException tables will be
migrated to an in-memory optimized table.
Availability
In order to minimize disruption at local stores during consolidation, nightly processes will
restore the databases to a staging server at corporate headquarters.
Technical Requirements
Security
The sensitive nature of financial transactions in the store databases requires certification of
the COFFECORP\Auditors group at corporate that will perform audits of the data. Members
of the COFFECORP\Auditors group cannot have sysadmin or datawriter access to the
database.
Compliance requires that the data stewards have access to any restored StoreTransactions
database without changing any security settings at a database level.
Nightly batch processes are run by the services account in the COFFECORP\StoreAgent
group and need to be able to restore and verify the schema of the store databases match.
No Windows group should have more access to store databases than is necessary.
Maintainability
You need to anticipate when POSTransaction table will need index maintenance.
When the daily maintenance finishes, micropayments that are one week old must be available
for queries in UserActivity table but will be queried most frequently within their first week
and will require support for in-memory queries for data within first week.
The maintenance of the UserActivity table must allow frequent maintenance on the day’s
most recent activities with minimal impact on the use of disk space and the resources
available to queries. The processes that add data to the UserActivity table must be able to
update data from any time period, even while maintenance is running.
The index maintenance strategy for the UserActivity table must provide the optimal structure
for both maintainability and query performance.
All micropayments queries must include the most permissive isolation level available for the
maximum throughput.
In the event of unexpected results, all stored procedures must provide error messages in text
message to the calling web service.
Any modifications to stored procedures will require the minimal amount of schema changes
necessary to increase the performance.
Performance
Stress testing of the mobile application on the proposed CoffeeTransactions database
uncovered performance bottlenecks. The sys.dm_os_wait_stats Dynamic Management View

(DMV) shows high wait_time values for WRTTELOG and PAGEIOLATCHJJP wait types
when updating the MobileLocation table.
Updates to the MobileLocation table must have minimal impact on physical resources.
Supporting Infrastructure
The stored procedure usp_LookupConcurrentUsers has the current implementation:

The current stored procedure for persisting a user location is defined in the following code:

The current stored procedure for managing micropayments needing investigation is defined
in the following code:

The current table, before implementing any performance enhancements, is defined as
follows:

###EndCaseStudy###

You need to implement security for the restore and audit process. What should you do?

###BeginCaseStudy###
Case Study: 7
Fourth Coffee
Background
Corporate Information
Fourth Coffee is global restaurant chain. There are more than 5,000 locations worldwide.
Physical Locations
Currently a server at each location hosts a SQL Server 2012 instance. Each instance contains
a database called StoreTransactions that stores all transactions from point of sale and uploads
summary batches nightly.
Each server belongs to the COFFECORP domain. Local computer accounts access the
StoreTransactions database at each store using sysadmin and datareaderwriter roles.

Planned changes
Fourth Coffee has three major initiatives:
• The FT department must consolidate the point of sales database infrastructure.
• The marketing department plans to launch a mobile application for micropayments.
• The finance department wants to deploy an internal tool that will help detect fraud.
Initially, the mobile application will allow customers to make micropayments to buy coffee
and other items on the company web site. These micropayments may be sent as gifts to other
users and redeemed within an hour of ownership transfer. Later versions will generate
profiles based on customer activity that will push texts and ads generated by an analytics
application.
When the consolidation is finished and the mobile application is in production, the
micropayments and point of sale transactions will use the same database.
Existing Environment
Existing Application Environment
Some stores have been using several pilot versions of the micropayment application. Each
version currently is in a database that is independent from the point of sales systems. Some
versions have been used in field tests at local stores, and others are hosted at corporate
servers. All pilot versions were developed by using SQL Server 2012.
Existing Support Infrastructure
The proposed database for consolidating micropayments and transactions is called
CoffeeTransactions. The database is hosted on a SQL Server 2014 Enterprise Edition
instance and has the following file structures:

Business Requirements
General Application Solution Requirements
The database infrastructure must support a phased global rollout of the micropayment
application and consolidation.

The consolidated micropayment and point of sales database will be into a CoffeeTransactions
database. The infrastructure also will include a new CoffeeAnalytics database for reporting
on content from CoffeeTransactions.
Mobile applications will interact most frequently with the micropayment database for the
following activities:
• Retrieving the current status of a micropayment;
• Modifying the status of the current micropayment; and
• Canceling the micropayment.
The mobile application will need to meet the following requirements:
• Communicate with web services that assign a new user to a micropayment by using a
stored procedure named usp_AssignUser.
• Update the location of the user by using a stored procedure named
usp_AddMobileLocation.
The fraud detection service will need to meet the following requirements:
• Query the current open micropayments for users who own multiple micropayments by
using a stored procedure named usp.LookupConcurrentUsers.
• Persist the current user locations by using a stored procedure named
usp_Mobilel_ocationSnapshot.
• Look at the status of micropayments and mark micropayments for internal
investigations.
• Move micropayments to dbo.POSException table by using a stored procedure named
ups_DetectSuspiciousActivity.
• Detect micropayments that are flagged with a StatusId value that is greater than 3 and
that occurred within the last minute.
The CoffeeAnalytics database will combine imports of the POSTransaction and
MobileLocation tables to create a UserActivity table for reports on the trends in activity.
Queries against the UserActivity table will include aggregated calculations on all columns
that are not used in filters or groupings.
Micropayments need to be updated and queried for only a week after their creation by the
mobile application or fraud detection services.
Performance
The most critical performance requirement is keeping the response time for any queries of the
POSTransaction table predictable and fast.
Web service queries will take a higher priority in performance tuning decisions over the fraud
detection agent queries.
Scalability
Queries of the user of a micropayment cannot return while the micropayment is being
updated, but can show different users during different stages of the transaction.
The fraud detection service frequently will run queries over the micropayments that occur
over different time periods that range between 30 seconds and ten minutes.

The POSTransaction table must have its structure optimized for hundreds of thousands of
active micropayments that are updated frequently.
All changes to the POSTransaction table will require testing in order to confirm the expected
throughput that will support the first year’s performance requirements.
Updates of a user’s location can tolerate some data loss.
Initial testing has determined that the POSTransaction and POSException tables will be
migrated to an in-memory optimized table.
Availability
In order to minimize disruption at local stores during consolidation, nightly processes will
restore the databases to a staging server at corporate headquarters.
Technical Requirements
Security
The sensitive nature of financial transactions in the store databases requires certification of
the COFFECORP\Auditors group at corporate that will perform audits of the data. Members
of the COFFECORP\Auditors group cannot have sysadmin or datawriter access to the
database.
Compliance requires that the data stewards have access to any restored StoreTransactions
database without changing any security settings at a database level.
Nightly batch processes are run by the services account in the COFFECORP\StoreAgent
group and need to be able to restore and verify the schema of the store databases match.
No Windows group should have more access to store databases than is necessary.
Maintainability
You need to anticipate when POSTransaction table will need index maintenance.
When the daily maintenance finishes, micropayments that are one week old must be available
for queries in UserActivity table but will be queried most frequently within their first week
and will require support for in-memory queries for data within first week.
The maintenance of the UserActivity table must allow frequent maintenance on the day’s
most recent activities with minimal impact on the use of disk space and the resources
available to queries. The processes that add data to the UserActivity table must be able to
update data from any time period, even while maintenance is running.
The index maintenance strategy for the UserActivity table must provide the optimal structure
for both maintainability and query performance.
All micropayments queries must include the most permissive isolation level available for the
maximum throughput.
In the event of unexpected results, all stored procedures must provide error messages in text
message to the calling web service.
Any modifications to stored procedures will require the minimal amount of schema changes
necessary to increase the performance.
Performance
Stress testing of the mobile application on the proposed CoffeeTransactions database
uncovered performance bottlenecks. The sys.dm_os_wait_stats Dynamic Management View

(DMV) shows high wait_time values for WRTTELOG and PAGEIOLATCHJJP wait types
when updating the MobileLocation table.
Updates to the MobileLocation table must have minimal impact on physical resources.
Supporting Infrastructure
The stored procedure usp_LookupConcurrentUsers has the current implementation:

The current stored procedure for persisting a user location is defined in the following code:

The current stored procedure for managing micropayments needing investigation is defined
in the following code:

The current table, before implementing any performance enhancements, is defined as
follows:

###EndCaseStudy###

You need to modify the usp_DetectSuspiciousActivity stored procedure.
Which two actions should you perform? Each correct answer presents part of the solution.
Choose two.

###BeginCaseStudy###
Case Study: 7
Fourth Coffee
Background
Corporate Information
Fourth Coffee is global restaurant chain. There are more than 5,000 locations worldwide.
Physical Locations
Currently a server at each location hosts a SQL Server 2012 instance. Each instance contains
a database called StoreTransactions that stores all transactions from point of sale and uploads
summary batches nightly.
Each server belongs to the COFFECORP domain. Local computer accounts access the
StoreTransactions database at each store using sysadmin and datareaderwriter roles.

Planned changes
Fourth Coffee has three major initiatives:
• The FT department must consolidate the point of sales database infrastructure.
• The marketing department plans to launch a mobile application for micropayments.
• The finance department wants to deploy an internal tool that will help detect fraud.
Initially, the mobile application will allow customers to make micropayments to buy coffee
and other items on the company web site. These micropayments may be sent as gifts to other
users and redeemed within an hour of ownership transfer. Later versions will generate
profiles based on customer activity that will push texts and ads generated by an analytics
application.
When the consolidation is finished and the mobile application is in production, the
micropayments and point of sale transactions will use the same database.
Existing Environment
Existing Application Environment
Some stores have been using several pilot versions of the micropayment application. Each
version currently is in a database that is independent from the point of sales systems. Some
versions have been used in field tests at local stores, and others are hosted at corporate
servers. All pilot versions were developed by using SQL Server 2012.
Existing Support Infrastructure
The proposed database for consolidating micropayments and transactions is called
CoffeeTransactions. The database is hosted on a SQL Server 2014 Enterprise Edition
instance and has the following file structures:

Business Requirements
General Application Solution Requirements
The database infrastructure must support a phased global rollout of the micropayment
application and consolidation.

The consolidated micropayment and point of sales database will be into a CoffeeTransactions
database. The infrastructure also will include a new CoffeeAnalytics database for reporting
on content from CoffeeTransactions.
Mobile applications will interact most frequently with the micropayment database for the
following activities:
• Retrieving the current status of a micropayment;
• Modifying the status of the current micropayment; and
• Canceling the micropayment.
The mobile application will need to meet the following requirements:
• Communicate with web services that assign a new user to a micropayment by using a
stored procedure named usp_AssignUser.
• Update the location of the user by using a stored procedure named
usp_AddMobileLocation.
The fraud detection service will need to meet the following requirements:
• Query the current open micropayments for users who own multiple micropayments by
using a stored procedure named usp.LookupConcurrentUsers.
• Persist the current user locations by using a stored procedure named
usp_Mobilel_ocationSnapshot.
• Look at the status of micropayments and mark micropayments for internal
investigations.
• Move micropayments to dbo.POSException table by using a stored procedure named
ups_DetectSuspiciousActivity.
• Detect micropayments that are flagged with a StatusId value that is greater than 3 and
that occurred within the last minute.
The CoffeeAnalytics database will combine imports of the POSTransaction and
MobileLocation tables to create a UserActivity table for reports on the trends in activity.
Queries against the UserActivity table will include aggregated calculations on all columns
that are not used in filters or groupings.
Micropayments need to be updated and queried for only a week after their creation by the
mobile application or fraud detection services.
Performance
The most critical performance requirement is keeping the response time for any queries of the
POSTransaction table predictable and fast.
Web service queries will take a higher priority in performance tuning decisions over the fraud
detection agent queries.
Scalability
Queries of the user of a micropayment cannot return while the micropayment is being
updated, but can show different users during different stages of the transaction.
The fraud detection service frequently will run queries over the micropayments that occur
over different time periods that range between 30 seconds and ten minutes.

The POSTransaction table must have its structure optimized for hundreds of thousands of
active micropayments that are updated frequently.
All changes to the POSTransaction table will require testing in order to confirm the expected
throughput that will support the first year’s performance requirements.
Updates of a user’s location can tolerate some data loss.
Initial testing has determined that the POSTransaction and POSException tables will be
migrated to an in-memory optimized table.
Availability
In order to minimize disruption at local stores during consolidation, nightly processes will
restore the databases to a staging server at corporate headquarters.
Technical Requirements
Security
The sensitive nature of financial transactions in the store databases requires certification of
the COFFECORP\Auditors group at corporate that will perform audits of the data. Members
of the COFFECORP\Auditors group cannot have sysadmin or datawriter access to the
database.
Compliance requires that the data stewards have access to any restored StoreTransactions
database without changing any security settings at a database level.
Nightly batch processes are run by the services account in the COFFECORP\StoreAgent
group and need to be able to restore and verify the schema of the store databases match.
No Windows group should have more access to store databases than is necessary.
Maintainability
You need to anticipate when POSTransaction table will need index maintenance.
When the daily maintenance finishes, micropayments that are one week old must be available
for queries in UserActivity table but will be queried most frequently within their first week
and will require support for in-memory queries for data within first week.
The maintenance of the UserActivity table must allow frequent maintenance on the day’s
most recent activities with minimal impact on the use of disk space and the resources
available to queries. The processes that add data to the UserActivity table must be able to
update data from any time period, even while maintenance is running.
The index maintenance strategy for the UserActivity table must provide the optimal structure
for both maintainability and query performance.
All micropayments queries must include the most permissive isolation level available for the
maximum throughput.
In the event of unexpected results, all stored procedures must provide error messages in text
message to the calling web service.
Any modifications to stored procedures will require the minimal amount of schema changes
necessary to increase the performance.
Performance
Stress testing of the mobile application on the proposed CoffeeTransactions database
uncovered performance bottlenecks. The sys.dm_os_wait_stats Dynamic Management View

(DMV) shows high wait_time values for WRTTELOG and PAGEIOLATCHJJP wait types
when updating the MobileLocation table.
Updates to the MobileLocation table must have minimal impact on physical resources.
Supporting Infrastructure
The stored procedure usp_LookupConcurrentUsers has the current implementation:

The current stored procedure for persisting a user location is defined in the following code:

The current stored procedure for managing micropayments needing investigation is defined
in the following code:

The current table, before implementing any performance enhancements, is defined as
follows:

###EndCaseStudy###

DRAG DROP
You need to create the usp.AssignUser stored procedure.
Develop the solution by selecting and arranging the required code blocks in the correct
order. You may not need all of the code blocks.

###BeginCaseStudy###
Case Study: 7
Fourth Coffee
Background
Corporate Information
Fourth Coffee is global restaurant chain. There are more than 5,000 locations worldwide.
Physical Locations
Currently a server at each location hosts a SQL Server 2012 instance. Each instance contains
a database called StoreTransactions that stores all transactions from point of sale and uploads
summary batches nightly.
Each server belongs to the COFFECORP domain. Local computer accounts access the
StoreTransactions database at each store using sysadmin and datareaderwriter roles.

Planned changes
Fourth Coffee has three major initiatives:
• The FT department must consolidate the point of sales database infrastructure.
• The marketing department plans to launch a mobile application for micropayments.
• The finance department wants to deploy an internal tool that will help detect fraud.
Initially, the mobile application will allow customers to make micropayments to buy coffee
and other items on the company web site. These micropayments may be sent as gifts to other
users and redeemed within an hour of ownership transfer. Later versions will generate
profiles based on customer activity that will push texts and ads generated by an analytics
application.
When the consolidation is finished and the mobile application is in production, the
micropayments and point of sale transactions will use the same database.
Existing Environment
Existing Application Environment
Some stores have been using several pilot versions of the micropayment application. Each
version currently is in a database that is independent from the point of sales systems. Some
versions have been used in field tests at local stores, and others are hosted at corporate
servers. All pilot versions were developed by using SQL Server 2012.
Existing Support Infrastructure
The proposed database for consolidating micropayments and transactions is called
CoffeeTransactions. The database is hosted on a SQL Server 2014 Enterprise Edition
instance and has the following file structures:

Business Requirements
General Application Solution Requirements
The database infrastructure must support a phased global rollout of the micropayment
application and consolidation.

The consolidated micropayment and point of sales database will be into a CoffeeTransactions
database. The infrastructure also will include a new CoffeeAnalytics database for reporting
on content from CoffeeTransactions.
Mobile applications will interact most frequently with the micropayment database for the
following activities:
• Retrieving the current status of a micropayment;
• Modifying the status of the current micropayment; and
• Canceling the micropayment.
The mobile application will need to meet the following requirements:
• Communicate with web services that assign a new user to a micropayment by using a
stored procedure named usp_AssignUser.
• Update the location of the user by using a stored procedure named
usp_AddMobileLocation.
The fraud detection service will need to meet the following requirements:
• Query the current open micropayments for users who own multiple micropayments by
using a stored procedure named usp.LookupConcurrentUsers.
• Persist the current user locations by using a stored procedure named
usp_Mobilel_ocationSnapshot.
• Look at the status of micropayments and mark micropayments for internal
investigations.
• Move micropayments to dbo.POSException table by using a stored procedure named
ups_DetectSuspiciousActivity.
• Detect micropayments that are flagged with a StatusId value that is greater than 3 and
that occurred within the last minute.
The CoffeeAnalytics database will combine imports of the POSTransaction and
MobileLocation tables to create a UserActivity table for reports on the trends in activity.
Queries against the UserActivity table will include aggregated calculations on all columns
that are not used in filters or groupings.
Micropayments need to be updated and queried for only a week after their creation by the
mobile application or fraud detection services.
Performance
The most critical performance requirement is keeping the response time for any queries of the
POSTransaction table predictable and fast.
Web service queries will take a higher priority in performance tuning decisions over the fraud
detection agent queries.
Scalability
Queries of the user of a micropayment cannot return while the micropayment is being
updated, but can show different users during different stages of the transaction.
The fraud detection service frequently will run queries over the micropayments that occur
over different time periods that range between 30 seconds and ten minutes.

The POSTransaction table must have its structure optimized for hundreds of thousands of
active micropayments that are updated frequently.
All changes to the POSTransaction table will require testing in order to confirm the expected
throughput that will support the first year’s performance requirements.
Updates of a user’s location can tolerate some data loss.
Initial testing has determined that the POSTransaction and POSException tables will be
migrated to an in-memory optimized table.
Availability
In order to minimize disruption at local stores during consolidation, nightly processes will
restore the databases to a staging server at corporate headquarters.
Technical Requirements
Security
The sensitive nature of financial transactions in the store databases requires certification of
the COFFECORP\Auditors group at corporate that will perform audits of the data. Members
of the COFFECORP\Auditors group cannot have sysadmin or datawriter access to the
database.
Compliance requires that the data stewards have access to any restored StoreTransactions
database without changing any security settings at a database level.
Nightly batch processes are run by the services account in the COFFECORP\StoreAgent
group and need to be able to restore and verify the schema of the store databases match.
No Windows group should have more access to store databases than is necessary.
Maintainability
You need to anticipate when POSTransaction table will need index maintenance.
When the daily maintenance finishes, micropayments that are one week old must be available
for queries in UserActivity table but will be queried most frequently within their first week
and will require support for in-memory queries for data within first week.
The maintenance of the UserActivity table must allow frequent maintenance on the day’s
most recent activities with minimal impact on the use of disk space and the resources
available to queries. The processes that add data to the UserActivity table must be able to
update data from any time period, even while maintenance is running.
The index maintenance strategy for the UserActivity table must provide the optimal structure
for both maintainability and query performance.
All micropayments queries must include the most permissive isolation level available for the
maximum throughput.
In the event of unexpected results, all stored procedures must provide error messages in text
message to the calling web service.
Any modifications to stored procedures will require the minimal amount of schema changes
necessary to increase the performance.
Performance
Stress testing of the mobile application on the proposed CoffeeTransactions database
uncovered performance bottlenecks. The sys.dm_os_wait_stats Dynamic Management View

(DMV) shows high wait_time values for WRTTELOG and PAGEIOLATCHJJP wait types
when updating the MobileLocation table.
Updates to the MobileLocation table must have minimal impact on physical resources.
Supporting Infrastructure
The stored procedure usp_LookupConcurrentUsers has the current implementation:

The current stored procedure for persisting a user location is defined in the following code:

The current stored procedure for managing micropayments needing investigation is defined
in the following code:

The current table, before implementing any performance enhancements, is defined as
follows:

###EndCaseStudy###

DRAG DROP
You need to implement a new version of usp_AddMobileLocation. Develop the solution by
selecting and arranging the required code blocks in the correct order. You may not need all
of the code blocks.

###BeginCaseStudy###
Case Study: 7
Fourth Coffee
Background
Corporate Information
Fourth Coffee is global restaurant chain. There are more than 5,000 locations worldwide.
Physical Locations
Currently a server at each location hosts a SQL Server 2012 instance. Each instance contains
a database called StoreTransactions that stores all transactions from point of sale and uploads
summary batches nightly.
Each server belongs to the COFFECORP domain. Local computer accounts access the
StoreTransactions database at each store using sysadmin and datareaderwriter roles.

Planned changes
Fourth Coffee has three major initiatives:
• The FT department must consolidate the point of sales database infrastructure.
• The marketing department plans to launch a mobile application for micropayments.
• The finance department wants to deploy an internal tool that will help detect fraud.
Initially, the mobile application will allow customers to make micropayments to buy coffee
and other items on the company web site. These micropayments may be sent as gifts to other
users and redeemed within an hour of ownership transfer. Later versions will generate
profiles based on customer activity that will push texts and ads generated by an analytics
application.
When the consolidation is finished and the mobile application is in production, the
micropayments and point of sale transactions will use the same database.
Existing Environment
Existing Application Environment
Some stores have been using several pilot versions of the micropayment application. Each
version currently is in a database that is independent from the point of sales systems. Some
versions have been used in field tests at local stores, and others are hosted at corporate
servers. All pilot versions were developed by using SQL Server 2012.
Existing Support Infrastructure
The proposed database for consolidating micropayments and transactions is called
CoffeeTransactions. The database is hosted on a SQL Server 2014 Enterprise Edition
instance and has the following file structures:

Business Requirements
General Application Solution Requirements
The database infrastructure must support a phased global rollout of the micropayment
application and consolidation.

The consolidated micropayment and point of sales database will be into a CoffeeTransactions
database. The infrastructure also will include a new CoffeeAnalytics database for reporting
on content from CoffeeTransactions.
Mobile applications will interact most frequently with the micropayment database for the
following activities:
• Retrieving the current status of a micropayment;
• Modifying the status of the current micropayment; and
• Canceling the micropayment.
The mobile application will need to meet the following requirements:
• Communicate with web services that assign a new user to a micropayment by using a
stored procedure named usp_AssignUser.
• Update the location of the user by using a stored procedure named
usp_AddMobileLocation.
The fraud detection service will need to meet the following requirements:
• Query the current open micropayments for users who own multiple micropayments by
using a stored procedure named usp.LookupConcurrentUsers.
• Persist the current user locations by using a stored procedure named
usp_Mobilel_ocationSnapshot.
• Look at the status of micropayments and mark micropayments for internal
investigations.
• Move micropayments to dbo.POSException table by using a stored procedure named
ups_DetectSuspiciousActivity.
• Detect micropayments that are flagged with a StatusId value that is greater than 3 and
that occurred within the last minute.
The CoffeeAnalytics database will combine imports of the POSTransaction and
MobileLocation tables to create a UserActivity table for reports on the trends in activity.
Queries against the UserActivity table will include aggregated calculations on all columns
that are not used in filters or groupings.
Micropayments need to be updated and queried for only a week after their creation by the
mobile application or fraud detection services.
Performance
The most critical performance requirement is keeping the response time for any queries of the
POSTransaction table predictable and fast.
Web service queries will take a higher priority in performance tuning decisions over the fraud
detection agent queries.
Scalability
Queries of the user of a micropayment cannot return while the micropayment is being
updated, but can show different users during different stages of the transaction.
The fraud detection service frequently will run queries over the micropayments that occur
over different time periods that range between 30 seconds and ten minutes.

The POSTransaction table must have its structure optimized for hundreds of thousands of
active micropayments that are updated frequently.
All changes to the POSTransaction table will require testing in order to confirm the expected
throughput that will support the first year’s performance requirements.
Updates of a user’s location can tolerate some data loss.
Initial testing has determined that the POSTransaction and POSException tables will be
migrated to an in-memory optimized table.
Availability
In order to minimize disruption at local stores during consolidation, nightly processes will
restore the databases to a staging server at corporate headquarters.
Technical Requirements
Security
The sensitive nature of financial transactions in the store databases requires certification of
the COFFECORP\Auditors group at corporate that will perform audits of the data. Members
of the COFFECORP\Auditors group cannot have sysadmin or datawriter access to the
database.
Compliance requires that the data stewards have access to any restored StoreTransactions
database without changing any security settings at a database level.
Nightly batch processes are run by the services account in the COFFECORP\StoreAgent
group and need to be able to restore and verify the schema of the store databases match.
No Windows group should have more access to store databases than is necessary.
Maintainability
You need to anticipate when POSTransaction table will need index maintenance.
When the daily maintenance finishes, micropayments that are one week old must be available
for queries in UserActivity table but will be queried most frequently within their first week
and will require support for in-memory queries for data within first week.
The maintenance of the UserActivity table must allow frequent maintenance on the day’s
most recent activities with minimal impact on the use of disk space and the resources
available to queries. The processes that add data to the UserActivity table must be able to
update data from any time period, even while maintenance is running.
The index maintenance strategy for the UserActivity table must provide the optimal structure
for both maintainability and query performance.
All micropayments queries must include the most permissive isolation level available for the
maximum throughput.
In the event of unexpected results, all stored procedures must provide error messages in text
message to the calling web service.
Any modifications to stored procedures will require the minimal amount of schema changes
necessary to increase the performance.
Performance
Stress testing of the mobile application on the proposed CoffeeTransactions database
uncovered performance bottlenecks. The sys.dm_os_wait_stats Dynamic Management View

(DMV) shows high wait_time values for WRTTELOG and PAGEIOLATCHJJP wait types
when updating the MobileLocation table.
Updates to the MobileLocation table must have minimal impact on physical resources.
Supporting Infrastructure
The stored procedure usp_LookupConcurrentUsers has the current implementation:

The current stored procedure for persisting a user location is defined in the following code:

The current stored procedure for managing micropayments needing investigation is defined
in the following code:

The current table, before implementing any performance enhancements, is defined as
follows:

###EndCaseStudy###

DRAG DROP
You need to redesign the system to meet the scalability requirements of the application.
Develop the solution by selecting and arranging the required code blocks in the correct
order.
You may not need all of the code blocks.

###BeginCaseStudy###
Case Study: 7
Fourth Coffee
Background
Corporate Information
Fourth Coffee is global restaurant chain. There are more than 5,000 locations worldwide.
Physical Locations
Currently a server at each location hosts a SQL Server 2012 instance. Each instance contains
a database called StoreTransactions that stores all transactions from point of sale and uploads
summary batches nightly.
Each server belongs to the COFFECORP domain. Local computer accounts access the
StoreTransactions database at each store using sysadmin and datareaderwriter roles.

Planned changes
Fourth Coffee has three major initiatives:
• The FT department must consolidate the point of sales database infrastructure.
• The marketing department plans to launch a mobile application for micropayments.
• The finance department wants to deploy an internal tool that will help detect fraud.
Initially, the mobile application will allow customers to make micropayments to buy coffee
and other items on the company web site. These micropayments may be sent as gifts to other
users and redeemed within an hour of ownership transfer. Later versions will generate
profiles based on customer activity that will push texts and ads generated by an analytics
application.
When the consolidation is finished and the mobile application is in production, the
micropayments and point of sale transactions will use the same database.
Existing Environment
Existing Application Environment
Some stores have been using several pilot versions of the micropayment application. Each
version currently is in a database that is independent from the point of sales systems. Some
versions have been used in field tests at local stores, and others are hosted at corporate
servers. All pilot versions were developed by using SQL Server 2012.
Existing Support Infrastructure
The proposed database for consolidating micropayments and transactions is called
CoffeeTransactions. The database is hosted on a SQL Server 2014 Enterprise Edition
instance and has the following file structures:

Business Requirements
General Application Solution Requirements
The database infrastructure must support a phased global rollout of the micropayment
application and consolidation.

The consolidated micropayment and point of sales database will be into a CoffeeTransactions
database. The infrastructure also will include a new CoffeeAnalytics database for reporting
on content from CoffeeTransactions.
Mobile applications will interact most frequently with the micropayment database for the
following activities:
• Retrieving the current status of a micropayment;
• Modifying the status of the current micropayment; and
• Canceling the micropayment.
The mobile application will need to meet the following requirements:
• Communicate with web services that assign a new user to a micropayment by using a
stored procedure named usp_AssignUser.
• Update the location of the user by using a stored procedure named
usp_AddMobileLocation.
The fraud detection service will need to meet the following requirements:
• Query the current open micropayments for users who own multiple micropayments by
using a stored procedure named usp.LookupConcurrentUsers.
• Persist the current user locations by using a stored procedure named
usp_Mobilel_ocationSnapshot.
• Look at the status of micropayments and mark micropayments for internal
investigations.
• Move micropayments to dbo.POSException table by using a stored procedure named
ups_DetectSuspiciousActivity.
• Detect micropayments that are flagged with a StatusId value that is greater than 3 and
that occurred within the last minute.
The CoffeeAnalytics database will combine imports of the POSTransaction and
MobileLocation tables to create a UserActivity table for reports on the trends in activity.
Queries against the UserActivity table will include aggregated calculations on all columns
that are not used in filters or groupings.
Micropayments need to be updated and queried for only a week after their creation by the
mobile application or fraud detection services.
Performance
The most critical performance requirement is keeping the response time for any queries of the
POSTransaction table predictable and fast.
Web service queries will take a higher priority in performance tuning decisions over the fraud
detection agent queries.
Scalability
Queries of the user of a micropayment cannot return while the micropayment is being
updated, but can show different users during different stages of the transaction.
The fraud detection service frequently will run queries over the micropayments that occur
over different time periods that range between 30 seconds and ten minutes.

The POSTransaction table must have its structure optimized for hundreds of thousands of
active micropayments that are updated frequently.
All changes to the POSTransaction table will require testing in order to confirm the expected
throughput that will support the first year’s performance requirements.
Updates of a user’s location can tolerate some data loss.
Initial testing has determined that the POSTransaction and POSException tables will be
migrated to an in-memory optimized table.
Availability
In order to minimize disruption at local stores during consolidation, nightly processes will
restore the databases to a staging server at corporate headquarters.
Technical Requirements
Security
The sensitive nature of financial transactions in the store databases requires certification of
the COFFECORP\Auditors group at corporate that will perform audits of the data. Members
of the COFFECORP\Auditors group cannot have sysadmin or datawriter access to the
database.
Compliance requires that the data stewards have access to any restored StoreTransactions
database without changing any security settings at a database level.
Nightly batch processes are run by the services account in the COFFECORP\StoreAgent
group and need to be able to restore and verify the schema of the store databases match.
No Windows group should have more access to store databases than is necessary.
Maintainability
You need to anticipate when POSTransaction table will need index maintenance.
When the daily maintenance finishes, micropayments that are one week old must be available
for queries in UserActivity table but will be queried most frequently within their first week
and will require support for in-memory queries for data within first week.
The maintenance of the UserActivity table must allow frequent maintenance on the day’s
most recent activities with minimal impact on the use of disk space and the resources
available to queries. The processes that add data to the UserActivity table must be able to
update data from any time period, even while maintenance is running.
The index maintenance strategy for the UserActivity table must provide the optimal structure
for both maintainability and query performance.
All micropayments queries must include the most permissive isolation level available for the
maximum throughput.
In the event of unexpected results, all stored procedures must provide error messages in text
message to the calling web service.
Any modifications to stored procedures will require the minimal amount of schema changes
necessary to increase the performance.
Performance
Stress testing of the mobile application on the proposed CoffeeTransactions database
uncovered performance bottlenecks. The sys.dm_os_wait_stats Dynamic Management View

(DMV) shows high wait_time values for WRTTELOG and PAGEIOLATCHJJP wait types
when updating the MobileLocation table.
Updates to the MobileLocation table must have minimal impact on physical resources.
Supporting Infrastructure
The stored procedure usp_LookupConcurrentUsers has the current implementation:

The current stored procedure for persisting a user location is defined in the following code:

The current stored procedure for managing micropayments needing investigation is defined
in the following code:

The current table, before implementing any performance enhancements, is defined as
follows:

###EndCaseStudy###

DRAG DROP
You need to optimize the index and table structures for POSTransaction.
Which task should you use with each maintenance step? To answer, drag the appropriate
tasks to the correct maintenance steps. Each task may be used once, more than once, or
not at all. You may need to drag the split bar between panes or scroll to view content.

###BeginCaseStudy###
Case Study: 7
Fourth Coffee
Background
Corporate Information
Fourth Coffee is global restaurant chain. There are more than 5,000 locations worldwide.
Physical Locations
Currently a server at each location hosts a SQL Server 2012 instance. Each instance contains
a database called StoreTransactions that stores all transactions from point of sale and uploads
summary batches nightly.
Each server belongs to the COFFECORP domain. Local computer accounts access the
StoreTransactions database at each store using sysadmin and datareaderwriter roles.

Planned changes
Fourth Coffee has three major initiatives:
• The FT department must consolidate the point of sales database infrastructure.
• The marketing department plans to launch a mobile application for micropayments.
• The finance department wants to deploy an internal tool that will help detect fraud.
Initially, the mobile application will allow customers to make micropayments to buy coffee
and other items on the company web site. These micropayments may be sent as gifts to other
users and redeemed within an hour of ownership transfer. Later versions will generate
profiles based on customer activity that will push texts and ads generated by an analytics
application.
When the consolidation is finished and the mobile application is in production, the
micropayments and point of sale transactions will use the same database.
Existing Environment
Existing Application Environment
Some stores have been using several pilot versions of the micropayment application. Each
version currently is in a database that is independent from the point of sales systems. Some
versions have been used in field tests at local stores, and others are hosted at corporate
servers. All pilot versions were developed by using SQL Server 2012.
Existing Support Infrastructure
The proposed database for consolidating micropayments and transactions is called
CoffeeTransactions. The database is hosted on a SQL Server 2014 Enterprise Edition
instance and has the following file structures:

Business Requirements
General Application Solution Requirements
The database infrastructure must support a phased global rollout of the micropayment
application and consolidation.

The consolidated micropayment and point of sales database will be into a CoffeeTransactions
database. The infrastructure also will include a new CoffeeAnalytics database for reporting
on content from CoffeeTransactions.
Mobile applications will interact most frequently with the micropayment database for the
following activities:
• Retrieving the current status of a micropayment;
• Modifying the status of the current micropayment; and
• Canceling the micropayment.
The mobile application will need to meet the following requirements:
• Communicate with web services that assign a new user to a micropayment by using a
stored procedure named usp_AssignUser.
• Update the location of the user by using a stored procedure named
usp_AddMobileLocation.
The fraud detection service will need to meet the following requirements:
• Query the current open micropayments for users who own multiple micropayments by
using a stored procedure named usp.LookupConcurrentUsers.
• Persist the current user locations by using a stored procedure named
usp_Mobilel_ocationSnapshot.
• Look at the status of micropayments and mark micropayments for internal
investigations.
• Move micropayments to dbo.POSException table by using a stored procedure named
ups_DetectSuspiciousActivity.
• Detect micropayments that are flagged with a StatusId value that is greater than 3 and
that occurred within the last minute.
The CoffeeAnalytics database will combine imports of the POSTransaction and
MobileLocation tables to create a UserActivity table for reports on the trends in activity.
Queries against the UserActivity table will include aggregated calculations on all columns
that are not used in filters or groupings.
Micropayments need to be updated and queried for only a week after their creation by the
mobile application or fraud detection services.
Performance
The most critical performance requirement is keeping the response time for any queries of the
POSTransaction table predictable and fast.
Web service queries will take a higher priority in performance tuning decisions over the fraud
detection agent queries.
Scalability
Queries of the user of a micropayment cannot return while the micropayment is being
updated, but can show different users during different stages of the transaction.
The fraud detection service frequently will run queries over the micropayments that occur
over different time periods that range between 30 seconds and ten minutes.

The POSTransaction table must have its structure optimized for hundreds of thousands of
active micropayments that are updated frequently.
All changes to the POSTransaction table will require testing in order to confirm the expected
throughput that will support the first year’s performance requirements.
Updates of a user’s location can tolerate some data loss.
Initial testing has determined that the POSTransaction and POSException tables will be
migrated to an in-memory optimized table.
Availability
In order to minimize disruption at local stores during consolidation, nightly processes will
restore the databases to a staging server at corporate headquarters.
Technical Requirements
Security
The sensitive nature of financial transactions in the store databases requires certification of
the COFFECORP\Auditors group at corporate that will perform audits of the data. Members
of the COFFECORP\Auditors group cannot have sysadmin or datawriter access to the
database.
Compliance requires that the data stewards have access to any restored StoreTransactions
database without changing any security settings at a database level.
Nightly batch processes are run by the services account in the COFFECORP\StoreAgent
group and need to be able to restore and verify the schema of the store databases match.
No Windows group should have more access to store databases than is necessary.
Maintainability
You need to anticipate when POSTransaction table will need index maintenance.
When the daily maintenance finishes, micropayments that are one week old must be available
for queries in UserActivity table but will be queried most frequently within their first week
and will require support for in-memory queries for data within first week.
The maintenance of the UserActivity table must allow frequent maintenance on the day’s
most recent activities with minimal impact on the use of disk space and the resources
available to queries. The processes that add data to the UserActivity table must be able to
update data from any time period, even while maintenance is running.
The index maintenance strategy for the UserActivity table must provide the optimal structure
for both maintainability and query performance.
All micropayments queries must include the most permissive isolation level available for the
maximum throughput.
In the event of unexpected results, all stored procedures must provide error messages in text
message to the calling web service.
Any modifications to stored procedures will require the minimal amount of schema changes
necessary to increase the performance.
Performance
Stress testing of the mobile application on the proposed CoffeeTransactions database
uncovered performance bottlenecks. The sys.dm_os_wait_stats Dynamic Management View

(DMV) shows high wait_time values for WRTTELOG and PAGEIOLATCHJJP wait types
when updating the MobileLocation table.
Updates to the MobileLocation table must have minimal impact on physical resources.
Supporting Infrastructure
The stored procedure usp_LookupConcurrentUsers has the current implementation:

The current stored procedure for persisting a user location is defined in the following code:

The current stored procedure for managing micropayments needing investigation is defined
in the following code:

The current table, before implementing any performance enhancements, is defined as
follows:

###EndCaseStudy###

You need to modify the stored procedure usp_LookupConcurrentUsers.
What should you do?

###BeginCaseStudy###
Case Study: 7
Fourth Coffee
Background
Corporate Information
Fourth Coffee is global restaurant chain. There are more than 5,000 locations worldwide.
Physical Locations
Currently a server at each location hosts a SQL Server 2012 instance. Each instance contains
a database called StoreTransactions that stores all transactions from point of sale and uploads
summary batches nightly.
Each server belongs to the COFFECORP domain. Local computer accounts access the
StoreTransactions database at each store using sysadmin and datareaderwriter roles.

Planned changes
Fourth Coffee has three major initiatives:
• The FT department must consolidate the point of sales database infrastructure.
• The marketing department plans to launch a mobile application for micropayments.
• The finance department wants to deploy an internal tool that will help detect fraud.
Initially, the mobile application will allow customers to make micropayments to buy coffee
and other items on the company web site. These micropayments may be sent as gifts to other
users and redeemed within an hour of ownership transfer. Later versions will generate
profiles based on customer activity that will push texts and ads generated by an analytics
application.
When the consolidation is finished and the mobile application is in production, the
micropayments and point of sale transactions will use the same database.
Existing Environment
Existing Application Environment
Some stores have been using several pilot versions of the micropayment application. Each
version currently is in a database that is independent from the point of sales systems. Some
versions have been used in field tests at local stores, and others are hosted at corporate
servers. All pilot versions were developed by using SQL Server 2012.
Existing Support Infrastructure
The proposed database for consolidating micropayments and transactions is called
CoffeeTransactions. The database is hosted on a SQL Server 2014 Enterprise Edition
instance and has the following file structures:

Business Requirements
General Application Solution Requirements
The database infrastructure must support a phased global rollout of the micropayment
application and consolidation.

The consolidated micropayment and point of sales database will be into a CoffeeTransactions
database. The infrastructure also will include a new CoffeeAnalytics database for reporting
on content from CoffeeTransactions.
Mobile applications will interact most frequently with the micropayment database for the
following activities:
• Retrieving the current status of a micropayment;
• Modifying the status of the current micropayment; and
• Canceling the micropayment.
The mobile application will need to meet the following requirements:
• Communicate with web services that assign a new user to a micropayment by using a
stored procedure named usp_AssignUser.
• Update the location of the user by using a stored procedure named
usp_AddMobileLocation.
The fraud detection service will need to meet the following requirements:
• Query the current open micropayments for users who own multiple micropayments by
using a stored procedure named usp.LookupConcurrentUsers.
• Persist the current user locations by using a stored procedure named
usp_Mobilel_ocationSnapshot.
• Look at the status of micropayments and mark micropayments for internal
investigations.
• Move micropayments to dbo.POSException table by using a stored procedure named
ups_DetectSuspiciousActivity.
• Detect micropayments that are flagged with a StatusId value that is greater than 3 and
that occurred within the last minute.
The CoffeeAnalytics database will combine imports of the POSTransaction and
MobileLocation tables to create a UserActivity table for reports on the trends in activity.
Queries against the UserActivity table will include aggregated calculations on all columns
that are not used in filters or groupings.
Micropayments need to be updated and queried for only a week after their creation by the
mobile application or fraud detection services.
Performance
The most critical performance requirement is keeping the response time for any queries of the
POSTransaction table predictable and fast.
Web service queries will take a higher priority in performance tuning decisions over the fraud
detection agent queries.
Scalability
Queries of the user of a micropayment cannot return while the micropayment is being
updated, but can show different users during different stages of the transaction.
The fraud detection service frequently will run queries over the micropayments that occur
over different time periods that range between 30 seconds and ten minutes.

The POSTransaction table must have its structure optimized for hundreds of thousands of
active micropayments that are updated frequently.
All changes to the POSTransaction table will require testing in order to confirm the expected
throughput that will support the first year’s performance requirements.
Updates of a user’s location can tolerate some data loss.
Initial testing has determined that the POSTransaction and POSException tables will be
migrated to an in-memory optimized table.
Availability
In order to minimize disruption at local stores during consolidation, nightly processes will
restore the databases to a staging server at corporate headquarters.
Technical Requirements
Security
The sensitive nature of financial transactions in the store databases requires certification of
the COFFECORP\Auditors group at corporate that will perform audits of the data. Members
of the COFFECORP\Auditors group cannot have sysadmin or datawriter access to the
database.
Compliance requires that the data stewards have access to any restored StoreTransactions
database without changing any security settings at a database level.
Nightly batch processes are run by the services account in the COFFECORP\StoreAgent
group and need to be able to restore and verify the schema of the store databases match.
No Windows group should have more access to store databases than is necessary.
Maintainability
You need to anticipate when POSTransaction table will need index maintenance.
When the daily maintenance finishes, micropayments that are one week old must be available
for queries in UserActivity table but will be queried most frequently within their first week
and will require support for in-memory queries for data within first week.
The maintenance of the UserActivity table must allow frequent maintenance on the day’s
most recent activities with minimal impact on the use of disk space and the resources
available to queries. The processes that add data to the UserActivity table must be able to
update data from any time period, even while maintenance is running.
The index maintenance strategy for the UserActivity table must provide the optimal structure
for both maintainability and query performance.
All micropayments queries must include the most permissive isolation level available for the
maximum throughput.
In the event of unexpected results, all stored procedures must provide error messages in text
message to the calling web service.
Any modifications to stored procedures will require the minimal amount of schema changes
necessary to increase the performance.
Performance
Stress testing of the mobile application on the proposed CoffeeTransactions database
uncovered performance bottlenecks. The sys.dm_os_wait_stats Dynamic Management View

(DMV) shows high wait_time values for WRTTELOG and PAGEIOLATCHJJP wait types
when updating the MobileLocation table.
Updates to the MobileLocation table must have minimal impact on physical resources.
Supporting Infrastructure
The stored procedure usp_LookupConcurrentUsers has the current implementation:

The current stored procedure for persisting a user location is defined in the following code:

The current stored procedure for managing micropayments needing investigation is defined
in the following code:

The current table, before implementing any performance enhancements, is defined as
follows:

###EndCaseStudy###

You need to optimize the index structure that is used by the tables that support the fraud
detection services.
What should you do?