sql >> Databáze >  >> RDS >> Sqlserver

Časový limit dotazu z webové aplikace vyprší, ale z manažerského studia běží v pořádku

To je to, co jsem se zatím naučil ze svého výzkumu.

.NET odesílá nastavení připojení, která nejsou stejná jako ta, která získáte, když se přihlásíte do management studia. Zde je to, co uvidíte, když naskenujete spojení s Sql Profiler:

-- network protocol: TCP/IP  
set quoted_identifier off  
set arithabort off  
set numeric_roundabort off  
set ansi_warnings on  
set ansi_padding on  
set ansi_nulls off  
set concat_null_yields_null on  
set cursor_close_on_commit off  
set implicit_transactions off  
set language us_english  
set dateformat mdy  
set datefirst 7  
set transaction isolation level read committed  

Tato nastavení nyní vkládám nad každý dotaz, který spustím při přihlášení k serveru SQL, abych se ujistil, že nastavení jsou stejná.

V tomto případě jsem po odpojení a opětovném připojení vyzkoušel každé nastavení jednotlivě a zjistil jsem, že změna arithabortu z vypnutého na zapnutý zkrátila problémový dotaz z 90 sekund na 1 sekundu.

Nejpravděpodobnější vysvětlení souvisí s čicháním parametrů, což je technika, kterou SQL Server používá k výběru toho, co považuje za nejúčinnější plán dotazů. Když změníte jedno z nastavení připojení, může optimalizátor dotazů zvolit jiný plán a v tomto případě zřejmě zvolil špatný.

Ale nejsem o tom úplně přesvědčen. Po změně tohoto nastavení jsem se pokusil porovnat skutečné plány dotazů a ještě jsem neviděl, že by rozdíl vykazoval nějaké změny.

Je v nastavení arithabort ještě něco, co by mohlo v některých případech způsobit pomalé spuštění dotazu?

Řešení se zdálo jednoduché:Stačí vložit set arithabort do horní části uložené procedury. To by ale mohlo vést k opačnému problému:změňte parametry dotazu a najednou to běží rychleji s 'vypnuto' než 'zapnuto'.

V současné době spouštím proceduru „s rekompilací“, abych se ujistil, že se plán pokaždé znovu obnoví. Pro tuto konkrétní zprávu je to v pořádku, protože její rekompilace trvá možná sekundu, a to není příliš patrné na zprávě, jejíž návrat trvá 1-10 sekund (je to monstrum).

Ale není to volba pro jiné dotazy, které se spouštějí mnohem častěji a potřebují se vrátit co nejrychleji, během několika milisekund.



  1. Vyberte tři nejlepší hodnoty v každé skupině

  2. Jak zobrazím seznam všech sloupců v tabulce?

  3. Problémy s připojením s SQLAlchemy a více procesy

  4. Transparentní šifrování dat a vždy šifrováno