Narzędzia środowiska projektowego ABAP

Narzędzia środowiska projektowego ABAP

Klucz obcy Klucz obcy pole tabeli połączonej z inną tabelą relacją klucza obcego Zastosowanie kontrola poprawności wprowadzanych danych, łączenie tabel w perspektywie, łączenie tabel obiektu blokady Łączenie dwóch tabel T1 i T2 w relacji klucza obcego: Klucz obcy T1 Tabela klucza obcego (zależna) Pole 1 Pole 2 Pole 3 Pole 4 Pole 5 Klucz główny T2 Tabela kontrolna (referencyjna) Pole 6 Pole 7 Pole 8 Pola klucza obcego muszą mieć tę samą długość i być tego samego typu co odpowiadające im pola tabeli kontrolnej Klucz główny

Pole kontrolne i wartość kontrolna Ekran wprowadzania danych tabeli T1 Tabela kontrolna T2 Pole 1 Pole 2 Pole 3 Pole 4 Pole 5 2 4 Pole 6 Pole 7 Pole 8 1 1 Tekst 1 1 2 Tekst 2 2 1 Tekst 3 2 3 Tekst 4 2 4 Tekst 5 3 1 Tekst 6 3 2 Tekst 7 Jedno z pól klucza obcego musi być zaznaczone jako tzw. pole kontrolne (pole dla którego określona jest relacja klucza obcego) Po wprowadzeniu danych w polu kontrolnym, sprawdzane jest czy tabela kontrolna zawiera rekord o kluczu określonym wartościami z pól klucza głównego; jeśli tak wprowadzone dane są akceptowane jako poprawne, w przeciwnym przypadku są odrzucane Zasada działania: 1. Z definicji klucza obcego tworzona jest przez interfejs użytkownika instrukcja SELECT postaci: SELECT * FROM T2 WHERE T2-Pole6 = T1-Pole2 AND T2-Pole7=T1-Pole4. 2. Po wprowadzeniu danych w polu kontrolnym wykonywana jest ta instrukcja 3. Jeśli tabela kontrolna zawiera odpowiedni rekord (klucz zgodny z wprowadzonymi wartościami), to te wartości zostają zaakceptowane, w przeciwnym przypadku są odrzucane

Wymagania dotyczące klucza obcego Sprawdzanie klucza obcego powinno odbywać się względem pól klucza głównego tabeli kontrolnej Pole klucza obcego i odpowiadające mu pole klucza głównego w tabeli kontrolnej muszą być tej samej domeny (identyczny typ i rozmiar) a element danych w obydwu przypadkach może, ale nie musi być taki sam

Klucz obcy algorytm tworzenia Tworzenie tabeli kontrolnej: podać nazwę tabeli kontrolnej i wybrać tworzenie tabeli podać krótki opis, klasę A, zezwolić na opracowywanie danych tabeli dla pól tabeli podać ich nazwy i elementy danych zaznaczyć pola wchodzące w skład klucza głównego zapisać tabelę podać ustawienia techniczne tabeli (rodzaj danych APPL0, kategorię wielkości 0) zapisać i aktywować Tworzenie klucza obcego: podać nazwę tabeli zawierającej klucz obcy i wybrać tryb zmian tabeli ustaw kursor w polu należącym do klucza obcego i wybierz opcję klucza obcego podaj krótki opis klucza obcego podaj nazwę istniejącej tabeli kontrolnej system spróbuje automatycznie połączyć pola klucza obcego z polami klucza głównego tabeli kontrolnej skopiować i aktywować w definicji tabeli w odpowiedniej kolumnie w wierszu klucza obcego powinna pojawić się nazwa tabeli kontrolnej Testowanie relacji klucza obcego: otworzyć tabelę klucza obcego wprowadzić wartość nieistniejącą w tabeli kontrolnej jeśli pojawi się komunikat o błędzie, to relacja jest poprawnie zdefiniowana

Mechanizm automatycznego określania pól klucza obcego System generuje propozycję składającą się z par pól, gdzie jedno pole jest polem z tabeli kontrolnej a drugie z tabeli klucza obcego; liczba par jest równa liczbie pól klucza głównego tabeli kontrolnej (wszystkie pola klucza głównego tabeli kontrolnej muszą być ujęte w relacji klucza obcego): system przegląda pola klucza głównego tabeli kontrolnej w poszukiwaniu tego, który ma taką samą domenę jak pole klucza obcego i łączy te pola w parę jeśli klucz główny tabeli kontrolnej składa się z wielu pól, to system po kolei stara się sparować te pola z odpowiednimi polami klucza obcego na zasadzie porównywania domen jeśli się to nie powiedzie, to poszukiwanie są pola o tym samym typie i tej samej długości jeśli system znajdzie więcej niż jedno pasujące pole, to wybiera jedno z nich i ostrzega o niejednoznaczności dokonanego wyboru proces ten trwa dopóki wszystkie pola klucza głównego tabeli kontrolnej nie zostaną sparowane z polami tabeli klucza obcego

Związek klucza obcego z pomocą F4 System automatycznie wiąże pomoc F4 z polem klucza obcego Po naciśnięciu klawisza F4 lub pojawi się zawartość klucza głównego tabeli kontrolnej w formie listy, której nagłówki i szerokości kolumn określone są przez etykietę nagłówka z definicji elementu danych

