Blog Oracle/Postgres

Wraz z wprowadzeniem wersji 14 PostgreSQL pojawiła się możliwość – na którą długo czekaliśmy – definiowania statystyk rozszerzonych dla wyrażeń. Jest to mechanizm znany np. z Oracle Database, wspomagający szacowanie selektywności predykatów opartych o funkcje/wyrażenia. Wiemy, jak ważne jest trafne szacowanie selektywności predykatów występujących w zapytaniach – od tego przecież zależy precyzja oszacowania kosztów planów wykonania zapytania i tym samym wybór planu optymalnego. W domyślnej konfiguracji, PostgreSQL gromadzi statystyki dla każdej kolumny każdej tabeli (statystyki Read more about Nowe w PostgreSQL 14: statystyki dla wyrażeń[…]

Ponieważ powrót do podstaw nikomu jeszcze nie zaszkodził, to proponujemy dziś małe repetytorium z zakresu MVCC i operacji Vacuum. Pamiętamy, że PostgreSQL jest oczywiście systemem transakcyjnym, wspierającym tradycyjne własności ACID dla transakcji realizowanych przez aplikacje użytkowników. W celu prawidłowej realizacji izolacji transakcji, PostgreSQL stosuje technikę MVCC (Multiversion Concurrency Control), w ramach której każda modyfikacja rekordu przyczynia się do powstania jego nowego obrazu, podczas gdy dotychczasowy obraz rekordu jest pozostawiany w tabeli na potrzeby innych transakcji Read more about Podstawy: Vacuum w PostgreSQL[…]

Jedną z nowych technik optymalizacji wydajności, jakie pojawiły się w PostgreSQL 13 jest sortowanie przyrostowe (incremental sorting). Znajduje ono zastosowanie w zapytaniach, które sortują rekordy według klucza wielokolumnowego. W przeszłości, popularnym sposobem na optymalizację takich sortowań było utworzenie indeksu na wszystkich kolumnach klucza sortowania. Obecnie, serwer PostgreSQL potrafi w takiej sytuacji skorzystać również z indeksu obejmującego tylko część (początkową) kolumn klucza sortowania, a następnie „dosortować” rekordy według końcowych kolumn klucza. Dzięki temu mechanizmowi, PostgreSQL 13 Read more about Sortowanie przyrostowe w PostgreSQL 13[…]

Spośród wielu nowości, jakie pojawiły się w wersji 13 serwera PostgreSQL, wielu z nas doceni interesujące narzędzie, umożliwiające weryfikację poprawności przechowywanej fizycznej kopii bezpieczeństwa: pg_verifybackup. Na wstępie należy zauważyć, że podczas wykonywania fizycznej kopii bezpieczeństwa za pomocą pg_basebackup, teraz generowany jest specjalny plik deskryptora, nazwany backup_manifest, który zawiera wykaz wszystkich plików wchodzących w skład kopii bezpieczeństwa, wraz z ich sumami kontrolnymi. Dodatkowo, plik backup_manifest zawiera również deklarację zakresu rekordów WAL, które będą niezbędne do uspójnienia Read more about Weryfikacja poprawności kopii bezpieczeństwa w PostgreSQL 13[…]

W domyślnej konfiguracji serwera, ewentualne uszkodzenia plików danych są wykrywane podczas dostępu do bloku dyskowego tylko w sytuacji, kiedy blok danych nie może być odczytany z dysku lub jego zawartość jest nieczytelna (uszkodzony format bloku). Niestety, bardziej „subtelne” uszkodzenia, polegające np. na przekłamaniu pojedynczego bajtu, są niedostrzegalne dla serwera PostgreSQL. Aby umożliwić automatyczną detekcję nawet takich „subtelnych” uszkodzeń, już w wersji 9.3 wprowadzono mechanizm sum kontrolnych, które pozwalają wykrywać jakiekolwiek zaburzenia zawartości bloków danych. Niestety, Read more about PostgreSQL 12/13: aktywacja sum kontrolnych w plikach danych[…]

Pojawienie się dwunastej wersji serwera PostgreSQL spowodowało konieczność wprowadzenia poprawek do stosowanych przez nas procedur odtwarzania bazy danych po awarii! Przypomnijmy, że w wersjach PostgreSQL 8, 9, 10, i 11 odtwarzanie bazy danych w oparciu o archiwalne pliki WAL realizowaliśmy poprzez utworzenie w katalogu Data Directory pliku o nazwie recovery.conf, a w nim – umieszczenie parametru restore_command. Parametr ten wskazywał sposób przywracania archiwalnych plików WAL z lokalizacji, w której pierwotnie były one zapisane. W chwili Read more about PostgreSQL 12 – co się stało z plikiem recovery.conf?[…]

Jednym z najbardziej interesujących rozwiązań technicznych dostępnych na platformie Oracle Exadata jest Smart Scan. Na początek małe przypomnienie: architektura sprzętowa platformy Oracle Exadata przewiduje podział na maszyny odpowiedzialne za fizyczne składowanie danych (Exadata Cell Server) i na maszyny, na których pracuje instancja serwera bazy danych (Database Machine). Te dwa rodzaje maszyn połączone są szybką siecią lokalną zrealizowaną w technologii Infiniband. Zarys tej architektury pokazuje poniższy rysunek. Ponieważ, mimo wszystko, przepustowość Infiniband jest ograniczona, a jednocześnie Read more about Podstawy: Exadata Smart Scan – jak sprawdzić, czy się odbył?[…]

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ą wartość parametru wywołania: CREATE TABLE mrows (id NUMBER); BEGIN   FOR i IN 0..999999 LOOP     INSERT INTO mrows VALUES Read more about PL/SQL w SQL: dwa proste eksperymenty [WITH, PRAGMA UDF, Result Cache, DETERMINISTIC, Scalar Subquery Caching][…]

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” niespełniony będzie pierwszy predykat (a=1), to w ogóle nie zostaną przebadane pozostałe predykaty, gdyż wynik jest już znany (false). Oracle Read more about Kolejność ewaluacji predykatów w WHERE: ASSOCIATE STATISTICS i ORDERED_PREDICATES[…]

W związku z coraz powszechniejszym wykorzystywaniem kontenerów Docker i wynikającymi z tego pytaniami o prawidłową instalację i konfigurację oprogramowania serwera bazy danych przeprowadźmy krótką demonstrację obejmującą: (1) przygotowanie systemu operacyjnego Oracle Linux 7.2, (2) instalację oprogramowania Docker Engine, (3) instalację i konfigurację oprogramowania Oracle Database 12c. 1. Przygotowanie systemu operacyjnego Oracle Linux 7.2 Obejmuje dwie czynności: aktualizację jądra systemu operacyjnego do wersji 4.1.12 lub wyższej (domyślna 3.8.13) oraz wyłączenie SELinux. Aby dokonać automatycznej aktualizacji jądra Read more about Instalacja Oracle Database 12.2 w środowisku Docker[…]

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 '%…%’. Niestety, tradycyjne struktury indeksów (B*-drzewo i bitmapowy) są w przypadku takich zapytań bezsilne, co doprowadza do planów wykonania bazujących na Read more about Przeszukiwanie danych pełnotekstowych – indeks Oracle Text typu CTXSYS.CONTEXT[…]

Od czasów wersji Oracle Database 10g powszechnie wykorzystujemy mechanizmy automatycznego zarządzania pamięcią operacyjną instancji (Automatic Shared Memory Management – ASMM, czy później Automatic Memory Management – AMM). Pamiętamy ze szkoleń, że zwalniają one administratora m.in. z obowiązku ręcznego konfigurowania rozmiarów obszarów buforowych takich jak Buffer Cache i Shared Pool oraz z podejmowania decyzji o proporcji rozmiarów PGA/SGA. Wymagają jedynie określenia pożądanego rozmiaru całkowitego SGA (parametr SGA_TARGET) lub pożądanego sumarycznego rozmiaru PGA i SGA (parametr MEMORY_TARGET). Read more about Automatyczne zarządzanie pamięcią SGA a usterka ORA-04031[…]

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 tym, jakie wskaźniki są gromadzone przy różnych ustawieniach kieruję do analizy wyniku zapytania „select statistics_name, description, activation_level from v$statistics_level”). Ponieważ Read more about STATISTICS_LEVEL=ALL – zyski vs. koszty[…]

