sql >> Databáze >  >> RDS >> Oracle

Chování Oracle Parallel Query s nástroji IDE jako SQL Developer nebo Toad

Vaše dotazy nejsou skutečně dokončeny. Přestože váš dotaz načítá pouze prvních 1000 řádků, SQL Developer načítá pouze prvních 50 řádků z těchto 1000 řádků. IDE nezavře kurzor, dokud nepřejdete na poslední řádek. Jakmile načtete všechna data, tyto paralelní procesy zmizí. Ujistěte se, že vidíte "Všechny řádky načteny:1000 za X sekund", místo ""Načteno 50 řádků za Y sekund". (Přál bych si, aby SQL Developer více vizuálně zviditelnil, že čekají další řádky.) Nebudete viz tento problém v SQL*Plus, protože SQL*Plus vždy zachytí všechny řádky.

Když je načteno pouze prvních N řádků, tyto paralelní procesy jsou "AKTIVNÍ", ale nic nedělají. měli byste být schopni tyto relace ignorovat, protože nevyužívají žádné významné zdroje.

Pokud se obáváte pouze počtu paralelních relací, možná budete chtít upravit svá očekávání. Kdysi jsem byl ve stejné situaci jako vy – neustále jsem uživatelům říkal, že jejich (neúplné) dotazy zatěžují všechny paralelní relace. Nakonec jsem zjistil, že to byl jen problém, protože jsem si vytvořil uměle vzácný zdroj. Paralelní procesy Oracle jsou obvykle lehké a databáze mohou podporovat mnohem více paralelních procesů, než si většina lidí myslí.

Jaké jsou hodnoty vašich parametrů pro PARALLEL_MAX_SERVERS, PARALLEL_THREADS_PER_CPU a CPU_COUNT? Podívejte se na výchozí hodnotu pro PARALLEL_MAX_SERVERS . Podle manuálu je výchozí číslo:PARALLEL_MAX_SERVERS = PARALLEL_THREADS_PER_CPU * CPU_COUNT * concurrent_parallel_users * 5 .

Většina správců databází vidí maximální počet paralelních vláken v řádu stovek, zpanikaří a pak toto číslo sníží. A pak začneme křičet na vývojáře, že používají nedůležitý zdroj, který byl uměle omezen. Místo toho bychom měli číslo vrátit zpět na výchozí hodnotu a prostě ignorovat náhodné paralelní relace. Pokud uživatel nepřekračuje limity IO nebo CPU, nemělo by záležet na tom, kolik paralelních vláken používá.

(Možná s výjimkou zabránění masivnímu využití paralelní relace dotazu. Umístěte své uživatele do jiného profilu a nastavte jejich SESSIONS_PER_USER na několik desítek. NEOMEZUJTE to pouze na 1 nebo 2. IDE potřebují další relace pro více karet, procesy na pozadí, které sbírají metadata, a relace ladění. Pokud nastavíte limit na 2, vaši vývojáři nebudou moci správně používat IDE.)

UPRAVIT (reakce na komentáře)

Nejsem si jistý, zda dokážete vyčíst mnoho o stavu koordinátor dotazů . Kontrola kvality dělá několik věcí, ale v ideálním případě bude většinu času nečinná, zatímco většinu práce zvládnou paralelní relace.

S modelem producent/spotřebitel může polovina paralelních relací přijímat data, ale ve skutečnosti nic nedělají – jako by to byly jen paměťové struktury v některých operacích. Paralelní relace se mohou přepínat mezi aktivními a neaktivními, protože ne všechny kroky budou vyžadovat tolik relací. Ale nechtěli bychom, aby Oracle uzavíral relace uprostřed, protože mohou být potřeba později, a nechtěli bychom ztrácet čas otevíráním a uzavíráním relací.

Existují desítky faktorů, které ovlivňují stupeň paralelismu, ale pokud vím, zvýšení PARALLEL_MAX_SERVERS neovlivní počet paralelních serverů požadovaných pro jeden příkaz. (Pokud však příkaz již požadoval více serverů, než je maximum, zvýšení parametru může ovlivnit počet přidělených relací).

Může se zdát, že příkazy SQL pouze náhodně zachycují všechny paralelní relace, ale nakonec výpočty DOP téměř vždy dodržují deterministická pravidla. Jen ta pravidla jsou tak složitá, že je těžké říct, jak to funguje. Jedním společným bodem zmatku je například to, že kdykoli dotaz přidá řazení nebo seskupení, počet paralelních relací se zdvojnásobí.




  1. Pomocí UNNEST s JOIN

  2. Aktualizace časového razítka Laravel bez explicitního volání

  3. MySQL - GROUP BY zpomalit stránku

  4. Naformátujte číslo jako měnu v SQLite