Felhasználói kézikönyv


Előre létrehozott kapcsolatok

A DB2 Connect Enterprise Edition kiszolgálók gyakran több ezer egyidejű ügyfélkérelemhez szolgáltatnak adatbázis-kapcsolatot. Az adatbáziskapcsolatok létrehozása és fenntartása nagyon erőforrás-igényes feladattá válhat, ami hátrányos hatással lehet mind az adatbázis-kiszolgáló, mind a DB2 Connect kiszolgáló teljesítményére. Ez különösen kézzelfogható webes környezetekben, ahol minden egyes web-oldalra irányuló látogatás megkövetelheti a kapcsolat felépítését az adatbázis-kiszolgálóval, a lekérdezés végrehajtását, majd a kapcsolat bontását. Ennek az időveszteségnek a csökkentéséhez a DB2 Connect Enterprise Edition előre létrehozott kapcsolatokat használ, azaz egy csomagban gyorsan elérhető már megnyitott kapcsolatokat tárol az adatbázishoz.

Az előre létrehozott kapcsolatok működése

Az előre létrehozott kapcsolatok nem láthatók a gazdagéphez DB2 Connecten keresztül kapcsolódó alkalmazások számára. Amikor az ügyfelek az összeköttetés bontását kérik a kiszolgálótól, az átjáró eldobja az ügyféllel létesített bemenő összeköttetést, de a kimenő összeköttetéseket csapatban tartja. Amikor egy új alkalmazás kér egy kapcsolatot, a DB2 Connect a meglevő csapatból használ egyet. Már létező összeköttetések használata egyaránt csökkenti a teljes kapcsolódás idejét és a gazdagépen a kapcsolódások magas CPU terhelését.

Az előre létrehozott kapcsolatok használatához a következő APAR-t kell alkalmazni a DB2 for OS/390 Version 6.1-hez:

     APAR PQ33473

A DB2 Connect ügynökök a következő két állapot egyikében lehetnek: tétlen vagy aktív. Egy ügynök akkor aktív, amikor egy alkalmazás számára munkát hajt végre. Amint ez a munka befejeződött, az ügynök tétlen állapotba kerül, és további munkára vár ugyanattól, vagy egy másik alkalmazástól. A tétlen ügynök együtt tárolódik az úgynevezett tétlen ügynökcsapatban. Ennek a csapatnak a méretét a NUM_POOLAGENTS konfigurációs paraméter segítségével lehet beállítani. Ez a paraméter egyenlő a rendszer által fenntartott tétlen ügynökök maximális számával. Ennek a paraméternek a nullára állítása azzal egyenértékű, mintha kikapcsolná az előre létrehozott kapcsolatok szolgáltatását.

Az első ügyfélkérelem fogadása előtt a DB2 Connect nem létesít adatbázis-kapcsolatokat. Azonban ha kívánja, feltöltheti a tétlen ügynökök csapatát, mielőtt egyetlen ügyfélkérelem is érkezne. A csapat a NUM_INITAGENTS konfigurációs paraméter segítségével rendszerindításkor feltölthető. Ez a paraméter meghatározza, hogy rendszerindításkor hány tétlen ügynök jöjjön létre. Ezek a tétlen ügynökök kezdetben nem rendelkeznek kapcsolattal a gazda adatbázis-kiszolgálóhoz.

Amikor egy ügyfél kapcsolatot kérelmez a gazdagéphez, a DB2 Connect megpróbál kiválasztani egy olyan ügynököt a csapatból, amelynek van kapcsolata a gazda adatbázis-kiszolgálóval. Ha ez nem sikerül, akkor a tétlen ügynökcsapatból próbál meg találni egy ügynököt. Ha ez a csapat üres, akkor a DB2 Connect létrehoz egy új ügynököt.

A MAX_COORDAGENTS konfigurációs paraméterrel szabályozhatja az egyidejűleg aktív ügynök maximális számát. Ezen szám túllépésekor az újabb kapcsolatok sqlcode SQL1226-os hibával meghiúsulnak. (Ez a kód azt jelenti, hogy a rendszer túllépte az egyidejű kifelé tartó kapcsolatok maximális számát.)