Jedną z flagowych funkcjonalności drugiego wydania serwera bazy danych Oracle Database 12c (12.2) jest Database Sharding (dzielenie bazy danych). Jest to klon rozwiązania dobrze znanego w świecie systemów NoSQL, polegającego na horyzontalnym partycjonowaniu danych pomiędzy wiele fizycznych lokalizacji. Taki rozdział danych pozwala następnie rozdzielić obciążenie aplikacyjne i tym samym uzyskać efekt prawie-liniowej skalowalności bardzo dużych baz danych. Oczywiście pod warunkiem, że rozsądnie rozdzielimy zarówno dane, jak i obciążenie aplikacyjne. Realizacja Database Shardingu w Oracle Database Read more about Oracle Database 12.2 Database Sharding – porady praktyczne[…]

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 to pytanie przeprowadźmy prosty eksperyment. Dana jest tabela o rozmiarze 375 bloków, zawierająca 100 tysięcy rekordów o średniej długości 22 Read more about Jak bardzo statystyki systemowe wpływają na wybór planu wykonania?[…]

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 się do implementacji funkcji PL/SQL, które generują treści predykatów selekcji – automatycznie i nieodwołalnie dołączanych do klauzuli WHERE każdego zapytania Read more about Oracle Database FGAC/VPD – blaski i cienie (a.k.a. CONTEXT_SENSITIVE)[…]

