it-swarm-eu.dev

Použití SQL Profiler v databázi, která je ve výrobě

Jako vývojář používám SQL Profiler poměrně často. Je to dobrý nástroj pro ladění, a to jak sledovat, co můj kód dělá, tak analyzovat problémy s výkonem.

Ale vždy jsem to použil na můj rozvoj prostředí a velmi kontrolovaným způsobem.

  • Spusťte aplikaci a získejte ji do konkrétního stavu
  • Spusťte trasování na profilu
  • Proveďte konkrétní sled akcí v mé aplikaci
  • Zastavte trasování a prozkoumejte výsledky.

Lze SQL Profiler prakticky použít v produkčním prostředí?

Moje první obava je, že by to snížilo výkon.

Moje druhá starost je, že protože je ve výrobě, nespouštíte samotné zajímavé akce. Budete muset nechat profiler běžet dlouhou dobu a poté analyzovat výsledky. Stane se výsledek příliš těžkopádný? (Zabírá příliš mnoho místa na disku a je příliš těžké na dotaz).

Používá někdo SQL Profiler ve výrobě?

28
Andrew Shepherd

Použití Sql Server Profiler (nástroj GUI) ke sledování produkčního serveru není dobrý nápad. Ale záleží to na zatížení. Namísto toho použijte trasování sql na straně serveru (viz sp_trace_XXX procedury). Také jsem našel články:

Dopad na výkon: Trailer Profiler vs. Tracing SQL na straně server ,

Automatizace trasování na straně serveru na serveru SQL

Vyhněte se příčinám problémů s Profilerem

možná to bude zajímavé a užitečné.

Kniha online říká:

  • Spusťte Profiler na dálku místo přímo na serveru
  • Vyhněte se zahrnutí událostí, které se vyskytují často (např. Zámek: Získané), pokud to není nezbytně nutné
  • Zahrnout pouze potřebné třídy událostí
  • Určete omezující filtry pro snížení počtu událostí
  • Vyhněte se nadbytečným datům (např. SQL: BatchStarting a SQL: BatchCompleted)
  • Vyhněte se běhu velkých stop s Profilerem; místo toho zvažte serverové SQL trasování
  • Omezte velikost trasovacího souboru na straně serveru a spravujte využití místa
19
garik

Vždy používám SQL Profiler proti produkci. Při správném provedení (filtrování tak, abyste získali zpět velmi malé množství dat) proti serveru, je riziko minimální. Sledování všeho by bylo zbytečné.

21
mrdenny
  1. Ano, akt monitorování bude vyžadovat určité zdroje. Jeho spuštění na přetíženém serveru by ho mohlo zabít.

  2. Budete skutečně sledovat zatížení skutečného života: vaše akce se mohou ztratit v hluku tohoto zatížení.

Někdy to běžíme na produkci. Hlavně s textovým filtrem pro konkrétní kód, nebo s filtry CPU/trvání pro zachycení delších běžících dotazů. A nesnažíme se zachytit plány provádění XML nebo nějaký takový nesmysl

Klíčem je vědět, co hledáte: nemáme tendenci nechat jej běžet a chytat všechno.

V tomto případě, pokud chcete vidět výsledky některých akcí, můžete to udělat mimo hodiny?

7
gbn

Profiler vždy představí dopad na výkon.

Pokud používáte SQL Server 2008R2 +, můžete použít rozšířené události. To poskytuje většinu informací, které vidíte v profilu, zlomkem výkonu.

Online úvod do knih http://technet.Microsoft.com/en-us/library/bb630354 (v = sql.105) .aspx

Tato funkce obdržela velkou aktualizaci v SQL Server 2012, která nyní obsahuje GUI v SSMS.

2
James Anderson