Klucz obcy w przetwarzaniu wsadowym Przetwarzanie wsadowe modyfikujące zawartość bazy danych w sposób bezpośredni wymagają automatycznego sprawdzania danych, co można osiągnąć pisząc program na jeden z trzech sposobów: program powinien przekazywać dane przez interfejs użytkownika wywołując transakcje ekranowe, dane są automatycznie wpisywane w pola ekranowe i sprawdzany jest klucz obcy całość realizowana jest w tle, a technika ta nazywana jest BDC (Batch Data Communication) i jest standardową techniką importowania danych do systemu R/3 program może zawierać polecenie SELECT realizujące sprawdzenie klucza obcego (wadą tego podejścia jest konieczność modyfikacji programu w przypadku pojawienia się nowego lub zmiany obecnego klucza obcego) program może przekazywać dane do specjalnego modułu realizującego zarówno sprawdzanie klucza obcego, jak i modyfikacje bazy danych (tzw. BAPIs Business APIs)

Złożony klucz obcy Klucz obcy składający się z co najmniej dwóch pól Kombinacja wartości tych pól musi występować w tabeli kontrolnej zanim wartości te zostaną wprowadzone do tabeli klucza obcego Wywołanie sprawdzania złożonego klucza obcego związane jest z jednym polem tzw. polem kontrolnym, dla którego definiowany jest klucz obcy Aby sprawdzenie zostało wywołane pole kontrolne nie może być puste Gdy pole kontrolne jest puste sprawdzanie nie będzie wykonane (nawet wtedy, gdy pozostałe pola klucza obcego zostały wypełnione) Definiowanie złożonego klucza obcego przebiega prawie tak samo jak definiowanie jednopolowego klucza obcego Zgodność domen wymagana jest wyłącznie dla pola kontrolnego, dla pozostałych pól klucza obcego wystarczy zgodność typu i rozmiaru danych, jednak zaleca się stosowanie domen, ze względu na nieprzewidywalne zachowania w przypadku zmiany typu i/lub rozmiaru danych jednego pola klucza (w takim przypadku zaleca się dokonywanie jednoczesnych zmian w obydwu tabelach) Wszystkie pola klucza głównego tabeli kontrolnej muszą wchodzić w skład klucza obcego, jednak nie wszystkie muszą być sprawdzane W tabelach zależnych od mandanta pole mandt wchodzi w skład klucza obcego i umożliwia definiowanie różnych warunków sprawdzania dla różnych mandantów Pomoc F4 jest związana tylko z polem kontrolnym

Liczność relacji klucza obcego Znaczenie: dopuszczalna liczba rekordów w tabeli klucza obcego odpowiadająca wartości klucza głównego (określana w fazie definiowania klucza obcego) na zasadzie stosunku (n:m), gdzie: n = 1 dla każdego rekordu tabeli klucza obcego tylko jeden rekord tabeli kontrolnej (usunięcie rekordu z tabeli kontrolnej wymusza usunięcie odpowiedniego rekordu tabeli klucza obcego) n = C tabela klucza obcego może zawierać wpisy nie mające swojego odpowiednika w tabeli kontrolnej ze względu na to, że niektóre pola klucza obcego są puste (np. gdy są opcjonalne) m = 1 każdemu rekordowi tabeli kontrolnej odpowiada dokładnie jeden rekord tabeli klucza obcego m = C każdemu rekordowi tabeli kontrolnej odpowiada co najwyżej jeden rekord tabeli klucza obcego m = N każdemu rekordowi tabeli kontrolnej odpowiada co najmniej jeden rekord tabeli klucza obcego m = C każdemu rekordowi tabeli kontrolnej może odpowiadać dowolna liczba rekordów tabeli klucza obcego Określenie wartości liczności nie jest obligatoryjne, nie wymusza też na systemie sprawdzania dopuszczalności modyfikacji zawartości tabel Liczność sprawdzana jest tyko w przypadku tworzenia zagregowanych (tj. składających się z więcej niż jednej tabeli) obiektów słownikowych (np. perspektyw) brak zdefiniowanej wartości liczności uniemożliwia tworzenie obiektów zagregowanych

Typy pól klucza obcego No key fields/candidates pola klucza obcego nie są polami klucza głównego tabeli zależnej, ani nawet nie kandydują do tego miana (nie identyfikują jednoznacznie rekordu) Key fields/candidates pola klucza obcego są jednocześnie polami klucza głównego tabeli zależnej (albo co najmniej kandydują do tego miana) Key fields of a text table dotyczy tabel tekstowych, a jedyną różnicą w stosunku do key fields/candidates jest to, że klucz obcy zawiera dodatkowe pole odpowiadające wersji językowej

Tabele tekstowe a pomoc F4 Typ klucza obcego key fields of a text table wskazuje, że tabela klucza obcego jest tabelą tekstową Właściwości klucza obcego typu key fields of a text table : na liście pomocy F4 pojawia się pierwsza kolumna opisowa wraz z polami klucza głównego tej tabeli na liście pomocy F4 pojawiają się tylko te rekordy, które mają ten sam język, co język logowania Przykład: spras faculty facultyfullname E FCM Faculty of Computing Science and Management L FCM Wydział Informatyki i Zarządzania E FEE Faculty of Electrical Engineering L FEE Wydział Elektryczny