Od czasu do czasu pojawia się konieczność skorygowania decyzji optymalizatora zapytań, który pomimo poprawnych i aktualnych statystyk uparcie nie chce wybrać najlepszego planu wykonania (query execution plan). Większość deweloperów sięga wtedy po wskazówki sterujące (hinty), umieszczane w treści problematycznego zapytania. Jest to metoda skuteczna, o ile mamy możliwość edycji treści zapytania – co bywa trudne w przypadku, gdy „leczymy” cudzą aplikację o zamkniętym kodzie źródłowym. Istnieje jednak „półlegalne” rozwiązanie, dzięki któremu możemy poprosić serwer bazy Read more about Hinty bez ingerencji w treść zapytania? SQL Patch![…]

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 jest odczytywany na podstawie referencji ROWID znajdujących się w liściu (sąsiednich liściach) indeksu. Od tego, czy referencje te są „sąsiednie” Read more about Wpływ Clustering Factor na wydajność zapytań zakresowych z indeksem[…]

Czas rozprawić się ze zbyt często powtarzaną herezją, zanim stanie się prawdą… Elementem techniki kosztowej optymalizacji zapytań jest szacowanie kosztów alternatywnych planów wykonania zapytania. Odbywa się ono automatycznie podczas przetwarzania polecenia SQL przez optymalizator zapytań. Plan wykonania, którego szacowany koszt okazał się najniższy ze wszystkich rozważanych, jest wybierany jako plan do realizacji. Programista ma możliwość obejrzenia zarysu najlepszego (najtańszego) planu wykonania zapytania (np. poleceniem EXPLAIN PLAN FOR lub – lepiej – zapytaniem do funkcji pakietu Read more about Podstawy Oracle Database: uwaga na koszt planu wykonania zapytania![…]

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 1 kB. Na początek tabela zostanie wypełniona 100 000 nieistotnych rekordów, dzięki czemu jej rozmiar wyniesie 100 MB. begin   Read more about Podstawy Oracle Database: Undo-Redo, czyli dlaczego UPDATE jest tak powolny?[…]

Hinty (wskazówki) są (niestety) dość popularnym narzędziem w rękach deweloperów usiłujących nakłonić kosztowy optymalizator zapytań do zastosowania wybranego (przez dewelopera) planu wykonania zapytania. Wiele hintów wymaga podania nazwy obiektu zapytania (tabeli, indeksu, itp.), w stosunku do którego chcemy wymusić określone zachowanie optymalizatora. Co jednak zrobić w przypadku, gdy zapytanie operuje na perspektywie, a chcemy użyć hintu w stosunku do np. tabeli użytej wewnątrz definicji ten perspektywy (oczywiście zwykle nie mamy możliwości ingerowania w definicję perspektywy)? Read more about Hinty dla perspektyw[…]

Pamięć PGA (Program Global Area) serwera bazy danych Oracle Database 12c jest bezpośrednio wykorzystywana przez procesy Server Process obsługujące sesje użytkowników. W przeciwieństwie do SGA, PGA nie jest współdzielona przez wiele sesji – każda sesja ma do dyspozycji swoją odrębną prywatną część PGA. Preferowany sumaryczny rozmiar PGA dla wszystkich sesji może być ustalony przez administratora (PGA_AGGREGATE_TARGET) lub automatycznie dobrany przez instancję (w ramach MEMORY_TARGET). W trybie serwera dedykowanego (Dedicated Server Mode) pamięć PGA zawiera trzy Read more about Podstawy Oracle Database: alokacja pamięci PGA[…]

Histogramy wykorzystujemy dość powszechnie w celu mniej lub bardziej precyzyjnego szacowania selektywności predykatów użytych w zapytaniach (oczywiście dla kolumn o nierównomiernym rozkładzie statystycznym). W pewnych przypadkach możemy jednak paść ofiarą uproszczenia zastosowanego przez Oracle podczas generowania histogramów, czego efektem będą złe/bardzo złe szacunki selektywności. Uproszczenie to dotyczy kolumn typu tekstowego i polega na uwzględnianiu w histogramie wyłącznie pierwszych 64 znaków (lub 32 znaków w wersji Oracle Database 11g) tekstu kolumny. W rezultacie, różne wartości posiadające Read more about Czy długi klucz = zły klucz?[…]

Dla poprawnego działania, kosztowy optymalizator zapytań musi posiadać wiedzę o rozkładzie wartości kolumny, na której oparty jest predykat w zapytaniu. Wiedzę taką może pozyskać na trzy sposoby: (1) pobierając losową próbkę danych w chwili wykonywania zapytania (dynamic sampling), (2) posługując się wcześniej zebranymi statystykami podstawowymi i przyjmując rozkład jednorodny wartości, (3) posługując się zebranym wcześniej histogramem i odczytując z niego charakterystykę rozkładu wartości. W systemach OLTP będziemy zwykle unikali Dynamic Samplingu na rzecz właściwie zbieranych Read more about Gdzie są moje histogramy? Słów kilka o SIZE AUTO[…]

Exadata, ZFS oraz Pillar Axiom umożliwiają stosowanie wysoce skutecznej kompresji kolumnowej HCC (Hybric Columnar Compression) – ciekawy opis znajduje się tu. Funkcjonalność HCC jest jednak wbudowana w każde wydanie serwera bazy danych Oracle Database 12c (nie tylko Exadata), lecz możliwość jej użycia jest blokowana na zasadzie „nie, bo nie”. Pomysły na jej odblokowanie publikowali już Jonathan Lewis i Martin Berger. Natomiast zupełnie legalnie z HCC korzysta funkcja DBMS_COMPRESSION.GET_COMPRESSION_RATIO, która w celu oszacowania skuteczności kompresji fizycznie Read more about Kompresja HCC – ocena skuteczności na laptopie[…]

Nie każdy administrator serwera bazy danych Oracle Database 10g/11g/12c zauważył, że wiele lat temu Oracle zmienił podejście do tworzenia tabeli PLAN_TABLE (wykorzystywanej do pobierania planu wykonania zapytania). O ile dawno temu musieliśmy ją budować samodzielnie za pomocą skryptu utlxplan.sql, oddzielnie w schemacie każdego zainteresowanego użytkownika, to począwszy od wersji 10g tabela PLAN_TABLE jest automatycznie tworzona przez skrypt catplan.sql (wołany z catptyps.sql, wołany z kolei z catproc.sql) jako ogólnodostępna globalna tabela tymczasowa w schemacie SYS wraz Read more about Uwaga na starą tabelę PLAN_TABLE[…]

Oracle Database 12c oferuje ciekawe rozwiązanie, pozwalające zredukować rozmiar indeksu tworzonego na tabeli partycjonowanej, w której wiele partycji ma charakter archiwalny (bardzo rzadko podlega zapytaniom). Indeks częściowy – bo o nim mowa – może obejmować swoim zasięgiem wybrane partycje tabeli, podczas gdy rekordy w pozostałych partycjach tabeli pozostają bez indeksu. Gdy realizowane jest zapytanie do tak indeksowanej tabeli, optymalizator zapytań skorzysta z indeksu w przypadku partycji uwzględnionych w indeksie, oraz z pełnego odczytu partycji w Read more about Indeksy częściowe w Oracle Database 12c[…]

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, który jest najkorzystniejszy. Dotąd jednak było to niemożliwe. W wersji Oracle Database 12c nieśmiało wprowadzono możliwość definiowania kilku indeksów na Read more about Kilka indeksów na tej samej kolumnie (wyrażeniu) ?![…]

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 zapisy informacji Redo jako element spowalniający funkcjonowanie całego systemu. Na przykład – podczas zapisywania w bazie danych informacji tymczasowych, które Read more about Walczymy ze zbędnym REDO w Oracle Database 12c! (temp_undo_enabled)[…]

To jedna z ciekawszych nowych funkcjonalności serwera Oracle Database 12c. Pomaga zoptymalizować mechanizmy składowania danych, którymi użytkownicy od pewnego czasu przestali się aktywnie interesować. Aktualnie dostępne są dwa rozwiązania: (1) kompresja (rekompresja) danych „niedotykanych” przez użytkowników, (2) przenoszenie (tzw. tiering) do „tańszej” przestrzeni tabel tych partycji, które przestają się mieścić w aktualnej przestrzeni tabel, a którymi użytkownicy najmniej się interesują. Aby skorzystać z Automatic Data Optimization należy zdefiniować tzw. politykę ILM, np.: alter table zamowienia Read more about Automatic Data Optimization w 12c (Information Lifecycle Management)[…]

Najczęstszą przyczyną błędu ORA-12519 ujawniającego się podczas próby logowania do serwera bazy danych: Listener refused the connection with the following error: ORA-12519, TNS:no appropriate service handler found [SQLCode: 12519] jest osiągnięcie przez serwer limitu równocześnie połączonych procesów/sesji określanego parametrami inicjalizacyjnymi PROCESSES i SESSIONS. Oto prosty sposób sprawdzenia aktualnych wartości tych limitów (LIMIT_VALUE), jak i odczytania najwyższej dotychczas (MAX_UTILIZATION) liczby równoczesnych sesji i procesów: SQL> select * from v$resource_limit where resource_name in (’processes’,’sessions’); RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION Read more about Błędy ORA-12519 – typowe rozwiązania[…]

Zajmowaliśmy się już kiedyś ciekawą kwestą korygowania nieoptymalnego planu wykonania z wykorzystaniem Cardinality Feedback (Jak optymalizator uczy się na błędach). Pokazaliśmy, że po pierwszym wykonaniu nieoptymalnego planu wykonania optymalizator potrafi go zmodyfikować tak, aby drugie wykonanie przebiegło już bardziej efektywnie. Niestety, ten mechanizm serwera potrafi być skuteczny dopiero przy drugim wywołaniu tego samego zapytania. Pierwsze wywołanie trzeba spisać na straty…? Niekoniecznie… Interesujące rozwiązanie zostało wprowadzone w Oracle Database 12.1 pod nazwą Adaptive Plans. Polega ono Read more about Jak nie pomylić się za pierwszym razem? Adaptatywne plany wykonania w Oracle Database 12c[…]

Zarówno SQL Profiles, jak i Hints to mechanizmy pozwalające sterować zachowaniem optymalizatora  zapytań tak, aby wydajność generowanych planów była jak najlepsza. Byłyby one niepotrzebne, gdyby optymalizator potrafił zawsze trafnie wybrać optymalny plan wykonania. Ponieważ jednak nierzadko zdarza się optymalizatorowi „chybić”, to takie lekarstwa są niezbędne. Hinty to zapisane w treści polecenia SQL wskazówki (zalecenia), instruujące optymalizator zapytań na temat tego, jakie kroki powinny, lub nie powinny znaleźć się w planie wykonania. Umożliwiają one zawężenie przestrzeni Read more about Profile czy hinty?[…]

Nierzadko spotykamy się z problemem gwałtownego pogorszenia wydajności starej, wielokrotnie sprawdzonej i zoptymalizowanej aplikacji. Przyczyną zwykle jest upgrade oprogramowania serwera bazy danych, zmiana sposobu zbierania statystyk dla optymalizatora zapytań, rekonfiguracja optymalizatora zapytań czy zmiana ustawień systemowych. Czy można jakoś uchronić się przed takimi wydajnościowymi niespodziankami w przyszłości? Istnieje mechanizm serwera bazy danych Oracle Database umożliwiający ochronę dobrych, wydajnych planów wykonania zapytań przed gwałtownym pogorszeniem w wyniku zmian systemowych – SQL Plan Management. Zastępuje on wcześniejsze Read more about Jak możemy chronić się przed pogorszeniem planu wykonania?[…]

Jednym z bardziej popularnych parametrów konfiguracyjnych jest CURSOR_SHARING, umożliwiający sterowanie współdzieleniem kursorów i planów wykonania zapytań (pojawił się w 8.1.6). Może przyjąć jedną z trzech wartości: EXACT (domyślna), SIMILAR, FORCE, przy czym Oracle zapowiedział wycofanie opcji SIMILAR (już nawet w wersji 11g [ogłoszenie ID 1169017.1], jednak jest nadal dostępna). Parametr CURSOR_SHARING jest reklamowany jako lekarstwo na problemy wydajnościowe powodowane przez niesfornych programistów, którzy w często wykonywanych zapytaniach SQL stosują literały zamiast zmiennych wiązanych (bind variables). Read more about Eksperymenty z CURSOR_SHARING[…]

Przyjrzyjmy się ciekawemu zjawisku, które przejawia się tym, że czasami wykonanie zapytania SELECT powoduje modyfikacje bloków dyskowych oraz zapisy danych powtórzenia (Redo). W konsekwencji , wydajność polecenia SELECT staje się nieakceptowalna. W poniższym eksperymencie posługuję się tabelą zawierającą milion rekordów, zajmująca 130MB. W pierwszym kroku, na tabeli wykonuję polecenie UPDATE, które modyfikuje co piąty rekord. Zagregowane statystyki sesji słusznie ukazują wykonanie modyfikacji bloków danych oraz wygenerowanie danych powtórzenia. Zatwierdzam transakcję, kończę sesję. W drugim kroku, Read more about Dlaczego polecenie SELECT powoduje zapisy dyskowe? Delayed Block Cleanout![…]

Jak wiemy, aby trafnie estymować koszty planów wykonania zapytań, optymalizator zapytań wymaga obecności szeregu statystyk (modeli statystycznych). Statystyki te dzielą się na cztery kategorie: (1) statystyki opisujące tabele (liczba rekordów, liczba bloków, średni rozmiar rekordu), (2) statystyki opisujące indeksy (liczba bloków liści, liczba poziomów, współczynnik klastrowania), (3) statystyki opisujące kolumny tabel (liczba wartości, liczba wartości pustych, rozkład wartości – histogram), (4) statystyki systemowe (wydajność CPU, wydajność dyskowego I/O). O ile pierwsze trzy kategorie statystyk są Read more about A czy pamiętasz o statystykach systemowych?[…]

Podczas estymacji kosztu planu wykonania zapytania, kosztowy optymalizator zapytań musi m.in. oszacować liczby rekordów (tzw. kardynalność), które będą przetwarzane przez zapytanie w różnych fazach jego realizacji. Od precyzji tych szacunków zależą decyzje dotyczące np. kolejności łączenia tabel czy też wyboru algorytmu łączenia tabel. Szacunki kardynalności są dokonywane przede wszystkim na podstawie dostępnych statystyk dla tabel i ich kolumn. Nie zawsze jednak optymalizator zachowuje sie nieomylnie, zwłaszcza gdy w zapytaniu występują złożone predykaty lub gdy dostępne Read more about Jak optymalizator Oracle Database uczy się na błędach (Cardinality Feedback)[…]

W bazie danych umieszczamy tabelę zawierającą sto rekordów, które w kolumnie PŁEĆ posiadają 99 razy wartość ‘M’ i jeden raz wartość ‘K’. Gromadzimy statystyki dla tej tabeli, gromadzimy histogram dla kolumny PŁEĆ. Następnie wykonujemy zapytanie, które w klauzuli WHERE posiada predykat UPPER(PŁEĆ) = ‘M’. Jaka jest selektywność tego predykatu? Oczywiście 99%. Jaką selektywność oszacuje optymalizator kosztowy? … 1%. Przyjrzyjmy się poniższemu przykładowi. Kolumna Rows w planie wykonania zapytania pokazuje oczekiwaną przez optymalizator liczbę rekordów spełniających Read more about Dlaczego 99 ze 100 to tylko 1%?[…]

Jednym z ciekawszych mechanizmów prowadzenia dyskowego wejścia/wyjścia w Oracle Database 11g jest realizacja pełnego odczytu tabeli (full table scan) metodą ścieżki bezpośredniej (direct path). Idea ścieżki bezpośredniej polega na pomijaniu bufora Buffer Cache i odczytywaniu bloków tabeli z dysku bezpośrednio do PGA. Dzięki temu możliwa jest poprawa wydajności operacji pełnego odczytu tabeli (brak narzutów związanych z zarządzaniem Buffer Cache). Czy programista/administrator ma możliwość decydowania, które operacje pełnego odczytu tabeli mają korzystać ze ścieżki bezpośredniej (np. Read more about Wyłączanie użycia ścieżki bezpośredniej przy pełnym odczycie tabeli (Oracle Database 11g)[…]

W jaki sposób kosztowy optymalizator zapytań estymuje koszt planu wykonania zapytania jeśli administrator/programista nie zadbał o zgromadzenie statystyk dla optymalizatora? Wcześniejsze wersje serwerów Oracle Database przełączały się wtedy w tryb optymalizacji regułowej. Serwer Oracle Database 11g skorzysta w tej sytuacji z tzw. dynamicznego próbkowania (dynamic sampling), polegającego na pobraniu losowej próbki bloków tabel uczestniczących w zapytaniu (i wykorzystaniu tych bloków do obliczeń selektywności). Ogólnie rzecz biorąc, dynamiczne próbkowanie pogarsza efektywność pracy optymalizatora zapytań, ponieważ powoduje Read more about Gdy brakuje (niektórych) statystyk dla optymalizatora[…]

Działanie kosztowego optymalizatora zapytań w uproszczeniu polega na: (1) transformacji tekstu zapytania SQL, (2) generowaniu alternatywnych planów wykonania zapytania, (3) estymacji ich kosztów, (4) wyborze tego planu wykonania, którego estymowany koszt jest najniższy. Transformacja tekstu zapytania SQL może obejmować np. scalanie definicji perspektywy, „wpychanie” predykatów, rozwijanie podzapytań, przepisywanie zapytań na perspektywy materializowane. Z kolei alternatywne plany wykonania zapytania mogą się różnić np. kolejnością łączenia tabel, algorytmami łączenia tabel, wyborem indeksów. Programista/administrator może oczywiście w łatwy Read more about Śledzenie pracy optymalizatora zapytań Oracle Database[…]

Buffer Cache to obszar pamięci wewnątrz SGA pełniący rolę dwukierunkowego bufora dyskowego uczestniczącego w operacjach odczytu i zapisu obiektów użytkowników (tabele, indeksy). Jego rozmiar jest określany automatycznie lub jest narzucony przez administratora (parametr db_cache_size). Buffer Cache służy redukcji aktywności dyskowej serwera. Zanim zapytanie SQL odczyta blok danych z dysku, najpierw próbuje znaleźć ten blok w Buffer Cache. Gdy szukany blok nie znajduje sie w Buffer Cache, wtedy jest odczytywany z dysku i (zwykle) umieszczany w Read more about Jak działa Database Buffer Cache? (część 1)[…]

Jak wiemy, do kompletnego odtworzenia bazy danych po awarii dyskowej niezbędne są: (1) kopie bezpieczeństwa uszkodzonych plików, (2) wszystkie archiwalne pliki dziennika powtórzeń, które powstały od momentu wykonania kopii bezpieczeństwa. Gdy brakuje niektórych plików dziennika powtórzeń, jesteśmy skazani na odtwarzanie niepełne (Incomplete Recovery). Jednak nawet procedura odtwarzania niepełnego wymaga co najmniej obecności archiwalnych plików dziennika powtórzeń, które powstawały _w trakcie_ wykonywania kopii bezpieczeństwa (gorącej). Co zrobić w niezwykle rzadkiej sytuacji utraty archiwalnych plików dziennika powtórzeń Read more about Odtwarzanie bazy danych Oracle po awarii – ostatnia deska ratunku[…]

Czy indeks B*-drzewo może być użyty do wyszukiwania opartego na predykacie LIKE? To zależy. Przyjrzyjmy się planom wykonania dwóch zapytań do przykładowej tabeli DUZA_TEKSTOWA (16 tysięcy rekordów, niepowtarzalne wartości w kolumnie tekstowej A). SQL> create index demo_idx1 on duza_tekstowa(a); … SQL> select * from duza_tekstowa where a like 'abcd%’; … Plan wykonywania —————————————————————– | Id | Operation        | Name      | Rows | Bytes | Cost (%CPU)| —————————————————————– | 0  | SELECT STATEMENT |           | 1 Read more about Oracle Database – indeks B*-drzewo a operator LIKE[…]

Nie każdy programista pamięta, że struktura indeksu B*-drzewo pomija wartości NULL, czego efektem jest odmowa użycia takiego indeksu do realizacji predykatu IS NULL. Łatwo zaobserwować takie zjawisko wykonując prosty eksperyment. Poniższa tabela DUZA_Z_NULLAMI(A,B) zawiera pół miliona rekordów, wśród których jeden rekord posiada wartość NULL w kolumnie A. Na kolumnie tej utworzony został indeks DEMO_IDX1. Obejrzyjmy plany wykonania dwóch zapytań – jedno wyszukuje rekord według konkretnej niepustej wartości kolumny A, drugie – wyszukuje rekord z wartością Read more about Indeks B*-drzewo a wyszukiwanie wartości NULL[…]

Jednym z trudniejszych zadań wdrożeniowych jest ocena i dobór wydajnej platformy sprzętowo-systemowej dla serwera bazy danych. Z powodu trudności w analitycznym szacowaniu wydajności serwera na planowanej platformie, powszechnie wykonujemy porównawcze testy wydajnościowe (benchmarki). Bardzo popularnym, standardowym benchmarkiem wydajnościowym jest TPC-C, opracowany we wrześniu 1992 roku przez organizację TPC. Benchmark TPC-C jest zorientowany na badanie wydajności systemów przetwarzania transakcyjnego (OLTP) – z dużą liczbą użytkowników oraz dużą liczbą operacji wprowadzania i modyfikowania danych biznesowych (ostatnia, piąta Read more about Wykonywanie testów wydajnościowych TPC-C: narzędzie HammerDB[…]