Fajnie obejrzę, super że są indeksy... ale kiedy ORACLE ogarnie się jeśli chodzi o prawidłowe plany przy niektórych zapytaniach gdzie używamy klauzuli OR :D... bo wstyd jakby jakaś podścianowa baza danych ;)
@@nieinformatyk Myślałem, że jest Ci temat znany!. (ProductNr='1111') vs (1=2 OR ProductNr='1111'), ten drugi czasami zepsuje wszystko i liczy się 30 razy dłużej. Przykład jest na oracle community temat: Slow query when using OR operater in WHERE clause (bo linka przecież nie wstawie)
@@TomaszTomzik a udało Ci się wygenerować taki problem? Bo mi wygląda podejrzanie. Sporo postów ludzi w internecie jest niezgodnych z prawdą, bo coś przeoczą. Poproszę o DDL-kę tabeli, insert ładujący dane i te 2 SELECT-y. Zerknę w plan i powiem o co chodzi :)
@@nieinformatyk spotkałem się z tym kilkakrotnie, problem ujawnia się co jakiś czas (zapytanie chodzi dobrze przez pół roku a tu nagle klops), dodatkowo na bardzo dużych zapytaniach często z widokami ale nie koniecznie jeśli chodzi o to drugie. Wiesz co jak natrafię znowu na taki przypadek (raz na miesiąc dwa trafiam) podeślę selekt i plany zapytań ;) Ale generalnie info potwierdzone na 100%, i to od wersji 11g do 19c, do bardzo skomplikowanego zapytania dodany zwykły OR 1=1 i całe zapytanie szlak trafia.
@@TomaszTomzik a może zmienia się rozkład danych, np. po jakimś procesie ETL a w zapytaniu zapisane są hinty? Maciej wykupiony support by zgłosić problem? :)
12:13 która kolumna ma mieć null? W podanym przykładzie nie ma żadnej kolumny mającej null. Employee_id zawsze ma wartość. Po co piszemy WHERE employee_id IS NOT NULL, gdy Employee_id nigdy nie jest null (ma wartości od 100 do 119)
pracownicy.employee_id. Zauważ, że ta kolumna nie ma constrainta NOT NULL. CREATE TABLE pracownicy ( employee_id NUMBER(6) , first_name VARCHAR2(20) , last_name VARCHAR2(25) , email VARCHAR2(25) NOT NULL , phone_number VARCHAR2(20) , hire_date DATE NOT NULL , job_id VARCHAR2(10) NOT NULL , salary NUMBER(8,2) , commission_pct NUMBER(2,2) , manager_id NUMBER(6) , department_id NUMBER(4) ); A skoro nie ma constrainta NOT NULL to skąd baza danych ma wiedzieć, że w tym polu nie ma nulli? Statystyki nie przechowują takich informacji, więc baza nie wie czy tam NULL jest czy nie. Wie tyle, że NULL jest możliwy. W związku z czym skoro nie ma ograniczenia pilnującego by nikt tam NULL-a nie wpisał to baza przeczyta tabelę, w obawie przed pominięciem nullowych rekordów, których w indeksie nie będzie. To, że w praktyce wszystkie rekordy w tabeli mają wartość w kolumnie employee_id nie ma znaczenia.
![KSI - Dirty [Official Visualiser]](http://i.ytimg.com/vi/VoDh1h1dPUE/mqdefault.jpg)
Mało jest informacji na ten temat, a ty jak zrobisz materiał to człowiek obejrzy rozumie świetna robota dziękuję 👍😃
cieszę się, że nagranie przypadło do gustu :)
Ooo jest cz 2 odcinka sprzed 2 lat, super, zara będzie oglądane, cz1 była super
Jak zawsze pełen profesjonalizm :)
Dzięki Arek :)
Bardzo fajny film. Polubione
dziękuję :)
Super!
dzięki :)
Dzięki za ten film
Proszę bardzo :)
Super materiał 🏆
dzięki :)
Świetny materiał.
dzięki :)
Fajnie obejrzę, super że są indeksy... ale kiedy ORACLE ogarnie się jeśli chodzi o prawidłowe plany przy niektórych zapytaniach gdzie używamy klauzuli OR :D... bo wstyd jakby jakaś podścianowa baza danych ;)
jakiś przykład możesz podesłać? bo nie bardzo mam jak się do tego odnieść :)
@@nieinformatyk Myślałem, że jest Ci temat znany!. (ProductNr='1111') vs (1=2 OR ProductNr='1111'), ten drugi czasami zepsuje wszystko i liczy się 30 razy dłużej. Przykład jest na oracle community temat: Slow query when using OR operater in WHERE clause (bo linka przecież nie wstawie)
@@TomaszTomzik a udało Ci się wygenerować taki problem? Bo mi wygląda podejrzanie. Sporo postów ludzi w internecie jest niezgodnych z prawdą, bo coś przeoczą.
Poproszę o DDL-kę tabeli, insert ładujący dane i te 2 SELECT-y. Zerknę w plan i powiem o co chodzi :)
@@nieinformatyk spotkałem się z tym kilkakrotnie, problem ujawnia się co jakiś czas (zapytanie chodzi dobrze przez pół roku a tu nagle klops), dodatkowo na bardzo dużych zapytaniach często z widokami ale nie koniecznie jeśli chodzi o to drugie. Wiesz co jak natrafię znowu na taki przypadek (raz na miesiąc dwa trafiam) podeślę selekt i plany zapytań ;) Ale generalnie info potwierdzone na 100%, i to od wersji 11g do 19c, do bardzo skomplikowanego zapytania dodany zwykły OR 1=1 i całe zapytanie szlak trafia.
@@TomaszTomzik a może zmienia się rozkład danych, np. po jakimś procesie ETL a w zapytaniu zapisane są hinty? Maciej wykupiony support by zgłosić problem? :)
12:13 która kolumna ma mieć null? W podanym przykładzie nie ma żadnej kolumny mającej null. Employee_id zawsze ma wartość.
Po co piszemy WHERE employee_id IS NOT NULL, gdy Employee_id nigdy nie jest null (ma wartości od 100 do 119)
pracownicy.employee_id. Zauważ, że ta kolumna nie ma constrainta NOT NULL. CREATE TABLE pracownicy
( employee_id NUMBER(6)
, first_name VARCHAR2(20)
, last_name VARCHAR2(25)
, email VARCHAR2(25) NOT NULL
, phone_number VARCHAR2(20)
, hire_date DATE NOT NULL
, job_id VARCHAR2(10) NOT NULL
, salary NUMBER(8,2)
, commission_pct NUMBER(2,2)
, manager_id NUMBER(6)
, department_id NUMBER(4)
);
A skoro nie ma constrainta NOT NULL to skąd baza danych ma wiedzieć, że w tym polu nie ma nulli? Statystyki nie przechowują takich informacji, więc baza nie wie czy tam NULL jest czy nie. Wie tyle, że NULL jest możliwy. W związku z czym skoro nie ma ograniczenia pilnującego by nikt tam NULL-a nie wpisał to baza przeczyta tabelę, w obawie przed pominięciem nullowych rekordów, których w indeksie nie będzie. To, że w praktyce wszystkie rekordy w tabeli mają wartość w kolumnie employee_id nie ma znaczenia.
#zasieg
Dzięki :)
Świetny materiał i fajnie, że wchodzisz na wyższy level, ale ten explain plan boli. W praktyce tylko execution ma sens
Dzięki. Masz na myśli, że nie ma sensu czytać planu, bo przy wykonaniu baza danych może użyć inny? Owszem, jest to możliwe, ale to raczej rzadkość.