A DB2CONNECT_IN_APP_PROCESS DB2 nyilvántartás-változó lehetővé teszi a DB2 Connect Enterprise Editionnel azonos gépen futó alkalmazások számára, hogy vagy futtassák a DB2 Connectet az alkalmazás folyamatán belül, ami az alapértelmezett viselkedés, vagy csatlakozzanak a DB2 Connect EE kiszolgálóhoz gazdakapcsolatot egy ügynökön futtatva. Ahhoz, hogy egy alkalmazás az előre létrehozott kapcsolatokat használja, a gazdagép-kapcsolatot a DB2 Connect Enterprise Edition ügynökein keresztül kell létrehoznia, ennek érdekében a DB2CONNECT_IN_APP_PROCESS változó értéke NO kell, hogy legyen.

DB2 Connect kapcsolat-összesítő

A DB2 Connect kapcsolat-összesítő technológiája lehetővé teszi DB2 Connect Enterprise Edition kiszolgálók számára, hogy több ezer párhuzamosan üzleti tranzakciókat végrehajtó felhasználót támogassanak, messzemenően csökkentve ennek során az S/390-es gazda- vagy AS/400-as adatbázis-kiszolgálókon igénybe vett erőforrásokat. Ezt úgy éri el, hogy az összes alkalmazás munkaterhelését sokkal kisebb számú S/390-es gazda- vagy AS/400-as adatbázis-kiszolgáló kapcsolatba vonja össze. Habár ez az eljárás hasonlónak tűnhet a fent ismertetett előre létrehozott kapcsolatokhoz, valójában ez a nagy mennyiségű OLTP (Online Tranzakció-feldolgozás) alkalmazás erőforrásfogyasztás-csökkentésének sokkal kifinomultabb megközelítése.

Az előre létrehozott kapcsolatokkal meg lehet takarítani az új kapcsolatok létrehozásának a költségét, amikor egy éppen befejeződő alkalmazásnak már nincs szüksége egy kapcsolatra. Másképp fogalmazva: egy alkalmazásnak szét kell kapcsolódnia a kiszolgálóval, mielőtt egy másik újra felhasználhatná a kapcsolatot.

A kapcsolat-összesítő viszont azt teszi lehetővé, hogy a DB2 Connect egy alkalmazás számára felhasználhatóvá tegyen egy kapcsolatot, mihelyt azon keresztül egy másik alkalmazás befejezett egy tranzakciót, és eközben nem kell annak a másik alkalmazásnak szétkapcsolódnia. A dolog lényege: egy alkalmazás egy adatbázis-kiszolgáló kapcsolatot a hozzárendelt gazda és DB2 Connect erőforrásokkal együtt csak az aktív tranzakciók ideje alatt használ. Amint a tranzakció befejeződik, a kapcsolat és a hozzárendelt erőforrások rendelkezésre állnak bármely más alkalmazás számára, amely tranzakciót hajtana végre.

A Kapcsolat-összesítő megvalósítása

A DB2 Connect előző verzióiban minden aktív alkalmazáshoz tartozott egy Alrendszer által Irányított Egység (Engine Dispatchable Unit, EDU), ami kezelte az adatbázis-kapcsolatot és az alkalmazások kérelmeit. Ezt az EDU-t általában koordinátor ügynöknek hívták. Minden egyes koordinátor ügynök nyomon követte az alkalmazás, valamint az EDU állapotát és környezetét. A kapcsolatok számának növekedésével minden egyes EDU jelentős memóriamennyiséget foglal le, és ehhez járul még az ügynökök közötti környezetváltás miatti további késleltetés.

A fenti felépítésben egy-egy megfeleltetés volt a kapcsolatok és az EDU-k között. A kapcsolat-összesítő azonban megengedi, hogy több kapcsolathoz ugyanaz az EDU tartozzon. Azaz a kapcsolatok (X) és az EDU-k (Y) viszonya most X >= Y.

