PL/SQL w SQL: dwa proste eksperymenty [WITH, PRAGMA UDF, Result Cache, DETERMINISTIC, Scalar Subquery Caching]

W związku z częstymi pytaniami o to, jak optymalnie wykorzystywać funkcje PL/SQL w poleceniach SQL, przyjrzyjmy się następującym dwóm eksperymentom wydajnościowym. Naszym celem będzie przeszukiwanie tabeli liczącej milion rekordów, a klazula WHERE będzie zawierać odwołanie do bardzo prostej funkcji PL/SQL. Eksperyment 1 Dane wejściowe: tabela MROWS zawierająca milion unikatowych rekordów, funkcja PL/SQL DBL() zwraca podwojoną Read more about PL/SQL w SQL: dwa proste eksperymenty [WITH, PRAGMA UDF, Result Cache, DETERMINISTIC, Scalar Subquery Caching][…]

Kolejność ewaluacji predykatów w WHERE: ASSOCIATE STATISTICS i ORDERED_PREDICATES

W przypadku złożonych zapytań SQL problem wydajnościowy może czasami wynikać z nieoptymalnej kolejności ewaluacji predykatów w klauzuli WHERE. Warto w tym miejscu przypomnieć dwa ważne fakty dotyczące optymalizacji i wykonywania zapytań w systemie Oracle Database: Oracle Database stosuje skróconą ewaluację (short-circuit evaluation) warunków logicznych – przykładowo, gdy w warunku „WHERE a=1 AND b=2 AND c=3” Read more about Kolejność ewaluacji predykatów w WHERE: ASSOCIATE STATISTICS i ORDERED_PREDICATES[…]

Przeszukiwanie danych pełnotekstowych – indeks Oracle Text typu CTXSYS.CONTEXT

Dość powszechnym wyzwaniem dla programistów jest umożliwienie użytkownikom bazy danych efektywnego wyszukiwania informacji w oparciu o częściowe dopasowanie danych tekstowych, np. szukanie produktów zawierających określone słowo w opisie, szukanie symboli produktów zawierających określony fragment, szukanie dokumentów tekstowych zawierających podaną frazę, itp. Zwykle zadania takie są realizowane za pomocą operatora LIKE ‚%…%’ lub UPPER(…) LIKE ‚%…%’. Read more about Przeszukiwanie danych pełnotekstowych – indeks Oracle Text typu CTXSYS.CONTEXT[…]

STATISTICS_LEVEL=ALL – zyski vs. koszty

Dwa z najbardziej atrakcyjnych mechanizmów optymalizatora zapytań Oracle Database 12c – „cardinality feedback” i „adaptive cursor sharing” – do prawidłowego działania wymagają (o czym często ze zdziwieniem przekonują się administratorzy) przełączenia parametru inicjalizacyjnego STATISTICS_LEVEL na poziom „ALL” (domyślnie „TYPICAL”). Przy takim ustawieniu gromadzone są dodatkowe wskaźniki wydajnościowe: Plan Execution Statistics i Timed OS Statistics (zainteresowanych Read more about STATISTICS_LEVEL=ALL – zyski vs. koszty[…]

Jak bardzo statystyki systemowe wpływają na wybór planu wykonania?

Wiemy, że statystyki systemowe są ważnym opisem wydajności wykorzystywanej platformy sprzętowej oraz że kosztowy optymalizator zapytań Oracle Database odwołuje się do ich wartości podczas szacowania kosztów planów wykonania zapytań (pisaliśmy o statystykach systemowych TU). Wielu administratorów zastanawia się jednak, jak bardzo optymalizator zapytań jest „wrażliwy” na wartości tych statystyk (zbieranych metodami eksperymentalnymi). Aby odpowiedzieć na Read more about Jak bardzo statystyki systemowe wpływają na wybór planu wykonania?[…]

Oracle Database FGAC/VPD – blaski i cienie (a.k.a. CONTEXT_SENSITIVE)

Drobnoziarnista kontrola dostępu (Fine-Grained Access Control – FGAC) jest popularną techniką kontroli dostępu użytkowników do danych na poziomie rekordów (w przeciwieństwie do kontroli dostępu na poziomie tabeli – realizowanej poleceniami GRANT), pozwalającą udostępniać różnym użytkownikom różne zestawy rekordów z tej samej tabeli (co daje efekt tzw. Virtual Private Database – VPD). Ogólna idea FGAC sprowadza Read more about Oracle Database FGAC/VPD – blaski i cienie (a.k.a. CONTEXT_SENSITIVE)[…]

Wpływ Clustering Factor na wydajność zapytań zakresowych z indeksem

W tabelach typu Heap (najpopularniejsze, domyślne) kolejność fizycznego ułożenia rekordów jest zasadniczo przypadkowa, wynikająca m.in. z porządku ich wstawiania. Kolejność ta nie ma żadnego znaczenia dla wydajności zapytań dokonujących pełnego odczytu tabeli lub jednorekordowych zapytań punktowych z użyciem indeksu. Ma jednak znaczenie dla wydajności realizacji zapytań zakresowych z użyciem indeksu, gdzie wynikowy zbiór rekordów tabeli Read more about Wpływ Clustering Factor na wydajność zapytań zakresowych z indeksem[…]

Podstawy Oracle Database: Undo-Redo, czyli dlaczego UPDATE jest tak powolny?

Przyjrzyjmy się dziś dość popularnemu problemowi wydajności masowej operacji UPDATE dokonującej modyfikacji bardzo dużej liczby rekordów. Spotykają się z nim najczęściej programiści implementujący zadania wsadowe. Dla celów demonstracji posłużymy się tabelą UPD_TEST o następującej strukturze: create table upd_test (c1 number(10), c2 char(1018)); Rozmiar kolumny C2 został tak dobrany, aby średnia długość rekordu oscylowała w okolicach Read more about Podstawy Oracle Database: Undo-Redo, czyli dlaczego UPDATE jest tak powolny?[…]

Kilka indeksów na tej samej kolumnie (wyrażeniu) ?!

W przeszłości wielokrotnie podejmowałem dyskusje dotyczące właściwego doboru typu indeksu w zależności od charakterystyki danych i od rodzaju wykonywanych zapytań. Wydawało się, że jednym z niespełnionych marzeń programistów było utworzenie wielu alternatywnych indeksów na tej samej kolumnie (np. bitmapowy, b-drzewo, partycjonowany lokalnie, partycjonowany globalnie,…) tak, aby to optymalizator zapytań (a nie programista) wybrał sobie ten, Read more about Kilka indeksów na tej samej kolumnie (wyrażeniu) ?![…]

Walczymy ze zbędnym REDO w Oracle Database 12c! (temp_undo_enabled)

Jak dobrze wiemy, serwer bazy danych Oracle Database zapewnia odtwarzalność realizowanych transakcji poprzez generowanie informacji Redo zapisywanych w dziennikach powtórzeń (redo logs). Gdy zdarzy się awaria, informacje te pozwalają zrekonstruować stan bazy danych będący skutkiem transakcji zrealizowanych przed awarią. Istnieją jednak sytuacje, w których programiście wcale nie zależy na zabezpieczeniu transakcji, a wręcz postrzega on Read more about Walczymy ze zbędnym REDO w Oracle Database 12c! (temp_undo_enabled)[…]