###BeginCaseStudy###

Testlet 1
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 IT 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_MobileLocationSnapshot.
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 orfraud 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 inmemory 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 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.
Select and Place:

###BeginCaseStudy###

Testlet 1
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 IT 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_MobileLocationSnapshot.
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 orfraud 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 inmemory 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 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.
Select and Place:

###BeginCaseStudy###

Testlet 1
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 IT 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_MobileLocationSnapshot.
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 orfraud 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 inmemory 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###

Testlet 1
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 IT 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_MobileLocationSnapshot.
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 orfraud 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 inmemory 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 design the UserActivity table.
Which three steps should you perform in sequence? To answer, move the appropriate three actions from the
list of actions to the answer area and arrange them in the correct order.
Select and Place:

###BeginCaseStudy###

Testlet 1
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 IT 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_MobileLocationSnapshot.
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 orfraud 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 inmemory 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 monitor the health of your tables and indexes in order to implement the required index
maintenance strategy.
What should you do?

###BeginCaseStudy###

Testlet 1
Coho Winery
Overview
You are a database developer for a company named Coho Winery. Coho Winery has an office in London.
Coho Winery has an application that is used to process purchase orders from customers and retailers in 10
different countries.
The application uses a web front end to process orders from the Internet. The web front end adds orders to a
database named Sales. The Sales database is managed by a server named Server1.
An empty copy of the Sales database is created on a server named Server2 in the London office. The database
will store sales data for customers in Europe.
A new version of the application is being developed. In the new version, orders will be placed either by using the
existing web front end or by loading an XML file.
Once a week, you receive two files that contain the purchase orders and the order details of orders from
offshore facilities.
You run the usp_ImportOders stored procedure and the usp_ImportOrderDetails stored procedure to copy the
offshore facility orders to the Sales database.
The Sales database contains a table named Orders that has more than 20 million rows.
Database Definitions
Database and Tables
The following scripts are used to create the database and its tables:

Stored Procedures
The following are the definitions of the stored procedures used in the database:

Indexes
The following indexes are part of the Sales database:

Data Import
The XML files will contain the list of items in each order. Each retailer will have its own XML schema and will be
able to use different types of encoding. Each XML schema will use a default namespace. The defaultnamespaces are not guaranteed to be unique.
For testing purposes, you receive an XSD file from a customer.
For testing purposes, you also create an XML schema collection named ValidateOrder. ValidateOrder contains
schemas for all of the retailers.
The new version of the application must validate the XML file, parse the data, and store the parsed data along
with the original XML file in the database. The original XML file must be stored without losing any data.
Reported Issues
Performance Issues
You notice the following for the usp_GetOrdersAndItems stored procedure:
The stored procedure takes a long time to complete.
Less than two percent of the rows in the Orders table are retrieved by usp_GetOrdersAndItems.
A full table scan runs when the stored procedure executes.
The amount of disk space used and the amount of time required to insert data are very high.
You notice that the usp_GetOrdersByProduct stored procedure uses a table scan when the stored procedure is
executed.
Page Split Issues
Updates to the Orders table cause excessive page splits on the IX_Orders_ShipDate index.
Requirements
Site Requirements
Users located in North America must be able to view sales data for customers in North America and Europe in
a single report. The solution must minimize the amount of traffic over the WAN link between the offices.
Bulk Insert Requirements
The usp_ImportOrderDetails stored procedure takes more than 10 minutes to complete. The stored procedure
runs daily. If the stored procedure fails, you must ensure that the stored procedure restarts from the last
successful set of rows.
Index Monitoring Requirements
The usage of indexes in the Sales database must be monitored continuously. Monitored data must be
maintained if a server restarts. The monitoring solution must minimize the usage of memory resources and
processing resources.

###EndCaseStudy###

You need to modify usp.GetOrdersAndItems to ensure that an order is NOT retrieved by
usp_GetOrdersAndItems while the order is being updated.
What should you add to usp.GetOrdersAndItems?

