Ta strona korzysta z plików cookie, abyśmy mogli zapewnić jak najlepszą obsługę. Informacje o plikach cookie są przechowywane w przeglądarce i wykonują takie funkcje, jak rozpoznawanie cię po powrocie do naszej witryny i pomaganie naszemu zespołowi w zrozumieniu, które sekcje witryny są dla Ciebie najbardziej interesujące i przydatne.
Optymalizacja programów ABAP
Aktualnie zarządzanie firmą wiąże się z poznaniem wielu nowych rozwiązań technologicznych. Pociąga to za sobą ciągłe kształcenie pracowników i naukę metod stosowania tych rozwiązań. Większość technologii wiąże się z pojęciem optymalizacji, która jest działaniem mającym zagwarantować znalezienie, bądź wyznaczenie najlepszego rozwiązania według kryteriów firmy. Dzięki prawidłowym działaniom związanym z optymalizacją, firma podnosi jakość swoich produktów i usług, zmniejsza koszty, a także zwiększa wydajność zarówno pracowników, jak i fabryk. Optymalizacja jest też ważnym elementem systemów SAP, które wiele zyskują poprzez prawidłowe jej zastosowanie.
# optymalizacja raportów SAP
Optymalizacja jest działaniem mającym na celu poprawę wydajności programu. Przede wszystkim polega na zmianie istniejącego już fragmentu kodu, na taki który pozwoli na szybsze działanie systemu, a także zagwarantuje mniejsze zużycie pamięci. Każda z tych zmian pozwala na bardziej korzystne zarządzanie firmą. Podczas pisania programów możliwe jest przygotowanie rozwiązań bardziej lub mniej optymalnych. Mimo, że większość zasad programowania jest uniwersalna dla wszystkich języków, przedstawiamy te szczególnie istotne dla języka ABAP. Zastosowanie poniższych podpowiedzi gwarantuje sprawniejszą pracę systemów, a co za tym idzie pracowników, którzy na tych systemach pracują.
# komunikacja z bazą danych
Podczas tworzenia raportu powinniśmy mieć na uwadze, że program nie jest jedynym, który aktualnie korzysta z bazy danych. Z tego powodu ilość wywołanych poleceń na bazie powinna być ograniczona do niezbędnego minimum. Pomocnym jest fakt, że polecenia te mają wbudowaną opcję, która umożliwia nam wysłanie większej ilości zmian jednocześnie. Dzięki temu nie będziemy zajmować bazy wielokrotnie dla każdej zmiany, a tylko jednorazowo dla wszystkich zmian. Operacjami tymi są: INSERT, UPDATE, MODIFY oraz DELETE.
INSERT umożliwia umieszczanie danych w tabelach.
UPDATE pozwala na modyfikację istniejących danych.
MODIFY działa jak INSERT jeśli dany rekord nie istnieje lub jako UPDATE jeśli istnieje.
DELETE usuwa dane z tabel.
DELETE posiada dodatkowo możliwość usuwania rekordów dla podanych warunków, co pozwala nam na sprawniejsze działania.
W wyborze odpowiednich danych pomaga program Optimizer.
# SELECT – dobre praktyki
Korzystając z polecenia SELECT powinniśmy mieć na uwadze fakt, że baza danych ma swoje ograniczenia i nie powinno się korzystać z niej częściej niż jest to konieczne. Dotyczy to również pobierania danych. Z tego powodu, jeśli wiemy że będą nam potrzebne tylko konkretne rekordy, powinniśmy określić warunki, na podstawie których zostaną one wybrane. Aby to zrobić korzystamy ze słowa kluczowego WHERE. Klauzula WHERE nie może korzystać z negacji i powinna być przedstawiona w najprostszej postaci, aby wykorzystane zostały odpowiednie indeksy. Pozwoli to na możliwe szybkie wyszukiwanie danych. Co więcej w instrukcji SELECT możemy również ograniczyć ilość kolumn, które wczytamy, jeśli wiemy że nie wszystkie będą nam przydatne. Nie należy także zagnieżdżać w sobie polecenia SELECT i pętli, jeżeli nie jest to konieczne do poprawnego działania raportu. Potrafi to znacznie obciążyć zarówno bazę danych, jak i same programy. Zamiast zagnieżdżania w sobie instrukcji SELECT zdecydowanie optymalniejszym rozwiązaniem będzie użycie polecenia JOIN do pobrania danych z kilku tabel jednocześnie, skorzystanie z SELECT FOR ALL ENTRIES albo utworzenie widoku w bazie danych.
SQL jest językiem służącym do komunikacji z bazą danych.
Optimizer jest programem, który obserwuje wykonywane polecenie i na jego podstawie tworzy plan wykonania polecenia SQL.
W przypadku instrukcji SELECT bardzo ważna jest klauzula WHERE. Powinna ona być możliwie prosto sformułowana i nie powinna zawierać w sobie instrukcji NOT. Taka budowa umożliwi wybranie odpowiednich indeksów i szybsze działanie polecenia. Optimizer sprawdza również ilość rekordów w tabelach, fizyczny rozmiar danych, rozmiar pól w indeksach, aby przeanalizowane dane mógł wziąć pod uwagę podczas tworzenia planu wykonywania poleceń SQL.
# tabele
Podczas pracy z tabelami transparentnymi mamy do wyboru kilka metod optymalizacyjnych. Jedną z nich są indeksy.
Indeks jest to osobna tabela w bazie danych, która zawiera tylko niektóre pola z oryginalnej tabeli, a także odniesienia do odpowiednich rekordów.
Istnieją dwa rodzaje indeksów: primary index oraz secondary index. Primary index jest indeksem podstawowy, tworzonym automatycznie, zawierającym tylko pola klucza danej tabeli. Secondary index jest tworzony przez programistę i to on określa, jakie pola ma w sobie zawierać. Podczas wyszukiwania danych w tabeli, interfejs bazodanowy postara się dopasować indeks do kryteriów wyszukiwania, co znacznie przyspieszy jego pracę.
Interfejs bazodanowy program komunikujący się z bazą danych.
Przeglądane będą tylko te wiersze, które określone zostały w indeksie, a więc przetworzona zostanie mniejsza liczba danych.
# buforowanie
Podczas tworzenia tabel mamy także możliwość ustalenia tabeli jako buforowanej.
Buforowanie polega na pobraniu tabeli i umieszczenie jej w pamięci podręcznej. Dzięki temu jej dane są zawsze pod ręką, bez konieczności łączenia się z bazą danych po raz kolejny.
Możemy wybrać jedną z trzech opcji: buforowanie pojedynczych rekordów, buforowanie obszaru ogólnego i buforowanie całkowite. Buforowanie całkowite polega na pobraniu do bufora całej tabeli jednocześnie. Buforowanie obszaru ogólnego i pojedynczych rekordów wpisuje do bufora tylko te rekordy, do których odbywał się już dostęp. Dodatkowo buforowanie obszaru ogólnego dodaje do bufora te rekordy, których klucz częściowo zgadza się z kluczem rekordu, który został już pobrany. Niestety buforowanie ma swoje wady. Przykładowo, jeśli mamy tabelę z danymi, które często się zmieniają lub musimy być absolutnie pewni że nasze dane są aktualne (przykładowo prowadzimy sklep internetowy) to może przytrafić się sytuacja, gdy w buforze dane będą inne niż w tabeli bazodanowej. Prowadzić to może do błędów systemu, takich jak próba sprzedaży produktów, których już nie posiadamy. Z tego powodu powinniśmy buforować tylko tabele, których dane rzadko się zmieniają.
Konkretne przykłady optymalnych i nieoptymalnych poleceń, zapytań, a nawet algorytmów można zobaczyć i przetestować w programie SAP Logon w transakcji SAT po przejściu do „Tips & Tricks” lub kliknięciu F6.