Ogólne i stałe klucze obce Wszystkie pola klucza głównego tabeli kontrolnej muszą się znaleźć w kluczu obcym; chyba, że klucz obcy jest kluczem ogólnym lub kluczem stałym Ogólny klucz obcy: jest typem klucza obcego, w którym co najmniej jedno pole klucza głównego tabeli kontrolnej zostało zaznaczone jako ogólne (*) pole ogólne klucza głównego tabeli kontrolnej nie ma swojego odpowiednika w tabeli klucza obcego stosowany jest w sytuacjach, gdy niemożliwe jest podanie dokładnej zawartości wszystkich pól klucza głównego tabeli kontrolnej (np. wtedy gdy jednym z pól składowych jest numer wersji) pole takie jest eliminowane z porównania. Stały klucz obcy: jest złożonym kluczem obcym, gdzie co najmniej jedno pole zastąpiono ustaloną wartością stałą wartość stała wprowadzana jest na etapie tworzenia klucza obcego przykład jeżeli potrzebna będzie lista kierunków studiów na określonym wydziale, to nazwa tego wydziału może być w tym przypadku potraktowana jako stała (wchodzi w skład klucza, ale zawsze będzie to ta sama wartość)

Adaptowany klucz obcy Złożony klucz obcy którego pola znajdują się w różnych tabelach Przykład: Tabele klucza obcego Tabela kontrolna ZPABTAB003 Pole 1 Pole 2 Pole 3 Tabela ZPABTAB004 Pole 1 Pole 3 Tabela ZPABTAB004 Pole 2

Tabele wartości Zwane także domyślnymi tabelami kontrolnymi Tabela, której nazwa pojawia się w definicji domeny Właściwości: jest automatycznie proponowana jako tabela kontrolna podczas tworzenia klucza obcego zawiera listę wartości dla pomocy F4, ale nie dostarcza mechanizmów walidacji Cel: ułatwienie i przyspieszenie prac związanych z tworzeniem klucza obcego

Definicja tabeli kolumna check table Zawartość i znaczenie: nazwa tabeli kontrolnej - dla pola które jest kluczem obcym gwiazdka (*) gdy dla pola nie zdefiniowano tabeli kontrolnej, ale w definicji tabeli występuje tabela wartości

Specjalne pola tabeli Dwa typy pól, które wymagają specjalnego potraktowania: pola monetarne pola ilościowe Pole monetarne: pole wartości monetarnej typu CURR referencyjne (powiązane z nim) pole waluty typu CUKY Pole ilościowe: pole ilościowe typu QUAN referencyjne pole jednostki miar typu UNIT

Struktury w ABAP Dictionary Struktura kolekcja pól zgrupowana pod wspólną nazwą Struktura a tabela: podobieństwa: układ pól deklaracja TABLES definiująca obszar roboczy konwencje nazewnicze (nie mogą istnieć tabele i struktury o takiej samej nazwie) różnice: ze strukturą nie jest związana tabela bazy danych struktura nie posiada klucza głównego struktura nie ma ustawień technicznych Zastosowanie: gdy potrzeba zdefiniować ten sam obszar roboczy dla kilku programów (np. odczytujących i zapisujących dane do pliku) Definiowanie struktury jest podobne do definiowania tabeli z następującymi różnicami: wybór opcji Struktura zamiast opcji Tabela nie występują informacje na temat klasy dostaw i zarządzania tabelą nie ma możliwości określenia klucza głównego nie ma możliwości określenia ustawień technicznych

Zagnieżdżenia struktur Struktury można zagnieżdżać w innych strukturach oraz tabelach Przykład: adres (miasto, nr kodu, ulica, nr domu itd.) może być zdefiniowany jako struktura, która następnie może być użyta przy definiowaniu adresu zameldowania lub adresu korespondencyjnego w pewnej tabeli Podczas aktywacji tabeli pola struktury są dołączane do tabeli z tą samą nazwą z jaką występują w strukturze Aby dołączyć strukturę do tabeli (lub innej struktury) należy jako nazwę pola podać.include a jako element danych nazwę struktury Możliwe jest wyświetlenie definicji tabeli z rozwiniętą strukturą (Extras Substructures ) Łańcuch include: łańcuch utworzony przez kolejne zagnieżdżenia struktur w tabelach i strukturach maksymalna liczba zagnieżdżeń: 9 maksymalna liczba tabel w łańcuchu include: 1

Wielokrotne zagnieżdżanie struktur Ta sama struktura może być zagnieżdżana wielokrotnie w jednej tabeli Zamiast.INCLUDE jako nazwę pola należy wprowadzić.inclu-xxx, gdzie xxx są dowolnymi trzema znakami Przy rozwijaniu struktury pola tabeli określone tą strukturą otrzymają sufiks xxx, co będzie je jednoznacznie identyfikować Na przykład adres zameldowania można włączyć przez.inclu-zam a adres korespondencyjny przez.inclu-kor

Indeksy Każda tabela posiada indeks główny zbudowany na kluczu głównym tej tabeli Indeks zawiera wskaźnik do wiersza tabeli (numer wiersza przydzielany wewnętrznie przez bazę danych w sposób niewidoczny dla użytkownika) Jeżeli w klauzuli WHERE instrukcji SELECT występuje indeksowane pole, to system w wyszukiwaniu odpowiedniego rekordu korzysta z indeksu Indeks wtórny ułatwia wyszukiwanie danych w tabeli Można zdefiniować wiele indeksów wtórnych dla jednej tabeli Zalecane jest stosowanie indeksów zawsze, gdy stosowana jest klauzula WHERE instrukcji SELECT Jeżeli w klauzuli WHERE występuje wiele pól i nie istnieje indeks składający się z tych wszystkich pól to optymizator wybiera najbliższy indeks i przeszukuje tylko pewien zakres wierszy tabeli

