Průvodce ověřováním a optimalizací po migraci

platí pro:SQL Server

Krok po migraci SQL Serveru je zásadní pro přizpůsobení přesnosti a úplnosti dat a odhalení problémů s výkonem úlohy.

Běžné scénáře výkonu

Následuje několik běžných scénářů výkonu, ke kterým dochází po migraci na platformu SQL Server a jak je vyřešit. Patří sem scénáře specifické pro migraci ze serveru SQL Server na novější verzi SQL Serveru (ze starších verzí na novější) a pro migraci z jiných platforem (například Oracle, DB2, MySQL a Sybase) na SQL Server.

Regrese dotazů v důsledku změny verze odhadu kardinality (CE)

Platí pro: migraci ze serveru SQL Server na SQL Server.

Při migraci ze starší verze SQL Serveru na SQL Server 2014 (12.x) nebo novějších verzí a upgrade úrovně kompatibility databáze na nejnovější dostupnou verzi může být úloha vystavena riziku regrese výkonu.

Důvodem je to, že počínaje SQL Serverem 2014 (12.x) jsou všechny změny Optimalizátoru dotazů svázané s nejnovější úrovní kompatibility databáze, takže plány se v okamžiku upgradu nezmění správně, ale když uživatel změní COMPATIBILITY_LEVEL možnost databáze na nejnovější. Tato funkce v kombinaci s úložištěm dotazů poskytuje skvělou úroveň kontroly nad výkonem dotazů v procesu upgradu.

Další informace o změnách optimalizátoru dotazů zavedených v SQL Serveru 2014 (12.x) najdete v tématu Optimalizace plánů dotazů pomocí nástroje pro posouzení kardinality SQL Serveru 2014.

Další informace o CE naleznete v tématu Odhad kardinality (SQL Server).

Postup řešení

Změňte úroveň kompatibility databáze na zdrojová verze a postupujte podle doporučeného pracovního postupu upgradu, jak je znázorněno na následujícím obrázku:

Diagram znázorňující doporučený pracovní postup upgradu

Další informace o tomto článku naleznete v tématu Zachování stability výkonu během upgradu na novější SQL Server.

Citlivost na zjišťování parametrů

Platí pro: Migrace z cizí platformy (například Oracle, DB2, MySQL a Sybase) na SQL Server.

Poznámka:

Při migracích ze serveru SQL Server na SQL Server platí, že pokud tento problém existoval ve zdrojovém SQL Serveru, migrace na novější verzi SQL Serveru v nezměněné podobě tento scénář neřeší.

SQL Server kompiluje plány dotazů na uložené procedury pomocí zašifrování vstupních parametrů při první kompilaci, generování parametrizovaného a opakovaně použitelného plánu optimalizovaného pro danou distribuci vstupních dat. I když nejsou uložené procedury, většina příkazů generující triviální plány je parametrizována. Jakmile je plán poprvé uložen do mezipaměti, každé další spuštění je přiřazeno k dříve uloženému plánu.

Potenciální problém nastane, když první kompilace nepoužívá nejběžnější sady parametrů pro běžnou úlohu. U různých parametrů se stejný plán provádění stane neefektivním. Další informace o tomto článku najdete v tématu Citlivost parametrů.

Postup řešení

  1. Použijte nápovědu RECOMPILE. Plán se pokaždé vypočítá pro každou hodnotu parametru zvlášť.

  2. Přepište uloženou proceduru tak, aby používala možnost (OPTIMIZE FOR(<input parameter> = <value>)). Rozhodněte se, kterou hodnotu použít, která vyhovuje většině relevantních úloh, a vytvořte a udržujte jeden plán, který bude efektivní pro parametrizovanou hodnotu.

  3. Přepište uloženou proceduru pomocí místní proměnné uvnitř procedury. Optimalizátor teď používá vektor hustoty pro odhady, což vede ke stejnému plánu bez ohledu na hodnotu parametru.

  4. Přepište uloženou proceduru tak, aby používala možnost (OPTIMIZE FOR UNKNOWN). Stejný účinek jako použití techniky místní proměnné.

  5. Přepište dotaz tak, aby používal nápovědu DISABLE_PARAMETER_SNIFFING. Má stejný účinek jako použití techniky lokálních proměnných, protože zcela vypne odposlouchávání parametrů, pokud se nepoužije OPTION(RECOMPILE), WITH RECOMPILE nebo OPTIMIZE FOR <value>.

Návod

Pomocí funkce Analýza plánu sady Management Studio můžete rychle zjistit, jestli se jedná o problém. Další informace najdete v tématu Nové v nástroji SSMS: Jednodušší řešení potíží s výkonem dotazů.

Chybějící indexy

Platí pro: Migraci z cizí platformy (například Oracle, DB2, MySQL a Sybase) na SQL Server a migraci ze serveru SQL Server na SQL Server.

Nesprávné nebo chybějící indexy způsobují nadbytečné vstupně-výstupní operace, které vedou k nedostatku paměti a procesoru. Důvodem může být změna profilu úlohy, například použití různých predikátů a zneplatnění stávajícího návrhu indexu. Mezi důkazy o špatné strategii indexování nebo změnách profilu úloh patří:

  • Vyhledejte duplicitní, redundantní, zřídka používané a zcela nepoužité indexy.
  • Zvláštní pozornost věnujte nepoužívaným indexům při aktualizacích

