Administrasjon: Implementering

Konfigurasjon av automatisk klientomdirigering (DB2_MAX_CLIENT_CONNRETRIES |og DB2_CONNRETRIES_INTERVAL)

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:

|
• DB2_MAX_CLIENT_CONNRETRIES: Det maksimale antall gjenforsøk på tilkobling som utføres av funksjonen for |automatisk klientomdirigering.
|
• DB2_CONNRETRIES_INTERVAL: Ventetiden mellom gjenforsøkene på tilkobling, i antall sekunder.

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:

|
• maxRetriesForClientReroute: Bruk denne egenskapen til å begrense antall gjenforsøk |hvis primærtilkoblingen til tjeneren ikke fungerer. Denne egenskapen brukes bare |hvis egenskapen retryIntervalClientReroute også er definert.
|
• retryIntervalForClientReroute: Bruk denne egenskapen til å oppgi hvor mange |sekunder det skal ventes mellom hvert gjenforsøk. Denne egenskapen brukes bare |hvis egenskapen maxRetriesForClientReroute også er definert.

Klargjøring om registervariabelen DB2TIMEOUT

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.

Kataloger som blir opprettet under opprettelse av tabellplasscontainer

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:

|
1. La oss tenke oss at det brukes samme katalogstruktur som ovenfor, og at katalognivåene /project/user_data ikke finnes.
|
2. bruker1 oppretter en forekomst, kalt bruker1 som standard, oppretter deretter |en database og oppretter så en tabellplass med /project/user_data/container1 som en av containerne.
|
3. bruker2 oppretter en forekomst, kalt bruker2 som standard, oppretter deretter |en database og prøver så å opprette en tabellplass med /project/user_data/container2 som en av containerne.

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:

|
1. Opprett katalogen /project/user_data før du oppretter tabellplassen, og sett |tillatelsen til den tilgangen som kreves for at både bruker1 og |bruker2 skal kunne opprette tabellplassene. Hvis alle nivåene for en tabellplasskatalog finnes, endrer |ikke DB2 UDB tilgangen.
|
2. Etter at bruker1 har opprettet /project/user_data/container1, definerer du tillatelsen |for /project/user_data til den tilgangen som kreves for at bruker2 skal kunne opprette tabellplassen.

Automatisk lager

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

• /T####### er tabellplass-IDen. For eksempel T0000003.
• /C####### er container-IDen. For eksempel C0000012.

Definere en generert kolonne på en eksisterende tabell

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.

Samlingsregistervariabler

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:

• Automatisk vedlikehold
• Utformingsrådgiver
• Informasjonsbilde for kontrollsenterdatabase
• Den lagrede prosedyren SYSINSTALLOBJECTS, hvis inndataparameteren for tabellplassen ikke er oppgitt
• Den lagrede prosedyren GET_DBSIZE_INFO

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:

• Opprett SYSTOOLSPACE manuelt (bare på katalognoden hvis du bruker DPF). For eksempel:

     CREATE REGULAR TABLESPACE SYSTOOLSPACE 
        IN IBMCATGROUP 
        MANAGED BY SYSTEM 
        USING ('SYSTOOLSPACE')

• Kall SYSINSTALLOBJECTS for å opprette objekter og oppgi en gyldig tabellplass for hver av disse verktøynavnene: "DB2AC", "POLICY" og "STMG_DBSIZE_INFO"

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.

Vurderinger om autentisering for fjernklienter

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:

• Klientnivået er versjon 7.2.
• Portnernivået er versjon 8 opprettingspakke 7 eller senere.
• Tjeneren er versjon 8 opprettingspakke 7 eller senere.

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.

Støtte for Direct I/O (DIO) og Concurrent I/O (CIO)

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/

Distributørteknologi og automatisk klientomdirigering

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

• Distributor Technology-komponenten har TCP/IP-vertsnavnet DThostname
• DB2 Connect-tjener 1 har TCP/IP-vertsnavnet GWYhostname1
• DB2 Connect-tjener 2 har TCP/IP-vertsnavnet GWYhostname2
• DB2 z/OS-tjeneren har TCP/IP-vertsnavnet zOShostname

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:

• sqlcode -20157
• sqlcode -1768 (årsakskode = 7)

Automatisk klientomdirigering og katalogisering på en DB2 Connect-tjener

Vurder følgende to situasjoner som omfatter tilkoblingsmuligheter for alternative tjenere med DB2 Connect-tjeneren:

• Den første situasjonen gjelder bruk av DB2 Connect-tjeneren for å gi tilgang til en vertsdatabase eller en iSeries-database på vegne av både fjerntliggende og lokale klienter. I slike situasjoner kan det oppstå usikkerhet rundt informasjonen om tilkoblingsmulighet for alternativ tjener i en post i systemets databasekatalog. Du kan redusere denne usikkerheten ved å vurdere å katalogisere to poster i systemets databasekatalog for å representere den sammen vertsdatabasen eller iSeries-databasen. Katalogiser en post for fjerntliggende klienter og en annen for lokale klienter.
• Den andre situasjonen oppstår når informasjonen om alternativ tjener som returneres fra en måltjener bare holdes i en hurtigbuffer. Hvis DB2-prosessen avsluttes, går dataene (og dermed informasjonen om alternativ tjener) i hurtigbufferen tapt.

Støtte for lokal systemkonto (Windows)

Applikasjoner som kjøres i konteksten til den lokale systemkontoen (LSA) støttes på alle Windows-plattformer unntatt Windows ME.

Støtte for todelt bruer-ID

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.

Informasjon om Kerberos-autentisering

Tilleggsopplysninger om Kerberos-støtte