DB2 Connect Enterprise Edition-servere stiller ofte databaseforbindelser til rådighed for tusindvis af samtidige klientforespørgsler. Etablering af forbindelser og det at fungere som server for dem kan være en meget ressourcekrævende proces, som påvirker både databaseserverens og DB2 Connect-serverens performance negativt. Dette ses specielt i Web-miljøer, hvor et enkelt besøg på en Web-side kan kræve oprettelse af en ny forbindelse til databaseserveren, udførelse af en forespørgsel og afslutning af en forbindelse. Med det formål at mindske dette tidstillæg benytter DB2 Connect Enterprise Edition forbindelsespuljer, så de åbne forbindelser til databasen kan bevares i en pulje, man straks kan få adgang til.
Brugen af forbindelsespuljer er transparent i forhold til de applikationer, der opretter forbindelse til værten via DB2 Connect. Når en applikation anmoder om, at forbindelsen til værten bliver afbrudt, afbryder DB2 Connect den indgående forbindelse fra applikationen, men bevarer den udgående forbindelse til serveren i en pulje. Når en ny applikation anmoder om oprettelse af en forbindelse, bruger DB2 Connect en forbindelse fra den eksisterende pulje. Når der anvendes allerede oprettede forbindelser, reduceres det samlede tidsforbrug og CPU-tidsforbruget ved oprettelse af forbindelser på værten.
Hvis du vil anvende forbindelsespuljen, skal følgende APAR installeres på DB2 til OS/390 Version 6.1:
APAR PQ33473
DB2 Connect-agenter kan være i to tilstande: Inaktiv eller aktiv. En agent er aktiv, når den udfører arbejde for en applikation. Når først dette arbejde er færdigt, overgår agenten til inaktiv tilstand og afventer videre arbejde fra den samme eller en anden applikation. Alle inaktive agenter holdes samlet i en såkaldt inaktiv agentpulje. Du kan konfigurere denne puljes størrelse vha. konfigurationsparameteren NUM_POOLAGENTS. Parameteren svarer til det maksimale antal inaktive agenter, du ønsker, systemet skal bevare. Hvis du angiver denne parameter til nul, svarer det til at deaktivere forbindelsespuljefunktionen.
DB2 Connect etablerer ikke forbindelser til databasen, inden den første klientforespørgsel modtages. Du kan dog fylde den inaktive agentpulje, inden der stilles nogen klientforespørgsel. Puljen kan fyldes ved start af programmet, hvis du bruger konfigurationsparameteren NUM_INITAGENTS. Denne parameter bestemmer, hvor mange inaktive agenter der skal oprettes ved start af programmet. I begyndelsen er der ikke oprettet forbindelse for disse inaktive agenter til værtsdatabaseserveren.
Når en klient anmoder om oprettelse af en forbindelse til værten, forsøger DB2 Connect at få en agent fra puljen, som har forbindelse til værtsdatabaseserveren. Hvis det ikke lykkes, forsøger DB2 Connect at finde en tilgængelig agent i den inaktive pulje. Hvis puljen er tom, opretter DB2 Connect en ny agent.
Du kan styre det maksimale antal agenter, som kan være aktive samtidigt, ved at anvende konfigurationsparameteren MAX_COORDAGENTS. Når det maksimale antal er nået, kan der ikke oprettes nye forbindelser. SQL-fejlkode SQL1226 vises. Koden angiver, at det maksimale antal samtidige udgående forbindelser er nået.
DB2-registreringsvariablen DB2CONNECT_IN_APP_PROCESS gør det muligt for applikationer, der udføres på samme maskine som DB2 Connect Extended Edition, enten at få DB2 Connect udført i applikationsprocessen (standardfunktion) eller at få applikationen til at oprette forbindelse til DB2 Connect EE Server og derefter få værtsforbindelsen udført inde fra en agent. Forbindelserne til værten skal oprettes inde fra DB2 Connect EE Server-agenter, og derfor skal DB2CONNECT_IN_APP_PROCESS angives til NO, for en applikation kan benytte forbindelsespuljer.
Med den DB2 Connect-teknologi, der anvendes til forbindelseskoncentrator, kan DB2 Connect Enterprise Edition-servere understøtte tusindvis af brugere, der udfører samtidige forretningstransaktioner, mens ressourceforbruget reduceres markant på S/390-værtsservere eller AS/400-databaseservere. Det opnås ved at koncentrere arbejdsbelastningen fra alle applikationer til et meget mindre antal forbindelser til S/390-værter eller AS/400-databaseservere. Det kan minde om brugen af forbindelsespuljer, der er beskrevet ovenfor, men det er i virkeligheden en meget mere raffineret måde at reducere ressourceforbruget for OLTP-applikationer (On-line Transaction Processing), der indeholder mange data.
Ved forbindelsespuljer spares udgiften til oprettelse af en forbindelse, når en afsluttet applikation ikke skal bruge forbindelsen længere. Med andre ord skal én forbindelse afbrydes, før en anden kan genbruge en puljeforbindelse.
Med forbindelsekoncentratoren kan DB2 Connect derimod oprette en forbindelse, der er til rådighed for en applikation, så snart en anden applikation er færdig med en transaktion, og forbindelsen til denne anden applikation behøver ikke at blive afbrudt. En databaseserverforbindelse og de tilknyttede værts- og DB2 Connect-ressourcer bruges kun af en applikation, mens der er en aktiv transaktion. Så snart transaktionen er færdig, er forbindelsen og de tilknyttede ressourcer til rådighed for en hvilken som helst anden applikation, der skal have en transaktion udført.
I de tidligere versioner af DB2 Connect havde alle aktive applikationer en EDU-enhed (Engine Dispatchable Unit), som styrede databaseforbindelserne foruden alle applikationsforespørgslerne. EDU blev ofte omtalt som koordinatoragenten. Hver koordinatoragent sporede tilstanden eller omfanget for applikationen og EDU. Hver EDU optager en bestemt mængde hukommelse, når antallet øges, og omfang, der skifter mellem agenter, resulterer i yderligere tidstillæg.
I denne type arkitektur er der en "en til en-relation" mellem forbindelserne og EDU'er. Forbindelsekoncentratoren giver derimod mulighed for en "mange til en-relation" mellem forbindelser og EDU'er. Det vil sige, at forholdet mellem forbindelser (X) og EDU'er (Y) er nu X >= Y.
Forbindelsekoncentratoren opdeler agenten i to enheder, en logisk agent og en arbejdende agent. Logiske agenter repræsenterer en applikation, men uden henvisning til en bestemt EDU. Den logiske agent indeholder alle de oplysninger og styreblokke, en applikation har brug for. Hvis der er n applikationer med forbindelse til serveren, vil der være n logiske agenter på serveren. De arbejdende agenter er fysiske EDU'er, som udfører applikationsforespørgsler, men som ikke har nogen permanent tilknytning til en given applikation. De arbejdende agenter knyttes til logiske agenter for at udføre transaktioner og ved transaktionsgrænsen afslutte tilknytningen og vende tilbage til den tilgængelige pulje.
En enhed, der planlægger for logiske agenter, knytter arbejdende agenter til logiske agenter. Begrænsninger i antallet af åbne filreferencer på visse edb-platforme kan resultere i flere planlægger-subsystemer, hvor antallet af logiske agenter overskrider grænsen for filreferencer.
Hvis du vil anvende forbindelseskoncentratoren, skal følgende APAR installeres på DB2 til OS/390 Version 6.1:
APAR PQ33473
Parameteren til konfiguration af databasesystemet MAX_LOGICAGENTS angiver det maksimale antal logiske agenter. Du kan aktivere koncentratorfunktionen ved at angive værdien for MAX_LOGICAGENTS til et tal, der er større end standardværdien. Standardværdien for MAX_LOGICAGENTS er lig med værdien for MAX_COORDAGENTS. Fordi alle applikationer har én logisk agent, styrer MAX_LOGICAGENTS faktisk det antal applikationer, som kan forbindes med DB2-subsystemet, mens MAX_COORDAGENTS styrer antallet af indgående forbindelser, der kan være aktive på et givet tidspunkt. MAX_LOGICAGENTS tager et numerisk interval fra MAX_COORDAGENTS på op til 64.000. Standardantallet af logiske agenter er lig med MAX_COORDAGENTS.
Der bruges adskillige eksisterende konfigurationsparametre til konfiguration af agenter. Det drejer sig om følgende parametre:
På grund af forbindelseskoncentratorens arkitektur kan DB2 Connect yde tætkoblet XA-transaktionsstøtte til DB2 til OS/390 og DB2 til AS/400. Koncentratoren knytter en arbejdende agent til en bestemt XA-transaktion (enkel XID), som der sker ved alle andre transaktioner. Men hvis XA-transaktionen afsluttes med xa_end() (forgreningsgrænse), frigiver den arbejdende agent ikke sig selv til den generelle pulje. I stedet for forbliver den arbejdende agent knyttet til den bestemte XA-transaktion. Når en anden applikation kommer med i samme XA-transaktion, knyttes den arbejdende agent til denne applikation.
Ethvert transaktionsgrænsekald sender agenten tilbage til puljen. Agenten bliver f.eks. sendt tilbage til den almindelige pulje af følgende: xa_prepare() med kun læseadgang, xa_rollback(), xa_recover(), xa_forget(), xa_commit() eller enhver XA-fejl, der resulterer i, at der udføres rollback. Xa_end() i sig selv afslutter kun transaktionsgrenen, og det er ikke nok til at afslutte tilknytningen til XID'en.
DB2 Connect-serversystemet kan måske ikke understøtte 4.000 samtidige åbne forbindelser til databasemaskinen. I de fleste tilfælde bliver det antal transaktioner, der indtræffer et givet øjeblik, betydeligt mindre end antallet af samtidige forbindelser. Systemadministratoren kan derefter maksimere systemets effektivitet ved at angive parametrene til konfiguration af databasen på denne måde:
MAX_LOGICAGENTS = 4.000 MAX_AGENTS = 1.000 MAX_COORDAGENTS = 1.000 NUM_POOLAGENTS = 1.000
Koncentratoren bevarer op til 4.000 samtidige sessioner, selv om gatewayen kun styrer 1.000 transaktioner ad gangen.
Når det drejer sig om XA-transaktioner, er det lidt anderledes. Ved dette eksempel kan man gå ud fra, at der bliver brugt en TP-overvågning sammen med en DB2 Connect-gateway og en OS/390- eller AS/400-database. Når en applikation anmoder om at få oprettet en forbindelse, vil koncentratoren enten overdrage udførelsen af anmodningen til en ikke-aktiv agent eller oprette en ny arbejdende agent. Lad os antage, at applikationen anmoder om en XA-transaktion. En XID oprettes til transaktionen, og den arbejdende agent tilknyttes.
Når anmodningen fra applikationen er udført, afsender applikationen en xa_end() og afbryder forbindelsen til den arbejdende agent. Den arbejdende agent forbliver knyttet til transaktionens XID. Den kan nu kun betjene anmodninger om transaktioner med den tilknyttede XID.
På dette tidspunkt kan en anden applikation evt. anmode om en ikke-XA-transaktion. Selv om der ikke er andre tilgængelige arbejdende agenter, bliver den agent, der er knyttet til XID'en, ikke gjort tilgængelig for den anden applikation. Den anses for at være aktiv. Den anden applikation får en ny arbejdende agent oprettet. Når den anden applikation færdiggør sin transaktion, frigives dens arbejdende agent til den tilgængelige pulje.
I mellemtiden kan andre applikationer, der anmoder om den transaktion, der er knyttet til den første agents XID, tilknytte sig og fjerne tilknytningen fra denne agent, som udfører dedikerede XA-transaktioner for dem. Alle applikationer, der anmoder om denne bestemte transaktion, sendes til denne arbejdende agent, hvis den er ledig.
Den arbejdende agent frigives ikke tilbage til den generelle pulje, før en applikation har afsendt et transaktionsgrænsekald (not xa_end()). En applikation kan f.eks. afslutte transaktionen med xa_commit(), hvorefter den arbejdende agent sletter sin tilknytning til XID'en og vender tilbage til den tilgængelige pulje. På dette tidspunkt kan enhver applikation bruge agenten til enten en anden XA- eller en ikke-XA-transaktion.
Der er et antal væsentlige begrænsninger for brugen af gatewaykoncentratoren. Læs alle nedenstående oplysninger, før du forsøger at anvende forbindelseskoncentratoren på dit eget system.
Databasens performance på værts- eller AS/400-databaseserveren har indflydelse på systemets performance.
Forskellige databasesystemer har forskellige performancefunktioner. Forskellige systemers SQL-optimeringsprogram kan opføre sig forskelligt med samme applikation. Der er flere oplysninger om performance i dokumentationen til det anvendte værts- eller AS/400-databaseserversystem.
Du kan muligvis forbedre performance i DB2 Universal Database til AS/400 ved at bruge bindeparameteren UR (ubekræftet læsning) eller NC (ingen commit), så journalisering undgås.
Bemærk: | Når UR benyttes, kan ikke-journaliserede data kun læses, ikke opdateres, og kun hvis BLOCKING er sat til ALL. |
Afhængigt af applikationsserveren og de låseniveauer, den stiller til rådighed, kan det isolationsniveau, der vælges til en forespørgsel eller applikation, have en betragtelig indflydelse på performance.
For databasen gælder, at den skal have den relevante normaliseringsgrad, indekser skal anvendes effektivt, og der skal være tildelt passende plads til den. Også de anvendte datatyper kan have indflydelse på performance. Det beskrives i de næste afsnit.
TCP/IP-støtte kræver mindst OS/390 Version 1 Release 3. OS/390 Version 2 Release 5 eller en nyere version anbefales.
DDF (Distributed Data Facility) er det program, der forbinder distribuerede applikationer med DB2 til OS/390. DDF bør konfigureres som en applikationsserver. Det kan du gøre ved at indsætte det eksterne systems LU-navn i tabellen SYSIBM.LUNAMES eller indsætte værdierne LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT og USERNAMES i tabellen SYSIBM.SYSLUNAME. Derefter skal du udføre en DDF-opdatering af BSDS (Boot Strap Data Set). Eksempel:
DDF LOCATION=LOC1,LUNAME=LU1,PORT=8000,RESPORT=8001
Du opnår den bedste performance ved at anvende den anbefalede prioritering af DDF-adresselagerområder (lidt under eller lig med DBM1, hvis du er i tilstanden COMPAT). Brug RACF-cache til autorisationer i VLF, og brug cache af version 5-pakkeautorisationer, hvis det er muligt. Værdien CACHEPAC=32768 er tilstrækkelig til de fleste funktioner.
DDF forsøger at oprette forbindelse med VTAM, og derfor skal VTAM være aktiv, når DDF starter. Nedenfor vises et eksempel på en VTAM APPL-definition:
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
Du kan optimere behandlingen af ikke-aktive programdele (threads) i OS/390. I Version 3 kan du anvende op til 10.000 samtidigt forbundne klienter og op til 25.000 i Version 4 og 5. I alle tilfælde kan maksimalt 1999 programdele være aktive samtidigt. Hver arbejdsstationsklient kan blive ved med at være forbundet, selv om den ikke er aktiv, idet den tilhørende programdel placeres på en ikke-aktiv kæde ved hver udførelse af commit.
DSNZPARM-parametrene CMTSTAT, CONDBAT og MAXDBAT har indflydelse på behandlingen af programdele. Du opnår den bedste performance ved at sætte CMTSTAT til INACTIVE, indstille CONDBAT til det maksimale antal forbundne DBAT-værdier, der giver optimal performance, og angive det højest mulige antal aktive DBAT-værdier for MAXDBAT.
Der er flere oplysninger om oprettelse af forbindelse for DB2 til OS/390 i et DRDA-netværk, herunder VTAM-konfiguration, i Connectivity Supplement.
Når data overføres fra ét miljø til et andet, kan det være nødvendigt at konvertere dem. Konverteringen kan påvirke performance.
Hvis vi betragter følgende platforme:
og følgende numeriske datatyper:
I Tabel 8 vises, hvornår der sker konvertering.
|
Intel |
IEEE |
S/370 og S/390 |
OS/400 |
---|---|---|---|---|
Pakkede tal | ||||
Intel IEEE S/370/390 OS/400 |
Nej Nej Nej Nej |
Nej Nej Nej Nej |
Nej Nej Nej Nej |
Nej Nej Nej Nej |
Zonede tal | ||||
Intel IEEE S/370/390 OS/400 |
Nej Nej Ja Ja |
Nej Nej Ja Ja |
Ja Ja Nej Nej |
Ja Ja Nej Nej |
Heltal | ||||
Intel IEEE S/370/390 OS/400 |
Nej Ja Ja Ja |
Ja Nej Nej Nej |
Ja Nej Nej Nej |
Ja Nej Nej Nej |
Tal med flydende decimaltegn | ||||
Intel IEEE S/370/390 OS/400 |
Nej Ja Ja Ja |
Ja Nej Ja Nej |
Ja Ja Nej Ja |
Ja Nej Ja Nej |
CPU-forbruget til konvertering af enkeltbytetegn af typen Character er normalt mindre, end når numeriske data skal konverteres.
Forbruget til konvertering af data af typen DATE/TIME/TIMESTAMP er næsten det samme som til enkeltbytedata af typen Character. Konvertering af tal med flydende decimaltegn har det største forbrug. Applikationsdesigneren kan udnytte disse kendsgerninger i designet af en applikation, der benytter DB2 Connect.
Hvis en databasetabel har en kolonne, der er defineret som 'FOR BIT DATA', kræves ingen konvertering af data af typen Character, der overføres mellem applikationen og databasen. Det kan bruges, når data arkiveres på værts- eller AS/400-databaseserveren.
Data af typen Character kan have datatypen CHAR eller VARCHAR. Hvilken datatype der er den mest effektive, afhænger af den typiske længde på data i feltet:
Den bedste måde at forbedre den samlede performance i et distribueret databasemiljø er at udelukke forsinkelser fra netværket. Netværksadministratorer tror ofte, at netværket fungerer mest effektivt, hvis der opsamles så mange data som muligt mellem transmissionerne. Denne fremgangsmåde gælder ikke for applikationer som f.eks. distribuerede databaser, fordi den opbygger forsinkelser på netværket. Slutbrugeren ser ikke netværkets effektivitet, kun forsinkelserne.
De fleste netværksenheder har DELAY-parametre, og de fleste af dem har standardværdier, som giver meget dårlige resultater for distribuerede databaser. Hvis du vil forbedre performance, skal du finde disse parametre og sætte dem til 0, hvis det er muligt. Desuden bør du sikre dig, at enhedens bufferstørrelse er stor nok, så du ikke risikerer, at data skal overføres igen, fordi der er gået data tabt. På UNIX-systemer er f. eks. standardkøstørrelsen til afsendelse (Transmit) eller modtagelse (Receive) typisk på 32. Angiv køstørrelsen til 150 for at få bedre resultater. Den tilsvarende parameter under DLC-indstillingerne er værdien for modtagelse (Receive Depth), som også skal sættes til 150.
IOBUF-parameteren er sat for lavt i mange installationer. Oftest er den sat til 500, men erfaringen har vist, at en værdi på 3992 virker bedst, hvis du flytter store mængder data - især til kanalforbindelser, f.eks. ESCON eller 3172.
SNA-forbindelser: Sæt MODE-profilen for alle arbejdsstationsprogrammer til 63. Generelt skal der angives maksimale værdier for modtagehastighed (Receive Pacing) i hele netværket. Derfor skal parametrene VPACING og PACING i DB2 APPL-sætningen og arbejdsstationens PU/LU som "switched major mode" også angives til 63. Dermed øges mængden af meddelelser tilsvarende, inden afsenderen bliver nødt til at vente på svar.
På et LAN-system kan størrelsen på DLC eller LLC Transmit Window eller Receive Window have afgørende betydning for performance. SEND-værdien bør sættes til 7 eller derover, og en RECEIVE-værdi på 4 eller derunder fungerer bedst for de fleste konfigurationer.
Hvis du kører Ethernet, bør du sætte TCP-segmentstørrelsen til 1500 byte. I et Token Ring- eller FDDI-netværk bør denne værdi sættes til 4400 byte, og hvis du bruger en ESCON-adapter med TCP/IP, skal segmentstørrelsen altid være 4096.
I TCP/IP-netværk skal TCP-bufferstørrelsen for SEND og RECEIVE sættes til over 32768. En værdi på 65536 er ofte bedst.
Bemærk: | Det tager længere tid at oprette en forbindelse fra gatewayen til serveren
(udgående forbindelse) end at etablere forbindelse mellem en klient og
gatewayen (indgående forbindelse). I et miljø, hvor tusindvis af
klienter ofte opretter forbindelse til og afbryder forbindelsen med serveren
via gatewayen, bruges meget behandlingstid på at oprette udgående
forbindelser. DB2 Connect indeholder en funktion til samling af
forbindelserne via TCP/IP i en pulje (Connection Pooling). Når en
klient anmoder om, at forbindelsen til serveren bliver afbrudt, afbryder
gatewayen den indgående forbindelse fra klienten, men bevarer den udgående
forbindelse til serveren i en pulje. Når en ny klient kommer til
gatewayen og anmoder om en forbindelse, stiller gatewayen en eksisterende
forbindelse fra puljen til rådighed, hvorved den samlede forbindelsestid
reduceres, og der spares på det store CPU-tidsforbrug på serveren.
Der er flere oplysninger om puljeforbindelser under DB2 i Administration Guide. |
Metoderne til tuning af netværksperformance opsummeres i nedenstående tabel.
Læg specielt mærke til | Eksempel | Indstilling | Bemærkninger |
---|---|---|---|
Forsætlige forsinkelser | DELAY-parametre på netværksenheder | Angiv til 0. | Standardværdier er ofte højere. |
Buffere | IOBUF-parameteren | Angiv op til 3992. | Specielt nyttig i forbindelse med ESCON eller andre kanaladaptere. |
RUSIZE | 4096 er den optimale værdi. | Angiv samme værdi for RUSIZE og RQRIOBLK for at opnå den bedste performance. | |
Pacing | VPACING, PACING og MODE-profiler skal angives til 63. | Brug tilpasset (adaptive) pacing, hvor det er muligt. | |
Adapter-indstillinger | Køstørrelse for Transmit/Receive | Den anbefalede værdi er 150. | Standardværdien er ofte 32. |
DLC Windows i SNA | Angiv høj værdi (>7) for størrelsen på Transmit Window. Angiv lav værdi (f.eks. 1) for størrelsen på Receive Window. Prøv dig frem for at finde den optimale værdi. | For hver logisk enhed tilføjes en forsinkelse. Brug en så enkel netværkstopologi som muligt. | |
TCP-indstillinger | Segmentstørrelser | 1500 på Ethernet, 4400 på Token Ring og FDDI. | ESCON-adaptere, der bruges til TCP/IP, bør altid sættes til 4096. |
Lagerområdestørrelse for Send/Receive | Bør være 64 KB for begge dele. | Standardværdien er kun 8192 for Windows. Kan angives i Windows-registreringsdatabasen. |
For hardware gælder følgende aspekter:
Jo hurtigere transmissionsmedium, des bedre performance. Nedenfor vises eksempler på typiske overførselshastigheder for rå data:
Dataoverførselshastigheden begrænses af det langsomste transmissionsmedium på ruten til værts- eller AS/400-databaseserveren.
Hukommelsesforbruget for netværksadapteren og kommunikationskontrolenheden bør planlægges nøje. I samarbejde med en netværksspecialist bør det sikres, at kontrolenheden har kapacitet til at håndtere den ekstra trafik, der genereres af DB2 Connect.
Netværkstiden skal tages i betragtning, hvis data overføres fra LAN til LAN eller fra ét SNA-netværk til et andet SNA-netværk. Netværksbroer, routere og gateways øger tidsforbruget. Hvis data f.eks. skal krydse færre netværksbroer, reduceres det nødvendige antal hop for hver forespørgsel.
Den fysiske afstand mellem noder skal også tages i betragtning. Selv om en meddelelse overføres via satellit, begrænses overførselstiden af lysets hastighed (3 * 10**8 msek.) og turen frem og tilbage mellem afsender og modtager.
Hvis netværkets kapacitet er fuldt udnyttet, vil både svartid og dataoverførselshastighed blive mindre for en enkelt applikation.
Der kan opstå overbelastning af netværket, hvis data ophobes et bestemt sted i netværket, f.eks. ved en gammel NCP med en meget lille bufferstørrelse.
Hvis fejlraten på netværket er høj, reduceres netværkets effekt, og performance bliver dårligere, fordi dataoverførsler skal gentages.
Performance kan blive dårligere, hvis mange opgaver i systemet konkurrerer om systemressourcer. Tænk over følgende spørgsmål:
Hvis DB2 Connect-brugere oplever lange svartider ved store forespørgsler til værts- eller AS/400-servere, bør følgende områder undersøges for at finde den mulige årsag til performanceproblemet:
db2 update database manager configuration using RQRIOBLK 32767