Som standard prøver funksjonen for automatisk klientomdirigering tilkoblingen |til en database på nytt gjentatte ganger i opptil 10 minutter. Det er imidlertid mulig å konfigurere |nøyaktig hvordan funksjonen skal virke, ved hjelp av begge eller den ene av disse registervariablene:
|Hvis DB2_MAX_CLIENT_CONNRETRIES blir definer, men ikke DB2_CONNRETRIES_INTERVAL, brukes |standardverdien 30 for DB2_CONNRETRIES_INTERVAL.
|Hvis DB2_MAX_CLIENT_CONNRETRIES ikke blir definert, men DB2_CONNRETRIES_INTERVAL blir |definert, brukes standardverdien 10 for DB2_MAX_CLIENT_CONNRETRIES.
|Hvis verken DB2_MAX_CLIENT_CONNRETRIES eller DB2_CONNRETRIES_INTERVAL blir definert, fungerer |funksjonen for automatisk klientomdirigering slik det er beskrevet ovenfor.
|Merk:
|Brukere av Type 4-tilknytning med DB2 Universal JDBC-styreprogram skal bruke |disse to datakildeegenskapene til å konfigurere automatisk klientomdirigering:
|Registervariabelen DB2TIMEOUT støttes ikke lenger. Denne innstillingen ble brukt til å |definere tidsutkoblingsperioden for Windows 3.x- og Macintosh-klienter under |lange SQL-spørringer. Denne funksjonen var deaktivert som standard.
| | |Ved opprettelse av tabellplasscontainere oppretter DB2 UDB eventuelle katalognivåer som ikke |finnes.
|Hvis en container for eksempel er spesifisert som /project/user_data/container1, og katalogen /project ikke finnes, oppretter DB2 UDB |katalogene /project og /project/user_data.
|Fra og med DB2 UDB V8.2, opprettingspakke 4, blir eventuelle kataloger som opprettes av DB2 UDB, |opprettet med PERMISSION 700. Det betyr at bare eieren har lese-, skrive- og utføringstilgang.
|Hvis du skal opprette flere forekomster, bør du være klar over hva som skjer i et scenario som dette:
|Fordi DB2 UDB opprettet katalognivåene /project/user_data med |PERMISSION 700 fra den første forespørselen, har ikke bruker2 tilgang til disse |katalognivåene og kan derfor ikke opprette container2 i disse katalogene. | Derfor mislykkes CREATE TABLESPACE-operasjonen.
|Denne konflikten kan løses på to måter:
|Formatet til navnene på containerne er endret slik at tabellplass-IDen og container-IDen også er endret. Dette er det nye formatet:
<lagerbane>/<forekomst>/NODE#### /T####### /C#######.<EXT>
der
Fra og med DB2(R) Universal Database versjon 8.2.2 (tilsvarer versjon 8.1 opprettingspakke 9), kan genererte kolonner brukes i entydige indekser.
Genererte kolonner kan ikke brukes i begrensninger, referansebegrensninger, primærnøkler og globale midlertidige tabeller. En tabell som er opprettet med LIKE og materialiserte utsnitt arver ikke egenskaper for genererte kolonner.
Når du har definert DB2WORKLOAD=SAP, blir ikke brukertabellplassen SYSTOOLSPACE og den midlertidige brukertabellplassen SYSTOOLSTEMPSPACE opprettet automatisk. Disse tabellplassene brukes for tabeller som opprettes automatisk av disse veiviserne, programmene eller funksjonene:
Uten tabellplassene SYSTOOLSPACE og SYSTOOLSTEMPSPACE kan du ikke bruke disse veiviserne, programmene eller funksjonene.
For å kunne bruke veiviserne, programmene eller funksjonene må du gjøre en av disse tingene:
CREATE REGULAR TABLESPACE SYSTOOLSPACE IN IBMCATGROUP MANAGED BY SYSTEM USING ('SYSTOOLSPACE')
Når du har utført minst ett av disse alternativene, oppretter du en midlertidig brukertabellplass (også bare på katalognoden hvis du bruker DPF). For eksempel:
CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE IN IBMCATGROUP MANAGED BY SYSTEM USING ('SYSTOOLSTMPSPACE')
Når tabellplassen SYSTOOLSPACE og den midlertidige tabellplassen SYSTOOLSTEMPSPACE er opprettet, kan du bruke veiviserne, programmene eller funksjonene som er nevnt ovenfor.
Autentiseringstypen DATA_ENCRYPT_CMP er laget for å tillate klienter fra en tidligere utgave som ikke støtter datakryptering, å koble seg til en tjener med SERVER_ENCRYPT-autentisering i stedet for DATA_ENCRYPT. Denne autentiseringen virker ikke når disse tre beskrivelsene stemmer:
I denne situasjonen kan ikke klienten koble seg til tjeneren. For å gjøre en tilkobling mulig må du enten oppgradere klienten til versjon 8, eller bruke et portnernivå på versjon 8 opprettingspakke 6 eller tidligere.
Direct I/O (DIO) forbedrer minneytelsen fordi den ikke bruker hurtigbufring på filsystemnivå. Denne prosessen reduserer CPU-bruken og gjør mer minne tilgjengelig for databaseforekomsten.
Concurrent I/O (CIO) har fordelene ved DIO og avlaster i tillegg serieomkodingen for skrivetilganger.
DB2 Universal Database (UDB) støtter DIO og CIO på AIX, og DIO på HP-UX, Solaris Operating Environment, Linux og Windows.
Nøkkelordene NO FILE SYSTEM CACHING og FILE SYSTEM CACHING er en del av SQL-setningene CREATE og ALTER TABLESPACE for å gjøre det mulig å oppgi om DIO eller CIO skal brukes sammen med hver enkelt tabellplass. Når NO FILE SYSTEM CACHING er i bruk, prøver DB2 UDB å bruke CIO der det er mulig. I tilfeller der CIO ikke støttes (for eksempel hvis JFS brukes), brukes DIO i stedet.
Hvis du vil vite mer om dette, kan du lese artikkelen "Improve database performance on file system containers in IBM DB2 UDB Stinger using Concurrent I/O on AIX" på denne URLen:
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/
Denne informasjonen er en del av Administration Guide: Implementation Appendix B "Using automatic client rerouting":
Funksjonen for automatisk klientomdirigering i DB2 Universal Database for Linux, UNIX, og Windows gjør det mulig for klientapplikasjoner å gjenoppta arbeidet etter brudd på kommunikasjonen med tjeneren, ved å automatisk gjenopprette databasetilkoblingen fra klienten til tjeneren, slik at applikasjonen kan fortsette å arbeide med minst mulig avbrudd.
Når forbindelsen mellom en klient og en tjener brytes, blir klientens forespørsel om gjenoppretting av forbindelsen distribuert til et definert sett med systemer av en distributør eller fordeler, for eksempel WebSphere EdgeServer
Du bruker kanskje Distributor Technology i et liknende miljø som dette:
Client --> Distributor Technology --> (DB2 Connect-tjener 1 eller DB2 Connect-tjener 2) --> DB2 z/OS
der
Klienten blir katalogisert ved hjelp av DThostname for å kunne bruke distributørteknologien til å få tilgang til en av DB2 Connect-tjenerne. Distributørteknologien bestemmer om det er GWYhostname1 eller GWYhostname2 som skal brukes. Så snart avgjørelsen er tatt, har klienten en direkte socket-tilkobling til en av disse to DB2 Connect-portnerne. Så snart socket-tilkoblingen er opprettet til den valgte DB2 Connect-tjeneren, har du en vanlig forbindelse mellom klienten, DB2 Connect-tjeneren og DB2 z/OS.
La oss for eksempel anta at distributøren velger GWYhostname2. Det gir dette miljøet:
Klient --> DB2 Connect-tjener 2 --> DB2 z/OS
Distributøren prøver ikke om igjen noen av tilkoblingene hvis det oppstår en kommunikasjonsfeil. Hvis du ønsker å aktivere funksjonen for automatisk klientomdirigering for en database i et slikt miljø, må den alternative tjeneren for den eller de tilknyttede databasene på DB2 Connect-tjeneren (DB2 Connect-tjener 1 eller DB2 Connect-tjener 2) konfigureres som distributør (DThostname). Hvis da DB2 Connect-tjener 1 blir låst av en eller annen grunn, utløses den automatiske klientomdirigeringen slik at klienttilkoblingen blir forsøkt på nytt med distributøren som både primær og alternativ tjener. Dette alternativet gjør det mulig å kombinere og opprettholde distributørfunksjonene sammen med DB2-funksjonen for automatisk klientomdirigering. Selv om du definerer den alternative tjeneren til en annen vert enn distributørens vertsnavn, vil klientene ha funksjonen for automatisk klientomdirigering. Klientene vil imidlertid opprette direkte tilkoblinger til den definerte alternative tjeneren og hoppe over distributørteknologien, slik at distributørens fordeler ikke kan utnyttes.
Automatisk klientomdirigering fanger opp disse sql-kodene:
Vurder følgende to situasjoner som omfatter tilkoblingsmuligheter for alternative tjenere med DB2 Connect-tjeneren:
Applikasjoner som kjøres i konteksten til den lokale systemkontoen (LSA) støttes på alle Windows-plattformer unntatt Windows ME.
CONNECT-setningen og ATTACH-kommandoen støtter todelte bruker-IDer. Kvalifikatoren til den SAM-kompatible bruker-IDen er NetBIOS-oppsettnavnet som har en maksimal lengde på 15 tegn. Denne funksjonen støttes ikke på Windows ME.
Du kan overstyre Kerberos-tjenerens prinsipalnavn som brukes av DB2 Universal Database (UDB)-tjeneren på UNIX- og Linux-operativsystemer. Sett systemvariabelen DB2_KRB5_PRINCIPAL til tjenerens fullstendige prinsipalnavn. Forekomsten må startes på nytt fordi tjenerens prinsipalnavn bare gjenkjennes av DB2 UDB etter at db2start er kjørt.
Forutsetningene for Kerberos-støtte på Linux er ikke beskrevet riktig i dokumentasjonen. Kerberos-tilleggsmodulen for sikkerhet som følger med DB2, støttes på Red Hat Enterprise Linux Advanced Server 3 med IBM Network Authentication Service (NAS) 1.4-klienten.
For tilkoblinger til zSeries og iSeries må databasen katalogiseres med parameteren AUTHENTICATION KERBEROS, og parameternavnet for TARGET PRINCIPAL må spesifiseres eksplisitt.
Verken zSeries eller iSeries støtter gjensidig autentisering.
I tillegg vil DB2-administrasjonsloggen eller db2diag.log i alle tilfeller indikere "Logon failed" eller "Logon denied."
Den lokale sikkerhetsautoriteten kan ikke kontaktesFeilen forårsakes av at Windows finner den lokale brukeren først. Løsningen er å kvalifisere brukeren fullstendig i tilkoblingsstrengen. For eksempel:
navn@DOMENE.IBM.COM
Du kan finne ut om Windows-kontoene er konfigurert til å bruke DES-kryptering, ved å se under kontoegenskapene i Active Directory. Du må kanskje starte på nytt hvis kontoegenskapene blir endret.
host/<server hostname>@<server domain name>For eksempel:
host/myhost.domain.ibm.com@DOMAIN.IBM.COMHvis ikke må du starte DB2-tjenesten under en gyldig domenekonto.