Je-li povolena proměnná registru DB2_FORCE_FCM_BP, bude pro další použití, zejména pro fondy vyrovnávacích pamětí, k dispozici o jeden segment sdílené paměti méně. Povolení proměnné registru DB2_FORCE_FCM_BP tak sníží maximální velikost fondů vyrovnávacích pamětí. Všimněte si, že vzhledem k velkému počtu dostupných segmentů sdílené paměti v 64bitovém prostředí hraje toto snížení počtu segmentů sdílené paměti roli pouze v 32bitových prostředích.
| | |Při prvním vytvoření tabulky je pro statistiku zadána hodnota -1 indikující, že pro tuto tabulku neexistuje žádná statistika. Až do shromáždění statistických údajů používá produkt |DB2 UDB pro kompilaci a optimalizaci příkazů SQL výchozí hodnoty. |Operace aktualizace statistiky indexu nebo tabulky může selhat, pokud nejsou nové hodnoty konzistentní s výchozími hodnotami. Proto před ruční aktualizací statistiky indexu nebo tabulky spusťte pro tuto tabulku nebo index příkaz runstats.
| | |Chybová zpráva SQL s označením SQL1169N má nový kód příčiny 5 indikující, že určitý sloupec tabulky vysvětlení je příliš malý.
|Následující text je aktualizací oddílu dokumentace Administration |Guide: Performance, Chapter 6. Understanding the SQL compiler (Příručka pro administraci: Výkon, kapitola 6. Princip činnosti kompilátoru SQL).
|Operaci odsunutí MDC lze použít i v případě, že index RID je součástí plánu optimalizace, bez ohledu na přítomnost klauzule WHERE v příkazu DELETE. |V důsledku toho je nutné při výpisu podmínek, které musí být splněny, aby byla povolena operace odsunutí a použita účinnější metoda pro odstranění řádků, odebrat podmínku stanovující, že "optimalizátorem není vybrán index RID při hledání řádků, které mají být odstraněny, kromě případů, kdy příkaz DELETE neobsahuje klauzuli WHERE".
|Dále můžete určit, zda je použita operace odsunutí MDC, protože výstup příkazu db2expln obsahuje frázi "Cell Delete". |Mějte na paměti, že příkaz db2exfmt tyto informace nezobrazuje.
|Následující text je aktualizací oddílu dokumentace Příloha A. |Proměnné registru a proměnné prostředí DB2:
|Popis proměnné DB2_MDC_ROLLOUT je třeba změnit tak, že podmínka stanovující, že "optimalizátorem není vybrán index RID při hledání řádků, které mají být odstraněny, kromě případů, kdy příkaz DELETE neobsahuje klauzuli WHERE" bude odstraněna ze seznamu.
| | |Pokud v prostředí produktu DB2 UDB Enterprise Server Edition aktualizujete hodnoty konfiguračních parametrů newlogpath, mirrorpath nebo overflowlogpath, bude k názvu cesty připojeno číslo uzlu bez ohledu na počet uzlů v systému. Toto pravidlo se vztahuje na systémy s jednou oblastí i na systémy s více oblastmi v prostředí DB2 UDB Enterprise Server Edition.
| | |Výchozí hodnota proměnné DB2_COLLECT_TS_REC_INFO je ON. V produktu DB2 UDB verze 8.1 s opravnou sadou FixPak 7 byla výchozí hodnota pro proměnnou registru DB2_COLLECT_TS_REC_INFO změněna na hodnotu ON. Ve stávající dokumentaci je výchozí hodnota pro tuto proměnnou nesprávně specifikována jako OFF.
Instance regulátoru sestává z obslužného programu typu frontend a jednoho nebo několika démonů. Každá spuštěná instance regulátoru je specifická pro instanci správce databází. Pokud spustíte regulátor, ve výchozím nastavení se spustí démon regulátoru pro každou oblast dělené databáze. Můžete však zadat, aby byl démon spuštěn pro jedinou oblast, kterou chcete monitorovat.
Jednotliví démoni regulátoru shromažďují informace o aplikacích, které pracují s databází. Tyto informace jsou pak démonem regulátoru kontrolovány oproti pravidlům, která zadáte v konfiguračním souboru regulátoru pro tuto databázi.
Místní reorganizace tabulky vyžaduje ve srovnání s klasickou reorganizací tabulky větší prostor pro žurnál.
Protože při místní reorganizaci tabulky jsou protokolovány aktivity, aby bylo možné provést zotavení v případě neočekávaného selhání, vyžaduje tato reorganizace více prostoru pro žurnál než klasická reorganizace.
Je možné, že pro místní reorganizaci bude zapotřebí prostor pro žurnál, jehož velikost bude rovna několikanásobku velikosti reorganizované tabulky. Množství požadovaného prostoru závisí na počtu přesouvaných řádků a počtu a velikosti indexů v tabulce.
Doporučení: Místní reorganizaci tabulky zvolte při nepřetržitém provozu s minimálními dobami vyhrazenými pro údržbu.
Reorganizace online tabulky DMS umožňuje spustit zálohování online tabulkového prostoru, ve kterém je tabulka uložena, a to během reorganizace. Během fáze zkracování se mohou vyskytnout čekání na zámek operace reorganizace.
Podrobné informace o provádění těchto metod reorganizace naleznete u popisu syntaxe příkazu REORG TABLE.
Proměnná registru DB2_LARGE_PAGE_MEM v 64bitové verzi systému AIX(R) 5L nyní podporuje klíčové slovo FCM.
U 64bitové verze systému AIX(R) 5L(TM) je ve výchozím nastavení paměť FCM v paměťové sadě DBMS. Pokud je však povolena proměnná registru DB2_FORCE_FCM_BP, je paměť FCM ve své vlastní paměťové sadě. U 64bitové verze systému AIX 5L(TM) podporuje proměnná DB2_LARGE_PAGE_MEM specifikaci paměťové sady DBMS. Pokud je paměť FCM v paměťové sadě DBMS a v této paměťové sadě je povolena podpora velkých stránek, bude paměť FCM ve velkých stránkách. Pokud je paměť FCM ve své vlastní paměťové sadě, musí být do hodnoty proměnné registru DB2_LARGE_PAGE_MEM přidáno klíčové slovo FCM, aby byly pro paměť FCM povoleny velké stránky.
Počínaje verzí DB2 Universal Database(TM) (UDB) 8.2.2 (ekvivalentní verzi 8.1 s opravou FixPak 9) lze v konfiguračním souboru určeném proměnnou registru DB2_RESOURCE_POLICY použít prvek SCHEDULING_POLICY. Prvek SCHEDULING_POLICY lze na některých platformách použít k výběru následujících položek:
Pomocí proměnných registru DB2PRIORITIES a DB2NTPRICLASS lze odděleně řídit strategii plánování operačního systému a nastavovat priority agentů DB2.
Zadání prvku SCHEDULING_POLICY v konfiguračním souboru zásad prostředků však poskytuje možnost společného zadání strategie plánování i souvisejících priorit agentů.
Výběr strategie plánování AIX SCHED_FIFO2 se zvýšením priority procesů zápisu a čtení žurnálu db2:
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>SCHED_FIFO2</POLICY_TYPE>
<PRIORITY_VALUE>60</PRIORITY_VALUE>
<EDU_PRIORITY>
<EDU_NAME>db2loggr</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
<EDU_PRIORITY>
<EDU_NAME>db2loggw</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>Náhrada nastavení DB2NTPRICLASS=H v systému Windows.
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>Ve verzi FixPak 8 byly přidány systémové proměnné DB2_MAPPED_BASE a DB2DBMSADDR.
Používání těchto proměnných registru se doporučuje pouze zkušeným uživatelům.
Není-li tato proměnná nastavena, produkt DB2 UDB se pokusí přemístit sdílené knihovny na virtuální adresu 0x10000000.
Proměnná registru může být také nastavena na libovolnou virtuální adresu (hexadecimální číslo) v rozsahu 31bitového a 32bitového adresního prostoru.
db2set DB2_MAPPED_BASE=
Následující zpráva se může v souboru db2diag.log objevit vícekrát, protože tato změna je vyžadována pro každý logický uzel jednou:
ADM0506I DB2 has automatically updated the "mapped_base" kernel parameter from "0x40000000(hex) 1073741824(dec)" to the recommended value "0x10000000(hex) 268435456(dec)".
Tato zpráva se zobrazí pouze v případě, že je nastavení proměnné registru úspěšné, a bude zahrnovat adresu, na kterou byly přemístěny sdílené knihovny.
db2set DB2DBMSADDR=
Tuto proměnnou lze nastavit společně s proměnnou DB2_MAPPED_BASE nebo samostatně a jemně tak doladit rozvržení adresního prostoru procesů DB2 UDB. Tato proměnná změní umístění sdílené paměti instance z aktuálního umístění na virtuální adrese 0x20000000 na novou zadanou hodnotu.
Ve verzi 8.2 byla přidána proměnná registru DB2TCP_CLIENT_RCVTIMEOUT.
Ve verzi 8.2 byla přidána proměnná výkonu DB2_LARGE_PAGE_MEM.
| Jméno proměnné | Operační systémy | Hodnoty |
|---|---|---|
| Popis | ||
| DB2_LARGE_PAGE_MEM |
pouze 64bitová verze systému AIX 5.x Linux |
Výchozí nastavení=NULL
Znakem * označíte všechny vhodné oblasti paměti, které mají používat paměť s velkými stránkami, nebo čárkami oddělený seznam specifických oblastí paměti, které mají používat paměť s velkými stránkami. Dostupné oblasti se liší podle operačního systému. V 64bitové verzi systému AIX 5.x lze zadat následující oblasti: DB, DBMS nebo PRIVATE. V systému Linux lze zadat následující oblasti: DB. |
|
Paměť s velkými stránkami je podporována pouze v produktu DB2 Universal Database (UDB) for AIX 5L, 64bitová edice, a v produktu DB2 UDB for Linux. Proměnná registru DB2_LARGE_PAGE_MEM se používá k povolení podpory velkých stránek při spuštění v systému AIX 5.x nebo v jakékoli architektuře Linux s odpovídající podporou jádra. Tato proměnná registru nahrazuje proměnnou registru DB2_LGPAGE_BP, kterou lze použít pouze pro povolení paměti s velkými stránkami u oblasti paměti sdílené databázemi. Tuto akci lze nyní povolit nastavením hodnoty DB2_LARGE_PAGE_MEM=DB. Veškerá dokumentace, která se zmiňuje o povolení velkých stránek pomocí proměnné registru DB2_LGPAGE_BP, může být považována za ekvivalentní nastavení DB2_LARGE_PAGE_MEM=DB. Použití velkých stránek je primárně určeno pro zlepšení výkonu vysokovýkonostních výpočetních aplikací. Aplikace s intenzivním přístupem k paměti, které používají velké množství virtuální paměti, mohou díky použití velkých stránek dosahovat zlepšení výkonu. Chcete-li v produktu DB2 UDB povolit používání velkých stránek, musíte nejdříve pro použití velkých stránek nakonfigurovat operační systém. Povolení velkých soukromých stránek zvýší použití paměti produktu DB2 UDB o významné množství, protože každý agent produktu DB2 UDB spotřebuje nejméně jednu velkou stránku (16 MB) fyzické paměti. Chcete-li povolit velké stránky pro soukromou paměť agenta v 64bitové verzi produktu DB2 UDB for AIX (nastavení DB2_LARGE_PAGE_MEM=PRIVATE), musí být kromě konfigurace operačního systému pro použití velkých stránek splněny následující podmínky:
V 64bitové verzi produktu DB2 UDB for AIX sníží povolení této proměnné velikost segmentu sdílené paměti podporujícího paměť databáze na minimální požadavek. Výchozím nastavením je vytvoření segmentu o velikosti 64 GB: další informace obsahuje konfigurační parametr databáze pro velikost sdílené paměti databáze (database_memory). Toto nastavení zabrání fixaci většího množství sdílené paměti, než bude skutečně potřeba, v paměti RAM. Nastavením této proměnné bude omezena schopnost dynamicky zvětšovat konfiguraci celkové sdílené paměti databáze (například možnost zvětšit velikost fondu vyrovnávacích pamětí). V systému Linux existuje ještě další požadavek, a to na dostupnost knihovny libcap.so. Má-li být tato volba funkční, musí být instalována tato knihovna. Je-li tato volba zapnuta a knihovna není v systému, produkt DB2 UDB zablokuje velké stránky jádra a bude pracovat jako dříve. Chcete-li v systému Linux ověřit, že jsou velké stránky jádra k dispozici, zadejte následující příkaz: cat /proc/meminfo Pokud k dispozici jsou, měly by se zobrazit následující tři řádky (čísla se budou lišit v závislosti na množství paměti konfigurované ve vašem počítači): HugePages_Total: 200
HugePages_Free: 200
Hugepagesize: 16384 KB
Pokud se tyto řádky nezobrazí nebo pokud je hodnota HugePages_Total rovna 0, je potřeba konfigurovat operační systém nebo jádro. |
||
Následující aktualizace se týká tématu "SQL compiler variables" (Proměnné kompilátoru SQL) v příloze A, "DB2 registry and environment variables" (Registr DB2 a proměnné prostředí), v příručce Administration Guide: Performance:
Pokud jsou jedna nebo obě proměnné kompilátoru DB2, DB2_MINIMIZE_LISTPREFETCH a DB2_INLIST_TO_NLJN, nastaveny na hodnotu ON, zůstanou aktivní, i když je zadána proměnná REOPT(ONCE).
Následují aktualizace dokumentace týkající se konfiguračních parametrů:
Konfigurační parametr správce databází Typ ověřování (ověřování) přijímá i následující hodnoty:
Server přijímá šifrovaná schémata ověřování SERVER a šifrování uživatelských dat. Ověřování funguje přesně stejným způsobem jako SERVER_ENCRYPT.
Při použití typu ověřování budou šifrována následující uživatelská data:
Server přijímá šifrovaná schémata ověřování SERVER a šifrování uživatelských dat. Kromě toho umožňuje tento typ ověřování kompatibilitu s dřívějšími produkty, které nepodporují typ ověřování DATA_ENCRYPT. Tyto produkty umožňují připojení k typu ověřování SERVER_ENCRYPT bez šifrování uživatelských dat. Produkty podporující nový typ ověřování jej musí použít. Tento typ ověřování je platný pouze v konfiguračním souboru správce databází serveru a neplatí, používá-li se v příkazu CATALOG DATABASE.
Od produktu DB2 Universal Database verze 8.2 se výchozí hodnota konfiguračního parametru správce databází Vliv obslužných programů na výkon (util_impact_lim) mění z hodnoty 100 na hodnotu 10.
Následující konfigurační parametry správce databází všechny přijímají jména skupin o velikosti 30 bajtů (nebo méně), a to na všech platformách:
Tabulka uvedená v tématu "Souhrn konfiguračních parametrů správce databází" obsahuje pro tyto konfigurační parametry správce databází nesprávné typy dat. Správná hodnota je ve všech případech char(30).
Maximální velikost konfiguračního parametru Databáze velikosti segmentu rozšířené paměti (estore_seg_size) v systému Windows založeném na platformách je 16 777 216.
Správné horní omezení konfiguračního parametru databáze Časový limit zotavení HADR (hadr_timeout) je 4 294 967 295.
V dokumentaci ke konfiguračnímu parametru databáze Maximální velikost paměti pro seznam zámků (locklist) je uvedeno, že maximální hodnota pro servery Windows (64bitová a 32bitová verze) sloužící pouze lokálním klientům je 60 000. Tato hodnota je nesprávná. Správná hodnota je 524 288.
Rozsah hodnot konfiguračního parametru databáze Počet databázových záloh (num_db_backups je nesprávný. Správný rozsah je 0 - 32 767.
Po migraci do produktu DB2 Universal Database (UDB) verze 8.2 z verze 8.1 bude produkt DB2 UDB používat nový soubor konfiguračních parametrů databáze velikosti 16 kB pojmenovaný SQLDBCONF. (Ve verzi 8.1 měl soubor konfiguračních parametrů databáze velikost pouze 4 kB a jmenoval se SQLDBCON.)
Od verze 8.1 je proměnná registru DB2_HASH_JOIN nastavena ve výchozím nastavení na hodnotu ON.
Je třeba použít proměnnou hašovaného spojení, ale musí se v zájmu lepšího výkonu doladit.
Výkon hašovaného spojení je nejlepší v případě, kdy se lze vyhnout smyčkám hašování a přetečení na disku. Chcete-li výkon hašovaného spojení vyladit, odhadněte maximální množství paměti dostupné pro parametr sheapthres a pak dolaďte parametr sortheap. Zvětšujte jeho velikost, dokud se nevyhnete co nejvíce smyčkám hašování a přetečení disku, ale nepřesáhněte omezení zadané parametrem sheapthres.
Další informace naleznete v tématu "Join methods" v příručce Administration Guide: Performance.
Funkčnosti dříve dosažené pomocí proměnné DB2NTNOCACHE lze dosáhnout na úrovni tabulkového prostoru zadáním klauzule NO FILE SYSTEM CACHING do příkazů CREATE TABLESPACE nebo ALTER TABLESPACE. Podrobnosti o použití naleznete v příručce SQL Reference. Proměnná registru DB2NTNOCACHE bude v budoucím vydání odebrána.
Tabulky modulu Explain mohou být společné několika uživatelům. Tabulky modulu Explain lze ovšem definovat pro jednoho uživatele a aliasy je možné definovat pro každého dalšího uživatele pomocí stejného jména ukazujícího na definované tabulky. Nebo mohou být tabulky modulu Explain definovány pod schématem SYSTOOLS. Prostředek Explain má výchozí nastavení odpovídající schématu SYSTOOLS, pokud nejsou pod ID relace uživatele pro dynamické příkazy SQL nebo pod ID autorizace příkazů pro statické příkazy SQL nalezeny jiné aliasy nebo tabulky Explain. Každý uživatel sdílející společné tabulky modulu Explain musí mít pro tyto tabulky oprávnění vkládat. Oprávnění pro čtení společných tabulek Explain by mělo být také omezeno, typicky na uživatele analyzující informace Explain.
Data modulu Explain jsou zachycena, pokud zadáte takový požadavek, při kompilaci příkazu SQL. Uvažte, jak zamýšlíte použít zachycené informace, když zadáte požadavek na data modulu Explain.
Informace tabulek Explain jsou zachyceny v následujících případech:
Parametr informací o řazení lze zobrazit pouze pomocí příkazu db2CfgGet. K jeho zobrazení nelze použít příkazový procesor ani Řídicí centrum.
Tento parametr poskytuje 260 bajtů informací o řazení databáze. Prvních 256 bajtů určuje posloupnost řazení databáze, kde bajt "n" obsahuje váhu řazení místa v kódu, jehož podkladová desetinná reprezentace v kódové stránce databáze je "n".
Poslední 4 bajty obsahují interní informace o typu posloupnosti řazení. Poslední 4 bajty parametru collate_info jsou celým číslem. Toto celé číslo je ovlivňováno pořadím endian pro platformu. Možné hodnoty jsou následující:
Použijete-li tento interní typ informací, musíte uvážit obracení bajtu při načítání informací pro databázi na jiné platformě.
Posloupnost řazení lze zadat v čase vytvoření databáze.
Od produktu DB2 Universal Database (UDB) verze 8.2 lze použít automatické nastavení velikosti pro načítání v předstihu pro tabulkový prostor. Produkt DB2 UDB automaticky aktualizuje velikost pro načítání v předstihu vždy, když se počet kontejnerů pro tabulkový prostor změní.
Syntaxe proměnné registru DB2_PARALLEL_IO byla rozšířena, aby bylo možné rozpoznat kontejnery s různou vstupně-výstupní charakteristikou paralelního zpracování. Pomocí rozšířené syntaxe mohou mít kontejnery pro různé tabulkové prostory různé vstupně-výstupní charakteristiky paralelního zpracování. Vstupně-výstupní charakteristika paralelního zpracování každého tabulkového prostoru se používá, když je pro tabulkový prostor zadána velikost pro načítání v předstihu AUTOMATIC. Je-li povolena proměnná registru DB2_PARALLEL_IO, ale pro tabulkový prostor není použita rozšířená syntaxe určující specifické vstupně-výstupní charakteristiky paralelního zpracování, bude se pracovat s výchozí úrovní paralelního zpracování. Výchozí úroveň je RAID 5 (6+1).
Informace o velikosti pro načítání v předstihu používané optimalizátorem jsou aktualizovány pouze při zadání příkazu ALTER TABLESPACE, který změní velikost tabulkového prostoru pro načítání v předstihu nebo změní počet kontejnerů (pomocí příkazů ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET). Změní-li se nastavení registru pro počet fyzických disků v jednom kontejneru, měl by být zadán příkaz ALTER TABLESPACE <jméno_tabulkového_prostoru> PREFETCHSIZE AUTOMATIC, který aktualizuje informace optimalizátoru (pokud není příkaz ALTER TABLESPACE aktualizující informace optimalizátoru již zadán).
Je-li tabulkový prostor přesměrován nebo obnoven pro použití jiného počtu kontejnerů, aktualizujte informace optimalizátoru zadáním příkazu ALTER TABLESPACE <jméno_tabulkového_prostoru> PREFETCHSIZE AUTOMATIC. Je-li v tabulkovém prostoru více sad pásem, použije se pro výpočet velikosti pro načítání v předstihu maximální počet kontejnerů ze sad pásem. Pokud vypočtená velikost pro načítání v předstihu přesáhne maximální velikost (32767 stránek), použije se jako velikost pro načítání v předstihu největší násobek počtu kontejnerů, který je menší než maximum.
Pokud v prostředí DB2 UDB Enterprise Server Edition tabulkový prostor používá velikost pro načítání v předstihu AUTOMATIC, může být velikost pro načítání v předstihu v různých databázových oblastech různá. K této situaci dochází proto, že různé databázové oblasti mají různé počty kontejnerů, které se používají pro výpočet velikosti pro načítání v předstihu. Má-li optimalizátor generovat přístupový plán dotazu, použije velikost pro načítání v předstihu z první oblasti ve skupině databázových oblastí.
[ Začátek stránky |Předchozí stránka | Další stránka | Obsah ]