Wyświetlanie indeksów Każdy indeks w systemie R/3 ma unikalny 1-, 2- lub 3-cyfrowy identyfikator indeks główny ma zawsze identyfikator 0 indeksy wtórne mogą mieć dowolny alfanumeryczny identyfikator Wyświetlanie indeksu: wyświetlić tabelę wybrać opcję indexes lista indeksów wtórnych pojawi się w okienku dialogowym wybrać nazwę indeksu Indeks może składać się z więcej niż jednego pola Gdy istnieje więcej niż jeden indeks RDBMS korzysta z optymizatora do wyboru jednego z nich: optymizator analizuje nazwy pól klauzuli WHERE instrukcji SELECT a następnie szuka indeksów, które maja takie same nazwy pól w tym samym porządku, w jakim występują w klauzuli WHERE Uwaga! Aby optymizator wybrał odpowiedni indeks istotna jest kolejność pól w klauzuli WHERE

Indeksy w tabelach zależnych od mandanta Jeśli tabela jest zależna od mandanta (pierwszo pole MANDT), to również indeks powinien zawierać to pole. Inaczej optymizator może nie wybrać tego indeksu. Jeżeli w OpenSQL-u używana jest cecha automatycznej obsługi mandanta to: przykłądowa instrukcja SELECT * FROM ZPABTAB06 WHERE faculty= FCM podczas wykonywania jest przekładana na SELECT * FROM ZPABTAB06 WHERE mandt=sy-mandt and faculty= FCM Tworzenie indeksu w tabeli zależnej od mandanta wymaga włączenia pola MANDT do indeksu, jako pierwszego pola