###BeginCaseStudy###

Testlet 1
Coho Winery
Overview
You are a database developer for a company named Coho Winery. Coho Winery has an office in London.
Coho Winery has an application that is used to process purchase orders from customers and retailers in 10
different countries.
The application uses a web front end to process orders from the Internet. The web front end adds orders to a
database named Sales. The Sales database is managed by a server named Server1.
An empty copy of the Sales database is created on a server named Server2 in the London office. The database
will store sales data for customers in Europe.
A new version of the application is being developed. In the new version, orders will be placed either by using the
existing web front end or by loading an XML file.
Once a week, you receive two files that contain the purchase orders and the order details of orders from
offshore facilities.
You run the usp_ImportOders stored procedure and the usp_ImportOrderDetails stored procedure to copy the
offshore facility orders to the Sales database.
The Sales database contains a table named Orders that has more than 20 million rows.
Database Definitions
Database and Tables
The following scripts are used to create the database and its tables:

Stored Procedures
The following are the definitions of the stored procedures used in the database:

Indexes
The following indexes are part of the Sales database:

Data Import
The XML files will contain the list of items in each order. Each retailer will have its own XML schema and will be
able to use different types of encoding. Each XML schema will use a default namespace. The defaultnamespaces are not guaranteed to be unique.
For testing purposes, you receive an XSD file from a customer.
For testing purposes, you also create an XML schema collection named ValidateOrder. ValidateOrder contains
schemas for all of the retailers.
The new version of the application must validate the XML file, parse the data, and store the parsed data along
with the original XML file in the database. The original XML file must be stored without losing any data.
Reported Issues
Performance Issues
You notice the following for the usp_GetOrdersAndItems stored procedure:
The stored procedure takes a long time to complete.
Less than two percent of the rows in the Orders table are retrieved by usp_GetOrdersAndItems.
A full table scan runs when the stored procedure executes.
The amount of disk space used and the amount of time required to insert data are very high.
You notice that the usp_GetOrdersByProduct stored procedure uses a table scan when the stored procedure is
executed.
Page Split Issues
Updates to the Orders table cause excessive page splits on the IX_Orders_ShipDate index.
Requirements
Site Requirements
Users located in North America must be able to view sales data for customers in North America and Europe in
a single report. The solution must minimize the amount of traffic over the WAN link between the offices.
Bulk Insert Requirements
The usp_ImportOrderDetails stored procedure takes more than 10 minutes to complete. The stored procedure
runs daily. If the stored procedure fails, you must ensure that the stored procedure restarts from the last
successful set of rows.
Index Monitoring Requirements
The usage of indexes in the Sales database must be monitored continuously. Monitored data must be
maintained if a server restarts. The monitoring solution must minimize the usage of memory resources and
processing resources.

###EndCaseStudy###

You need to implement a solution that solves the performance issues of usp_GetOrdersAndItems.
Which statements should you execute?

###BeginCaseStudy###

Testlet 1
Coho Winery
Overview
You are a database developer for a company named Coho Winery. Coho Winery has an office in London.
Coho Winery has an application that is used to process purchase orders from customers and retailers in 10
different countries.
The application uses a web front end to process orders from the Internet. The web front end adds orders to a
database named Sales. The Sales database is managed by a server named Server1.
An empty copy of the Sales database is created on a server named Server2 in the London office. The database
will store sales data for customers in Europe.
A new version of the application is being developed. In the new version, orders will be placed either by using the
existing web front end or by loading an XML file.
Once a week, you receive two files that contain the purchase orders and the order details of orders from
offshore facilities.
You run the usp_ImportOders stored procedure and the usp_ImportOrderDetails stored procedure to copy the
offshore facility orders to the Sales database.
The Sales database contains a table named Orders that has more than 20 million rows.
Database Definitions
Database and Tables
The following scripts are used to create the database and its tables:

