No i kolejny POUG za nami! Organizatorzy ORA600 dali z siebie wszystko i w tym roku przebili nawet samych siebie. Konferencja w salach kinowych kina Nowe Horyzonty we Wrocławiu to strzał w dziesiątkę. Prezentacje wyświetlane na olbrzymich kinowych ekranach, wygodne, miękkie fotele i atmosfera luksusu! Czegoś takiego to jeszcze nie było!
A do tego w tym roku naprawdę był fantastyczny wybór prezentacji. I nie tylko administratorzy mogli wybierać ale również developerzy mieli ogromy wybór ciekawych tematów. Sama czasem miałam dylemat i najchętniej bym poszła na dwie równoległe prezentacje!
A działo się działo:
Adam Kierzkowski
Low-code development in Oracle
Adam opowiedział, a potem żeby nie być gołosłownym, zaprezentował szybkie prototypowanie w APEX. Magia quick SQL dostępna w Oracle 18 zdecydowanie mnie urzekła! Koniecznie muszę wypróbować :D
Dani Schnider
The SQL horror show
45 minut prawdziwego horroru! Zapytania wijące się przez kilka ekranów i u największego twardziela wywoływały ciarki na karku. Ale na szczęście - dzisiejszy horror miał happy end - wszystkie zapytania udało się zoptymalizować!
Z każdego horroru można wynieść jakąś naukę. Dobrze jest pamiętać, że najszybciej działa zapytanie, którego nie ma :) Więc i optymalizację dobrze jest zacząć od przejrzenia i uproszczenia SQL i usunięcia niepotrzebnego kodu. I czasem nic więcej nie potrzeba by przyspieszyć z kilku godzin do kilku sekund.
Keep your SQL simple. And fast.
Erik van Roon
Calling userdefined functions from SQL queries got faster in Oracle 12c.
Erik podjął się zadania porównania wydajności wywoływania funkcji PLSQL z SQL z wykorzystaniem klauzuli WITH, PRAGMA UDF, result cache, funkcji DETERMINISTIC czy scalar subquery caching.
Wnioski nie są zbyt optymistyczne.
Warto próbować chować PLSQL w klauzuli WITH, lecz nie dla wszystkich funkcji będzie miało to sens. Przydatny może być hint with_plsql w przypadku, gdy funkcja nie jest wywoływana w top level SQL.
Deterministic - w wersji 12.1 jest brutalnie ignorowana, w wersjach wyższych raz działa a raz nie działa. Związane jest to z bugiem 27329690, więc może kiedyś zostanie to naprawione. Może. Kiedyś. Na razie aż do wersji 19 - nie jest.
Scalar subquery caching działa w wersji 12.1. /jupi!
Jednak w wyższych wersjach już nie. :o
Pragma UDF - zgodnie z dokumentacją MOŻE poprawić wydajność. Może. Ale nie musi. Może na przykład tę wydajność pogorszyć. Także trzeba być czujnym.
Z testów Erika nic nie wynika. Zastosowanie powyższych technik może pomóc ale nie musi. Co ciekawe, na wydajność wpływa również typ parametrów wejściowych oraz typ zwracany w klauzuli RETURN funkcji wywoływanej z SQL. Także w zasadzie nic nie można założyć. Można jedynie próbować i testować.
A najlepiej nie wywoływać funkcji PL/SQL z SQL. I już, po problemie :D
Jacek Gębal
Test your PL/SQL - your database will love you
Jacek podczas prezentacji gorąco zachęcał do testowania. W czasach gdy "testy na prodzie zawsze w modzie" jest to odświeżające. Jacek przypomniał zasadę F.I.R.S.T, o których warto w kontekście testów pamiętać: F-fast, I-Isolated, R-repeatable, S-Self-verifying, T-thorough and timely.
Zaskoczyło mnie jednak podejście Jacka zachęcające do testowania w ramach testów jednostkowych i TDD wymagań i oczekiwań klienta. Jest to podejście bardzo kosztowne i czasochłonne. Lepsze wydaje się klasyczne podejście inżynierii oprogramowania definiujące testy jednostkowe jako stricte techniczne testy jednostek programowych: testy parametrów, wartości brzegowych, ścieżek logicznych, pętli itp. Na tym etapie jeśli już coś ma być weryfikowane to projekt techniczny (o ile jest :P) a nie wymagania. Na testy funkcjonalne jeszcze przyjdzie czas. Testowanie wymagań na etapie developmentu to bardzo drogi luksus, potrafiący niepotrzebnie zwielokrotnić koszty tworzenia oprogramowania.
Abstrahując jednak od definicji testów jednostkowych zaprezentowane przez Jacka narzędzie utPLSQL v3 to doskonała pomoc tak przy klasycznych testach jednostkowych jak i przy testach funkcjonalnych. W prosty sposób umożliwia definiowanie testów, zarządzaniem transakcyjnością testów oraz posiada spory zestaw raportów wizualizujących nasze zmagania z testami.
Także jeśli ktoś szuka fajnego narzędzia to z pewnością można polecić utPLSQL.
LOTHAR FLATZ
The MacGyver Approach
Optymalizacja zapytań to fantastyczna zabawa niemniej często wymagająca dużych zmian w kodzie, przez co czasochłonna. A klient nierzadko niecierpliwy i wymagający, oczekujący szybkich efektów. I wtedy trzeba zacząć kombinować, a do kombinowania w Oracle fantastycznie nadają się hinty.
Na początku należy rozwiać mit, że hinty mogą być zignorowane przez Oracle. Nie, nie mogą. Oracle MUSI zastosować hint. No chyba, że się nie da :). Hinty są przymierzane do zapytania PO TRANSFORMACJI, więc zapytanie może być niezbyt podobne do zapytania, które napisaliśmy i nasz hint może w ogóle nie mieć racji bytu.
Hm, czyli podsumowując, nie zawsze będzie hint zastosowany :P
Lothar udowodnił, że hintami można wywrócić zapytanie do góry nogami. Dosłownie!
Neil Chandler
Database Stats. Doing It Right, The Easy Way
Statystyki to podstawa wydajnej bazy danych. Neil pokazał na prezentacji jak prawidłowo naliczać statystyki i jak unikać typowych pułapek. Szczególnie warto zwrócić uwagę na standardowe okna uruchamiania naliczania automatycznych statystyk. W dni robocze okno zaczyna się o 22 i maksymalnie może trwać 4 godziny, w weekendy zaś od 6 rano przez 10 godzin. Dobrze jest na to zwrócić uwagę - jeśli statystyki liczą się dłużej niż okno, to zostaną zatrzymane i tak naprawdę nigdy się nie naliczą. Należy wtedy albo skrócić czas naliczania np. zmniejszając próbkę lub wydłużyć okno. Trzeba też rozważyć okno weekendowe, w wielu firmach systemy działają w weekendy tak samo jak w dni robocze i naliczanie statystyk w ciągu dnia może poważnie wpłynąć na wydajność aplikacji.
Statystyki są niezwykle potrzebne ale wymagają należytej dbałości.
MARTIN WIDLAKE
The Heart of Oracle
Martin zaprezentował na slajdach bijące serce Oracle i przepływ krwi w plikach i blokach systemu. Wszystko to by zapewnić jakość i spójność naszych danych.
SHASANK CHAVAN
Deep Dive into the Implementation of Oracle's Join Methods: Past, Present and Future
Hash join, merge join i nested loop to klasyczne sposoby łączenia tabel. Klasyczne i wydawałoby się nie do ruszenia. Ale okazało się, że Oracle nie zasypuje gruszek w popiele i nawet tutaj wprowadza śmiałe modyfikacje i ulepszenia.
Warto zwrócić uwagę na takie pojęcia jak fast bloom filter, join groups, vector group by transformation (VGBY), dense grouping key (DGKS) a wszystko to w database in memory (DBIM).
A patrząc w przyszłość kluczowe mogą okazać się EXADATA, persistent memory, hardware acceleration czy chunk hash join.
Przyszłość wygląda hmm… wydajnie :D
JIM CZUPRYNSKI
Conquer Big Data with Oracle 18c, In-Memory External Tables and Analytic Functions
Kolejna prezentacja gdzie patrzymy w przyszłość. Bazy danych stają przed wyzwaniem przechowywanie zettabajtów danych. Przetwarzamy niewiarygodne ilości informacji, która musi być przechowywana a dzisiejszy konsument oczekuje przetwarzania danych w czasie rzeczywistym. Oracle musi się stać prawdziwą wyrocznią, musi analizować miliony danych i na ich podstawie przewidywać, wyciągać wnioski, podejmować decyzje.
W USA w ten sposób przyznawane są wizy - to system na podstawie punktów decyduje, czy jesteś godny zostać obywatelem USA. W Chinach zaś życie dogoniło filmy s-f - ludziom przypisywane są punkty od których zależy praktycznie każdy aspekt ich życia!
Jak sobie radzić z taką ilością danych? Obecnie w modzie są systemy typu noSQL. Jednak to może być taki typowy awocado toast. Modny i smaczny jednak żeby się najeść to potrzebujesz steka z jajami! A takim stekiem jest Oracle.
Oracle ma wszelkie narzędzia i możliwości by zmierzyć się z taką ilością danych. Trzeba tylko je wykorzystać! Analytical views, in-memory external tables, partitioned external tables, top-n approximate aggregation to jedne z wielu z nowoczesnych technik Oracle do wydajnego przechoytwania i przetwarzania gigantycznych ilości danych!
Ja też wolę stek od awokado :D
Wszystkie prezentacje, na których udało mi się być były rewelacyjne. I starzy wyjadacze i młodzi prelegenci dali oraclowego czadu (pytanie ile w tym wrodzonej charyzmy a ile piwa :D)
Już nie mogę się doczekać kolejnej edycji. Ciekawe czy uda się przebić tegoroczną konferencję? Będzie ciężko :)
Do zobaczenia!
Adam opowiedział, a potem żeby nie być gołosłownym, zaprezentował szybkie prototypowanie w APEX. Magia quick SQL dostępna w Oracle 18 zdecydowanie mnie urzekła! Koniecznie muszę wypróbować :D
Dani Schnider
The SQL horror show
Z każdego horroru można wynieść jakąś naukę. Dobrze jest pamiętać, że najszybciej działa zapytanie, którego nie ma :) Więc i optymalizację dobrze jest zacząć od przejrzenia i uproszczenia SQL i usunięcia niepotrzebnego kodu. I czasem nic więcej nie potrzeba by przyspieszyć z kilku godzin do kilku sekund.
Keep your SQL simple. And fast.
Erik van Roon
Calling userdefined functions from SQL queries got faster in Oracle 12c.
Erik podjął się zadania porównania wydajności wywoływania funkcji PLSQL z SQL z wykorzystaniem klauzuli WITH, PRAGMA UDF, result cache, funkcji DETERMINISTIC czy scalar subquery caching.
Wnioski nie są zbyt optymistyczne.
Warto próbować chować PLSQL w klauzuli WITH, lecz nie dla wszystkich funkcji będzie miało to sens. Przydatny może być hint with_plsql w przypadku, gdy funkcja nie jest wywoływana w top level SQL.
Deterministic - w wersji 12.1 jest brutalnie ignorowana, w wersjach wyższych raz działa a raz nie działa. Związane jest to z bugiem 27329690, więc może kiedyś zostanie to naprawione. Może. Kiedyś. Na razie aż do wersji 19 - nie jest.
Scalar subquery caching działa w wersji 12.1. /jupi!
Jednak w wyższych wersjach już nie. :o
Pragma UDF - zgodnie z dokumentacją MOŻE poprawić wydajność. Może. Ale nie musi. Może na przykład tę wydajność pogorszyć. Także trzeba być czujnym.
Z testów Erika nic nie wynika. Zastosowanie powyższych technik może pomóc ale nie musi. Co ciekawe, na wydajność wpływa również typ parametrów wejściowych oraz typ zwracany w klauzuli RETURN funkcji wywoływanej z SQL. Także w zasadzie nic nie można założyć. Można jedynie próbować i testować.
A najlepiej nie wywoływać funkcji PL/SQL z SQL. I już, po problemie :D
Jacek Gębal
Test your PL/SQL - your database will love you
Jacek podczas prezentacji gorąco zachęcał do testowania. W czasach gdy "testy na prodzie zawsze w modzie" jest to odświeżające. Jacek przypomniał zasadę F.I.R.S.T, o których warto w kontekście testów pamiętać: F-fast, I-Isolated, R-repeatable, S-Self-verifying, T-thorough and timely.
Zaskoczyło mnie jednak podejście Jacka zachęcające do testowania w ramach testów jednostkowych i TDD wymagań i oczekiwań klienta. Jest to podejście bardzo kosztowne i czasochłonne. Lepsze wydaje się klasyczne podejście inżynierii oprogramowania definiujące testy jednostkowe jako stricte techniczne testy jednostek programowych: testy parametrów, wartości brzegowych, ścieżek logicznych, pętli itp. Na tym etapie jeśli już coś ma być weryfikowane to projekt techniczny (o ile jest :P) a nie wymagania. Na testy funkcjonalne jeszcze przyjdzie czas. Testowanie wymagań na etapie developmentu to bardzo drogi luksus, potrafiący niepotrzebnie zwielokrotnić koszty tworzenia oprogramowania.
Abstrahując jednak od definicji testów jednostkowych zaprezentowane przez Jacka narzędzie utPLSQL v3 to doskonała pomoc tak przy klasycznych testach jednostkowych jak i przy testach funkcjonalnych. W prosty sposób umożliwia definiowanie testów, zarządzaniem transakcyjnością testów oraz posiada spory zestaw raportów wizualizujących nasze zmagania z testami.
Także jeśli ktoś szuka fajnego narzędzia to z pewnością można polecić utPLSQL.
LOTHAR FLATZ
The MacGyver Approach
Optymalizacja zapytań to fantastyczna zabawa niemniej często wymagająca dużych zmian w kodzie, przez co czasochłonna. A klient nierzadko niecierpliwy i wymagający, oczekujący szybkich efektów. I wtedy trzeba zacząć kombinować, a do kombinowania w Oracle fantastycznie nadają się hinty.
Na początku należy rozwiać mit, że hinty mogą być zignorowane przez Oracle. Nie, nie mogą. Oracle MUSI zastosować hint. No chyba, że się nie da :). Hinty są przymierzane do zapytania PO TRANSFORMACJI, więc zapytanie może być niezbyt podobne do zapytania, które napisaliśmy i nasz hint może w ogóle nie mieć racji bytu.
Hm, czyli podsumowując, nie zawsze będzie hint zastosowany :P
Lothar udowodnił, że hintami można wywrócić zapytanie do góry nogami. Dosłownie!
Neil Chandler
Database Stats. Doing It Right, The Easy Way
Statystyki to podstawa wydajnej bazy danych. Neil pokazał na prezentacji jak prawidłowo naliczać statystyki i jak unikać typowych pułapek. Szczególnie warto zwrócić uwagę na standardowe okna uruchamiania naliczania automatycznych statystyk. W dni robocze okno zaczyna się o 22 i maksymalnie może trwać 4 godziny, w weekendy zaś od 6 rano przez 10 godzin. Dobrze jest na to zwrócić uwagę - jeśli statystyki liczą się dłużej niż okno, to zostaną zatrzymane i tak naprawdę nigdy się nie naliczą. Należy wtedy albo skrócić czas naliczania np. zmniejszając próbkę lub wydłużyć okno. Trzeba też rozważyć okno weekendowe, w wielu firmach systemy działają w weekendy tak samo jak w dni robocze i naliczanie statystyk w ciągu dnia może poważnie wpłynąć na wydajność aplikacji.
Statystyki są niezwykle potrzebne ale wymagają należytej dbałości.
MARTIN WIDLAKE
The Heart of Oracle
Martin zaprezentował na slajdach bijące serce Oracle i przepływ krwi w plikach i blokach systemu. Wszystko to by zapewnić jakość i spójność naszych danych.
SHASANK CHAVAN
Deep Dive into the Implementation of Oracle's Join Methods: Past, Present and Future
Hash join, merge join i nested loop to klasyczne sposoby łączenia tabel. Klasyczne i wydawałoby się nie do ruszenia. Ale okazało się, że Oracle nie zasypuje gruszek w popiele i nawet tutaj wprowadza śmiałe modyfikacje i ulepszenia.
Warto zwrócić uwagę na takie pojęcia jak fast bloom filter, join groups, vector group by transformation (VGBY), dense grouping key (DGKS) a wszystko to w database in memory (DBIM).
A patrząc w przyszłość kluczowe mogą okazać się EXADATA, persistent memory, hardware acceleration czy chunk hash join.
Przyszłość wygląda hmm… wydajnie :D
JIM CZUPRYNSKI
Conquer Big Data with Oracle 18c, In-Memory External Tables and Analytic Functions
Kolejna prezentacja gdzie patrzymy w przyszłość. Bazy danych stają przed wyzwaniem przechowywanie zettabajtów danych. Przetwarzamy niewiarygodne ilości informacji, która musi być przechowywana a dzisiejszy konsument oczekuje przetwarzania danych w czasie rzeczywistym. Oracle musi się stać prawdziwą wyrocznią, musi analizować miliony danych i na ich podstawie przewidywać, wyciągać wnioski, podejmować decyzje.
W USA w ten sposób przyznawane są wizy - to system na podstawie punktów decyduje, czy jesteś godny zostać obywatelem USA. W Chinach zaś życie dogoniło filmy s-f - ludziom przypisywane są punkty od których zależy praktycznie każdy aspekt ich życia!
Jak sobie radzić z taką ilością danych? Obecnie w modzie są systemy typu noSQL. Jednak to może być taki typowy awocado toast. Modny i smaczny jednak żeby się najeść to potrzebujesz steka z jajami! A takim stekiem jest Oracle.
Oracle ma wszelkie narzędzia i możliwości by zmierzyć się z taką ilością danych. Trzeba tylko je wykorzystać! Analytical views, in-memory external tables, partitioned external tables, top-n approximate aggregation to jedne z wielu z nowoczesnych technik Oracle do wydajnego przechoytwania i przetwarzania gigantycznych ilości danych!
Ja też wolę stek od awokado :D
Wszystkie prezentacje, na których udało mi się być były rewelacyjne. I starzy wyjadacze i młodzi prelegenci dali oraclowego czadu (pytanie ile w tym wrodzonej charyzmy a ile piwa :D)
Już nie mogę się doczekać kolejnej edycji. Ciekawe czy uda się przebić tegoroczną konferencję? Będzie ciężko :)
Do zobaczenia!
Komentarze
Prześlij komentarz