Selektywność a efektywność indeksu Jeśli klauzula WHERE zawiera więcej pól niż indeks, to: system używa indeksu by zawęzić obszar wyszukiwania, zatem indeks jest tylko częściowo efektywny jeśli kombinacja wartości pól klucza jest bardzo specyficzna i daje w wyniku niewiele rekordów to indeks jest selektywny, w przeciwnym przypadku indeks nie jest za bardzo selektywny w przypadku indeksu selektywnego nie ma potrzeby dodawania dodatkowych pól do indeksu (koszty zarządzania indeksem przy update tabeli, są zbyt duże w porównaniu z kosztami przeszukania kilku rekordów w przypadku indeksu niezbyt selektywnego liczba wynikowych rekordów może być zbyt duża by opłacalne było przeszukiwanie tych rekordów, w takim przypadku dodanie pola do indeksu może przyspieszyć wyszukiwanie i zredukować konsumpcję zasobów pamięciowych Podczas tworzenia nowego lub modyfikacji istniejącego indeksu należy uważać, by nie dodawać do niego pól, które już są wykorzystywane w innym indeksie może to doprowadzić do zmiany indeksu wybieranego przez optymizatora, a w konsekwencji i w efekcie pogorszenia efektywności istniejących programów

Reguły tworzenia indeksów Należy unikać dodawania niepotrzebnych indeksów należy się zastanowić, czy nie można czegoś zakodować używając istniejących indeksów Należy unikać nakładania się indeksów występowania tych samych pól w więcej niż jednym indeksie Należy dążyć do tworzenia bardzo selektywnych indeksów, ale unikać dodawania do indeksu pól, które tylko nieznacznie poprawiają selektywność Maksymalna liczba indeksów wtórnych dla jednej tabeli: 15

Procedura tworzenia indeksu wtórnego 1. Wyświetlić tabelę 2. Wybrać opcję Indexes (jeśli jakieś indeksy wtórne już zdefiniowano to pojawi się tu ich lista) 3. Wybrać opcję Create 4. Podać identyfikator indeksu (musi zaczynać się na Z lub Y) 5. Podać krótki opis 6. Podać nazwy pól tworzących indeks w porządku określającym kolejność sortowania 7. Jeśli wymagana jest niepowtarzalność zawartości tych pól należy zaznaczyć odpowiednią opcję (Uwaga! System nie pozwoli dodać innego rekordu o takich samych wartościach pól indeksu) 8. Zapisać i aktywować (następuje utworzenie indeksu w BD)

Usuwanie indeksu Indeks można usunąć opcja menu Uwaga! operacja usuwania indeksu jest nieodwracalna tj. Cancel nie jest w stanie anulować tej operacji

Określanie indeksu użytego w SELECT 1. Utworzyć prosty i poprawnie działający program zawierający wyłącznie instrukcję SELECT 2. Otworzyć program w Edytorze ABAP-a 3. W odrębnej sesji uruchomić SQL Trace (opcja menu lub transakcja ST05), jeśli jest włączony to wyłączyć (chyba, że ktoś jeszcze na nim działa - blokada) 4. Włączyć SQL Trace i o ile zachodzi taka potrzeba to podać swój identyfikator 5. W pierwszej sesji uruchomić (F8) wyświetlany w Edytorze ABAP-a program 6. Po wykonaniu programu (gdy gaśnie klepsydra) wrócić do drugiej sesji 7. Wyłączyć SQL Trace 8. Wylistować Trace a 9. Wprowadzić %sc w polu komend 10. Wprowadzić nazwę tabeli z SELECT-a 11. Wybrać z listy nazwę tabeli 12. Wybrać opcję Explain SQL 13. Odnaleźć nazwę użytego indeksu

Ustawienia techniczne tabeli Opcja menu Pola: klasa danych (wiąże tabelę z odpowiednim tablespacem): APPL0 tabela zawiera dane podstawowe, zawartość tabeli nie jest często aktualizowana a sama tabela rośnie stosunkowo wolno (małe tabela) APPL1 dane transakcyjne, tabela aktualizowana w miarę często i rosnąca dosyć szybko APPL2 dane konfiguracyjne, dane niezmienne USER tymczasowa klasa nadawana automatycznie przez system kategoria wielkości: określa maksymalną liczbę rekordów jakie będą przechowywane w tej tabeli ustawia się ekstensję początkową, następne ekstensje i maksymalną ich liczbę ekstensja rozmiar przestrzeni dyskowej przydzielony tabeli dopuszczalne wartości 0 do 4 jednak ostateczna liczba rekordów w każdej kategorii zależy od rozmiaru pojedynczego wektora zaleca się raczej przewymiarować kategorię wielkości niż ją niedowymiarować (większa liczba ekstensji zmniejsza wydajność i wymaga czasochłonnej reorganizacji przestrzeni tabel w przypadku, gdy chce się daną tabelę usunąć łatwiej jest zmienić kategorię na niższą)

Wyświetlanie liczby ekstensji dla danej tabeli 1. db02 2. detailed analysis 3. w polu Tables wprowadzić nazwę tabeli 4. wybrać nazwę tabeli 5. zaznaczyć opcję Extents 6. OK

Buforowanie tabeli Program ABAP/4 wykonywany w procesie roboczym Serwer aplikacji Proces roboczy SELECT * FROM TAB1 Bufory Serwer bazy danych Dane mogą być buforowane w RAM serwera aplikacji Algorytm dostępu do danych buforowanych: 1. Proces roboczy sprawdza czy dane znajdują się w buforze. Jeśli nie to: 2. Pobiera je z bazy danych i 3. Zapisuje do bufora (o ile ustawiono odpowiedni atrybut tabeli) 4. Kolejne odczyty danych będą następowały z bufora Baza danych

Właściwości buforowania tabel Wpływa na poprawę wydajności programy szybciej się wykonują (brak oczekiwania na odpowiedź bazy danych, brak czasu traconego na transmisję danych z serwera BD) inne programy korzystające z dostępu do BD działają szybciej (mniejsze obciążenie serwera BD, mniejszy ruch w sieci) Przyspieszenie instrukcji SELECT ok. 10-100 razy Nie da się zbuforować wszystkich danych (choć wydaje się logiczne ograniczone jest rozmiarem pamięci RAM serwera aplikacji) Przepełnienie bufora grozi zrzucaniem danych do pliku wymiany, co może zniwelować wszelkie korzyści wydajnościowe Tabele o kluczu głównym typu numerycznego (CURR, DEC, FLTP, INT1, INT2, INT4, PREC, QUAN) nie mogą być buforowane Transakcja ST02 służy do wyświetlania zawartości i statystyk użycia buforów

Synchronizacja buforów Operacja niezbędna, gdy instalacja systemu R/3 wykonana jest na kilku serwerach aplikacji Operacja wykonywana w cyklu 1-4 minutowym (zależnie od ustawień parametru konfiguracyjnego rdisp/bufreftime) polegająca na przekazaniu informacji o zmianie buforowanego rekordu do wszystkich serwerów aplikacji (jeżeli na którymś z nich zbuforowany był ten sam rekord to należy go uaktualnić) Na każdym serwerze aplikacji działa odpowiedni proces synchronizacyjny a na serwerze bazy danych istnieje log synchronizacji. W predefiniowanych cyklach każdy proces synchronizacyjny sprawdza zawartość logu synchronizacji, aby upewnić się, czy którakolwiek z danych przechowywanych w buforze serwera nie uległa zmianie. Jeśli tak, to zmodyfikowane dane zostają zaznaczone w buforze jako nieprawidłowe i przy następnej próbie odczytu muszą być pobrane bezpośrednio z bazy danych

Schemat synchronizacji buforów Użytkownik 1 Użytkownik 2 Serwer aplikacji 1 Rekord 1 * Proces synchronizacyjny Serwer aplikacji 2 Rekord 1 * Proces synchronizacyjny Serwer bazy danych Rekord 1 * Log synchronizacji Rekord 1

Wyświetlanie parametru rdisp/bufreftime Transakcja RZ10 Wyświetlanie aktywnych serwerów aplikacji (GotoProfile ValuesOf A Server) Wyświetlanie listy parametrów z profilu serwera aplikacji (wybrać nazwę serwera aplikacji) Wyszukiwanie parametrów dotyczących buforów (wzorzec rdisp/buf) Wyświetlanie ustawień parametru rdisp/bufreftime (wybrać nazwę parametru z listy)

Modyfikacja buforowanych danych przykład Użytkownik 1 Użytkownik 2 Serwer aplikacji 1 A1 X B1 C1 Serwer aplikacji 2 A1 B1 YC1 Serwer bazy danych Pole 1 Pole 2 Pole 3 X A1 B1 C1 Y D2 B2 E2

Modyfikacja buforowanych danych reguły Przed modyfikacją danych z tabeli BD należy upewnić się, że modyfikuje się bieżącą zawartość tego rekordu Przy odczycie danych w celu ich modyfikacji, zaleca się w instrukcji SELECT stosować klauzulę BYPASSING BUFFER, która ze względu na konieczność odczytu danych z tabeli nieco spowalnia operację modyfikacji) W przypadku, gdy używany jest tylko jeden serwer aplikacji nie ma potrzeby stosowania klauzuli BYPASSING BUFFER Jeśli zawartość tabeli jest często modyfikowana nie należy stosować buforowania danych (proces synchronizacji w takich przypadkach powoduje znaczny wzrost obciążenia) Klasyfikacja według wydajności podejść: buforowanie tabeli, SELECT bez BYPASSING BUFFER, zapewnienie używania tylko jednego serwera aplikacji buforowanie tabeli, SELECT z klauzulą BYPASSING BUFFER bez buforowania tabeli

