Wanneer u een toepassing maakt, kunt u de performance op verschillende manieren verbeteren:
Netwerkoverhead kan van belang zijn voor toepassingen die veel opdrachten en antwoorden verzenden en ontvangen. Samengestelde SQL-instructies en opgeslagen procedures zijn manieren voor het verminderen van deze overhead.
Als een toepassing verschillende SQL-instructies verzendt zonder tussenkomst van programmeringslogica kunt u gebruikmaken van samengestelde SQL. Als u programmeringslogica wilt opnemen in de groep SQL-instructies, kunt u gebruikmaken van opgeslagen procedures.
Alle uitvoerbare instructies kunnen in een samengestelde SQL-instructie voorkomen, met uitzondering van:
CALL FETCH CLOSE OPEN Compound SQL Connect Prepare Release Describe Rollback Disconnect Set connection execute immediate
Raadpleeg de SQL Reference voor meer informatie.
Zie Samengestelde SQL-instructie NOT ATOMIC voor informatie over het gebruik van samengestelde SQL-instructies in een toepassing. Zie Hulpprogramma's voor import en export voor informatie over het gebruik van samengestelde SQL-instructies met het importhulpprogramma.
Opgeslagen procedures zorgen voor vermindering van netwerkverkeer door programmeringslogica op de server te plaatsen. In DB2-versies ouder dan versie 5.0 kon een opgeslagen procedure slechts uitvoerparameters terugzenden en moest er door de toepassing een afzonderlijke COMMIT-opdracht worden opgegeven. Dit leidde tot twee netwerktrips. In DB2 versies 5.0 en hoger kunt u automatisch de wijzigen vastleggen wanneer u de procedure afsluit. Ook kunnen er resultaatsets worden teruggezonden die de toepassingslogica op de client reduceren.
Zie Opgeslagen procedures voor informatie over het gebruik van opgeslagen procedures.
Het groeperen van gerelateerde databaseopdrachten (SQL-instructies) tot één databaseopdracht kan de hoeveelheid over het netwerk verzonden opdrachten en respons verminderen. Door bijvoorbeeld de volgende instructies te groeperen:
SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=1 SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=2
in
SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=1 OR ROW_ID=2
worden minder opdrachten over het netwerk verzonden.
U kunt ook sleutelwoorden zoals IN en BETWEEN gebruiken om het aantal teruggezonden rijen te verminderen. Daarnaast kunt u gebruikmaken van de sleutelwoorden WHERE, IN en BETWEEN in UPDATE- en DELETE-instructies.
Predikatenlogica kan worden gebruikt om uitsluitend de vereiste rijen en kolommen op te vragen. Dit verkleint het netwerkverkeer en de CPU-overhead voor datatransmissie.
Maak bijvoorbeeld geen gebruik van de volgende query:
SELECT * FROM TABLEA
als u alleen de eerste rij van TABLEA met ROW_ID=1 echt nodig hebt of alleen kolom 1 en 2.
Maak gebruik van gegevensmarkering wanneer u grote hoeveelheden gegevens van de server verwacht. Door markering verbetert het gebruik van de bandbreedte van het netwerk en vermindert de CPU-overhead van de host of de AS/400-databaseserver en het DB2 Connect-werkstation.
Voor elk bericht dat wordt verzonden of ontvangen wordt een vaste hoeveelheid CPU en netwerkoverhead toegekend, ongeacht de omvang ervan. Gegevensmarkering vermindert het aantal berichten dat is vereist voor dezelfde hoeveelheid gegevensoverdracht.
Door het markeren van gegevens wordt de eerste rij van een query pas aan de toepassing geleverd als de eerste markering is ontvangen. Markeren zorgt ervoor dat een ophaalbewerking voor de eerste rij langer duurt, maar verkort de tijd voor de volgende rijen.
Een andere overweging is de hoeveelheid gebruikt geheugen. Over het algemeen wordt het configuratiepakket voor geheugen vergroot wanneer markeren wordt ingeschakeld. Raadpleeg de DRDA Connectivity Guide voor een uitgebreide beschrijving van markeren met gebruik van SNA-verbindingen.
In DB2 Connect kunt u de hoeveelheid gegevens besturen die binnen elke markering wordt overgebracht, zoals beschreven in RQRIOBLK.
Gebruik de optie BLOCKING van de opdracht prep of bind als u gegevensmarkering wilt instellen. (Zie De opdracht BIND voor meer informatie.) Markeren is ingeschakeld als:
Raadpleeg de Application Development Guide voor definities van alleen-lezen, de mogelijkheid tot bijwerken en de ambigue cursor.
Opmerking: | Wanneer dynamische SQL-instructies worden gebruikt, is de cursor altijd ambigu. |
SELECT-instructies die kunnen worden bijgewerkt (met gebruik van de instructies UPDATE/DELETE WHERE CURRENT OF) zijn query's waarvoor geen markeringen kunnen worden gebruikt. Gebruik ze dus alleen wanneer dat absoluut noodzakelijk is.
Met een SELECT-opdracht die kan worden bijgewerkt, kan de rij niet zijn veranderd tussen het moment waarop SELECT is voltooid en UPDATE/DELETE wordt opgegeven. Wanneer dit niveau van gelijktijdig gebruik voor uw toepassing niet belangrijk is, kan DELETE of UPDATE worden gebruikt met zoekcriteria die zijn gebaseerd op de waarden die worden teruggezonden vanaf een SELECT-opdracht die niet kan worden bijgewerkt.
Geef voor alleen-lezen SELECT-opdrachten FOR FETCH ONLY op (met uitzondering van VM- en VSE-systemen die hiervoor geen ondersteuning bieden).
Maak zoveel mogelijk gebruik van statische SQL-instructies. Hiermee voorkomt u runtime voorbereiding van SQL-secties en ambigue cursors. Als dynamische SQL-instructies niet kunnen worden vermeden, kan op de volgende manier het netwerkverkeer worden verminderd en de performance worden verbeterd:
Als de SQLDA-toewijzing onvoldoende is voor de opslag van teruggezonden SQLDA, moet door het programma een andere DESCRIBE-instructie worden opgegeven. Hierin moet de SQLDA groot genoeg zijn om het resultaat op te slaan. Hierdoor wordt het netwerkverkeer vergroot.
Maak geen gebruik van de reeks PREPARE en DESCRIBE. Door de instructie PREPARE.....INTO te gebruiken, wordt de performance verbeterd.
Het gebruik van de Opdrachtregelinterface werkt in het algemeen langzamer dan het gebruik van dynamische SQL-instructies in het programma. Dit komt doordat de Opdrachtregelinterface de invoer moet ontleden voordat de SQL aan het databaseprogramma wordt doorgegeven. Wanneer er gegevens worden ontvangen, deelt de Opdrachtregelinterface deze ook in. Dit hoeft voor uw toepassing niet noodzakelijk te zijn.
SQL-instructies in een geïnterpreteerde taal (zoals REXX) zijn aanzienlijk langzamer dan dezelfde SQL-instructies in een gecompileerde taal (zoals C).
Er bestaan twee typen CONNECT-instructies die type 1 en type 2 worden genoemd. Bij type 2 wordt bij verbinding met een database de vorige verbinding in een inactieve status gebracht maar niet verwijderd. Als u later naar een inactieve verbinding overschakelt, vermijdt u de overhead van het laden van bibliotheken en het instellen van interne gegevensstructuren. Hierdoor kan het gebruik van type 2 de performance verbeteren voor toepassingen die toegang hebben tot meer dan een database. Raadpleeg de Administration Guide en de SQL Reference voor meer informatie over verbindingen van type 2.