A Kapcsolat-összesítő két részre bontja az ügynököt, egy logikai ügynökre, és egy dolgozó ügynökre. A logikai ügynökök egy alkalmazást jelölnek, de egy konkrét EDU-ra való hivatkozás nélkül. A logikai ügynök tartalmaz minden szükséges információt és vezérlőtömböt, amire az alkalmazásnak szüksége van. Ha n alkalmazás csatlakozott a kiszolgálóhoz, akkor n logikai ügynök lesz a kiszolgálón. A dolgozó ügynökök fizikai EDU-k, amelyek végrehajtják az alkalmazások kérelmeit, de amelyeknek nincs állandó csatolásuk egyetlen alkalmazáshoz sem. A dolgozó ügynökök társulnak a logikai ügynökökökkel a tranzakciók végrehajtására, a tranzakció végeztével pedig befejezik a társulást, és visszatérnek a szabadon felhasználható csapatba.

Az úgynevezett logikai ügynök ütemező rendeli a dolgozó ügynököket a logikai ügynökökhöz. Bizonyos platformokon a megnyitott fájlhivatkozások számának korlátozása azt eredményezheti, hogy egynél több logikai ügynök ütemező fog futni, amennyiben a logikai ügynökök száma meghaladja a fájlhivatkozás-korlátot.

Az összesítő aktívvá tétele

A Kapcsolat-összesítő használatához a következő APAR-t kell alkalmazni DB2 for OS/390 Version 6.1 esetén:

      APAR PQ33473

A MAX_LOGICAGENTS adatbáziskezelői konfigurációs paraméter állítja be a logikai ügynökök maximális számát. A MAX_LOGICAGENTS változó értékét bármely, az alapértelmezésnél nagyobb értékre állítva aktívvá teheti az összesítőt. A MAX_LOGICAGENTS alapértelmezett értéke egyenlő a MAX_COORDAGENTS értékével. Mivel minden alkalmazáshoz tartozik egy logikai ügynök, MAX_LOGICAGENTS valójában az adatbázis példányhoz csatlakoztatható alkalmazások számát határozza meg, miközben a MAX_COORDAGENTS azt szabályozza, hogy a mindenkori bejövő kapcsolatok közül hány lehet egyszerre aktív. A MAX_LOGICAGENTS változó a MAX_COORDAGENTS és 64.000 közötti tartományban tetszőleges numerikus értéket felvehet. A logikai ügynökök alapértelmezett száma egyenlő a MAX_COORDAGENTS változóval.

Számos létező konfigurációs paraméter segítségével konfigurálhatóak az ügynökök. Ezek a paraméterek a következőek:

MAXAGENTS
A dolgozó ügynökök maximális száma.

MAX_COORDAGENTS
Az aktív koordinátor ügynökök maximális száma.

NUM_POOLAGENTS
Az ügynökcsapat mérete. Az ügynökcsapatban benne foglaltatnak az inaktív, valamint a tétlen ügynökök is.

NUM_INITAGENTS
A dolgozó ügynökök kezdeti száma a csapatban. Ezek tétlen ügynökök lesznek.

XA tranzakció támogatás

A Kapcsolat-összesítő felépítése lehetővé teszi, hogy a DB2 Connect szorosan csatolt XA tranzakció kezelést nyújtson OS/390-es valamint AS/400-as DB2-höz. Az összesítő egyetlen ügynököt társít egy adott XA tranzakcióhoz (egyetlen XID), mint ahogy ezt bármely más tranzakcióval is tenné. Azonban ha az XA tranzakció xa_end() (elágazás határa) hívással ér véget, a dolgozó ügynök nem fog visszatérni az általános csapatba. Ehelyett az ügynök az adott XA tranzakcióhoz marad hozzárendelve. Amikor egy másik alkalmazás társul ugyanahhoz az XA tranzakcióhoz, a dolgozó ügynök ahhoz az alkalmazáshoz csatolódik.

Az ügynök minden tranzakció határvonal hívás után visszakerül a csapatba. Például az xa_prepare() csak olvashatóként kiadva, az xa_rollback(), xa_recover(), xa_forget(), xa_commit(), vagy bármely XA hiba, amely visszagörgetést okoz, visszaküldi az ügynököt a normál csapatba. Xa_end() önmagában csak a tranzakció ágat fejezi be, és ez nem elégséges ahhoz, hogy megszűnjön a társítása az XID-vel.

