Administração e Optimização de BDs 2º semestre

Transcription

1 DepartamentodeEngenhariaInformática 2009/2010 AdministraçãoeOptimizaçãodeBDs2ºsemestre AuladeLaboratório8 Inthislabclasswewillapproachthefollowingtopics: 1. Basicsoflock,log,memory,CPUandI/Otuning 2. Tuninglocks 3. Tuninglogging 4. Tuningmemoryusage 5. TuningCPUusage 6. TuningI/Oandcaching 7. Otherresources 1. Basicsoflock,log,memory,CPUandI/Otuning Memory, CPU and disk access affects many different aspects of SQL Server, e.g. query execution,cachingandevenuserconnectionsandlocks.thereareconfigurationoptions andhintsthatcanbeusedtofine tunetheseaspects.differentqueriescanhavediverse memoryandcpurequirements.asimplequerysuchasasinglerowlookupwillrequire littlememoryandcputoexecute.otherqueries,suchastheadhocqueriesfoundindata warehouse type systems, may need to perform large sorts. Some queries will need to performhashjoinsonlargeamountsofdata.thequeriesthatneedtosortandhashwill benefitfromlotsofmemory.ifthesortcanfitintomemory,orthehashbucketscanfit intomemory,queryperformancewillbeimproved. Locking also brings lots of possibilities towards affecting performance. A good chunk of poorperformancethatyoumightnoticeinsystemsoccursbecauseprocessesarewaiting toeitheracquirealockorbreakfromadeadlock.normally,lockingoccursattherowlevel unless many adjacent rows on a page are locked, in which SQL server will automatically promotethelocktoapage level,orinextremecases,toatable levellock.fine tuningthis behaviorcansometimesbethekeyforachievingtherequiredlevelsofperformance. 1. Tuninglocks 1.1. Identifyinglong runningtransactions Onewaytohelpreducelockingissuesistoidentifythosetransactionsthataretakinga long time to run. The longer they take to run, the longer their locks will block other processes,causingcontentionandreducingperformance.thefollowingscriptcanberun toidentifycurrent,long runningtransactions.thiswillprovideyouwithaclueastowhat transactionsaretakingalongtime,allowingyoutoinvestigateandresolvethecause. IST/DEI Pág.1de7

2 AdministraçãoeOptimizaçãodeBasesdeDados SELECTspid,cmd,status,loginame,open_tran, datediff(s,last_batch,getdate())as[waittime(s)] FROMmaster..sysprocessespWHEREopen_tran>0ANDspid>50AND datediff(s,last_batch,getdate())>30and EXISTS(SELECT*FROMmaster..syslockinfol WHEREreq_spid=p.spidANDrsc_type<>2) Thisqueryprovidesresultsbasedontheinstantisruns,andwillvaryeachtimeyourunit. The goal is to review the results and look for transactions that have been open a long time.thisgenerallyindicatessomeproblemthatshouldbeinvestigated Lockgranularityandlockescalation SQLServersupportsrowlocking,butoftenusesrough grainedlocks.thisisbecauselock management is a complex issue. Locks aren't small or simple entities, so if you only do row level locking, you can get yourself into many problems: a million row update can easilyswampmemoryandbecomehardtomanage. Databases that do more than just row level locking often use a technique called lock escalation to achieve better performance. Unless its clear from the outset that a whole tablewillbemodified,thesedatabasesstartoffusingrowlocks,andtheymakeplansto trade these locks in for rough grained locks later if too many rows are modified.unfortunately, lock escalation amplifies the deadlocks problem. If two users try to modify semantically unrelated but physically near data in two separate tables in reverseorder,bothuserswillstartoffwithrowlocks,thentrytoupgradethemtopage locks, and the situation will be that each user wants something the other user has, so they're stuck. Databases that use only row level locking almost never have this problem because two users rarely want to modify the exact same row, and even more rarely do theyattainlocksintheorderneededtocauseadeadlock. Inpractice,underhighload,SQLServer'slockingsystemdoesnotperformwellduetolock contention(i.e,deadlocksandwaitingforlocks).becauseofsharedlocks,evenusersnot tryingtomodifythedatabaseareaffectedbythelocksystem.however,thenolockand ROWLOCKhintscanbeofsomehelp.Thesehintsareusedlikeintheexamplesbellow: SELECTCOUNT(EmployeeID)FROMHumanResources.EmployeeWITH(NOLOCK); UPDATEHumanResources.EmployeeWITH(ROWLOCK) SETEmployeeName='JohnDoe'WHEREEmployeeID=100; SELECTCOUNT(E.EmployeeID)FROMHumanResources.EmployeeASEWITH (NOLOCK)JOINHumanResources.EmployeeAddressASE2WITH(NOLOCK) ONE.EmployeeID=E2.EmployeeID; IST/DEI Pág.2de7