Techniki buforowania W ustawieniach technicznych tabeli można zmienić sposób buforowania (w przypadku tabeli systemowej konieczne jest podanie odpowiedniego klucza deweloperskiego, w pozostałych przypadkach sposób buforowania można określić na etapie tworzenia tabeli lub zmienić go później) Możliwe ustawienia: buforowanie niedopuszczalne buforowanie dopuszczalne ale wyłączone buforowanie włączone Buforowanie niedopuszczalne stosowane, gdy dane nigdy nie powinny być buforowane: użytkownik potrzebuje 100% pewności, że pobrane dane są aktualne (systemy czasu rzeczywistego, stany magazynowe itp.) każdy odczyt danych jest związany z ich modyfikacją (buforowanie jest wówczas nieefektywne i niewskazane) Uwaga! Tego sposobu buforowania nie można zmienić. Buforowanie włączone gdy akceptowalne są niewielkie (1-4 minutowe) opóźnienia aktualności buforowanych danych (nie występujące przy stosowaniu klauzuli BYPASSING BUFFER) Buforowanie dopuszczalne ale wyłączone podobnie jak przy buforowaniu włączonym, gdy jeszcze nie wiadomo, czy buforowanie może przynieść korzyści

Typy buforowania Określane w ustawieniach technicznych tabeli Typy: buforowanie pełne buforowanie ogólne buforowanie pojedynczego-rekordu Typ buforowania określa, który z dwóch buforów serwera aplikacji będzie używany: TABL ogólny TABLP pojedynczego-rekordu

Buforowanie pełne właściwości system sprawdza w TABL, czy są nim zbuforowane rekordy tabeli, do której odwołuje się instrukcja SELECT jeśli nie, to wszystkie rekordy tabeli ładowane są do bufora TABL, nawet wtedy, gdy żaden z rekordów nie spełnia warunku SELECT SINGLE nie powoduje załadowania tabeli do bufora, natomiast może odczytywać dane z bufora (o ile tabela została do niego uprzednio załadowana) synchronizacja zaznacza całą zbuforowaną tabelę jako nieprawidłową zawsze, gdy zmieniono jakikolwiek z jej rekordów (następny odczyt spowoduje przeładowanie całej tabeli w buforze) buforowanie całej tabeli może być korzystne, nawet gdy SELECT dość często nie znajduje żadnego rekordu odpowiednie dla małych tabel, które nie zmieniają się często, tabele kontrolne i ich tabele tekstowe

Buforowanie ogólne - właściwości W buforze TABL zamiast całej tabeli przechowywana jest tylko część rekordów Liczba kopiowanych do bufora rekordów zależy od parametru liczbowego podawanego przy określaniu tego typu buforowania, parametr ten oznacza liczbę branych pod uwagę pól klucza głównego (np. wartość 2 oznacza, że do bufora trafią te rekordy bazy danych, dla których dwa pierwsze pola klucza są takie same jak dwa pierwsze pola klucza w odczytanym rekordzie) Odpowiednie dla tabel, których rekordy są przetwarzane w grupach (np. tabele tekstowe, wartość parametru 2 pierwsze pola klucza to numer mandanta i język logowania) Niestety zarządzanie poszczególnymi grupami wymaga pewnych dodatkowych nakładów czasowych, dlatego zaleca się stosowanie grup o względnie dużej liczbie rekordów Synchronizacja jeżeli zmieniony został jakikolwiek rekord z buforowanej grupy, to zostaje ona w całości zaznaczona jako nieprawidłowa i zostaje przeładowana przy następnej próbie odczytania jakiegokolwiek rekordu z tej grupy

Buforowanie pojedynczego rekordu właściwości Pojedynczy rekord buforowany jest w TABLP Tylko wykonanie instrukcji SELECT SINGLE powoduje wpisanie rekordu do bufora Wykonanie SELECT SINGLE wiąże się ze sprawdzeniem zawartości bufora TABLP; jeśli nie znaleziono tam rekordu, to sprawdzana jest tabela BD; jeśli i tam nie znaleziono rekordu, to mimo wszystko wykonuje się wpis do bufora TABLP, by przy następnej próbie odczytu tego samego rekordu nie był konieczny dostęp do BD Odpowiednie dla dużych tabel, w których tylko nieliczne rekordy są odczytywane często

Typy buforów podsumowanie Dwa typy buforów: TABL ogólny TABLP pojedynczego rekordu Dwa typy instrukcji SELECT zwykły SELECT SELECT SINGLE Zapis: TABL tylko SELECT TABLP tylko SELECT SINGLE Odczyt TABL SELECT i SELECT SINGLE TABLP tylko SELECT SINGLE Rekord może znajdować się tylko w jednym buforze (ponieważ tabela może mieć tylko jeden typ buforowania) Zawartość obydwu buforów można wyczyścić komendą /$tab; jest to przydatne, gdy chce się np. zbadać wpływ buforowania na wydajność systemu, ale uwaga taka operacja może spowolnić pracę całego systemu na okres do kilku godzin, aż zawartość buforów się nie odnowi

Wymiana danych w przepełnionym buforze TABLP: usuwany jest najstarszy rekord, tj. taki, który najdłużej pozostawał w buforze bez żadnego dostępu TABL: rekordy nie są usuwane pojedynczo z bufora okresowo usuwane są całe tabele algorytm wyboru tabeli do usunięcia oraz odstępu czasowego między usuwaniem tabeli określany jest algorytmem buforowania systemu R/3 i zależy między innymi od: stosunkiem zajętości bufora przez tabelę do liczby odczytów rekordów tej tabeli w poprzednim okresie ilości wolnej przestrzeni w buforze aktualnej jakości dostępu do buforowanych danych