Példák

  1. Tekintsünk egy olyan környezetet, ahol akár 4.000-nél is több párhuzamos kapcsolatra van szükség. Egy CGI alkalmazásokat használó WWW-kiszolgáló, vagy egy irodai rendszer sok munkaállomással egyaránt meghaladhatja ezt az igényszintet. Ezekben az esetekben a hatékonyság érdekében a DB2 Connect általában önálló átjáróként működik; tehát az adatbázis és a DB2 Connect rendszer külön gépen futnak.

    Elképzelhető, hogy a DB2 Connect kiszolgáló nem tud 4.000 egyidejű kapcsolatot fenntartani az adatbázis-kiszolgálóval. A legtöbb esetben az egy időpillanatban történő tranzakciók száma jóval kevesebb, mint a párhuzamos kapcsolatok száma. A rendszergazda ekkor az adatbázis-konfigurációs paraméterek következő beállításával maximalizálhatja a rendszer hatékonyságát:

         MAX_LOGICAGENTS =  4.000
         MAX_AGENTS      =  1.000
         MAX_COORDAGENTS =  1.000
         NUM_POOLAGENTS  =  1.000
    

    Az összesítő így akár 4.000 párhuzamos szekciót is nyitva tarthat, bár az átjáró egyszerre csak 1.000 tranzakciót kezel.

  2. A fenti példában a dolgozó ügynökök folamatosan hoznak létre, illetve szakítanak meg társításokat a logikai ügynökökkel. Az olyan ügynökök, amelyek nem tétlenek, de éppen nem vesznek részt egy tranzakcióban sem, fenntarthatják a kapcsolatot az adatbázissal, így a kapcsolatot igénylő logikai ügynökök (alkalmazások) rendelkezésére állnak.

    Az XA tranzakciók esete valamennyire különböző. A példa kedvéért tegyük fel, hogy egy TP megfigyelőt használunk DB2 Connect átjáróval és egy OS/390-es vagy AS/400-as adatbázist. Amikor egy alkalmazás összeköttetést kérelmez, a kapcsolat-összesítő egy (eddig) inaktív ügynökkkel szolgálja ki a kérést vagy létrehoz egy új dolgozó ügynököt. Tegyük fel, hogy az alkalmazás egy XA tranzakciót kér. Egy XID jön létre a tranzakcióhoz, és hozzárendelődik a dolgozó ügynök.

    Amikor az alkalmazás - kérésének kiszolgálása után - kiad egy xa_end() utasítást, elengedi a dolgozó ügynököt. A dolgozó ügynök továbbra is ugyanahhoz az XID-hez marad hozzárendelve. Most már csak az ilyen XID-nek megfelelő tranzakciók kéréseit tudja kiszolgálni.

    Ekkor - tegyük fel - egy másik alkalmazás kérelmez egy nem XA tranzakciót. Ha nincs más rendelkezésre álló dolgozó ügynök, az XID-hez rendelt ügynök akkor sem lesz elérhető e második alkalmazás számára. Aktívnak tekintődik. A második alkalmazás számára új ügynök készül. Amikor a második alkalmazás befejezi a tranzakcióját, az ügynöke visszatér a szabadon felhasználható csapatba.

    Ezalatt más alkalmazások, amelyek az első ügynökhöz rendelt XID-vel rendelkező tranzakciót kérelmeznek, csatlakozhatnak és lekapcsolódhatnak az első ügynökről, amely végrehajtja a számára kijelölt XA tranzakciót. Bármely alkalmazás, amely azt az adott tranzakciót kéri, ehhez az ügynökhöz kerül, ha ez éppen szabad.

    A dolgozó ügynök nem tér vissza az általános csapatba, ameddig egy alkalmazás ki nem ad egy tranzakció határvonal hívást (ez nem az xa_end() hívás). Egy alkalmazás például befejezheti a tranzakcióját egy xa_commit() hívással, és ekkor a dolgozó ügynök eldobja a társítását az XID-vel, és visszatér a felhasználható csapatba. Ezután bármely alkalmazás igénybe veheti az ügynököt akár XA, akár nem XA tranzakcióra.