3 AdministraçãoeOptimizaçãodeBasesdeDados NOLOCK politely asks SQL Server to ignore locks and read directly from the tables. This means you completely circumvent the lock system, which is a major performance and scalabilityimprovement.however,youalsocompletelycircumventthelocksystem,which means you may read the not necessarily valid uncommitted modifications of a running transaction. ROWLOCK politely asks SQL Server to only use row level locks. You'd think that an UPDATEinwhichyouspecifytheprimarykeywouldalwayscausearowlock,butwhen SQLServergetsabatchwithmanyofthese,andsomeofthemhappentobeinthesame page, you'll see page locks. And if you don't specify a primary key for an UPDATE or DELETE,there'snoreasonthedatabasewouldn'tassumethatalotwon'tbeaffected,soit probably goes right to page locks.by specifically requesting row level locks, these problems are avoided. However, be aware that if you are wrong and lots of rows are affected,eitherthedatabasewilltaketheinitiativeandescalatetopagelocks,oryouwill haveamanyrowlocksfillingyourserver'smemoryandbringingdownperformance BesidestuningSQLinstructionswiththeaboveHINTS,othercommonrecommendations aregivenext: Ontablesthatchangelittle,ifatall,suchaslookuptables,consideralteringthedefault locklevelforthesetables.sincelookuptablesarenotbeingchangedbyusers,itwould be more efficient to use a table lock instead of many individual row locks. You can override how SQL Server performs locking on a table by using the SP_INDEXOPTION command. Below is an example of code you can run to tell SQL Server to use page locking,notrowlocks,foraspecifictable: SP_INDEXOPTION'table_name','AllowRowLocks',FALSE; SP_INDEXOPTION'table_name','AllowPageLocks',FALSE; Thiscodeturnsoffbothrowandpagelocking,andthusonlytablelockingisavailable. Ifthereisalotofcontentionforaparticulartableinyourdatabase,considerturningoff pagelockingforthattable,requiringsqlservertouserowlevellocking.thiswillhelpto reducethecontentionforrowslocatedonthesamepage.itwillalsocausesqlserverto workalittleharderinordertotrackalloftherowlocks.howwellthisoptionwillworkfor youdependsonthetradeoffinperformancebetweenthecontentionandtheextrawork SQL Server has to perform to maintain many row locks. Testing will be needed to determinewhatisbestforyourparticularenvironment.usethesp_indexoptionstored proceduretoturnoffpagelockingforanyparticulartable. Keepalltransactionsasshortaspossible.Thishelpstoreducethenumberoflocks(ofall types),helpingtospeeduptheoverallperformanceofyoursqlserverapplications. IST/DEI Pág.3de7

