Ha a DB2_FORCE_FCM_BP rendszerleíró adatbázis változó engedélyezve van, |akkor eggyel kevesebb osztott memória szegmens elérhető egyéb célokra, |például adatbázis puffertárolók számára. Így a DB2_FORCE_FCM_BP |rendszerleíró adatbázis változó engedélyezésével csökkenti az adatbázis |puffertárolók maximális méretét. Mivel 64 bites környezetben sok osztott |memória szegmens áll rendelkezésre, ez inkább 32 bites környezetben okoz |problémát.
| | |Egy táblázat első létrehozásakor a rendszerkatalógus statisztikák |értéke -1 lesz, így jelezve, hogy a táblázatnak nincsenek statisztikái. Statisztikák gyűjtéséig a DB2 UDB az alapértelmezett értékeket használja |SQL utasítások fordításához és optimalizálásához. | A táblázat vagy az |indexstatisztikák frissítése meghiúsulhat, ha az új értékek |összeférhetetlenek az alapértelmezett értékekkel. Így a táblázat vagy az |index statisztikáinak kézi frissítése előtt futtassa le rajtuk a |runstats parancsot.
| | |Az SQL1169N üzenet új 5-ös kódja azt jelzi, hogy egy magyarázó |táblázat oszlopa túl kicsi.
|Az alábbi szöveg az Adminisztrátori útmutató: |Teljesítmény, 6. fejezet - Az SQL fordító bemutatása frissítése.
|Az MDC kivonást akkor is lehet használni, ha a RID index az |optimalizálási terv része, tekintet nélkül a DELETE utasításban levő WHERE |záradék jelenlétére. |Ennek eredményeként a kivonás lehetővé tételéhez szükséges feltételek és a |hatékonyabb sortörlés módok felsorolásakor az "Optimizáló nem jelölt ki |RID indexeket a törlendő sorok kereséséhez, hacsak nincs WHERE záradék a |DELETE utasításban" feltételt el kell távolítani.
|Továbbá tudni lehet, hogy MDC kivonás van folyamatban, mivel a |db2expln kimeneten a "Cella törlése" |kifejezés látható. | Megjegyzésre érdemes, hogy a |db2exfmt nem mutatja ezt az információt.
|Az alábbi szöveg az A függelék frissítése. |DB2 rendszerleíró adatbázis- és környezeti változók:
|A DB2_MDC_ROLLOUT leírásból el kell távolítani az "Optimizáló nem jelölt ki |RID indexeket a törlendő sorok kereséséhez, hacsak nincs WHERE záradék a |DELETE utasításban" feltételt.
| | |Ha frissíti a newlogpath, mirrorpath, vagy |overflowlogpath konfigurációs paramétereket a DB2 UDB Enterprise |Server Edition környezetben, akkor a csomópontszám hozzá lesz fűzve az |útvonalnévhez, tekintet nélkül a rendszer csomópontjainak számára. Ez |érvényes a DB2 UDB Enterprise Server Edition környezet egypartíciós és |többpartíciós rendszereire is.
| | |A DB2_COLLECT_TS_REC_INFO alapértelmezett értéke | ON. A DB2 UDB 8.1 7-es javítócsomagjában a |B2_COLLECT_TS_REC_INFO rendszerleíró adatbázis változó alapértelmezett |értéke ON-ra módosult. A jelenlegi |dokumentáció helytelenül adja meg a változó alapértelmezett értékét | OFF-ként.
Egy irányító példány egy kezelőfelületből és egy vagy több démonból áll. Az irányító minden elindított példánya az adatbázis-kezelő egy példányához tartozik. Alapértelmezés szerint az irányító indításakor egy irányító démon indul el a particionált adatbázis minden partícióján. Megadhatja azonban, hogy egy démon egyetlen figyelni kívánt partíción induljon el.
Minden irányító démon információkat gyűjt az adatbázist használó alkalmazásokról. Az irányító démon ezután összehasonlítja ezeket az információkat az irányítónak az adatbázishoz tartozó konfigurációs fájljában megadott szabályokkal.
A helyben végzett tábla-újraszervezés megfontolásakor (a klasszikus tábla-újraszervezés helyett) vegye figyelembe, hogy a helyben végzett tábla-újraszervezés nagyobb naplózási területet igényel.
Mivel a helyben végzett tábla-újraszervezés a tevékenységeit úgy naplózza, hogy nem várt meghibásodás esetén lehetséges legyen a helyreállítás, nagyobb naplózási területet igényel, mint a klasszikus újraszervezés.
Lehetséges, hogy a helyben végzett újraszervezés az újraszervezett tábla méreténél többször nagyobb naplózási területet igényel. Az igényelt terület mérete az átmozgatott sorok számától és a tábla indexeinek méretétől és számától függ.
Javaslat: A helyben végzett tábla-újraszervezést 24x7 műveletekhez válassza minimális karbantartási ablakokkal.
Egy DMS tábla online újraszervezése lehetővé teszi az újraszervezés közben a táblát tartalmazó táblaterület online biztonsági mentési műveletének megkezdését. A csonkolási fázisban lehet, hogy az újraszervezési művelet zárolására kell várakozni.
A tábla-újraszervezési metódusok végrehajtásáról további információkat a REORG TABLE szintaxisának leírásánál talál.
AIX(R) 5L 64 bites rendszeren a DB2_LARGE_PAGE_MEM nyilvántartási változó most már támogatja az FCM kulcsszót.
Alapértelmezés szerint AIX(R) 5L(TM) 64 bites rendszeren az FCM memória a DBMS memóriakészletben van. Ha azonban a DB2_FORCE_FCM_BP nyilvántartási változó engedélyezve van, az FCM memória a saját memóriakészletében van. AIX 5L(TM) 64 bites rendszeren a DB2_LARGE_PAGE_MEM támogatja a DBMS memóriakészlet meghatározását. Ha az FCM memória a DBMS memóriakészletben van, és ehhez a memóriakészlethez engedélyezve van a nagy memórialapok támogatása, az FCM memória nagy lapokat fog tartalmazni. Ha az FCM memória a saját memóriakészletében van, az FCM kulcsszót fel kell venni a DB2_LARGE_PAGE_MEM nyilvántartási változó értékéhez, hogy az FCM memóriánál engedélyezve legyenek a nagy memórialapok.
A DB2 Universal Database(TM) (UDB) 8.2.2 változatától kezdődően (egyenértékű a 9-es javítócsomaggal rendelkező 8.1 verzióval) a DB2_RESOURCE_POLICY nyilvántartási változó által megadott konfigurációs fájl elfogad egy SCHEDULING_POLICY elemet. A SCHEDULING_POLICY elem néhány platformon a következők kijelöléséhez használható:
A rendszerleíró adatbázis DB2PRIORITIES és DB2NTPRICLASS változója külön is használható az operációs rendszer ütemezési rendjének felügyeletéhez és a DB2 ügynök prioritásainak megadásához.
Ugyanakkor az erőforrási rend konfigurációs fájljában a SCHEDULING_POLICY elem megadása egyetlen helyen biztosítja az ütemezési rend és a társított ügynökprioritások meghatározását.
Az AIX SCHED_FIFO2 ütemezési rend kiválasztása a db2 naplóírási és -olvasási folyamatok prioritásának ugrásszerű növelésével:
<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>A DB2NTPRICLASS=H cseréje Windows rendszeren.
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>A DB2_MAPPED_BASE és a DB2DBMSADDR rendszerkörnyezeti változók hozzáadása történt meg a 8-as FixPak javítócsomagban.
Ezen rendszerleíró adatbázis-változók használata csak gyakorlott felhasználók esetében ajánlott.
Ha nincs megadva ez a változó, a DB2 UDB megkísérli áthelyezni a megosztott könyvtárakat a 0x10000000 látszólagos címre.
A rendszerleíró adatbázis-változónak tetszőleges (hex) látszólagos cím adható a 31 és 32 bites címterületek tartományában.
db2set DB2_MAPPED_BASE=
A következő üzenet többször is megjelenhet a db2diag.log fájlban, mivel ez a változtatás minden logikai csomópont esetében szükséges:
ADM0506I DB2 has automatically updated the "mapped_base" kernel parameter from "0x40000000(hex) 1073741824(dec)" to the recommended value "0x10000000(hex) 268435456(dec)".
Ez az üzenet csak akkor jelenik meg, ha a rendszerleíró adatbázis-változó megadása sikeres, és tartalmazza az áthelyezett megosztott könyvtárak új címét.
db2set DB2DBMSADDR=
Ezt a változót megadhatja a DB2_MAPPED_BASE változóval együtt, illetve magában is a DB2 UDB folyamatok címtartomány-elrendezésének finomhangolásához. Ez a változó módosítja a példány közös memóriájának helyét a jelenlegi 0x20000000 látszólagos címről a megadott új értéknek megfelelő helyre.
A 8.2-es verzióban megjelent a DB2TCP_CLIENT_RCVTIMEOUT rendszerleíró adatbázis-változó.
A 8.2-es verzióban megjelent a DB2_LARGE_PAGE_MEM teljesítményváltozó.
| Változónév | Operációs rendszerek | Értékek |
|---|---|---|
| Leírás | ||
| DB2_LARGE_PAGE_MEM |
Csak 64 bites AIX 5.x Linux |
Alapérték=NULL
A * karakterrel kell jelölni, ha az összes megfelelő memóriatartomány nagy memórialapokat kell hogy használjon, vagy vesszővel elválasztott listával adhatja meg, hogy mely memóriatartományok használjanak nagy memórialapokat. A rendelkezésre álló tartományok az operációs rendszertől függnek. 64 bites AIX 5.x rendszeren a következő tartományok adhatók meg: DB, DBMS vagy PRIVATE. Linux rendszeren a következő tartomány adható meg: DB. |
|
Nagy memórialap használata csak DB2 Universal Database (UDB) for AIX 5L, 64 bites kiadás, illetve DB2 UDB for Linux esetében támogatott. A DB2_LARGE_PAGE_MEM rendszerleíró adatbázis-változó szerepe a nagy memórialapok támogatásának engedélyezése AIX 5.x vagy bármely, a megfelelő rendszermag-támogatással rendelkező Linux architektúrán történő futtatáskor. Ez a rendszerleíró adatbázis-változó érvényteleníti a DB2_LGPAGE_BP rendszerleíró adatbázis-változót, mely csak az adatbázis közös memóriatartománya esetében használható a nagy memórialapok alkalmazásának engedélyezésére. Ez jelen verzióban engedélyezhető a következő beállítással: DB2_LARGE_PAGE_MEM=DB. Minden dokumentáció, mely a nagy lapok engedélyezését a DB2_LGPAGE_BP rendszerleíró adatbázis-változóval írja le, ugyanúgy érvényben marad, de a DB2_LARGE_PAGE_MEM=DB beállítást kell használni. A nagy memórialapok használata elsősorban teljesítménynövelésre szolgál a nagy teljesítményű számítási alkalmazásoknál. Azok az alkalmazások, amelyek sok látszólagosmemóriát használnak intenzív memóriaeléréssel, teljesítményjavulást érhetnek el nagy lapok használatával. Annak engedélyezéséhez, hogy a DB2 UDB nagy memórialapokat használhasson, először az operációs rendszert kell konfigurálni a nagy lapok használatához. Nagy saját lapok engedélyezése jelentősen megnöveli a DB2 UDB memóriahasználatát, mivel minden egyes DB2 UDB ügynök legalább 1 nagy lapot (16 MB) használ a fizikai memóriából. Ahhoz, hogy engedélyezni lehessen a nagy memórialapok használatát az ügynökök saját memóriájában a 64 bites DB2 UDB for AIX termék esetében (a DB2_LARGE_PAGE_MEM=PRIVATE beállítás), (a nagy lapok használatának operációs rendszeren történő engedélyezésén túl) a következő feltételeknek kell teljesülniük:
A 64 bites DB2 UDB for AIX esetében ezen változó engedélyezése a minimálisan szükségesre csökkenti az adatbázis-memóriát kiegészítő megosztott memóriaszegmens méretét. Alapértelmezésben egy 64 GB-os szegmens jön létre: lásd az adatbázis megosztott memóriáját megadó (database_memory) adatbázis-konfigurációs paramétert a további részletekért. Ezzel elkerülhető a várhatóan használtnál nagyobb mennyiségű megosztott memória lefoglalása a RAM-ban. Ezen változó beállítása korlátozza annak képességét, hogy dinamikusan meg lehessen növelni a teljes adatbázis megosztott memória konfigurációt (pl. a pufferterületek méretének növelése). Linux rendszeren további követelmény, hogy elérhető legyen a libcap.so könyvtár. A funkció működéséhez ennek a könyvtárnak telepítve kell lennie. Ha ez a beállítás be van kapcsolva és a könyvtár nem található meg a rendszeren, a DB2 UDB letiltja a rendszermag lapjait, és korábbiaknak megfelelően folytatja működését. Linux rendszeren a következő parancs segítségével ellenőrizheti, hogy a nagy rendszermaglapok hozzáférhetőek-e: cat /proc/meminfo Ha elérhetők, az alábbi három sor jelenik meg (természetesen a számok eltérhetnek, az adott gépen lévő memória függvényében): HugePages_Total: 200
HugePages_Free: 200
Hugepagesize: 16384 KB
Ha nem jelennek meg ezek a sorok, vagy a HugePages_Total értéke 0, akkor az operációs rendszer vagy a rendszermag konfigurálására van szükség. |
||
A következő frissítés az "SQL fordító változók" témára vonatkozik, mely az Adminisztrációs útmutató: Teljesítmény kiadvány A függelékében ("DB2 rendszerleíróadatbázis- és környezeti változók") szerepel:
Ha valamelyik vagy mindkét DB2 fordító változó (DB2_MINIMIZE_LISTPREFETCH és DB2_INLIST_TO_NLJN) beállítása ON, aktív állapotban maradnak REOPT(ONCE) megadása esetén is.
A következő frissítések történtek a konfigurációs paraméterek dokumentációjában:
A Hitelesítési típus (authentication) adatbázis-kezelő konfigurációs paraméter elfogadja a következő értékeket is:
A kiszolgáló elfogadja a titkosított SERVER hitelesítési sémákat és a felhasználói adatok titkosítását. A hitelesítés menete teljesen azonos a SERVER_ENCRYPT esetén zajlóval.
A következő felhasználói adatok titkosítása történik meg ezen hitelesítési típus használata esetén:
A kiszolgáló elfogadja a titkosított SERVER hitelesítési sémákat és a felhasználói adatok titkosítását. Ezen felül ez a hitelesítési típus lehetővé teszi a korábbi, DATA_ENCRYPT hitelesítési típust nem támogató termékekkel való kompatibilitást. Ezen termékek számára engedélyezi a kapcsolódást a SERVER_ENCRYPT hitelesítési típussal, a felhasználói adatok titkosítása nélkül. Az új hitelesítési típust támogató termékek számára használata kötelező. Ez a hitelesítési típus csak a kiszolgáló adatbázis-kezelő konfigurációs fájljában érvényes, a CATALOG DATABASE parancs esetében érvénytelen.
A 8.2-es verziójú DB2 Universal Database termékkel kezdődően az Példányérintettségi rend ( util_impact_lim) adatbázis-kezelő konfigurációs paraméter alapértelmezett értéke 100-ról 10-re változik.
A következő adatbázis-kezelő konfigurációs paraméterek mindegyike elfogad 30 bájtos (vagy kisebb) csoportneveket minden platformon:
A "Database manager configuration parameter summary" ("Adatbázis-kezelői konfigurációs paraméterek összefoglalója") téma hibás adattípusokat tartalmaz ezen adatbázis-kezelői konfigurációs paraméterekre vonatkozóan. A helyes érték minden esetben char(30).
A Kiterjesztett tároló memóriaszegmensének mérete (estore_seg_size) konfigurációs paraméter maximális mérete Windows alapú platformokon 16 777 216.
A HADR időtúllépési érték (hadr_timeout) adatbázis-konfigurációs paraméter helyes értéke: 4 294 967 295.
A Maximális tárhely zárlistához (locklist) adatbázis-konfigurációs paraméter dokumentációjában az szerepel, hogy a csak helyi ügyfelekkel dolgozó, 64 bites és 32 bites Windows kiszolgálók esetében a maximális érték 60 000. Ez az érték hibás, a helyes érték: 524 288.
Az Adatbázis-másolatok száma (num_db_backups adatbázis-konfigurációs paraméter lehetséges értékeinek tartománya hibás. A helyes tartomány: 0 - 32 767.
8.1-es verzióról 8.2-es verziójú DB2 Universal Database (UDB) rendszerre történő költöztetés után a DB2 UDB új, 16 KB méretű adatbázis-konfigurációs paraméter fájlt használ, melynek neve SQLDBCONF. (A 8.1-es verzióban az adatbázis-konfigurációs paraméter fájl mérete csak 4 KB volt, neve pedig SQLDBCON).
A 8.1-es verzióban a DB2_HASH_JOIN rendszerleíró adatbázis-változó értéke alapértelmezés szerint ON.
A hash-join változót kell használni, de a legjobb teljesítmény eléréséhez szükséges annak finomhangolása.
A hash-join teljesítmény akkor a legmagasabb, ha sikerül elkerülni a hash hurkokat és túlcsordulásokat a lemezre. A hash-join teljesítmény finomhangolásához becsülje meg a sheapthres paraméter számára elérhető memória maximális méretét, majd hajtsa végre a sortheap paraméter finomhangolását. Növelje értékét mindaddig, amíg a lehető legtöbb hash hurkot és lemeztúlcsordulást kiküszöbölte, de ne érje el a sheapthres paraméter által meghatározott korlátot.
További információk a "Join methods" ("Összekapcsolási módok") témában érhetők el, az Adminisztrációs útmutató: Teljesítmény kézikönyvben.
Azon funkciók, amelyek korábban a DB2NTNOCACHE változón keresztül voltak elérhetők, a továbbiakban táblaterület szinten úgy érhetők el, hogy a CREATE TABLESPACE vagy az ALTER TABLESPACE utasításnál megadja a NO FILE SYSTEM CACHING tagmondatot. A használat részleteit az SQL kézikönyvben találja. A DB2NTNOCACHE nyilvántartási változó a jövőbeni kiadásokban már nem fog szerepelni.
A magyarázó táblák több felhasználó számára lehetnek közösek. Azonban a magyarázó tábla egy felhasználónál lehet definiálva, a fedőneveket lehet definiálni minden további felhasználónál ugyanazzal a névvel a definiált táblára mutatva. Másik megoldásként a magyarázó táblákat a SYSTOOLS séma alatt is lehet definiálni. Az Explain (Magyarázat) szolgáltatás alapértelmezésben a SYSTOOLS sémára mutat, ha nem található más magyarázó tábla vagy fedőnév a felhasználó munkameneti azonosítója alatt (dinamikus SQL-nél), vagy az utasíás hitelesítési azonosítója alatt (statikus SQL-nél). A közös magyarázó táblákat használó minden egyes felhasználónak beillesztési engedéllyel kell rendelkeznie azokra a táblákra vonatkozóan. A közös magyarázó táblák olvasási engedélyeit is korlátozni kell, általában azokra a felhasználókra, akik a magyarázó információkat elemzik.
Magyarázó adatok akkor kerülnek megszerzésre, ha ezt kéri egy SQL állítás fordításakor. Gondolja át, miként fogja felhasználni a megszerzett információkat a magyarázó adatok kérelmezésekor.
A magyarázó táblák információi az alábbi esetekben kerülnek beolvasásra:
Az információrendezési paraméter (collating information) csak a db2CfgGet API használatával jeleníthető meg. A parancsfeldolgozó vagy a Vezérlőközpont használatával nem lehet megjeleníteni.
Ez a paraméter 260 bájtos adatbázis-rendezési információt szolgáltat. Az első 256 bájt adja meg az adatbázis-rendező sorrendet, ahol az "n". bájt tartalmazza a rendezési súlyát annak a kódpontnak, amelynek decimális megfeleltetése "n" az adatbázis kódlapján.
Az utolsó 4 bájt a rendezési sorrend típusára vonatkozó belső információt tartalmaz. A collate_info utolsó 4 bájtja egész számot alkot. Ez az egész szám érzékeny arra, hogy az adott rendszeren milyen a helyiérték sorrend. A lehetséges értékek:
Ha felhasználja ezt a belső típusinformációt, figyelnie kell a bájtok esetleges fordított sorrendjére, ha más platformon lévő adatbázisról olvas be adatokat.
A rendezési sorrendet az adatbázis létrehozásának idejében adhatja meg.
A DB2 Universal Database (UDB) 8.2-es verziójától kezdődően lehetőség van az előzetes lehívás méretének AUTOMATIC (automatikus) értéket adni valamely táblaterületre vonatkozóan. A DB2 UDB automatikusan frissíti az előzetes lehívás méretét, ha a táblaterülethez tartozó tárolók száma megváltozik.
A DB2_PARALLEL_IO rendszerleíró adatbázis-változó szintaxisa kibővült annak érdekében, hogy felismerje az eltérő I/O párhuzamossági jellemzővel bíró tárolókat. A kibővített szintaxisnak köszönhetően a különböző táblaterületekhez tartozó tárolók különböző I/O párhuzamossági jellemzővel rendelkezhetnek. Az egyes táblaterületek I/O párhuzamossági jellemzőjét akkor használja a rendszer, ha a táblaterület esetében az előzetes lehívás méretének beállítása AUTOMATIC. Ha a DB2_PARALLEL_IO rendszerleíró adatbázis-változó engedélyezett, de a táblaterületekre vonatkozó I/O párhuzamossági jellemzőket azonosító kibővített szintaxis nincs használatban, a rendszer az alapértelmezés szerinti mértékű párhuzamosságot feltételezi. Az alapértelmezett szint: RAID 5 (6+1).
Az optimalizáló által használt előzetes lehívási méret adatot csak akkor frissíti a rendszer, ha olyan ALTER TABLESPACE utasítást ad ki, mely módosítja az előzetes lehívási méretet vagy a tárolók számát (ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET segítségével). Ha módosul a tárolónkénti fizikai lemezek rendszerleíró adatbázis-beállítások száma, ki kell adni egy ALTER TABLESPACE <táblaterületnév> PREFETCHSIZE AUTOMATIC utasítást az optimalizáló információinak frissítéséhez (hacsak nem adott már ki egy az optimalizáló adatait frissítő ALTER TABLESPACE utasítást).
Ha valamely táblaterület átirányítása vagy visszaállítása úgy történik, hogy megváltozik az által használt tárolók száma, frissítse az optimalizáló adatait ALTER TABLESPACE <táblaterületnév> PREFETCHSIZE AUTOMATIC utasítás kiadásával. Ha több szétosztási készlet található egy táblaterületen belül, a program a szétosztási készletek közti tárolók maximális számát használja fel az előzetes lehívási méret kiszámításakor. Ha a kiszámított előzetes lehívási méret meghaladja a maximális méretet (32 767 lap), az előzetes lehívási méretet a rendszer a következő módon határozza meg: a tárolók számának azon legnagyobb többszöröse, mely nem haladja meg a maximális értéket.
DB2 UDB nagyvállalati kiszolgáló kiadás (Enterprise Server Edition, ESE) környezetben, ha a táblaterület esetében az előzetes lehívási méret beállítása AUTOMATIC, az előzetes lehívási méret eltérő lehet a különböző partíciókon. Ez a helyzet előfordulhat, mivel a különböző helyzet-partíciók különböző számú tárolót tartalmazhatnak, mely alapján az előzetes lehívási méret számítása történik. A lekérdezés-hozzáférési terv létrehozásához az optimalizáló egy adatbázis-partíció csoport első partíciójának előzetes lehívási méretét használja.
[ Oldal eleje |Előző oldal | Következő oldal | Tartalom ]