Korlátozások

Számos fontos korlátozás létezik az átjáró összesítő használatával kapcsolatban. Mielőtt megkísérelné a Kapcsolat-összesítő használatát az adott rendszeren, tekintse át teljes egészében az alábbi tájékoztatót!

Adatbázis finomhangolása

A rendszerteljesítményre hatással van a gazdagép vagy AS/400 adatbázis-kiszolgáló adatbázis teljesítménye.

A különböző adatbáziskezelő rendszereknek különböző teljesítményjellemzőik vannak. Például az egyes rendszerek SQL optimalizálói ugyanazon alkalmazás esetén különbözőképpen viselkedhetnek. További információért olvassa el a gazdagép vagy AS/400 adatbázis-kiszolgáló rendszerteljesítmény dokumentációját!

A DB2 Universal Database for AS/400 esetén javíthat a teljesítményen, ha a véglegesítés nélküli olvasás (uncommitted read, UR) vagy a nincs véglegesítés (no commit, NC) összerendelési beállítások segítségével elkerüli a naplózást.

Megjegyzés:UR használata esetén azonban a nem naplózott adatokat csak olvasni lehet, frissíteni nem, és azt is csak akkor, ha a blokk-kezelés ALL-ra van állítva.

Az alkalmazás-kiszolgálótól és a támogatott zárolási fokozatoktól függően a lekérdezés vagy alkalmazás elszigetelési szintje jelentős hatással lehet a teljesítményre.

Az adatbázisnak a normalizálás megfelelő szintjén kell lennie, hatékonyan kell használnia az indexeket és rendelkeznie kell megfelelő lefoglalt adatbázis-területtel. A teljesítményt a használt adattípusok is befolyásolhatják, a következő részekben leírtaknak megfelelően.

DB2 for OS/390 finomhangolása

Az OS/390 V1R3 a minimális követelmény a TCP/IP támogatáshoz. Erősen javasolt az OS/390 V2R5 vagy ennél újabb verziója.

Az Elosztott adat szolgáltatás (Distributed Data Facility, DDF) felelős az elosztott alkalmazások DB2 for OS/390 termékhez történő kapcsolásáért. A DDF-et alkalmazáskiszolgálónak kell beállítani. Ehhez vagy be kell illeszteni a távoli rendszer LU nevét a SYSIBM.LUNAMES táblába, vagy be kell illeszteni a LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT és USERNAMES értékeket a SYSIBM.SYSLUNAME táblába. Ezután végezzen DDF frissítést a rendszerbetöltő adathalmazon (Boot Strap Data Set, BSDS), például az az alábbiak szerint:

   DDF LOCATION=LOC1,LUNAME=LU1,PORT=8000,RESPORT=8001

A legjobb teljesítményhez a javasolt DDF címtartomány sorrendezést (COMPAT mód esetén a DBM1-gyel egyenlő vagy kissé alacsonyabb érték) tanácsos használnia. VLF-ben használja a jogosultságok RACF gyorsítótárban való tartását, és lehetőség esetén használjon V5-ös csomag-jogosultság gyorsítótárat! A CACHEPAC=32768 beállítás elegendő a legtöbb művelet esetén.

Mivel a DDF megpróbál a VTAM-hoz kapcsolódni, a VTAM-nak aktívnak kell lennie a DDF indításakor. Íme egy VTAM APPL definíció:

   SYD51TC* APPL  AUTH=(ACQ),                                  X
              PARSESS=YES,                                     X
              HAVAIL=YES,                                      X
              EAS=1600,                                        X
              APPC=YES,                                        X
              DSESLIM=1024,                                    X
              DMINWNL=512,                                     X
              DMINWNR=512,                                     X
              AUTOSES=1,                                       X
              SECACPT=ALREADYV,                                X
              SRBEXIT=YES,                                     X
              SYNCLVL=SYNCPT,                                  X
              MODETAB=DB2MODET,                                X
              VPACING=63                                       X

