###BeginCaseStudy###
Case Study 2
Contoso Ltd
Overview
Application Overview
Contoso, Ltd., is the developer of an enterprise resource planning (ERP) application.
Contoso is designing a new version of the ERP application. The previous version of the ERP
application used SQL Server 2008 R2. The new version will use SQL Server 2014.
The ERP application relies on an import process to load supplier data. The import process
updates thousands of rows simultaneously, requires exclusive access to the database, and runs daily.
You receive several support calls reporting unexpected behavior in the ERP application.
After analyzing the calls, you conclude that users made changes directly to the tables in the
database.
Tables
The current database schema contains a table named OrderDetails. The OrderDetails
table contains information about the items sold for each purchase order. OrderDetails
stores the product ID, quantities, and discounts applied to each product in a purchase
order. The product price is stored in a table named Products.
The Products table was defined by using the SQL_Latin1_General_CPl_CI_AS collation. A
column named ProductName was created by using the varchar data type.
The database contains a table named Orders. Orders contains all of the purchase orders from
the last 12 months. Purchase orders that are older than 12 months are stored in a table named OrdersOld.
Stored Procedures
The current version of the database contains stored procedures that change two tables. The
following shows the relevant portions of the two stored procedures:
Customer Problems
Installation Issues
The current version of the ERP application requires that several SQL Server logins be set up
to function correctly. Most customers set up the ERP application in multiple locations and
must create logins multiple times.
Index Fragmentation Issues
Customers discover that clustered indexes often are fragmented. To resolve this issue, the
customers defragment the indexes more frequently.
All of the tables affected by fragmentation have the following columns that are used as the
clustered index key:
Backup Issues
Customers who have large amounts of historical purchase order data report that backup time
is unacceptable.
Search Issues
Users report that when they search product names, the search results exclude product names
that contain accents, unless the search string includes the accent.
Missing Data Issues
Customers report that when they make a price change in the Products table, they cannot
retrieve the price that the item was sold for in previous orders.
Query Performance Issues
Customers report that query performance degrades very quickly. Additionally, the customers
report that users cannot run queries when SQL Server runs maintenance tasks.
Import Issues
During the monthly import process, database administrators receive many supports call from
users who report that they cannot access the supplier data. The database administrators want
to reduce the amount of time required to import the data.
Design Requirements
File Storage Requirements
The ERP database stores scanned documents that are larger than 2 MB. These files must only
be accessed through the ERP application. File access must have the best possible read and
write performance.
Data Recovery Requirements
If the import process fails, the database must be returned to its prior state immediately.
Security Requirements
You must provide users with the ability to execute functions within the ERP application,
without having direct access to the underlying tables.
Concurrency Requirements
You must reduce the likelihood of deadlocks occurring when Sales.Proc1 and Sales.Proc2 execute.
###EndCaseStudy###
You need to recommend a solution that addresses the index fragmentation and index width issue.
What should you include in the recommendation? (Each correct answer presents part of the
solution. Choose all that apply.)
A.
Change the data type of the lastModified column to smalldatetime.
B.
Remove the lastModified column from the clustered index.
C.
Change the data type of the modifiedBy column to tinyint.
D.
Change the data type of the id column to bigint.
E.
Remove the modifiedBy column from the clustered index.
F.
Remove the id column from the clustered index.
Explanation:
Scenario: Index Fragmentation Issues
Customers discover that clustered indexes often are fragmented. To resolve this issue, the
customers defragment the indexes more frequently.
All of the tables affected by fragmentation have the following columns that are used as the
clustered index key:
Correct answer is:
BEC
why need add – C
http://www.sqlservercentral.com/blogs/glennberry/2010/03/22/why-uniqueidentifier-is-a-bad-choice-for-a-clustered-index-in-sql-server/
I think you want to say D not C
Yes D, sorry
uniqueidentifier is not compatible with tinyint and bigint
The correct answers are B and D.
For option B, the lastModified column is of ‘datetime’ datatype, which in itself is “nondeterministic” and is a bad choice for an index (clustered or non-clustered)
For option D, the id is of ‘unique identifier’ datatype; also a bad candidate for this kind of scenario: clustered index, where… “the ERP application relies on an import process to load supplier data. The import process updates thousands of rows simultaneously, and runs daily.”
“index width issue?!”
OK, maybe we need to add option E as well, because @@modifiedBy varchar(200) is certain to bloat the clustered index.
Should be B,D,E
Where Can I add new question for exam 70-465 which consist of new adventure cycle case study and other SQL 2014 questions to be discussed?
Just copy and paste here
B and E is correct
BDE. Unfortunately there isn’t an option for setting the default for the id column to be newSequentialId(). Having a random non incrementing clustered index key is a terrible idea. At least 10x worse insert performance in my own testing. Given the random nature of the leading column in the CI the other two columns really can not be contributing anything at all and should go.
NEWSEQUENTIALID() can only be used with DEFAULT constraints on table columns of type uniqueidentifier.
Assume Id was defines as “Id uniqueidentifier DEFAULT NEWSEQUENTIALID()” ; then it should be ok to keep Id as uniqueidentifier.
My vote goes for “B”, “E”
Option D. needs a lot of re-development
B) Remove the lastModified column from the clustered index.
E) Remove the modifiedBy column from the clustered index.
I take the exam last week and you need to choose 3 from the list.
B) Remove the lastModified column from the clustered index
D) Change the data type of the id column to bigint
E) Remove the modifiedBy column from the clustered index
“It is true that uniqueidentifier makes poor choice for indexes for the reasons you mention, but by no means does that implies that you should not create these indexes. Changing the data type to INT or BIGINT would be advisable, if possible. Using NEWSEQUENTIALID() or UuidCreateSequential to generate them would help with fragmentation issues.”
http://stackoverflow.com/questions/13803326/use-of-non-clustered-index-on-guid-type-column-in-sql-server