{"id":527,"date":"2017-05-29T17:09:59","date_gmt":"2017-05-29T15:09:59","guid":{"rendered":"http:\/\/explainit.pl\/wordpress\/?p=527"},"modified":"2017-06-11T17:12:05","modified_gmt":"2017-06-11T15:12:05","slug":"jak-bardzo-statystyki-systemowe-wplywaja-na-wybor-planu-wykonania","status":"publish","type":"post","link":"https:\/\/explainit.pl\/wordpress\/2017\/05\/29\/jak-bardzo-statystyki-systemowe-wplywaja-na-wybor-planu-wykonania\/","title":{"rendered":"Jak bardzo statystyki systemowe wp\u0142ywaj\u0105 na wyb\u00f3r planu wykonania?"},"content":{"rendered":"

Wiemy, \u017ce statystyki systemowe s\u0105 wa\u017cnym opisem wydajno\u015bci wykorzystywanej platformy sprz\u0119towej oraz \u017ce kosztowy optymalizator zapyta\u0144 Oracle Database odwo\u0142uje si\u0119 do ich warto\u015bci podczas szacowania koszt\u00f3w plan\u00f3w wykonania zapyta\u0144 (pisali\u015bmy o statystykach systemowych TU<\/a>). Wielu administrator\u00f3w zastanawia si\u0119 jednak, jak bardzo optymalizator zapyta\u0144 jest „wra\u017cliwy” na warto\u015bci tych statystyk (zbieranych metodami eksperymentalnymi). Aby odpowiedzie\u0107 na to pytanie przeprowad\u017amy prosty eksperyment.<\/p>\n

Dana jest tabela o rozmiarze 375 blok\u00f3w, zawieraj\u0105ca 100 tysi\u0119cy rekord\u00f3w o \u015bredniej d\u0142ugo\u015bci 22 bajt\u00f3w. Na jednej z kolumn tej tabeli utworzony zosta\u0142 indeks (wsp\u00f3\u0142czynnik clustering_factor=371). U\u017cytkownicy wykonuj\u0105 zapytania wykorzystuj\u0105ce predykat oparty na indeksowanej kolumnie. Zapytania te maj\u0105 r\u00f3\u017cne selektywno\u015bci. Postanawiamy sprawdzi\u0107, dla jakiej granicznej selektywno\u015bci stosowany b\u0119dzie ten indeks (powy\u017cej niej nast\u0105pi pe\u0142en odczyt). Testy wykonujemy dla r\u00f3\u017cnych proporcji statystyk systemowych SREADTIM (czas wykonywania odczytu dyskowego swobodnego) i MREADTIM (czas wykonywania odczytu dyskowego wieloblokowego) – przyk\u0142adowo, gdy SREADTIM=5ms a MREADTIM=10ms, to proporcja wynosi 0.5. Wyniki eksperymentu na platformie Oracle Database 12.2 obrazuje poni\u017cszy wykres.<\/p>\n

\"sreadtim<\/p>\n

Komentarz jest nast\u0119puj\u0105cy. Relacja pomi\u0119dzy statystykami systemowymi SREADTIM i MREADTIM ma decyduj\u0105cy g\u0142os w procedurze decydowania czy zostanie u\u017cyty indeks, czy te\u017c wykonany zostanie pe\u0142en odczyt tabeli. Gdy SREADTIM by\u0142 sto razy mniejszy od MREADTIM, kosztowy optymalizator zapyta\u0144 proponowa\u0142 u\u017cycie indeksu nawet dla zapyta\u0144 o selektywo\u015bci przekraczaj\u0105cej 50%! Z kolei gdy SREADTIM mia\u0142o warto\u015b\u0107 blisk\u0105 MREADTIM, indeks przestawa\u0142 by\u0107 u\u017cywany ju\u017c przy selektywno\u015bci 4-5%.<\/p>\n

Zastanawiaj\u0105ce jest te\u017c widoczne na wykresie „zerwanie” przebiegu krzywej, gdy zr\u00f3wnuj\u0105 si\u0119 warto\u015bci SREADTIM i MREADTIM. Zjawisko to wynika z innego zachowania si\u0119 optymalizatora zapyta\u0144 w przypadku, gdy MREADTIM<SREADTIM – w takiej sytuacji (czasami wyst\u0119puj\u0105cej na macierzach dyskowych stosuj\u0105cych agresywny read-ahead) optymalizator przestaje uwzgl\u0119dnia\u0107 warto\u015b\u0107 statystyki systemowej MREADTIM. Pisano o tym wiele lat temu na blogu AskTom<\/a>.<\/p>\n

Je\u017celi wi\u0119c kto\u015b si\u0119 zastawia, dlaczego identyczne zapytania wykonywane na identycznych bazach danych, ale osadzonych na r\u00f3\u017cnych maszynach, stosuj\u0105 inne plany wykonania, to jednym z winowajc\u00f3w mog\u0105 by\u0107 w\u0142a\u015bnie statystyki systemowe.<\/p>\n

Dla przypomnienia – jak ustawia\u0107 i odczytywa\u0107 statystyki systemowe:<\/p>\n