DepartamentodeEngenhariaInformática 2009/2010 AdministraçãoeOptimizaçãodeBDs2ºsemestre AuladeLaboratório5 Inthislabclasswewillapproachthefollowingtopics: 1. LockingbehaviorinSQLServer2008 2. Isolationlevelsandmodifyingthedefaultlockingbehavior 3. Laboratoryexperiment 4. Otherresources 1. LockingbehaviorinSQLServer2008 ThelockingprotocoladoptedbySQLServerformanagingconcurrenttransactionsconsists ofplacingdifferenttypesoflocksondifferentdatabaseobjects.sqlserverappliesawrite lock(i.e.,exclusive)whenitwritesinformationorareadlock(i.e.,shared)whenitreads information. Writing information usually refers to inserting, updating, or deleting rows, whereasreadinginformationreferstoretrievingrowswithanselectstatement. Thesedatabaseobjectsthatcanbelockedincludetables,databasepages,rows,andindex entries.aswehaveseen,adatabasepageis8kbinsize,andanyobjectresidentwithin this 8 KB is locked implicitly when the database page is locked. Therefore, if a database page is locked, every row held on that page is effectively locked. Similarly, if a table is locked,everyrowinthattableislocked. Lockgranularity Applications require different levels of locking granularity. One application may benefit from page level locking while another application may benefit from row level locking. Locking individual columns provides the highest level of concurrency. By this we mean thatmultipleuserscouldbeupdatingdifferentcolumnsinthesamerowsimultaneously andtheywouldnotbeinvolvedinlockconflict.ifthelockgranularityisimplementedat thedatabaselevel,thelowestlevelofconcurrencyisachieved.multipleuserscouldnot simultaneouslychangeanythingatallinthedatabase.however,thefinerthegranularity, the more system resources are used. This is why SQL Server and database systems in generaldonotlockatthecolumnlevel.thesystemresourcesusedtomanageallthelocks would be too great. Locks are approximately 100 bytes each in SQL Server. Using 100 bytes of memory to lock a ten byte column seems a little over the top. To lock at the columnlevelwouldprobablyusetensofthousandsoflocksinamedium sizeddatabase, which could equate to many megabytes of memory. The CPU resources needed to managetheselockswouldalsobemassive.consequently,sqlserverlocksrows,pages, andtables,whichisareasonableapproach.thedatabaseitselfcan,ofcourse,besetto single usermode,whicheffectivelyprovideslockingatthedatabaselevel. IST/DEI Pág.1de7
AdministraçãoeOptimizaçãodeBasesdeDados Lockingattherowlevelcanbeconsideredtobethedefaultsituation.Oneofthereasons thatsqlservertendstolockattherowlevelisthatithasthecapabilitytoescalatelocks butnottode escalatelocks.therefore,ifsqlserverdecidesthatasqlstatementislikely tolockthemajorityofrowsinatable,itmaylockatthetablelevel.thesamelogicisused ifsqlserverdeterminesthatmostoftherowsinapagearelikelytobelocked itmay takeoutapagelockinsteadofmultiplerowlocks. IntentLocks SQL Server also makes use of a type of lock known as an intent lock. Intent locks are placedovertablesandoverpagesinthetables,whenauserlocksrowsinthetable,and they stay in place for the life of the row locks. These locks are used primarily to ensure thatausercannottakeoutlocksonatableorpagesinthetablethatwouldconflictwith another user s row locks. For example, if a user was holding an exclusive row lock and anotheruserwishedtotakeoutanexclusivetablelockonthetablecontainingtherow, theintentlockheldonthetablebythefirstuserwouldensurethatitsrowlockwouldnot beoverlookedbythelockmanager. Deadlockprevention Once a lock has been placed on an object, it has a lifetime. Suppose a T SQL statement thatcausesarowlockisexecutedinsideauser definedtransaction.itispossibleinsql Servertosetalocktimeoutvalueforaconnection,sothatitwillonlywaittobegranted its lock for a predefined period of time, after which it will receive an error message informingitthatthetime outperiodhasbeenexceeded.alocktimeoutvalueissetper connectionasfollows: SET LOCK_TIMEOUT 10000 The timeout value is specified in milliseconds. The default value of 1 means wait indefinitely,whereasavalueof0meansdonotwaitatall. Deadlockresolution A deadlock situation can occur in SQL Server when a user holds a lock on a resource neededbyafellowuserwhoholdsalockonaresourceneededbythefirstuser.thisisa deadly embrace, and the users would wait forever if SQL Server did not intervene. SQL Server chooses one of the deadlocked users as a victim and issues a rollback for its transaction.aconnectioncansetitsdeadlockprioritysuchthat,intheeventofitbeing involvedinadeadlock,itwillbechosenasthevictim,asfollows: SET DEADLOCK_PRIORITY LOW Toreturntothedefaultdeadlockhandlingmechanism,usethefollowingcode: SET DEADLOCK_PRIORITY NORMAL IST/DEI Pág.2de7
AdministraçãoeOptimizaçãodeBasesdeDados Generally,thetransactioninvolvedinthedeadlockthathasaccumulatedtheleastamount ofcputimeisusuallychosenasthevictim. Read,WriteandUpdatelocks Aswellasplacingsharedandexclusivelocksondatabaserows,SQLServeralsomakesuse ofatypeoflockknownasanupdatelock.theselocksareassociatedwithsqlstatements that perform update and delete operations, which need to initially read rows before changing or deleting them. These rows have update locks placed on them that are compatible with shared read locks but are not compatible with other update locks or exclusivelocks.iftherowsmustsubsequentlybeupdatedordeleted,sqlserverattempts to promote the update locks to exclusive locks. If any other shared locks are associated with the rows, SQL Server will not be able to promote the update locks until these are released.updatelocksareanoptimizationtoreducethepossibilityofdeadlocks. Snapshotisolationlevels SinceSQLServer2005,Microsofthasincludedtheabilitytouseversioninginadditionto locking(set READ_COMMITTED_SNAPSHOT ON and SET TRANSACTION ISOLATION LEVEL SNAPSHOT). In a system using versioning, data is not being locked but instead read operations happen against an older version of the data being manipulated. Depending uponisolationlevels,thereadoperationcaneitherreadthelatestcommitteddataorthe dataasitwaswhenthereadoperationstarted.beawarethatwhenanupdateoperation takesplaceagainstthedata,thedatabeingtouchediscopiedtoaseparatestoragearea, incurringinaperformancepenalty(i.e.,donotuseversioningifyouaredoinglargebatch updates). For details about the snapshot isolation level, please consider looking at www.sqlteam.com/article/transaction isolation and the new snapshot isolation level. 2. Isolationlevelsandmodifyingthedefaultlockingbehavior There are two ways in which SQL Server s default locking behavior can be modified. IndividualSQLstatementscanbequalifiedwithakeywordknownasalockhinttomodify the locking behavior for that particular statement, or a default locking behavior for the connectioncanbesetwiththesettransactionisolationlevelstatement. LevelsoftransactionisolationarespecifiedbytheANSIstandard,witheachonedefining the type of phenomenon not permitted while concurrent transactions are running. The problemsthatmayincurinusingconcurrentaccesstoadabatasetableareasfollows: DirtyReads Adirtyreadoccurswhenatransactionreadsdatafromarowthathasbeen modifiedbyanothertransaction,butnotyetcommitted. IST/DEI Pág.3de7
AdministraçãoeOptimizaçãodeBasesdeDados Nonrepetable Reads Non repeatable reads happen when a query returns data that would be different if the query were repeated within the same transaction. Nonrepeatablereadscanoccurwhenothertransactionsaremodifyingdatathatatransaction isreading(e.g.readlocksarenotacquiredwhenperformingaselect). Phantoms This occurs when, in the course of a transaction, two identical queries are executed,andthecollectionofrowsreturnedbythesecondqueryisdifferentfromthe first.thiscanoccurwhenrangelocksarenotcorrectlyacquiredonperformingaselect. The higher the isolation level, the more stringent the locking protocol with the higher levelsbeingasupersetofthelowerlevels.thetransactionisolationlevelsareasfollows and,bydefault,sqlserverrunsattransactionisolationlevelreadcommitted. IsolatonLevel DirtyReads NonrepetableReads Phantoms Serializable No No No RepeatableRead No No Yes ReadCommitted No Yes Yes ReadUncommitted Yes Yes Yes Snapshot No No No ReadCommitedSnapshot No Yes Yes Thekeywordsavailableaslockhintsformodifyinglockingbehaviorareasfollows: DBLOCK forcesashareddatabaselocktobetakenwheninformationisread. HOLDLOCK forcesasharedlockonatabletoremainuntilthetransactioncompletes. Key range locking will also be used to prevent phantom inserts. Nonrepeatable reads arealsoprevented. NOLOCK allows a dirty read to take place that is, a transaction can read the uncommittedchangesmadebyanothertransaction. PAGLOCK forcessharedpagelockstobetakenwhereotherwisesqlservermayhave usedatableorrowlock. READCOMMITTED ensures that the statement behaves in the same way as if the connectionweresettotransactionisolationlevelreadcommitted. READPAST enablesastatementtoskiprowsthatarelockedbyotherstatements. READUNCOMMITTED equivalenttothenolocklockhint. REPEATABLEREAD ensures that the statement behaves in the same way as if the connectionweresettotransactionisolationlevelrepeatableread. ROWLOCK forcestheuseofrowlocksandissimilarinusetopaglock. SERIALIZABLE forces shared locks to stay until the transaction completes. This is equivalenttospecifyingtheholdlockhint. TABLOCK forcesasharedtablelocktobetakenwhereotherwisesqlservermayhave usedrowlocks. IST/DEI Pág.4de7
AdministraçãoeOptimizaçãodeBasesdeDados UPDLOCK forcessqlservertotakeupdatelockswhereotherwisesqlserverwould haveusedsharedlocks. XLOCK forcesexclusivelockstobetakenout.thisistypicallyusedwithtablockand PAGLOCK. LockhintsareusuallyusedonSELECTstatements.Thenextlineprovidesanexample: SELECT balance FROM accounts WITH (READUNCOMMITTED) WHERE account_no = 1000; Beware of the SET IMPLICIT_TRANSACTIONS ON statement. It will automatically start a transactionwhentransact SQLstatementssuchasSELECT,INSERT,UPDATE,andDELETE areused.thetransactionwillnotbecommittedanditslockswillnotbereleaseduntilan explicitcommittransactionstatementisexecuted. 3. ALaboratoryExperiment The Activity Monitor allows you to examine database connections. In SQL Server ManagementStudio,connecttotheserverandthenstarttheActivityMonitor.Thethree availableoptionscoverprocesses,locksbyprocess,andlocksbyobject.theobjectiveof theactivitymonitoranditslockingmonitoringtoolsistoallowforlockstoberemoved ifalockiscausingsomekindofperformanceproblem.inextremecases,alocksuchasa deadlockcanevencauseadatabasehalt. Students will now test the following steps in SQL Server 2008, in order to see how concurrenttransactionsarehandled.betweeneachstep,besuretoexecutethefollowing statementtoplacetheadventureworksdatabasewiththedefaultvalues. SET Name = 'Blade' WHERE ProductID = 316; Case1:Usingthereaduncommittedisolationlevel Userscanquerythevalueofa row/columnthatisinthemiddleofatransactionbutnotyetcompleted. -- was previously 'Blade', now 'Super Blade' SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; ProductID = 316; -- WILL RETURN 'Super Blade', even before -- committing the first transaction, IST/DEI Pág.5de7
AdministraçãoeOptimizaçãodeBasesdeDados Case2:Usingthereadcommittedisolationlevel User2willresultinadeadlockonthe SELECT statement until the COMMIT TRANSACTION for User 1 executes, because the READCOMMITTEDisolationlevelcanonlyreadCOMMITTEDdata. -- was previously 'Blade', now 'Super Blade' SET TRANSACTION ISOLATION LEVEL READ COMMITTED; ProductID = 316; -- Deadlock until the COMMIT finishes for User 1, Case3:Usingtherepeatablereadisolationlevel User2willalwaysreadthesamepiece ofdataandreturnthesameresult,notallowinguser1'supdatetocompleteuntiluser 2'squeriescomplete. SET TRANSACTION ISOLATION LEVEL REPEATABLE READ -- Deadlock, because User 2 still has the row -- Still in deadlock until User 2 commits -- UPDATE completes we can COMMIT SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; BEGIN TRAN ProductID = 316; -- returns 'Blade' SELECT Name fromproduction.product WHERE ProductID = 316; -- Will still return 'Blade' COMMIT TRANSACTION Case 4 : Using the serializable isolation level Will lock out any insertions that would matchtherange,untiltheothertransactioniscommitted,thusavodingphantomreads. SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; INSERT INTO HumanResources.Department (Name,GroupName,ModifiedDate) VALUES ('Test Department','G', '9-04-2010'); -- Deadlock, because this would affect the -- rowcount for User 2 - Still in deadlock until User 2 commits -- INSERT completes we can COMMIT SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; SELECT COUNT(*) FROM HumanResources.Department; -- returns number of rows in table SELECT COUNT(*) FROM HumanResources.Department; -- STILL returns the same number Case5:Usingthesnapshotisolationlevel non blockingreadcommitted,bytakinga "snapshot"(thusthenameoftheisolationlevel)intothetempdbdatabase.thisallowsa developer to query against a specific version of the data throughout the entire IST/DEI Pág.6de7
AdministraçãoeOptimizaçãodeBasesdeDados transaction, without needing to wait for any other locks to clear, and without reading fromany"dirtydata".thesnapshotisolationlevelalsoavoidphantoms,butintroduces an anomalie called write skews (i.e. two transactions may each read a value, then changetheother'svalue,butneitherseestheresultoftheother'supdate) ALTER DATABASE AdventureWorks SET ALLOW_SNAPSHOT_ISOLATION ON; SET TRANSACTION ISOLATION LEVEL SNAPSHOT; -- was previously 'Blade', now 'Super Blade' SET TRANSACTION ISOLATION LEVEL SNAPSHOT BEGIN TRAN ProductID = 316; -- Still 'Blade' ProductID = 316; -- Still 'Blade' ProductID = 316; -- NOW it's 'Super Blade' IST/DEI Pág.7de7