Az OS/390-ben optimalizálhatja az inaktív szálak feldolgozását. A V3-ban legfeljebb 10,000 párhuzamosan csatlakozott ügyfél lehetséges, míg a V4-ben és V5-ben 25.000. A párhuzamosan aktív kapcsolatok legnagyobb száma azonban minden esetben 1999. Minden munkaállomás ügyfél csatlakozva maradhat, amikor inaktív; a hozzátartozó szál inaktív láncba kerül minden véglegesítéskor.

A CMTSTAT, CONDBAT és MAXDBAT DSNZPARM paraméterek befolyásolják a szálak feldolgozását. A legjobb teljesítmény elérése érdekében állítsa a CMTSTAT értékét INACTIVE-ra, igazítsa a CONDBAT értékét a bekapcsolódott DBAT-ok maximális számához úgy, hogy az jó teljesítményt adjon, a MAXDBAT értékét pedig állítsa a maximálisan elfogadható DBAT-ok számára!

A DB2 for OS/390 DRDA hálózatba való csatlakoztatásának teljes leírását (beleértve a VTAM konfigurálást is) lásd: Kapcsolódási kiegészítés.

Adatátalakítás

Adatok egyik környezetből a másikba való átvitelekor átalakításra lehet szükség. Ez az átalakítás hatással lehet a teljesítményre.

A következő környezeteket kell figyelembe vennie:

valamint a következő numerikus adattípusokat:

A táblázat 8 alatt látható, hogy mikor van szükség átalakításra.

táblázat 8. adatátalakítás

 


Intel


IEEE


S/370 & S/390


OS/400


Tömörített decimális szám


Intel
IEEE
S/370/390
OS/400


Nem
Nem
Nem
Nem


Nem
Nem
Nem
Nem


Nem
Nem
Nem
Nem


Nem
Nem
Nem
Nem


Tizedes tört adattípus


Intel
IEEE
S/370/390
OS/400


Nem
Nem
Igen
Igen


Nem
Nem
Igen
Igen


Igen
Igen
Nem
Nem


Igen
Igen
Nem
Nem


Egész szám adattípus


Intel
IEEE
S/370/390
OS/400


Nem
Igen
Igen
Igen


Igen
Nem
Nem
Nem


Igen
Nem
Nem
Nem


Igen
Nem
Nem
Nem


Lebegőpontos adattípus


Intel
IEEE
S/370/390
OS/400


Nem
Igen
Igen
Igen


Igen
Nem
Igen
Nem


Igen
Igen
Nem
Igen


Igen
Nem
Igen
Nem

Az egybájtos karakteres adatátalakítás erőforrásigénye általában kisebb, mint a numerikus adatátalakításé (ahol adatátalakítás szükséges).

A DATE/TIME/TIMESTAMP adatok átalakítási erőforrásigénye majdnem ugyanannyi, mint az egybájtos CHAR típusé. A lebegőpontos adatok átalakítása veszi igénybe a legtöbb erőforrást. DB2 Connect alkalmazás készítésekor az alkalmazástervezőnek célszerű figyelembe vennie ezeket a tényezőket.

Ha az adatbázis táblában van 'FOR BIT DATA' oszlop, akkor az alkalmazás és az adatbázis közötti karakteres adatátvitelhez semmiféle átalakítás nem szükséges. Ez a gazdagépen vagy AS/400 adatbázis-kiszolgálón történő adatarchiváláskor használható.

Karakteres adattípusok

A karakteres adatok CHAR vagy VARCHAR típusúak lehetnek. A mezőben lévő adatok tipikus méretétől függ, hogy a kettő közül melyik a hatékonyabb.

Hálózat finom beállítása

Elosztott adatbázis környezetben az általános teljesítményjavítás legjobb módja a hálózatból fakadó késleltetések kiküszöbölése. A hálózati rendszergazdák gyakran akkor tekintik a hálózatot hatékonynak, ha a lehető legtöbb adatot gyűjti össze az átvitelek között. Ez a megközelítés nem működik az elosztott adatbázisokhoz hasonló alkalmazások esetén, mivel az késleltetést épít a hálózatba. A végfelhasználó nem látja a hálózat hatékonyságát, csak a késleltetéseket.