Stored Procedures
The following are the definitions of the stored procedures used in the database:

Indexes
The following indexes are part of the Sales database:

Data Import
The XML files will contain the list of items in each order. Each retailer will have its own XML schema and will be
able to use different types of encoding. Each XML schema will use a default namespace. The defaultnamespaces are not guaranteed to be unique.
For testing purposes, you receive an XSD file from a customer.
For testing purposes, you also create an XML schema collection named ValidateOrder. ValidateOrder contains
schemas for all of the retailers.
The new version of the application must validate the XML file, parse the data, and store the parsed data along
with the original XML file in the database. The original XML file must be stored without losing any data.
Reported Issues
Performance Issues
You notice the following for the usp_GetOrdersAndItems stored procedure:
The stored procedure takes a long time to complete.
Less than two percent of the rows in the Orders table are retrieved by usp_GetOrdersAndItems.
A full table scan runs when the stored procedure executes.
The amount of disk space used and the amount of time required to insert data are very high.
You notice that the usp_GetOrdersByProduct stored procedure uses a table scan when the stored procedure is
executed.
Page Split Issues
Updates to the Orders table cause excessive page splits on the IX_Orders_ShipDate index.
Requirements
Site Requirements
Users located in North America must be able to view sales data for customers in North America and Europe in
a single report. The solution must minimize the amount of traffic over the WAN link between the offices.
Bulk Insert Requirements
The usp_ImportOrderDetails stored procedure takes more than 10 minutes to complete. The stored procedure
runs daily. If the stored procedure fails, you must ensure that the stored procedure restarts from the last
successful set of rows.
Index Monitoring Requirements
The usage of indexes in the Sales database must be monitored continuously. Monitored data must be
maintained if a server restarts. The monitoring solution must minimize the usage of memory resources and
processing resources.

###EndCaseStudy###

You need to implement a solution that addresses the index monitoring requirements.
What should you do?

###BeginCaseStudy###

Testlet 1
Coho Winery
Overview
You are a database developer for a company named Coho Winery. Coho Winery has an office in London.
Coho Winery has an application that is used to process purchase orders from customers and retailers in 10
different countries.
The application uses a web front end to process orders from the Internet. The web front end adds orders to a
database named Sales. The Sales database is managed by a server named Server1.
An empty copy of the Sales database is created on a server named Server2 in the London office. The database
will store sales data for customers in Europe.
A new version of the application is being developed. In the new version, orders will be placed either by using the
existing web front end or by loading an XML file.
Once a week, you receive two files that contain the purchase orders and the order details of orders from
offshore facilities.
You run the usp_ImportOders stored procedure and the usp_ImportOrderDetails stored procedure to copy the
offshore facility orders to the Sales database.
The Sales database contains a table named Orders that has more than 20 million rows.
Database Definitions
Database and Tables
The following scripts are used to create the database and its tables:

Stored Procedures
The following are the definitions of the stored procedures used in the database:

Indexes
The following indexes are part of the Sales database:

Data Import
The XML files will contain the list of items in each order. Each retailer will have its own XML schema and will be
able to use different types of encoding. Each XML schema will use a default namespace. The defaultnamespaces are not guaranteed to be unique.
For testing purposes, you receive an XSD file from a customer.
For testing purposes, you also create an XML schema collection named ValidateOrder. ValidateOrder contains
schemas for all of the retailers.
The new version of the application must validate the XML file, parse the data, and store the parsed data along
with the original XML file in the database. The original XML file must be stored without losing any data.
Reported Issues
Performance Issues
You notice the following for the usp_GetOrdersAndItems stored procedure:
The stored procedure takes a long time to complete.
Less than two percent of the rows in the Orders table are retrieved by usp_GetOrdersAndItems.
A full table scan runs when the stored procedure executes.
The amount of disk space used and the amount of time required to insert data are very high.
You notice that the usp_GetOrdersByProduct stored procedure uses a table scan when the stored procedure is
executed.
Page Split Issues
Updates to the Orders table cause excessive page splits on the IX_Orders_ShipDate index.
Requirements
Site Requirements
Users located in North America must be able to view sales data for customers in North America and Europe in
a single report. The solution must minimize the amount of traffic over the WAN link between the offices.
Bulk Insert Requirements
The usp_ImportOrderDetails stored procedure takes more than 10 minutes to complete. The stored procedure
runs daily. If the stored procedure fails, you must ensure that the stored procedure restarts from the last
successful set of rows.
Index Monitoring Requirements
The usage of indexes in the Sales database must be monitored continuously. Monitored data must be
maintained if a server restarts. The monitoring solution must minimize the usage of memory resources and
processing resources.

