###BeginCaseStudy###
Case Study: 2
Scenario 2
Application Information
You have two servers named SQL1 and SQL2 that have SQL Server 2012 installed.
You have an application that is used to schedule and manage conferences.
Users report that the application has many errors and is very slow.
You are updating the application to resolve the issues.
You plan to create a new database on SQL1 to support the application. A junior database
administrator has created all the scripts that will be used to create the database. The script that
you plan to use to create the tables for the new database is shown in Tables.sql. The script
that you plan to use to create the stored procedures for the new database is shown in
StoredProcedures.sql. The script that you plan to use to create the indexes for the new
database is shown in Indexes.sql. (Line numbers are included for reference only.)
A database named DB2 resides on SQL2. DB2 has a table named SpeakerAudit that will
audit changes to a table named Speakers.
A stored procedure named usp_UpdateSpeakersName will be executed only by other stored
procedures. The stored procedures executing usp_UpdateSpeakersName will always handle
transactions.
A stored procedure named usp_SelectSpeakersByName will be used to retrieve the names of
speakers. Usp_SelectSpeakersByName can read uncommitted data.
A stored procedure named usp_GetFutureSessions will be used to retrieve sessions that will
occur in the future.
Procedures.sql
Indexes.sql
Tables.sql
###EndCaseStudy###
While testing usp.GetFutureSessions, you discover that IX_Sessions is accessed by a scan
rather than a seek.
You need to minimize the amount of time it takes to execute usp_GetFutureSessions.
What should you do? (Each correct answer presents part of the solution. Choose all that apply.)
A.
Option A
B.
Option B
C.
Option C
D.
Option D
E.
Option E
F.
Option F
Explanation:
Future delivery dates.
Looks C to me
I think it’s C and E. Cannot create indexes with nondeterministic functions.
While testing usp.GetFutureSessions, you discover that IX_Sessions is accessed by a SCAN rather than a SEEK.
With C there still will be a scan. Only index which can allow seek is A. In my opinion it’s A and E.
C will be the best solution and E
Why E ?? should it not be D… A stored procedure named usp_GetFutureSessions will be used to retrieve sessions that will occur in the future
D is wrong. GETDATE() should occur before the Delivery Date (Future): Option E
The index definition should cover SpeakerID (instead of SessionID); and should include DeliveryTime and RoomID (to prevent Table Lookup): Option C
The correct option are C, E
This question is wrong in so many points that it is just impossible to answer just look at the queries not even including a join for the room ID column and the where Getdate()> in an index is impossible to do …
Impossible in an index i mean
That is why option B is wrong. that is why the same GETDATE() < DeliveryTime choice is available to be inserted in the stored procedure. :Option E
A and E
a: Because the where-attribute is listed first and therefore is sorted primarly in the index -> seek will be used
e: current date session date is in the future. Index where is not possible because its nor deterministic
Option A recommends changing line02 of indexes.sql to (DeliveryTime, SessionID). How does this make any sense to you?!
The usp_GetFutureSessions.sql procedure that the (IX_Sessions) index is defined for selects the following columns (SpeakerID, RoomID, and DeliveryTime) from the Sessions Table.
And, if you’d argue that Getdate() < DeliveryTime is non-deterministic for the index, how then would it be valid by picking option A instead of option C?!
to mee annonymous