A legtöbb hálózati eszköz késleltetési paraméterekkel rendelkezik, és a legtöbbnek olyan az alapértelmezése, amely nagyon rossz hatású elosztott adatbázisok esetén. A teljesítmény javításának érdekében tanácsos megkeresnie ezeket a paramétereket, és ha lehetséges nullára állítani azokat. Ezen kívül biztosítania kell, hogy az eszközökön lévő pufferméret elég nagy legyen ahhoz, hogy elkerülje az adatok újraküldését az adatok elveszte miatt. Például UNIX rendszerek esetén a küldési vagy vételi várakozási sor mélységének alapértéke 32. Jobb eredményt kap, ha a várakozási sor mélységét 150-re állítja. Az ehhez tartozó paraméter a DLC beállításokban a vételi mélység (Receive Depth), amelyet szintén 150-re kell állítani.

Az IOBUF paraméter a legtöbb esetben túl alacsony értékre van beállítva. Általában 500-ra van állítva, de a tapasztalat azt mutatja, hogy a 3992-es érték adja a legjobb teljesítményt nagy adatmennyiségek mozgatásakor, különösen csatorna összeköttetések, például ESCON vagy 3172 esetén.

SNA összeköttetések esetén tanácsos minden munkaállomás szoftver módprofil (Mode Profile) értékét 63-ra állítani. A vételi lépéstartás értékeket általában tanácsos a legnagyobb értékekre állítani, így a DB2 APPL utasításban illetve a munkaállomás PU/LU esetén a VPACING és PACING paramétereket, 63-ra kell állítani kapcsolt fő módban. Ez azt fogja eredményezni, hogy jelentősen megnövekedhet az üzenetváltások mennyisége, mielőtt a küldőnek a válaszra várakoznia kellene.

LAN rendszerben a DLC vagy LLC küldési és vételi ablakméretnek meghatározó hatása lehet a teljesítményre. A küldési értéket tanácsos hétre vagy ennél nagyobbra állítani, a legtöbb konfiguráció esetén pedig a négyes vagy kisebb vételi érték működik a legjobban.

Ha Ethernet hálózatot használ, a TCP szegmensméretet 1500 bájtra kell állítania. Token ring vagy FDDI hálózat esetén ezt az értéket 4400 bájtra érdemes állítani, míg ha ESCON kártyát használ TCP/IP-vel, mindig 4096-ra állítsa a szegmensméretet!

Végül TCP/IP hálózat esetén a TCP küldési és vételi pufferméreteknek 32768-nál nagyobbnak kell lenniük. A 65536-os érték általában a legjobb.
Megjegyzés:Az átjáróról a kiszolgálóra kapcsolatot létesíteni (kimenő összeköttetés) sokkal költségesebb, mint az ügyfélről az átjáróra (bemenő összeköttetés). Olyan környezetben, ahol az ügyfelek ezrei gyakran kapcsolódnak le és fel a kiszolgálóra az átjárón keresztül, jelentős mennyiségű idő telik el a kimenő összeköttetések létesítésével. A DB2 Connect TCP/IP-ben összeköttetés-csapatokat kínál. Amikor az ügyfelek az összeköttetés bontását kérik a kiszolgálótól, az átjáró eldobja az ügyféllel létesített bemenő összeköttetést, de a kimenő összeköttetéseket csapatban tartja. Amikor új ügyfél érkezik az átjáróhoz összeköttetési kéréssel, az átjáró egy meglévőt ad a csapatból, ezzel csökkentve a teljes összeköttetési időt és megkíméli a CPU-t az összeköttetések létrehozásának magas költségétől.

Ha további tájékoztatásra van szüksége a DB2 alatti csapatokkal kapcsolatban, tekintse át az Administration Guide kézikönyvet!