###EndCaseStudy###

You need to ensure that usp_AddXMLOrder can be used to validate the XML input from the retailers.
Which parameters should you add to usp_AddXMLOrder on line 04 and line 05? (Each correct answer presents
part of the solution. Choose all that apply.)

###BeginCaseStudy###

Testlet 1
Coho Winery
Overview
You are a database developer for a company named Coho Winery. Coho Winery has an office in London.
Coho Winery has an application that is used to process purchase orders from customers and retailers in 10
different countries.
The application uses a web front end to process orders from the Internet. The web front end adds orders to a
database named Sales. The Sales database is managed by a server named Server1.
An empty copy of the Sales database is created on a server named Server2 in the London office. The database
will store sales data for customers in Europe.
A new version of the application is being developed. In the new version, orders will be placed either by using the
existing web front end or by loading an XML file.
Once a week, you receive two files that contain the purchase orders and the order details of orders from
offshore facilities.
You run the usp_ImportOders stored procedure and the usp_ImportOrderDetails stored procedure to copy the
offshore facility orders to the Sales database.
The Sales database contains a table named Orders that has more than 20 million rows.
Database Definitions
Database and Tables
The following scripts are used to create the database and its tables:

Stored Procedures
The following are the definitions of the stored procedures used in the database:

Indexes
The following indexes are part of the Sales database:

Data Import
The XML files will contain the list of items in each order. Each retailer will have its own XML schema and will be
able to use different types of encoding. Each XML schema will use a default namespace. The defaultnamespaces are not guaranteed to be unique.
For testing purposes, you receive an XSD file from a customer.
For testing purposes, you also create an XML schema collection named ValidateOrder. ValidateOrder contains
schemas for all of the retailers.
The new version of the application must validate the XML file, parse the data, and store the parsed data along
with the original XML file in the database. The original XML file must be stored without losing any data.
Reported Issues
Performance Issues
You notice the following for the usp_GetOrdersAndItems stored procedure:
The stored procedure takes a long time to complete.
Less than two percent of the rows in the Orders table are retrieved by usp_GetOrdersAndItems.
A full table scan runs when the stored procedure executes.
The amount of disk space used and the amount of time required to insert data are very high.
You notice that the usp_GetOrdersByProduct stored procedure uses a table scan when the stored procedure is
executed.
Page Split Issues
Updates to the Orders table cause excessive page splits on the IX_Orders_ShipDate index.
Requirements
Site Requirements
Users located in North America must be able to view sales data for customers in North America and Europe in
a single report. The solution must minimize the amount of traffic over the WAN link between the offices.
Bulk Insert Requirements
The usp_ImportOrderDetails stored procedure takes more than 10 minutes to complete. The stored procedure
runs daily. If the stored procedure fails, you must ensure that the stored procedure restarts from the last
successful set of rows.
Index Monitoring Requirements
The usage of indexes in the Sales database must be monitored continuously. Monitored data must be
maintained if a server restarts. The monitoring solution must minimize the usage of memory resources and
processing resources.

###EndCaseStudy###

You need to implement a solution that addresses the page split issues.
Which statement should you execute?