Validerings- och optimeringsguide efter migreringen
gäller för:
SQL Server
SQL Server-steget efter migreringen är avgörande för att säkerställa datanoggrannhet och fullständighet samt upptäcka prestandaproblem av arbetsbelastningen.
Vanliga prestandascenarier
Följande är några av de vanliga prestandascenarier som påträffas efter migrering till SQL Server Platform och hur du löser dem. Dessa inkluderar scenarier som är specifika för SQL Server till SQL Server-migrering (äldre versioner till nyare versioner) och extern plattform (till exempel Oracle, DB2, MySQL och Sybase) till SQL Server-migrering.
Frågeregressioner på grund av ändring i version av kardinalitetsestimator (CE)
gäller för: SQL Server till SQL Server-migrering.
När du migrerar från en äldre version av SQL Server till SQL Server 2014 (12.x) eller senare versioner och uppgraderar databaskompatibilitetsnivå till den senaste tillgängliga, kan en arbetsbelastning exponeras för risken för prestandaregression.
Det beror på att från och med SQL Server 2014 (12.x) är alla query optimizer-ändringar kopplade till den senaste databaskompatibilitetsnivå, så planer ändras inte direkt vid uppgraderingspunkten, utan i stället när en användare ändrar COMPATIBILITY_LEVEL databasalternativet till det senaste. Den här funktionen i kombination med Query Store ger dig en bra kontroll över frågeprestanda i uppgraderingsprocessen.
Mer information om query optimizer-ändringar som introducerades i SQL Server 2014 (12.x) finns i Optimera dina frågeplaner med SQL Server 2014 Cardinality Estimator.
Mer information om CE finns i Kardinalitetsuppskattning (SQL Server).
Steg för att lösa
Ändra databaskompatibilitetsnivå till källversionen och följ det rekommenderade uppgraderingsarbetsflödet enligt följande bild:
Mer information om den här artikeln finns i Behåll prestandastabilitet under uppgraderingen till nyare SQL Server-.
Känslighet för parametersniffning
gäller för: Utländsk plattform (till exempel Oracle, DB2, MySQL och Sybase) för SQL Server-migrering.
Obs
För migreringar från SQL Server till SQL Server, om det här problemet fanns i källans SQL Server, kommer en migrering till en nyare version av SQL Server as-is inte att lösa det här problemet.
SQL Server kompilerar frågeplaner på lagrade procedurer genom att sniffa indataparametrarna vid den första kompileringen, generera en parametriserad och återanvändbar plan som är optimerad för den indatadistributionen. De flesta instruktioner som genererar triviala planer parametriseras, även om de inte är lagrade procedurer. När en plan först cachelagras mappar alla framtida körningar till en tidigare cachelagrad plan.
Ett potentiellt problem uppstår när den första kompilering inte använder de vanligaste uppsättningarna parametrar för den vanliga arbetsbelastningen. För olika parametrar blir samma körningsplan ineffektiv. Mer information om den här artikeln finns i Parameterkänslighet.
Steg för att lösa
- Använd tipset
RECOMPILE. En plan beräknas varje gång den anpassas till varje parametervärde. - Skriv om den lagrade proceduren för att använda alternativet
(OPTIMIZE FOR(<input parameter> = <value>)). Bestäm vilket värde som ska användas som passar de flesta relevanta arbetsbelastningar, skapa och underhålla en plan som blir effektiv för det parametriserade värdet. - Skriv om den lagrade proceduren med hjälp av den lokala variabeln i proceduren. Nu använder optimeraren densitetsvektorn för uppskattningar, vilket resulterar i samma plan oavsett parametervärde.
- Skriv om den lagrade proceduren för att använda alternativet
(OPTIMIZE FOR UNKNOWN). Samma effekt som med hjälp av den lokala variabeltekniken. - Skriv om frågan för att använda tipset
DISABLE_PARAMETER_SNIFFING. Samma effekt som att använda den lokala variabeltekniken genom att helt inaktivera parametersniffning, såvida inteOPTION(RECOMPILE),WITH RECOMPILEellerOPTIMIZE FOR <value>används.
Tips
Använd funktionen Management Studio Plan Analysis för att snabbt identifiera om det här är ett problem. Mer information finns i Nyheter i SSMS: Felsökning av frågaresultat blev enklare!.
Index saknas
gäller för: Utländsk plattform (till exempel Oracle, DB2, MySQL och Sybase) och SQL Server till SQL Server-migrering.
Felaktiga eller saknade index orsakar extra I/O som leder till att extra minne och PROCESSOR slösas bort. Det kan bero på att arbetsbelastningsprofilen har ändrats, till exempel genom att använda olika predikat, vilket gör den befintliga indexdesignen ogiltig. Exempel på dålig indexeringsstrategi eller ändringar i arbetsbelastningsprofilen är:
- Leta efter duplicerade, redundanta, sällan använda och helt oanvända index.
- Var särskilt försiktig med uppdateringar av oanvända index.
Steg för att lösa
- Använd den grafiska körningsplanen för eventuella indexreferenser som saknas.
- Indexeringsförslag som genereras av Database Engine Tuning Advisor.
- Använd sys.dm_db_missing_index_details.
- Använd befintliga skript som kan använda befintliga DMV:er för att ge insikter om eventuella saknade, duplicerade, redundanta, sällan använda och helt oanvända index, men även om någon indexreferens tipsas/hårdkodas i befintliga procedurer och funktioner i databasen.
Tips
Exempel på sådana befintliga skript är skapande av index och indexinformation.
Det går inte att använda predikat för att filtrera data
gäller för: Utländsk plattform (till exempel Oracle, DB2, MySQL och Sybase) och SQL Server till SQL Server-migrering.
Not
Om detta problem fanns i käll-SQL Servern, kommer en migrering till en nyare version av SQL Server as-is inte att lösa det här scenariot.
SQL Server Query Optimizer kan bara ta hänsyn till information som är känd vid kompileringstillfället. Om en arbetsbelastning förlitar sig på predikat som bara är kända vid körningstid ökar risken för ett dåligt val av plan. För en plan av bättre kvalitet måste predikaten vara SARGable, eller Search Argumentkunna.
Några exempel på icke-SARGable predikat:
- Implicita datakonverteringar, till exempel varchar till nvarchar, eller int till varchar. Leta efter körtidsvarningar
CONVERT_IMPLICITi de faktiska körningsplanerna. Konvertering från en typ till en annan kan också orsaka en förlust av precision. - Komplexa obestämda uttryck som
WHERE UnitPrice + 1 < 3.975, men inteWHERE UnitPrice < 320 * 200 * 32. - Uttryck som använder funktioner, till exempel
WHERE ABS(ProductID) = 771ellerWHERE UPPER(LastName) = 'Smith' - Strängar som börjar med ett wildcard-tecken, till exempel
WHERE LastName LIKE '%Smith', men inteWHERE LastName LIKE 'Smith%'.
Steg för att lösa
Deklarera alltid variabler/parametrar som avsett mål Datatyper.
Det kan handla om att jämföra alla användardefinierade kodkonstruktioner som lagras i databasen (till exempel lagrade procedurer, användardefinierade funktioner eller vyer) med systemtabeller som innehåller information om datatyper som används i underliggande tabeller (till exempel sys.columns (Transact-SQL)).
Om det inte går att bläddra igenom all kod till föregående punkt ändrar du i samma syfte datatypen i tabellen så att den matchar en variabel-/parameterdeklaration.
Ta reda på hur användbara följande konstruktioner är:
- Funktioner som används som predikat;
- Jokerteckensökningar;
- Komplexa uttryck baserade på kolumndata – utvärdera behovet av att i stället skapa beständiga beräknade kolumner som kan indexeras.
Notera
Alla dessa steg kan utföras programmatiskt.
Användning av tabellvärdesfunktioner (flerradsfunktioner jämfört med inlinjefunktioner)
gäller för: Utländsk plattform (till exempel Oracle, DB2, MySQL och Sybase) och SQL Server till SQL Server-migrering.
Not
För SQL Server-till-SQL Server-migreringar, om det här problemet fanns i käll-SQL Server, kommer migrering till en nyare version av SQL Server as-is inte att åtgärda problemet.
Tabellvärdefunktioner returnerar en tabelldatatyp som kan vara ett alternativ till vyer. Även om vyer är begränsade till en enda SELECT-instruktion kan användardefinierade funktioner innehålla ytterligare instruktioner som tillåter mer logik än vad som är möjligt i vyer.
Viktig
Eftersom utdatatabellen för en tabellvärdesfunktion med flera instruktioner (MSTVF) inte skapas vid kompileringstillfället förlitar sig SQL Server Query Optimizer på heuristik och inte faktisk statistik för att fastställa raduppskattningar. Även om index läggs till i bastabellerna kommer detta inte att hjälpa. För MSTVF:er använder SQL Server en fast uppskattning på 1 för det antal rader som förväntas returneras av en MSTVF (från och med SQL Server 2014 (12.x) som fast uppskattning är 100 rader).
Steg för att lösa
Om MSTVF endast består av ett enda uttryck, konvertera det till en infogad tabellvärdesfunktion.
CREATE FUNCTION dbo.tfnGetRecentAddress(@ID int) RETURNS @tblAddress TABLE ([Address] VARCHAR(60) NOT NULL) AS BEGIN INSERT INTO @tblAddress ([Address]) SELECT TOP 1 [AddressLine1] FROM [Person].[Address] WHERE AddressID = @ID ORDER BY [ModifiedDate] DESC RETURN ENDExemplet med inlineformat visas nästa.
CREATE FUNCTION dbo.tfnGetRecentAddress_inline(@ID int) RETURNS TABLE AS RETURN ( SELECT TOP 1 [AddressLine1] AS [Address] FROM [Person].[Address] WHERE AddressID = @ID ORDER BY [ModifiedDate] DESC )Om det är mer komplext bör du överväga att använda mellanliggande resultat som lagras i Memory-Optimized tabeller eller temporära tabeller.