Alkalmazás létrehozásakor a teljesítményt számos módon növelheti, például:
A hálózati torlódás azon alkalmazások esetében lehet jelentős, amelyek sok parancsot küldenek és sok választ fogadnak. Az összetett SQL és a tárolt eljárások használata két különböző mód ennek a hatásnak a csökkentésére.
Ha az alkalmazás számos SQL utasítást küld programozási beavatkozás nélkül, használhatja az összetett SQL-t. Ha programozási beavatkozás szükséges az SQL utasítások csoportjain belül, akkor tárolt eljárások használhatók.
Összetett SQL utasítás bármely végrehajtható utasítást tartalmazhatja, kivéve az alábbiakat:
CALL FETCH CLOSE OPEN Compound SQL Connect Prepare Release Describe Rollback Disconnect Set connection execute immediate
További információért lásd: SQL Reference!
Az összetett SQL-ek alkalmazásban való használatával kapcsolatban lásd: NOT ATOMIC összetett SQL! Az összetett SQL-ek beviteli segédprogramban való használatával kapcsolatban lásd: Behozatali és kiviteli segédprogramok használata!
A tárolt eljárások segítik csökkenteni a hálózati forgalmat azáltal, hogy a program logikáját a kiszolgálóra helyezi. A 5.0-ás verzió előtti DB2-ben a tárolt eljárások csak kimenő paramétereket adhattak vissza, és külön commit parancsot kellett kiadnia az alkalmazásnak. Emiatt két hálózati üzenetváltásra volt szükség. A 5.0-ás és későbbi verziójú DB2-ben önműködően is véglegesíthet, amikor kilép az eljárásból. Eredményhalmazokat is visszaadhat, ami minimalizálhatja az ügyfélprogramban lévő logikát.
A tárolt eljárások használatával kapcsolatban lásd: Tárolt eljárások.
Az egymáshoz kapcsolódó adatbáziskérelmek (SQL utasítások) egy adatbáziskérelembe kombinálása csökkenti a hálózaton átvitt kérelmek és válaszok számát. Például a következő utasítások:
SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=1 SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=2
az alábbi módon kombinálhatók eggyé:
SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=1 OR ROW_ID=2
Ebben az esetben kevesebb kérelemnek kell a hálózaton átmennie.
Az IN és BETWEEN kulcsszavak használatával csökkenthető a visszaadott sorok száma. Továbbá használhatja a WHERE, IN és BETWEEN kulcsszavakat az UPDATE és DELETE utasítással is.
Célszerű csak a tényleg szükséges sorokat és oszlopokat lekérdezni. Így csökkenthető az adatátvitel miatti hálózati forgalom és CPU terhelés.
Például ne használja az alábbi lekérdezést:
SELECT * FROM TABLEA
ha csak a TABLEA tábla ROW_ID=1 értékű első sorára, vagy például csak az 1. és 2. oszlopra van szüksége.
Az adatblokkolást akkor célszerű használni, ha nagyobb mennyiségű adat érkezése várható a kiszolgálótól. A blokkolás javítja a hálózati sávszélesség kihasználását és csökkenti mind a gazdagép vagy AS/400 adatbázis-kiszolgáló, mind a DB2 Connect munkaállomás CPU terhelését.
Minden elküldött üzenetnek mérettől független, fix CPU- és hálózatterhelése van. Az adatblokkolás csökkenti az ugyanazon adatmennyiség átviteléhez szükséges üzenetek számát.
Blokkolás esetén az alkalmazás nem kapja meg a lekérdezés első sorát, amíg az első blokk meg nem érkezett. A blokkolás növeli az első sor betöltési idejét, viszont csökkenti a további sorokét.
A másik szempont a szükséges memória mennyisége. A blokkolás bekapcsolt állapotában általában nagyobb mennyiségű memóriára van szükség. Az SNA összeköttetés esetén alkalmazható blokkolás teljes leírását lásd: DRDA Connectivity Guide!
A DB2 Connectben beállítható az egyes blokkokban átvitt adatmennyiség, a következő helyen leírtaknak megfelelően: RQRIOBLK.
A blokk-kezelés bekapcsolásához használja a prep vagy bind parancs BLOCKING paraméterét. (További információtért lásd: A BIND parancs.) A blokk-kezelés be van kapcsolva, ha:
A csak olvasható, a frissíthető és a többértelmű kurzor meghatározását az alábbi helyen találja: Application Development Guide.
Megjegyzés: | Dinamikus SQL használata esetén a kurzor mindig többértelmű. |
A frissíthető SELECT utasítások (az UPDATE/DELETE WHERE CURRENT OF utasítások használatával) nem blokk-kezelésű lekérdezések, ezért csak akkor használja őket, ha ez tényleg elkerülhetetlen!
Frissíthető SELECT esetén biztos, hogy a sor nem változott meg a SELECT végrehajtása és az UPDATE/DELETE kiadása között. Ha az egyidejűségnek ez a szintje nem érdekes az alkalmazás szempontjából, akkor másik megoldásként használhatja a DELETE vagy UPDATE utasítást egy nem frissíthető SELECT által visszaadott értékeken alapuló keresési feltétellel.
Csak olvasható SELECT eléréséhez adja meg: FOR FETCH ONLY (kivéve VM és VSE alatt, ahol ez nem támogatott).
Amikor csak lehetséges, használjon statikus SQL-t! Így elkerülheti a futásidejű SQL szakaszelőkészítést és a többértelmű kurzorokat. Ha a dinamikus SQL használata nem kerülhető el, a következőket teheti a hálózati forgalom csökkentése és a teljesítmény növelése érdekében:
Ha a lefoglalt SQLDA nem elég nagy a visszaadott SQLDA tárolására, a programnak újabb DESCRIBE utasítást kell kiadnia, az eredmény tárolásához elegendően nagy SQLDA megadásával. Ez növeli a hálózati forgalmat.
Ne használja a PREPARE és DESCRIBE utasításpárt! A PREPARE.....INTO utasítás jobb teljesítményt nyújt.
A Parancsfeldolgozó használata általában lassabb a dinamikus SQL-nél, mivel a Parancsfeldolgozónak elemeznie kell a bevitt utasítást, mielőtt elküldi az SQL-t az adatbázis alrendszernek. A Parancsfeldolgozó emellett formázza is az adatokat, amire lehet, hogy az adott alkalmazásnak nincs is szüksége.
Az SQL utasítások lényegesen lassabban hajtódnak végre interpretált nyelvben (pl. REXX), mint fordítóval rendelkező nyelvben (pl. C).
A CONNECT utasításnak két fajtája van: 1. típus és 2. típus. 2. típusú kapcsolatnál az adatbázishoz kapcsolódás az előző kapcsolatot rejtett állapotba helyezi, de nem szünteti meg. Ha később egy rejtett kapcsolatra vált át, nem kell újra betölteni a katalógusokat, és újból felépíteni a belső adatszerkezeteket. Emiatt a 2. típus használata több adatbázist használó alkalmazások esetén javíthatja a teljesítményt. A 2. típusú kapcsolatokról bővebben lásd: Administration Guide és SQL Reference.