Podczas tworzenia aplikacji można poprawić wydajność na wiele sposobów, na przykład przez:
Dla aplikacji, które wysyłają i otrzymują wiele komend i odpowiedzi, znaczący może być nakład pracy sieci. Można go zredukować przy użyciu złożonego języka SQL i procedur zapisanych w bazie.
Jeśli aplikacja wysyła wiele instrukcji języka SQL, które nie są ze sobą logicznie powiązane, można używać złożonego języka SQL. Jeśli wewnątrz grupy mają być użyte instrukcje powiązane logicznie, można skorzystać z procedur zapisanych w bazie.
Wewnątrz złożonego języka SQL można używać wszystkich instrukcji wykonywalnych, poza następującymi:
CALL FETCH CLOSE OPEN Compound SQL Connect Prepare Release Describe Rollback Disconnect Set connection execute immediate
Więcej informacji na ten temat można znaleźć w podręczniku SQL Reference.
Informacje na temat używania złożonego języka SQL w aplikacji zawiera sekcja Złożona instrukcja SQL NOT ATOMIC. Informacje na temat używania złożonego języka SQL z modułem importującym można znaleźć w sekcji Korzystanie z modułów importujących i eksportujących.
Procedury zapisane w bazie ograniczają przepływ danych w sieci przez umieszczenie oprogramowania na serwerze. W wersjach wcześniejszych niż DB2 wersja 5.0, procedury zapisane w bazie mogły zwracać tylko parametry wyjściowe i aplikacja musiała wydawać oddzielną komendę zatwierdzania. Powodowało to dwukrotne przesyłanie danych w sieci. W DB2 wersja 5.0 i wersjach nowszych zatwierdzanie może być wykonywane automatycznie podczas wychodzenia z procedury. Można również zwracać tabele wynikowe minimalizujące oprogramowanie aplikacji po stronie klienta.
Informacje na temat używania procedur zapisanych w bazie można znaleźć w sekcji Procedury zapisane w bazie.
Grupowanie żądań związanych z bazą danych (instrukcje języka SQL) w jedno żądanie może zredukować liczbę żądań i odpowiedzi przesyłanych przez sieć. Na przykład zgrupowanie następujących instrukcji:
SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=1 SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=2
w
SELECT COL1, COL2, COL5, COL6 FROM TABLEA WHERE ROW_ID=1 OR ROW_ID=2
spowoduje wysłanie mniejszej ilości żądań przez sieć.
Aby zredukować liczbę zwracanych wierszy, można także używać parametrów, na przykład IN i BETWEEN. Ponadto w instrukcjach UPDATE i DELETE można używać parametrów WHERE, IN i BETWEEN.
Predykatu logicznego można używać w celu zażądania wyłącznie potrzebnych wierszy i kolumn. Zminimalizuje to ruch w sieci oraz nakład pracy jednostki centralnej związanej z przesyłaniem danych.
Na przykład nie należy używać zapytania:
SELECT * FROM TABLEA
jeśli jest potrzebny tylko pierwszy wiersz tabeli TABLEA z ROW_ID=1 albo tylko kolumny 1 i 2.
Łączenia danych w bloki należy używać w przypadku większej ilości danych z serwera. Łączenie danych w bloki poprawia wykorzystanie przepustowości sieci i redukuje ilość informacji sterujących jednostki centralnej serwera baz danych hosta lub AS/400 i stacji roboczej DB2 Connect.
Bez względu na wielkość komunikatu, ilość informacji sterujących CPU i sieci dla każdego wysłanego i otrzymanego komunikatu jest stała. Łączenie danych w bloki redukuje liczbę komunikatów wymaganych dla tej samej wielkości przesyłanych danych.
Jeśli łączenie w bloki jest używane, pierwszy wiersz danych z zapytania nie będzie dostarczony do aplikacji, dopóki pierwszy blok nie zostanie odebrany. Łączenie w bloki zwiększa czas wyszukiwania dla pierwszego wiersza, ale zmniejsza czas wyszukiwania dla kolejnych wierszy.
Inne rozważania dotyczą wielkości używanej pamięci. Wykorzystywana pamięć wzrasta, jeśli zostaje włączone łączenie w bloki. Wyczerpujące informacje dotyczące łączenia w bloki w czasie używania połączeń SNA można znaleźć w podręczniku DRDA Connectivity Guide.
Wewnątrz DB2 Connect można sterować wielkością danych przesyłanych wewnątrz każdego bloku. Zostało to opisane w sekcji RQRIOBLK.
Aby wywołać łączenie w bloki, należy użyć opcji BLOCKING w komendzie prep lub bind. (Więcej informacji można znaleźć w sekcji Komenda BIND). Łączenie w bloki jest włączone, jeśli:
Więcej informacji na temat definicji kursora tylko do odczytu, aktualizującego i niejednoznacznego można znaleźć w podręczniku Application Development Guide.
Uwaga: | Kursor jest zawsze niejednoznaczny, jeśli używany jest dynamiczny SQL. |
Aktualizujące instrukcje SELECT (używające instrukcji UPDATE/DELETE WHERE CURRENT OF) są zapytaniami nie łączącymi danych w bloki, tak że można ich używać tylko wtedy, gdy jest to bezwzględnie konieczne.
Aktualizująca instrukcja SELECT zapewnia, że między momentem zakończenia instrukcji SELECT i wywołania instrukcji UPDATE/DELETE wiersz nie zostanie zmieniony. Jeśli dla danej aplikacji nie jest ważny poziom współbieżności, alternatywnym rozwiązaniem jest zastosowanie instrukcji DELETE lub UPDATE z kryterium wyszukiwania opartym na wartościach zwracanych z nieaktualizującej instrukcji SELECT.
Dla instrukcji SELECT tylko do odczytu należy podać FOR FETCH ONLY (z wyjątkiem systemów VM i VSE, które nie obsługują takiej opcji).
Należy używać statycznego SQL tak często, jak to możliwe. Uniknie się w ten sposób przygotowania sekcji SQL czasu przetwarzania i niejednoznacznych kursorów. Jeśli nie można uniknąć stosowania dynamicznego SQL, w celu zminimalizowania ruchu w sieci i poprawy wydajności można wykonać następujące czynności:
Jeśli przydzielony obszar danych SQL nie jest dostatecznie duży do przechowywania zwracanego obszaru danych SQL, program musi ponownie wywołać instrukcję DESCRIBE z dostatecznie dużym obszarem danych SQL do ponownego przechowywania wyniku. Zwiększy to ruch w sieci.
Nie należy używać wyrażeń PREPARE i DESCRIBE. Użycie instrukcji PREPARE.....INTO zapewni lepszą wydajność.
Użycie Procesora wiersza komend jest najczęściej wolniejsze niż użycie dynamicznego języka SQL, ponieważ Procesor wiersza komend musi przed wprowadzeniem SQL do motoru bazy danych wykonać analizę składniową danych wejściowych. Procesor wiersza komend formatuje również napotkane dane, które nie muszą być konieczne dla danej aplikacji .
Instrukcje SQL w języku zawierającym interpreter (na przykład REXX) są znacznie wolniejsze niż te same instrukcje SQL w języku z kompilatorem (na przykład C).
Są dwa typy instrukcji CONNECT, typ 1 i typ 2. Przy użyciu połączenia typu 2, połączenie z bazą danych wprowadza poprzednie połączenie w stan uśpienia lecz go nie usuwa. Jeśli przełączenie do uśpionego połączenia nastąpi później, uniknie się ładowania bibliotek i ustawiania struktur danych wewnętrznych. Z tego powodu użycie połączenia typu 2 może poprawić wydajność aplikacji, które mają dostęp do więcej niż jednej bazy danych. Więcej informacji na temat połączeń typu 2 można znaleźć w podręcznikach Administration Guide i SQL Reference.