Postup řešení

  1. Pro všechny chybějící odkazy na index použijte plán grafického spouštění.

  2. Návrhy indexování generované poradcem pro ladění databázového stroje

  3. Použijte sys.dm_db_missing_index_details.

  4. Pomocí existujících skriptů, které můžou používat existující zobrazení dynamické správy, můžete získat přehled o všech chybějících, duplicitních, redundantních, zřídka používaných a zcela nepoužívaných indexech, ale také v případě, že se jakýkoli odkaz na index naznačuje nebo pevně zakóduje do existujících procedur a funkcí ve vaší databázi.

Návod

Mezi příklady takových existujících skriptů patří vytvoření indexu a informace o indexu.

Nemožnost používat predikáty k filtrování dat

Platí pro: Migraci z cizí platformy (například Oracle, DB2, MySQL a Sybase) na SQL Server a migraci ze serveru SQL Server na SQL Server.

Poznámka:

Při migracích ze serveru SQL Server na SQL Server platí, že pokud tento problém existoval ve zdrojovém SQL Serveru, migrace na novější verzi SQL Serveru v nezměněné podobě tento scénář neřeší.

Optimalizátor dotazů SQL Serveru může obsahovat pouze informace, které jsou známé v době kompilace. Pokud úloha spoléhá na predikáty, které je možné znát pouze v době provádění, zvyšuje se potenciál pro špatnou volbu plánu. Pro kvalitnější plán musí být predikáty SARGable.

Poznámka:

Termín SARGable v relačních databázích označuje predikát Search ARGumentable, který může využít index ke zrychlení zpracování dotazu. Další informace najdete v průvodci architekturou a návrhem indexů v SQL Serveru a Azure SQL.

Některé příklady ne-SARGable predikátů:

  • Implicitní převody dat, například z varchar na nvarchar nebo z int na varchar. V plánech skutečného spuštění vyhledejte upozornění modulu runtime CONVERT_IMPLICIT . Převod z jednoho typu na jiný může také způsobit ztrátu přesnosti.

  • Složité nedeterminované výrazy, například WHERE UnitPrice + 1 < 3.975, ale ne WHERE UnitPrice < 320 * 200 * 32.

  • Výrazy používající funkce, například WHERE ABS(ProductID) = 771 nebo WHERE UPPER(LastName) = 'Smith'

  • Řetězce s úvodním zástupným znakem, například WHERE LastName LIKE '%Smith', ale ne WHERE LastName LIKE 'Smith%'.

Postup řešení

  1. Vždy deklarujte proměnné/parametry jako zamýšlené cílové datové typy.

    To může zahrnovat porovnání libovolného uživatelem definovaného konstruktoru kódu, který je uložený v databázi (například uložené procedury, uživatelem definované funkce nebo zobrazení) se systémovými tabulkami, které obsahují informace o datových typech používaných v podkladových tabulkách (například sys.columns).

  2. Pokud nelze procházet veškerý kód k předchozímu bodu, změňte datový typ tabulky tak, aby odpovídal jakékoli deklaraci proměnné nebo parametru.

  3. Zdůvodněte užitečnost následujících konstrukcí:

    • Funkce používané jako predikáty;
    • Vyhledávání pomocí zástupných znaků;
    • Komplexní výrazy založené na sloupcových datech – vyhodnoťte nutnost vytvořit trvalé počítané sloupce, které je možné indexovat;

Poznámka:

Všechny tyto kroky je možné provádět programově.

Použití funkcí s hodnotami tabulky (více příkazů vs. vložené)

Platí pro: Migraci z cizí platformy (například Oracle, DB2, MySQL a Sybase) na SQL Server a migraci ze serveru SQL Server na SQL Server.

Poznámka:

Při migracích ze serveru SQL Server na SQL Server platí, že pokud tento problém existoval ve zdrojovém SQL Serveru, migrace na novější verzi SQL Serveru v nezměněné podobě tento scénář neřeší.

Funkce s hodnotami tabulky vrací datový typ tabulky, který může být alternativou k zobrazením. Zobrazení jsou sice omezená na jeden SELECT příkaz, ale uživatelem definované funkce můžou obsahovat další příkazy, které umožňují více logiky, než je v zobrazeních možné.

Vzhledem k tomu, že výstupní tabulka funkce vracející tabulku s více příkazy (MSTVF) se nevytváří v době kompilace, spoléhá se optimalizátor dotazů SQL Serveru při určování odhadovaného počtu řádků na heuristiky, nikoli na skutečné statistiky.

I když se indexy přidají do základních tabulek, nepomůže to.

Pro MSTVFs sql Server používá pevný odhad 1 pro počet řádků, které má vrátit MSTVF (počínaje SQL Serverem 2014 (12.x), který pevný odhad představuje 100 řádků).

Postup řešení

  1. Pokud MSTVF obsahuje pouze jediný příkaz, převeďte ji na inline funkci vracející tabulku.

    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;
END

    Příklad vloženého formátování je zobrazen níže.

    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)

  2. Pokud je složitější, zvažte použití průběžných výsledků uložených v tabulkách Memory-Optimized nebo dočasných tabulkách.

Související obsah

  • Last updated on