Az automatikus kliens átirányítás szolgáltatás alapértelmezésben |legfeljebb 10 percig próbálkozik az adatbázishoz csatlakozni. Azonban be |lehet állítani a pontos újrapróbálkozási viselkedést az alábbi két |rendszerleíró adatbázis változóval:
|Ha a DB2_MAX_CLIENT_CONNRETRIES meg van adva, míg a |DB2_CONNRETRIES_INTERVAL nincs, akkor a DB2_CONNRETRIES_INTERVAL |alapértelmezése 30.
|Ha a DB2_MAX_CLIENT_CONNRETRIES nincs beállítva, de a |DB2_CONNRETRIES_INTERVAL igen, akkor a DB2_MAX_CLIENT_CONNRETRIES |alapértelmezése 10.
|Ha sem a DB2_MAX_CLIENT_CONNRETRIES, sem a DB2_CONNRETRIES_INTERVAL |nincs beállítva, akkor az automatikus kliens átirányítás szolgáltatás a |korábban leírt alapértelmezett viselkedést követi.
|Megjegyzés:
|A 4-es típusú csatlakozás és a DB2(R) Universal JDBC |illesztőprogram használóinak az alábbi két adatforrás tulajdonságokat kell |használnia az automatikus kliens átirányítás konfigurálásához:
|A DB2TIMEOUT rendszerleíró adatbázis változó már nem támogatott. Ezzel |a beállítással lehetett vezérelni a Windows(R) 3.x és Macintosh |kliensek időkorlát tartamát hosszú SQL lekérdezések alatt. Ez az |összetevő alapértelmezésben tiltott volt.
| | |A táblázat terület tárolók létrehozásakor a DB2 UDB létrehozza a nem |létező könyvtárszinteket.
|Például ha a /projekt/felhasználói_adatok/tároló1 van |megadva tárolóként, és a /projekt könyvtár nem létezik, akkor a |DB2 UDB létrehozza a /projekt és a |/projekt/felhasználói_adatok könyvtárakat.
|A DB2 UDB V8.2 változat 4-es javítócsomagjával kezdődően a DB2 UDB |által létrehozott könyvtárak 700-as jogosultsággal vannak létrehozva. Ez |azt jelenti, hogy csak a tulajdonosnak van olvasási, írási és futtatási |hozzáférése.
|Több példány létrehozásakor vegye figyelembe az alábbi példahelyzetet:
|Mivel a DB2 UDB 700-as jogosultsággal hozta létre a |/projekt/felhasználói_adatok könyvtárat az első kérésben, a |felhasználó2-nek nincs hozzáférése ezekhez a könyvtárszintekhez, és nem |tudja létrehozni a tároló2 tárolót ezekben a könyvtárakban. | Ebben az esetben a CREATE TABLESPACE művelet meghiúsul.
|Kétféleképpen lehet megoldani ezt a konfliktust:
|A tárolók nevének formátuma oly módon változott meg, hogy a módosítás érinti a táblaterület-azonosítókat és a tárolóazonosítókat is. Az új formátum:
<tárolási útvonal>/<példány>/CSOMÓPONT#### /T####### /C#######.<EXT>
ahol:
A DB2(R) Universal Database 8.2.2-es verziójától kezdve (mely egyenértékű a FixPak 9 javítócsomaggal futó 8.1-es verzióval) létrehozott oszlopok használhatók egyedi indexekben.
Létrehozott oszlopok nem használhatók nyomvonalakban, hivatkozási nyomvonalakban, elsődleges kulcsokban és globális ideiglenes táblákban. LIKE segítségével és létrehozott nézetekkel létrehozott tábla nem örökli a létrehozott oszlopok tulajdonságait.
A DB2WORKLOAD=SAP beállítás mellett a SYSTOOLSPACE felhasználói táblaterület és a SYSTOOLSTEMPSPACE felhasználói ideiglenes táblaterület létrehozása nem történik meg automatikusan. Ezeket a táblaterületeket a rendszer a következő varázslók, segédprogramok, illetve funkciók által létrehozott táblák esetében használja:
A SYSTOOLSPACE és SYSTOOLSTEMPSPACE táblaterületek nélkül ezek a varázslók, segédprogramok, illetve funkciók nem használhatók.
A varázslók, segédprogramok és funkciók használatához a következők végrehajtása szükséges:
CREATE REGULAR TABLESPACE SYSTOOLSPACE
IN IBMCATGROUP
MANAGED BY SYSTEM
USING ('SYSTOOLSPACE')Ezen választások közül legalább egyet befejezve hozzon létre egy felhasználói ideiglenes táblaterületet (szintén csak a katalógus csomóponton, DPF használata esetén). Például:
CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE
IN IBMCATGROUP
MANAGED BY SYSTEM
USING ('SYSTOOLSTMPSPACE')
A SYSTOOLSPACE táblaterület és a SYSTOOLSTEMPSPACE ideiglenes táblaterület létrehozását követően használhatóvá válnak a korábban említett varázslók, segédprogramok és funkciók.
A DATA_ENCRYPT_CMP hitelesítési típus kialakítása úgy történt, hogy lehetővé tegye a korábbi, az adattitkosítást nem támogató kiadások valamelyikét használó ügyfelek csatlakozását kiszolgálóhoz SERVER_ENCRYPT hitelesítéssel (DATA_ENCRYPT hitelesítés helyett). Ez a hitelesítés nem működik, ha a következő három állítás igaz:
Ebben az esetben az ügyfél nem tud csatlakozni a kiszolgálóhoz. A csatlakozás lehetővé tételéhez vagy az ügyfelet kell frissíteni 8-as verziójúra, vagy az átjáró esetében kell a 8-as verzió 6-os vagy korábbi FixPak javítócsomagját használni.
A közvetlen I/O (Direct I/O, DIO) javítja a memóriafelhasználási teljesítményt, mivel a fájlrendszer szintjén kiküszöböli a gyorsítótár használatát. Ez a folyamat csökkenti a CPU többletterhelését és több szabad memóriát tesz elérhetővé az adatbázispéldány számára.
Az egyidejű I/O (Concurrent I/O, CIO) biztosítja a DIO előnyeit, továbbá feloldja az írási hozzáférések sorosítását (serialization).
A DB2 Universal Database (UDB) támogatja a DIO és a CIO szolgáltatást AIX rendszer esetében; illetve a DIO szolgáltatást HP-UX, Solaris Operating Environment, Linux és Windows rendszerek esetében.
A NO FILE SYSTEM CACHING és a FILE SYSTEM CACHING kulcsszavak részét képezik a CREATE és az ALTER TABLESPACE SQL utasításoknak, így minden egyes táblaterületre vonatkozóan megadható a DIO vagy a CIO használata. A NO FILE SYSTEM CACHING megadása esetén a DB2 UDB az egyidejű I/O szolgáltatást kísérli meg használni, ahol az lehetséges. Amennyiben a CIO nem támogatott (például JFS használata esetében), a rendszer a DIO szolgáltatást használja.
További információkért olvassa el az "Improve database performance on file system containers in IBM DB2 UDB Stinger using Concurrent I/O on AIX" című (Adatbázis teljesítményének növelése AIX rendszeren, az IBM DB2 UDB Stinger program fájlrendszer-tárolóin, egyidejű I/O segítségével) cikket a következő URL címen:
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/
A következő információk megtalálhatók az Adminisztrációs útmutató: Megvalósítás B függelék "Az automatikus ügyfélátirányítás használata" részben:
A DB2 Universal Database for Linux, UNIX, és Windows automatikus ügyfélátirányítási szolgáltatás lehetővé teszi az ügyfélalkalmazások számára, hogy a kiszolgálóval folytatott kommunikáció megszakadása esetén automatikusan új adatbázis-kapcsolatot hozzon létre a kiszolgáló és a kiszolgáló között, így az alkalmazás minimális fennakadással képes folytatni működését.
Ha az ügyfél-kiszolgáló kapcsolódás sikertelen, az ügyfél kérelmeit egy szétosztó (distributor) vagy elosztó (dispatcher) program elküldi a rendszerek egy megadott csoportjának. Ilyen program például a WebSphere EdgeServer.
A Distributor Technology (szétosztási technológia) a következőhöz hasonló környezetben használható:
Client --> Distributor Technology --> (DB2 Connect Server 1 vagy DB2 Connect Server 2) --> DB2 z/OS
ahol:
Az ügyfél katalógusba vétele a DThostname segítségével történt annak érdekében, hogy a szétosztási technológia (distributor technology) használható legyen a DB2 Connect kiszolgálók valamelyikének eléréséhez. A beavatkozó szétosztási technológia meghatározza, hogy a GWYhostname1 vagy a GWYhostname2 kiszolgálót használja-e. Ennek eldöntése után az ügyfél közvetlen socket (foglalati) kapcsolatot létesít ezen két DB2 Connect átjáró egyikével. Miután a socket (foglalati) kapcsolódás létrejött a kiválasztott DB2 Connect kiszolgálóval, szokványos ügyféllel rendelkezik a DB2 Connect kiszolgáló és a DB2 z/OS közti kapcsolódáshoz.
Például tegyük fel, hogy a szétosztó a GWYhostname2 kiszolgálót jelöli ki. Ez a következő környezetet eredményezi:
Client --> DB2 Connect Server 2 --> DB2 z/OS
A szétosztó nem kísérli meg a csatlakozások újbóli létrehozását, ha kommunikációs hiba lép fel. Ha engedélyezni kívánja az Automatic Client Reroute (Automatikus ügyfélátirányítás) szolgáltatást egy ilyen környezetben futó adatbázis esetében, a DB2 Connect Server (DB2 Connect Server 1 vagy DB2 Connect Server 2) kiszolgálón található társított adatbázis(ok)hoz tartozó másodlagos kiszolgálót kell szétosztóként (DThostname) beállítani. Ebben az esetben, ha a DB2 Connect Server 1 bármilyen okból zárolás alá kerül, elindul az Automatic Client Reroute (Automatikus ügyfélátirányítás) szolgáltatás, és a program megkísérli újra létrehozni az ügyfélkapcsolatot a szétosztóval elsődleges és másodlagos kiszolgálóként egyaránt. Ez a beállítás lehetővé teszi a szétosztó szolgáltatásainak egyesítését és fenntartását a DB2 Automatic Client Reroute szolgáltatással. A másodlagos kiszolgáló a szétosztó gazdanevétől eltérő gazdagépként történő megadása továbbra is lehetővé teszi az ügyfelek számára az Automatic Client Reroute (Automatikus ügyfélátirányítás) szolgáltatás használatát. Ekkor azonban az ügyfelek közvetlen kapcsolatokat létesítenek a megadott másodlagos kiszolgálóval és megkerülik a szétosztási technológiát, mely kizárja a szétosztót és az általa adott értéket.
Az Automatic Client Reroute a következő sqlcode kódok esetében avatkozik be:
Vegye figyelembe az alábbi két szempontot a DB2 Connect kiszolgáló és egy másodlagos kiszolgáló csatlakozásával kapcsolatban:
A helyi rendszerfiók (LSA) környezetében futó alkalmazások a Windows ME kivételével minden Windows rendszeren támogatottak.
A CONNECT utasítás és az ATTACH parancs támogatja a kétrészes felhasználói azonosítókat. A SAM-kompatibilis felhasználói azonosító minősítője a NetBIOS stílusnév, amely maximum 15 karakterből állhat. Ez a szolgáltatás nem támogatott Windows ME rendszer esetében.
A DB2(R) Universal Database (UDB) kiszolgáló által használt Kerberos kiszolgáló azonosítóját felülbírálhatja UNIX(R) és Linux(TM) operációs rendszereken. A DB2_KRB5_PRINCIPAL környezeti változó értékeként adja meg a kívánt teljesen megadott kiszolgálói elöljárónevet. A példányt újra kell indítani, mivel a kiszolgálói elöljárónevet a DB2 UDB rendszer a db2start futtatását követően ismeri fel.
A Linux Kerberos támogatásra vonatkozó előfeltételek leírása pontatlan a dokumentációban. A mellékelt DB2 Kerberos biztonsági bővítő a következő esetében támogatott: Red Hat Enterprise Linux Advanced Server 3, IBM Network Authentication Service (NAS) 1.4 ügyféllel.
zSeries vagy iSeries rendszerhez való kapcsolódáskor az adatbázist az AUTHENTICATION KERBEROS paraméterrel kell katalógusba venni, és pontosan meg kell adni a TARGET PRINCIPAL paraméternevet.
Sem a zSeries, sem az iSeries nem támogatja a kölcsönös hitelesítést.
Továbbá a DB2 adminisztrációs naplója vagy a db2diag.log naplófájl minden esetben "Logon failed" ("Sikertelen bejelentkezés") vagy "Logon denied" ("Bejelentkezés visszautasítva") bejegyzést fog tartalmazni.
The Local Security Authority cannot be contacted (A helyi biztonsági rendszerrel nem lehet kapcsolatba lépni)A hibát az okozza, hogy a Windows először a helyi felhasználót keresi. Megoldás: teljesen meg kell adni a felhasználót a kapcsolódási karakterláncban. Például:
name@DOMAIN.IBM.COM
Annak megállapítására, hogy a Windows fiókok a DES titkosítás használatára vannak-e konfigurálva, nézze meg a Fiók tulajdonságai alatt, az Active Directory helyen. A fiók tulajdonságainak módosításakor újra kell indítani a rendszert.
gazdagép/ <kiszolgálói gazdagépnév>@<kiszolgálói tartománynév>Például:
gazda/gazda.tartomany.ibm.com@TARTOMANY.IBM.COMMáskülönben a DB2 szolgáltatást érvényes tartományfiókból kell indítani.