Når du utvikler en applikasjon, kan du forbedre ytelsen på flere måter, for eksempel:
For applikasjoner som sender og mottar mange kommandoer og svar, kan nettverksbelastningen bli stor. Denne belastningen kan reduseres ved hjelp av sammensatt SQL og lagrede prosedyrer.
Hvis en applikasjon sender flere SQL-setninger uten å gripe inn i programmeringslogikken, kan du bruke sammensatt SQL. Hvis du må benytte programmeringslogikk i gruppen av SQL-setninger, kan du bruke lagrede prosedyrer.
Du kan bruke alle utførbare setninger unntatt disse i en sammensatt SQL-setning:
CALL FETCH CLOSE OPEN Compound SQL Connect Prepare Release Describe Rollback Disconnect Set connection execute immediate
Du finner flere opplysninger i SQL Reference.
Hvis du vil vite hvordan du bruker sammensatt SQL i en applikasjon, leser du Ikke-enhetlig sammensatt SQL. Hvis du vil vite hvordan du bruker sammensatt SQL sammen med importfunksjonen, leser du Bruke import- og eksportfunksjoner.
Lagrede prosedyrer hjelper deg å redusere nettverkstrafikken ved å legge programlogikk på tjeneren. I DB2 før versjon 5.0 kunne en lagret prosedyre bare returnere utdataparametere, og applikasjonen måtte utstede en separat iverksettingskommando. Dette krevde to nettverksturer. I DB2 versjon 5.0 og nyere kan du automatisk iverksette kommandoen når du avslutter prosedyren. Du kan også returnere resultatsett, som minimerer applikasjonslogikk på klienten.
Hvis du ønsker flere opplysninger om hvordan du bruker lagrede prosedyrer, leser du Lagrede prosedyrer.
Ved å gruppere relaterte databaseforespørsler (SQL-setninger) i en databaseforespørsel kan du redusere antall forespørsler og svar som blir overført i nettverket. Du kan for eksempel gruppere disse setningene:
SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=1 SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=2
til
SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=1 OR ROW_ID=2
som sender færre forespørsler over nettverket.
Du kan også bruke nøkkelord, for eksempel IN og BETWEEN, for å redusere antall rader som blir returnert. Du kan også bruke nøkkelordene WHERE, IN og BETWEEN i UPDATE- og DELETE-setninger.
Du kan bruke predikatlogikk for å be om bare de radene og kolonnene du behøver. Dette minimerer nettverkstrafikken og CPU-behandlingen ved dataoverføringer.
Du bør for eksempel ikke bruke spørringen
SELECT * FROM TABLEA
hvis du bare behøver den første raden i TABLEA med ROW_ID=1, eller hvis du bare behøver kolonne 1 og 2.
Du bør bruke datablokking hvis du venter store mengder data fra tjeneren. Blokking forbedrer bruken av nettverksbåndbredden og reduserer CPU-behandlingen på både verts- eller AS/400-databasetjeneren og DB2 Connect-arbeidsstasjonen.
Det er en fast mengde CPU- og nettverksbehandling for hver melding som blir sendt og mottatt, uavhengig av størrelsen. Datablokking minimerer antall meldinger som er nødvendig for den samme mengden dataoverføringer.
Med blokking blir ikke den første dataraden fra en spørring levert til applikasjonen før den første blokken blir mottatt. Blokking øker hentetiden for den første raden, men forbedrer hentetiden for resten av radene.
En annen faktor er mengden minne som blir brukt. Arbeidsminnet øker vanligvis når blokking er slått på. Hvis du vil vite mer om bruk av blokking sammen med SNA-tilkoblinger, leser du DRDA Connectivity Guide.
I DB2 Connect kan du kontrollere hvor mye data som skal overføres i hver enkelt blokk, slik det er beskrevet i RQRIOBLK.
Hvis du vil starte blokking, bruker du BLOCKING-alternativet i prep- eller bind-kommandoen. (Du finner flere opplysninger i BIND-kommandoen.) Blokking er på hvis
Du finner definisjoner av skrivebeskyttede, oppdaterbare og tvetydige pekere i Application Development Guide.
Merk: | Når du bruker dynamisk SQL, er pekeren alltid tvetydig. |
Spørringer med oppdaterbare SELECT-setninger (med UPDATE/DELETE WHERE CURRENT OF-setninger) bruker ikke blokking, så du bør bare bruke dem når det er helt nødvendig.
En oppdaterbar SELECT-setning sikrer at radene ikke blir endret fra SELECT-setningen blir fullført til UPDATE/DELETE-setningen blir utført. Hvis dette nivået av samtidighet (concurrency) ikke er viktig for applikasjonen, kan du også bruke en DELETE- eller UPDATE-setning med søkekriterier på grunnlag av verdiene som ble returnert fra en ikke-oppdaterbar SELECT-setning.
Hvis SELECT-setningen bare gjelder lesing, oppgir du FOR FETCH ONLY (unntatt på VM og VSE, der det ikke er støttet).
Bruk statisk SQL så mye som mulig. Da unngår du klargjøring av en SQL-seksjon når SQL-setningene utføres, og tvetydige pekere. Hvis du ikke kan unngå dynamisk SQL, kan du gjøre følgende for å minimere nettverkstrafikken og forbedre ytelsen:
Hvis den tildelte SQLDA-verdien ikke er stor nok til å lagre den returnerte SQLDA-verdien, må programmet utstede en annen DESCRIBE-setning med en SQLDA-verdi som er stor nok til å lagre resultatet. Dette øker nettverkstrafikken.
Ikke bruk PREPARE- og DESCRIBE-sekvensen. Hvis du bruker setningen PREPARE.....INTO, får du bedre ytelse.
Generelt sett tar det lengre tid å bruke kommandolinjebehandleren enn å bruke dynamisk SQL i programmet siden kommandolinjebehandleren må analysere inndataene før den sender SQL-setningene til databasetjenestene. Kommandolinjebehandleren formaterer også dataene den mottar, noe som kanskje ikke er nødvendig for applikasjonen.
SQL-setninger i et tolket språk (for eksempel REXX) tar mye lengre tid enn de samme SQL-setningene i et kompilert språk (for eksempel C).
Det finnes to typer CONNECT-setninger, kalt type 1 og type 2. Hvis du kobler deg til en database med type 2 connect, får den forrige tilkoblingen hvilestatus, men den blir ikke slettet (drop). Hvis du senere bytter til en tilkobling i hvilestatus, behøver du ikke å laste inn biblioteker og konfigurere interne datastrukturer. Derfor kan det øke ytelsen å bruke type 2 connect for applikasjoner som bruker flere databaser. Du finner flere opplysninger om type 2 connect-setninger i Administration Guide og SQL Reference.