4 AdministraçãoeOptimizaçãodeBasesdeDados To help reduce the amount of time tables are locked, which hurts concurrency and performance, avoid interleaving reads and database changes within the same transaction. Instead, try to do all your reads first, then perform all of the database changes (UPDATES, INSERTS, DELETES) near the end of the transaction. This helps to minimizetheamountoftimethatexclusivelocksareheld. Iftablescansareusedregularlytoaccessatable,andyourtabledoesn'thaveanyuseful indexes to prevent this, then consider turning off both row locking and page locking for that table. This in effect tells SQL Server to only use table locking when accessing this table.thiswillboostaccesstothistablebecausesqlserverwillnothavetoescalatefrom rowlocking,topagelocking,totablelockingeachtimeatablelockisneededtoperform thetablescan.onthenegativeside,doingthiscanincreasecontentionforthetable. 2. Tuninglogging Forperformancereasons,theDatabaseEngineperformsmodificationstodatabasepages inmemoryanddoesnotwritethepagetodiskaftereverychange.however,periodically, the Database Engine needs to perform a checkpoint to write these dirty pages to disk. WritingdirtypagestodiskcreatesaknowngoodpointfromwhichtheDatabaseEngine canstartapplyingchangescontainedinthelogduringrecovery. Beforeadatabasebackup,theDBEngineautomaticallyperformsacheckpointsothatall changestothedatabasepagesarecontainedinthebackup.stoppingaserveralsoissues a checkpoint in each database. In addition, checkpoints can be specified by the users throughthecheckpointinstruction,ortheycanoccurautomaticallywheneitherofthe followingconditionsoccur: The active portion of the log exceeds the size that the server could recover in the amountoftimespecifiedintherecoveryintervalserverconfigurationoption. Thelogbecomes70percentfull,andthedatabaseisinlog truncatemode. AdatabaseisinlogtruncatemodewhenboththeseconditionsareTRUE:thedatabaseis using the Simple recovery model, and, after execution of the last BACKUP DATABASE statementthatreferencedthedatabase,oneofthefollowingeventsoccurs: Aminimallyloggedoperationisperformedinthedatabase(e.g.,abulkcopyoperation). AnALTERDATABASEstatementisexecutedthataddsordeletesafileinthedatabase. ABACKUPLOGstatementreferencingthedatabaseisexecutedwitheithertheNO_LOG ortruncate_onlyclauses. IST/DEI Pág.4de7

5 AdministraçãoeOptimizaçãodeBasesdeDados In general, the amount time required for a checkpoint operation increases with the number of dirty pages that the operation must write. To minimize the performance impactonotherapplications,sqlserver,bydefault,adjuststhefrequencyofwritesthata checkpoint operation performs. SQL Server uses this strategy for automatic checkpoints and for any CHECKPOINT statement that does not specify a checkpoint_duration value. Decreasingthewritefrequencyincreasesthetimethecheckpointoperation. CHECKPOINT[checkpoint_duration]; Users can use checkpoint_duration to request that the checkpoint operation complete within a specific amount of time. The performance impact of using checkpoint_duration dependsonthenumberofdirtypages,theactivityonthesystem,andtheactualduration specified. For example, if the checkpoint would normally complete in 120 seconds, specifying a checkpoint_duration of 45 seconds causes SQL Server to devote more resourcestothecheckpointthanwouldbeassignedbydefault.incontrast,specifyinga checkpoint_duration of 180 seconds causes SQL Server to assign fewer resources than would be assigned by default. In general, a short checkpoint_duration will increase the resources devoted to the checkpoint, while a long checkpoint_duration will reduce the resources devoted to the checkpoint. SQL Server always completes a checkpoint if possible, and the CHECKPOINT statement returns immediately when a checkpoint completes. Therefore, in some cases, a checkpoint may complete sooner than the specifieddurationormayrunlongerthanthespecifiedduration. 3. Tuningmemoryusage Two server configuration options, min server memory (MB) and max server memory (MB), can be used to specify upper and lower bounds for the memory an SQL Server instance will use. The SQL Server documentation discusses the issue of how to properly settheseconfigurationparameters( US/). Thesetwoserveroptionscanbesetsothattheirvaluesareequal.Inthissituation,once the instance has grown its memory to that value, it should not increase or decrease it. These server configuration options can be set with the system stored procedure sp_configureorwiththesqlservermanagementstudio.whentheinstanceisstarted,it takes as much memory as it needs to initialize. This may well be below the min server memory(mb)value.however,onceithascrossedthisvalue,itshouldnotdropbelowit. This ensures that even if the instance is not busy, some memory will be kept ready for starting queries. Thus performance is not degraded by the instance trying to suddenly acquirememoryithasgivenup.themaxservermemory(mb)valueplacesanupperlimit onthememorytheinstancewilluse. IST/DEI Pág.5de7