Az alábbi táblázat összefoglalja a hálózati teljesítményhangolási módszereket.
Mit keressen Példa Beállítás Megjegyzések
Szándékos késleltetések Késleltetési paraméterek hálózati eszközökön Állítsa 0-ra! Az alapértelmezések általában magasabbak.
Pufferek IOBUF paraméter Állítsa 3992-re! Különösen hasznos ESCON vagy más csatorna kártya esetén!
RUSIZE 4096 az optimális méret Az RUSIZE és RQRIOBLK ugyanakkora méretre való állítása adja a legjobb teljesítményt.
Lépéstartás VPACING, PACING és a módprofilokat 63-ra kell állítani. Lehetőleg használjon adaptív lépéstartást!
Kártyabeállítások Küldési/vételi várakozási sor mélység 150 a javasolt érték. Az alapértelmezés általában 32.
DLC ablakozás SNA esetén Állítsa a küldési ablakméretet magasra (>7)! Állítsa az ablakméretet alacsonyra (pl. 1-re), próbálja ki és növelje addig, amíg megtalálja az ideális értéket! Minden logikai egységnek van késleltetése. A lehető legegyszerűbb hálózati topológiát használja!
TCP beállítások Szegmensméretek 1500 Ethernet, 4400 token ring és FDDI esetén. TCP/IP-hez használt ESCON kártyák esetén mindig 4096-ra kell állítani.
Küldési/vételi területméretek Mindkettőnek 64K-nak kell lennie. Windows esetén 8192 az alapérték. A Windows nyilvántartásban lehet beállítani.

Hálózati hardver

A hardverrel kapcsolatosan a következő tényezőket kell figyelembe venni:

Versengés a rendszererőforrásokért

A teljesítmény lecsökkenhet, ha túl sok feladat verseng a rendszer erőforrásaiért. Gondolja át a következő kérdéseket:

Teljesítmény hibaelhárítás

Ha a DB2 Connect felhasználók hosszú válaszidőt tapasztalnak a gazdagép vagy AS/400 kiszolgálóról érkező nagy lekérdezések esetén, a teljesítményprobléma lehetséges okának kiderítése érdekében a következő területeket kell megvizsgálni:

  1. A gazdagép vagy AS/400 kiszolgálótól nagy adatblokkokat (általában 32K vagy több adat) visszaadó lekérdezések esetén győződjön meg róla, hogy az adatbáziskezelő RQRIOBLK konfigurációs paramétere 32767-re van-e állítva! Ezt a parancsfeldolgozóval (CLP) a következőképpen lehet megtenni:
       db2 update database manager configuration using RQRIOBLK 32767
    
  2. Ha a VTAM-ot a gazdagéphez vagy AS/400 kiszolgálóhoz kapcsolva használja, a "váltott főcsomópont" konfigurációjánál ellenőrizze a PACING paraméter értékét. Nézze meg az IBMRDB üzemmódmeghatározás "LU 6.2 üzemmódprofil" kommunikációs beállításait a DB2 Connect munkaállomáson. Ebben a meghatározásban a "Vételi lépéstartási ablak" paraméternek a VTAM-on megadott PACING értéknél kisebbnek, vagy azzal egyenlőnek kell lennie. A DB2 Connect munkaállomáson a "Vételi lépéstartási ablak" és a VTAM-on a "PACING" tipikus értéke 8.
  3. Győződjön meg arról, hogy az IBMRDB üzemmód-meghatározásban az RU maximális mérete megfelelő értékre van-e állítva! Token-ring vezérlőt használó kapcsolatoknál nem javasolt 4K-nál kisebb érték használata. Ethernet vezérlőt használó kapcsolatoknál az Ethernet keretméret maximális értéke 1536 bájt, amely korlátozó tényezőt jelenthet.
  4. Kérjen tanácsot a környezetében tevékenykedő VTAM adminisztrátortól annak biztosítása érdekében, hogy a DB2 Connect munkaállomásán a VTAM az "adaptív lépéstartást" használja az LU-LU szekciók esetén.


[ Oldal eleje | Előző oldal | Következő oldal | Tartalom | Tárgymutató ]