W bazie danych umieszczamy tabel\u0119 zawieraj\u0105c\u0105 sto rekord\u00f3w, kt\u00f3re w kolumnie P\u0141E\u0106 posiadaj\u0105 99 razy warto\u015b\u0107 \u2018M\u2019 i jeden raz warto\u015b\u0107 \u2018K\u2019. Gromadzimy statystyki dla tej tabeli, gromadzimy histogram dla kolumny P\u0141E\u0106. Nast\u0119pnie wykonujemy zapytanie, kt\u00f3re w klauzuli WHERE posiada predykat UPPER(P\u0141E\u0106) = \u2018M\u2019. Jaka jest selektywno\u015b\u0107 tego predykatu? Oczywi\u015bcie 99%. Jak\u0105 selektywno\u015b\u0107 oszacuje optymalizator kosztowy? … 1%.
\nPrzyjrzyjmy si\u0119 poni\u017cszemu przyk\u0142adowi. Kolumna Rows w planie wykonania zapytania pokazuje oczekiwan\u0105 przez optymalizator liczb\u0119 rekord\u00f3w spe\u0142niaj\u0105cych nasz predykat (pami\u0119tajmy, \u017ce plan wykonania zapytania jest generowany _przed_ wykonaniem zapytania).<\/p>\n
Rows=1! A jak wida\u0107, zapytanie naprawd\u0119 zwr\u00f3ci\u0142o 99 rekord\u00f3w. Co jest przyczyn\u0105 tak powa\u017cnej pomy\u0142ki optymalizatora? Ot\u00f3\u017c sam fakt posiadania histogramu dla kolumny nie umo\u017cliwia szacowania selektywno\u015bci dla wyra\u017cenia funkcyjnego, w kt\u00f3rym taka kolumna uczestniczy. Bo oczywi\u015bcie selektywno\u015b\u0107 predykatu PLEC=\u2019M\u2019 (a dla tego predykatu mamy histogram) nie musi by\u0107 taka sama jak predykatu UPPER(PLEC)=\u2019M\u2019. W ostatnim przypadku serwer Oracle Database automatycznie przyjmuje selektywno\u015b\u0107 \u201ez kapelusza\u201d wynosz\u0105c\u0105 1% (lub 5% dla predykat\u00f3w nier\u00f3wno\u015bciowych).<\/p>\n Czy mo\u017cna w jaki\u015b spos\u00f3b pom\u00f3c optymalizatorowi we w\u0142a\u015bciwym szacowaniu selektywno\u015bci predykat\u00f3w opartych na wyra\u017ceniach? Mo\u017cna. W gr\u0119 wchodzi albo wymuszenie dynamicznego pr\u00f3bkowania, albo zebranie histogramu dla wyra\u017cenia funkcyjnego UPPER(PLEC) \u2013 jawnie lub w wyniku utworzenia indeksu funkcyjnego. Sprawd\u017amy.<\/p>\n Rows=99. Teraz estymacja jest poprawna. Wprawdzie w mojej prostej demonstracji plan wykonania zapytania nie uleg\u0142 zmianie, lecz w \u201e\u017cyciowych\u201d zastosowaniach konsekwencje by\u0142yby du\u017co powa\u017cniejsze.<\/p>\n <\/p>\n <\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":"SQL> exec dbms_stats.gather_table_stats('SYS','ARMIA',method_opt=>'FOR COLUMNS SIZE 2 PLEC');
\nSQL> set autotrace on;
\nSQL> select * from armia where upper(plec)='M';
\n...
\n99 wierszy zosta\u0142o wybranych.
\n...
\nPlan wykonywania
\n---------------------------------------------------------------------------
\n| Id | Operation\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | Name\u00a0 | Rows | Bytes | Cost (%CPU)| Time\u00a0\u00a0\u00a0\u00a0 |
\n---------------------------------------------------------------------------
\n| 0\u00a0 | SELECT STATEMENT |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | 1\u00a0\u00a0\u00a0 | 5\u00a0\u00a0\u00a0\u00a0 | 2 (0)\u00a0\u00a0\u00a0\u00a0\u00a0 | 00:00:01 |
\n|* 1 | TABLE ACCESS FULL| ARMIA | 1\u00a0\u00a0\u00a0 | 5\u00a0\u00a0\u00a0\u00a0 | 2 (0)\u00a0\u00a0\u00a0\u00a0\u00a0 | 00:00:01 |
\n---------------------------------------------------------------------------
\n<\/code><\/p>\nSQL> alter system set optimizer_dynamic_sampling=3;
\nSQL> select * from armia where upper(plec)='M';
\n...
\n99 wierszy zosta\u0142o wybranych.
\n...
\nPlan wykonywania
\n---------------------------------------------------------------------------
\n| Id | Operation\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 | Name\u00a0 | Rows | Bytes | Cost (%CPU)| Time\u00a0\u00a0\u00a0\u00a0 |
\n---------------------------------------------------------------------------
\n| 0\u00a0 | SELECT STATEMENT | \u00a0 \u00a0 \u00a0 | 99 \u00a0 | 495\u00a0\u00a0 | 2 (0)\u00a0\u00a0\u00a0\u00a0\u00a0 | 00:00:01 |
\n|* 1 | TABLE ACCESS FULL| ARMIA | 99 \u00a0 | 495\u00a0\u00a0 | 2 (0)\u00a0\u00a0\u00a0\u00a0\u00a0 | 00:00:01 |
\n---------------------------------------------------------------------------
\n<\/code><\/p>\n