6 AdministraçãoeOptimizaçãodeBasesdeDados Theindexcreatememoryconfigurationoptioncontrolstheamountofmemoryusedby sortoperationsduringindexcreation.whencreatingindexesinfrequentlyandduringoffpeak time, increasing this number can improve the performance of index creation. However,itisadvisabletokeeptheíndexcreatememoryoptionatalowernumber,so theindexcreationjobstillstartsevenifalltherequestedmemoryisnotavailable. The min memory per query server configuration option can be used to specify the minimumamountofmemorythatisallocatedfortheexecutionofaquery.whenthere are many queries executing concurrently in a system, increasing the value of the min memoryperquerycanhelpimprovetheperformanceofmemory intensivequeries,such assubstantialsortandhashoperations.however,donotsettheminmemoryperquery serverconfigurationoptiontoohigh,especiallyonverybusysystems,becausethequery hastowaituntilitcansecuretheminimummemoryrequestedoruntilthevaluespecified in the query wait server configuration option is exceeded. If more memory is available than the specified minimum value, the query is allowed to make use of the additional memory,providedthatthememorycanbeusedeffectivelybythequery. 4. TuningCPUusage In SQL Server, a single query can execute in parallel over multiple CPUs. For workloads that have a small number of complex queries running on SMP computers, this should bringaperformanceboost.foroltpworkloads,whichconsistofmanysmalltransactions, parallelism is unlikely to enhance performance. However, longer queries usually benefit fromparallelexecutionplans. Therearetwoserverconfigurationoptionsthataffectparallelqueryprocessing: ThemaxdegreeofparallelismoptioncontrolsthenumberofCPUsSQLServercanusefor parallelqueries thatis,themaximumnumberofthreadsaquerycanuse.thedefaultis to use all the processors. There is also a query optimizer hint, which can be used to influence parallel query execution. The MAXDOP query hint allows the max degree of parallelismtobesetonastatement by statementbasis. Thecostthresholdforparallelismcontrolsthethresholdoverwhichthequeryoptimizer generates a parallel plan. SQL Server creates and runs a parallel plan only when the estimatedcosttorunaserialplanforthesamequeryishigherthanthevaluesetincost thresholdforparallelism.thecostreferstoanestimatedelapsedtimeinsecondsrequired toruntheserialplanonaspecifichardwareconfiguration.thedefaultisfiveseconds. IST/DEI Pág.6de7

7 AdministraçãoeOptimizaçãodeBasesdeDados 5. TuningI/Oandcaching In previous labs, we have already looked at how databases, tables and indexes can be partitionedthroughmultipledevices,inordertofine tunei/operformance.wewillnow discussi/otuningaspectsrelatedtocachingbehaviorandrowprefetching. Read aheadprocessingisamechanismusedbysqlservertoreducethenumberofstalls a thread experiences waiting for a physical read to complete. It is a concept similar to instructionprefetchinacpu.ifsqlserverrealizesthatatablescanoranindexscanis taking place in other words, sequential scanning of pages it can start to prefetch pagesintothedatacachebeforethethreadrequeststhosepages. SQLServerusesanLRUstrategyforupdatingthedatacache.Tablesandindexesthatare accessedfrequentlystayinthecache,whileother,leastusedpagesareflushedoutfirst. In this way the pages that are often required are the pages that connections get fast accessto.however,itispossiblethatfastaccessisrequiredtotablesandindexesthatare notaccessedfrequentlyenoughtokeeptheminthedatacache. Tokeepatableanditsindexesindatacacheusethesp_tableoptionstoredprocedure: EXECsp_tableoption'table_name','pintable',true; Thetablenamecanusewildcardcharacters.Thisstatementdoesnotloadpagesfromthe tableintothedatacache,butoncetheyarereadintodatacachebynormalactivity,they stay there and are not removed. This can result in little data cache being left for other tablesandindexes,sotablepinningshouldbeusedwithcare. Toturntheoptionoff,justusethefalsekeyword,asfollows: EXECsp_tableoption'table_name','pintable',false; IST/DEI Pág.7de7