Buforować czy nie? Cel buforowania: poprawa efektywności odczytu danych i redukcja obciążenia ruchu w sieci Buforowanie tabel bez modyfikacji danych: częsty odczyt danych, rzadkie modyfikacje zalecane buforowanie postępowanie: zapytać administratora Basis o możliwość buforowania (czy jest miejsce w RAM serwera aplikacji) jeśli nie ma wystarczającej ilości RAM-u, to w zależności od możliwości albo przydzielenie buforowi dodatkowej pamięci albo zastąpienie innej tabeli o rzadszym dostępie Buforowanie danych a indeksy zbuforowane rekordy są niejawnie indeksowane w RAM (wg klucza głównego) klucze wtórne nie są używane w przypadku zbuforowanych danych, zatem w klauzuli WHERE należy na początku umieścić pierwsze pole klucza głównego a dalej tyle pozostałych pól tego klucza ile się da (inaczej nastąpi pełen przegląd zbuforowanej tabeli) buforowanie dużych tabel (kategorii 1 lub wyższych) przyspiesza wyszukiwanie rekordów wg klucza głównego, ale spowalnia wyszukiwanie wg klucza wtórnego, zaleca się więc wyszukiwanie wg klucza wtórnego wykonywać z klauzulą BYPASSING BUFFER jeżeli dokonuje się modyfikacji danych instrukcją SELECT z klauzulą BYPASSING BUFFER, to konsekwentnie należy stosować tę klauzulę we wszystkich próbach modyfikacji danych w tej zbuforowanej tabeli i tabelach z nią związanych w zakresie jednej transakcji (w przeciwnym przypadku może dojść do niespójności danych prze pomieszanie danych buforowanych i niebuforowanych

Buforowanie - podsumowanie Buforowanie tabel przyspiesza działanie programów, chociaż niewłaściwie zaprojektowane może przynieść przeciwny efekt Bufory mają ograniczoną pojemność (zależną od rozmiaru pamięci RAM serwera aplikacji) zatem należy unikać buforowania tabel, w których dane są rzadko odczytywane, aby zabezpieczyć się przed częstym przepełnianiem się bufora Tabele o małych rozmiarach (kategoria 0), o częstym dostępie i rzadko modyfikowanych danych powinny być w pełni buforowane Duże tabele (kategoria >0) o częstym dostępie do pojedynczych rekordów (SELECT SINGLE) powinny być buforowane w TABLP Tabele, w których rekordy są przetwarzane grupami, powinny być buforowane ogólnie, a grupa powinna być identyfikowana przez część klucza głównego Tabele, w których często dochodzi do modyfikacji danych nie powinny być w ogóle buforowane jeżeli w systemie jest więcej niż jeden serwer aplikacji Jeśli tabela jest buforowana to należy użyć klauzuli BYPASSING BUFFER aby otrzymać najnowszą (aktualną) wersję danych przed ich modyfikacją Jeśli tabela jest buforowana, to w klauzuli WHERE należy stosować pola klucza głównego, a jeśli nie jest to możliwe, to należy używać klauzuli BYPASSING BUFFER użyć w klauzuli WHER pól klucza wtórnego

Automatyczne rejestrowanie zmian Automatyczna historia tabeli: w ustawieniach technicznych zaznaczyć rejestrowanie zmiany danych w Basis ustawić parametr rec/client (numer mandanta zmiany, w którym mają być rejestrowane) każde utworzenie, modyfikacja bądź usunięcie danych z takiej tabeli będzie rejestrowane w postaci rekordu tabeli DBTABPRT zwanego dokumentem zmiany Dokument zmiany zawiera związane ze zmianą: datę i godzinę id użytkownika kod transakcji nazwę programu typ zmiany (INS,UPD,DEL) Wyświetlanie dokumentów zmiany: SCU3 lub OY18 (takie same) Opcje wyświetlania dokumentów zmiany: zmiany z bieżącego dnia zmiany z pewnego okresu wg kryterium użytkownika liczba dokumentów zmian w danym zakresie dat lub tabel lista tabel, dla których rejestrowane są zmiany całkowita liczba dokumentów zmian w tabeli DBTABPRT porównanie danych historycznych z dokumentu zmian z danymi aktualnymi Zastosowanie: tabele zawierające krytyczne dane (o kluczu nie dłuższym niż 86B i pozostałej części nie większej niż 500B Wada spowolnienie przetwarzania Obiekty dokumentów zmian

Ustawienia techniczne podsumowanie Klasa danych określa przynależność tabeli do odpowiedniego tablespace a właściwy wybór: łatwiejsze zarządzanie bazą danych poprawa wydajności systemu niewłaściwy: częste reorganizacje bazy w trybie offline ogólny spadek wydajności Kategoria wielkości określa rozmiar ekstensji początkowej i następnych niewłaściwy wybór: konieczność przydzielenia dodatkowych ekstensji ogólne obniżenie wydajności, trudniejsze zarządzanie bazą, mniejsza dostępność bazy (częste reorganizacje w trybie offline) Buforowanie właściwe: wzrost wydajności szczególnie w przypadku tabel z częstym odczytem i rzadkimi modyfikacjami Automatyczne rejestrowanie zmian tworzy dokumenty zmian spowolnia modyfikację danych w bazie zalecane tylko w przypadku tabel przechowujących krytyczne informacje

Wersje aktywne i poprawione W słowniku ABAP mogą istnieć dwie wersje tego samego obiektu: wersja aktywna wersja poprawiona Wersja aktywna tworzona podczas aktywacji używana przez programy ważna do momentu aktywacji wersji poprawionej Wersja poprawiona zapisana ale nie aktywowana niewidoczna dla programów po aktywacji staje się wersją aktywną wyświetlana domyślnie w środowisku projektowym ABAP

Narzędzie database utility Zastosowanie: testowanie i modyfikacje tabeli z poziomu bazy danych Uruchomienie: wyświetlanie lub edycja tabeli Utilities Database utility Działanie: sprawdzenie spójności definicji słownikowej z tabelą bazy danych wgląd do logu aktywacji wyświetlanie i modyfikacja parametrów przechowywania bazy danych usuwanie tabeli lub czyszczenie jej zawartości z poziomu bazy danych

Kontrola spójności Definicja tabeli w dwóch miejscach: słownik ABAP baza danych Extras Database object Check Porównywane są: aktywna wersja tabeli z tabelą bazy danych Niespójności powstają, gdy: zmieniono definicję tabeli na poziomie bazy danych (ręcznie lub programem ABAP-owym korzystającym z rdzennego SQL-a) baza danych została uszkodzona Przypadki stosowania: podczas testowania pojawia się nietypowy błąd SQL-a otrzymano nieprawidłowe wyniki z programu, który powinien działać poprawnie, ale z nieznanych przyczyn działa nieprawidłowo

Nametab Nametab obiekt wykonywalny tabeli tworzony podczas jej aktywacji Wyświetlanie: Extras Runtime object Display Zawiera wiele informacji o tabeli (m.in. typ tabeli, typ tabeli BD, liczba pól, rozmiar rekordu, liczba pól klucza, rozmiar klucza, typ buforowania, lista pól, ustawienia techniczne itp.) Rola nametab w programie: w programach korzystających z danych zgromadzonych w tabelach bazy danych instrukcja TABLES odpowiada za przekazanie informacji o strukturze tabeli do programu w przypadku obiektu wykonywalnego programu informacja o strukturze tabeli nie jest w nim umieszczana, ale w czasie wykonywania programu następuje odwołanie do nametab w celu określenia struktury tabeli nametab umożliwia uwzględnienie zmian w definicji tabeli lub struktury bez konieczności ponownego generowania wszystkich programów korzystających z tej tabeli (struktury), ponieważ zostanie ona dynamicznie uwzględniona w trakcie wykonywania programu przez wywołanie nametab Wyszukiwanie programów, w których wykorzystywana jest tabela opcja Lista miejsc użycia

Sprawdzanie spójności Nametab Nametab pobiera charakterystyki elementów danych i domen stosowanych w tabeli Zmiana jakiejś domeny (elementu danych) będzie widoczna dopiero po aktywacji, a z nią związana jest ponowna aktywacja wszystkich tabel, w których wykorzystywana jest ta domena (element danych) W takich przypadkach ponowna aktywacja tabel odbywa się automatycznie, ale może się nie powieść (np. ograniczenia bazy danych, baza danych zawiera dane, które po zmianie muszą być poddane konwersji) w efekcie powstaje niespójność pomiędzy obiektami Nametab a obiektami słownika ABAP Sprawdzanie spójności Nametab Extras Runtime object Check Niespójność pomiędzy Nametab a domeną (elementem danych) jest o tyle groźna, że na ogół jest niezauważalna, a może produkować nieprawidłowe wyniki

Wyświetlanie logu aktywacji Wywołanie: opcja Object log Wpisy do logu aktywacji następują tylko wtedy, gdy aktywacja powoduje wygenerowanie odpowiedniego kodu SQL Wpisy w logu aktywacji zawierają ciąg wykonanych w trakcie aktywacji kroków wraz z poleceniami SQL wysyłanymi do bazy danych w czasie aktywacji obiektu Szczegółowe informacje na temat poszczególnych komunikatów w logu można wyświetlić zaznaczając odpowiedni komunikat i wybierając pomoc F1

Wyświetlanie i zmiana parametrów przechowywania danych Przeznaczenie dla DBA dostęp do ustawień parametrów przechowywania danych z poziomu R/3 po aktywacji tabeli Wyświetlane są charakterystyczne dla BD parametry przechowywania tabel: Src kolumna określająca źródło wartości: DBS linia z bieżącymi ustawieniami BD CMP linia zawierająca wartości obliczone w oparciu o kategorię wielkości i klasę danych tabeli USR linia umożliwia podanie własnych wartości NextE, MaxE, Pf, Pu i bezpośrednie ich zastosowanie Pozostałe kolumny: InitExt, NextExt rozmiar w blokach dla ekstensji początkowej i ekstensji następnych MinE, MaxE najmniejsza i największa dopuszczalna liczba ekstensji FG, Fr ustawienia dla równoległego trybu przetwarzania (tylko Oracle) Pf, Pu procent wolnej i używanej przestrzeni w blokach danych Linie DBS i CMP są na ogół takie same, o ile po aktywacji tabeli ręcznie nie zmieniono dla niej parametrów przechowywania danych

Usuwanie i przywracanie tabel Najszybszy sposób czyszczenia tabeli: usunięcie i ponowne utworzenie tabeli Usuwanie tabeli: z poziomu Database utility Delete Database Table Przywracanie tabeli: Create Database Table tabela zostanie odtworzona na podstawie aktywnej wersji tej tabeli Przed usunięciem tabeli warto zrobić jej kopię (definicja tabeli i dane) Jeśli tabela ma więcej niż jedną ekstensję, to szybkim i łatwym sposobem jej reorganizacji jest: skopiowanie danych tymczasowo do innej tabeli usunięcie tabeli przywrócenie tabeli powrotne skopiowanie danych