Jak często należy uruchamiać statystyki Oracle database?

Z Twojego doświadczenia wynika, jak często należy uruchamiać statystyki Oracle database? Nasz zespół programistów niedawno odkrył, że statystyki nie były uruchamiane w naszym pudełku produkcyjnym od ponad 2 i pół miesiąca. To brzmi jak długi czas, ale nie jestem DBA.

Author: user11318, 2008-09-17

9 answers

W mojej ostatniej pracy prowadziliśmy statystyki raz w tygodniu. Jeśli dobrze pamiętam, zaplanowaliśmy je w czwartek wieczorem, a w piątek DBAs byli bardzo ostrożni, aby monitorować najdłużej działające zapytania pod kątem niczego nieoczekiwanego. (Piątek został wybrany, ponieważ często był tuż po wydaniu kodu i miał tendencję do dość małego ruchu.) Kiedy zobaczyli złe zapytanie, znaleźli lepszy plan zapytań i zapisali go, aby nie zmienił się ponownie nieoczekiwanie. (Oracle ma do tego narzędzia automatycznie informujesz go o zapytaniu do optymalizacji i to robi.)

Wiele organizacji unika prowadzenia statystyk ze strachu przed nieoczekiwanym pojawieniem się złych planów zapytań. Ale to zwykle oznacza, że ich plany zapytań stają się coraz gorsze z czasem. A kiedy prowadzą statystyki, napotykają wiele problemów. Wynikająca z tego próba rozwiązania tych problemów potwierdza ich obawy o niebezpieczeństwa związane z prowadzeniem statystyk. Ale jeśli regularnie prowadzili statystyki, korzystali z narzędzi monitorowania tak jak powinni I naprawili problemy, gdy pojawili się wtedy mieliby mniej bólów głowy i nie napotkaliby ich wszystkich na raz.

 13
Author: user11318,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-18 05:44:52

Ponieważ statystyki Oracle 11g są domyślnie zbierane automatycznie.

Dwa okna Schedulera są predefiniowane podczas instalacji bazy danych Oracle:

  • WEEKNIGHT_WINDOW zaczyna się o 22: 00, a kończy o 6: 00 w każdy poniedziałek do piątku.
  • WEEKEND_WINDOW obejmuje całe dni soboty i niedzieli.

Kiedy ostatnio zebrano statystyki?

SELECT owner, table_name, last_analyzed FROM all_tables ORDER BY last_analyzed DESC NULLS LAST; --Tables.
SELECT owner, index_name, last_analyzed FROM all_indexes ORDER BY last_analyzed DESC NULLS LAST; -- Indexes.

Status automatycznego zbierania statystyk?

SELECT * FROM dba_autotask_client WHERE client_name = 'auto optimizer stats collection';

Okna Grupy?

SELECT window_group_name, window_name FROM dba_scheduler_wingroup_members;

Rozkład Okien?

SELECT window_name, start_time, duration FROM dba_autotask_schedule;

Ręcznie zbieraj Statystyki bazy danych w tym schemacie:

EXEC dbms_stats.gather_schema_stats(ownname=>NULL, cascade=>TRUE); -- cascade=>TRUE means include Table Indexes too.

Ręcznie zbieraj Statystyki bazy danych we wszystkich schematach!

-- Probably need to CONNECT / AS SYSDBA
EXEC dbms_stats.gather_database_stats;
 15
Author: grokster,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-05-24 18:32:51

Gdy dane zmieniają się "znacząco".

Jeśli tabela przechodzi z 1 wiersza do 200 wierszy, jest to znacząca zmiana. Gdy tabela przechodzi od 100 000 wierszy do 150 000 wierszy, nie jest to strasznie istotna zmiana. Gdy tabela przechodzi od 1000 wierszy z identycznymi wartościami w powszechnie zapytanej kolumnie X do 1000 wierszy z prawie unikalnymi wartościami w kolumnie X, jest to znacząca zmiana.

Statystyki przechowują informacje o liczbie pozycji i względnych częstotliwościach -- rzeczy, które będą niech "odgadnie" ile wierszy będzie pasowało do podanych kryteriów. Gdy zgadnie źle, optymalizator może wybrać bardzo nieoptymalny Plan zapytań.

 13
Author: Jonathan Rupp,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-17 02:47:43

Jakiej wersji Oracle używasz? Sprawdź tę stronę, która odnosi się do Oracle 10:

Http://www.acs.ilstu.edu/docs/Oracle/server.101/b10752/stats.htm

Pisze:

Zalecanym podejściem do gromadzenia statystyk jest umożliwienie Oracle automatycznego gromadzenia statystyk. Oracle automatycznie gromadzi statystyki wszystkich obiektów bazy danych i utrzymuje je w ramach regularnie zaplanowanego zadania konserwacji.

 5
Author: David Medinets,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-17 03:06:02

Kiedy zarządzałem dużym systemem planowania dla wielu użytkowników wspieranym przez Oracle, nasz DBA miał cotygodniową pracę, która zbierała statystyki. Ponadto, gdy wprowadziliśmy znaczącą zmianę, która może mieć wpływ lub być dotknięta statystykami, zmusilibyśmy pracę do wyczerpania cyklu, aby nadrobić zaległości.

 2
Author: Joe Skora,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-17 03:10:45

W przypadku wersji oracle 10g i wyższej optymalizator potrzebuje aktualnych statystyk dotyczących tabel i indeksów, aby podjąć "dobrą" decyzję o planie realizacji. Jak często zbierasz statystyki to trudne połączenie. To zależy od aplikacji, schematu, szybkości transmisji danych i praktyki biznesowej. Niektóre aplikacje innych firm, które są napisane jako kompatybilne wstecz ze starszą wersją oracle, nie działają dobrze z nowym optymalizatorem. Te aplikacje wymagają, aby tabele nie miały statystyk, tak aby db / align = "left" / Ale średnio oracle zaleca, aby statystyki były zbierane na tabelach z przestarzałymi statystykami. Możesz ustawić tabele do monitorowania i sprawdzania ich stanu oraz kazać im analizować, czy/kiedy są stare. Często to wystarczy, czasami nie. To naprawdę zależy od twojej bazy danych. Dla mojej bazy danych mamy zestaw tabel OLTP, które wymagają nocnego zbierania statystyk, aby utrzymać wydajność. Inne tabele są analizowane raz w tygodniu. W naszej dużej bazie danych dw analizujemy jako potrzebne, ponieważ tabele są zbyt duże do regularnej analizy bez wpływu na ogólne obciążenie db i wydajność. Więc prawidłowa odpowiedź jest, to zależy od aplikacji, zmiany danych i potrzeb biznesowych.

 2
Author: MichaelN,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-03-10 15:13:04

Upewnij się, że zrównoważysz ryzyko, że nowe statystyki powodują niepożądane zmiany w planach zapytań, a ryzyko, że stare statystyki mogą same spowodować zmianę planów zapytań.

Wyobraź sobie, że masz bazę danych błędów z problemem tabeli i kolumną CREATE_DATE, gdzie wartości w kolumnie zwiększają się mniej lub bardziej monotonicznie. Załóżmy, że na tej kolumnie znajduje się histogram, który mówi Oracle, że wartości dla tej kolumny są równomiernie rozłożone między 1 stycznia 2008 i 17.09.2008. Umożliwia to optymalizatorowi rozsądne oszacowanie liczby wierszy, które zostaną zwrócone, jeśli szukasz wszystkich problemów utworzonych w zeszłym tygodniu(tj. Jeśli aplikacja będzie nadal używana, a statystyki nigdy nie będą aktualizowane, histogram będzie coraz mniej dokładny. Optymalizator będzie więc oczekiwać, że zapytania dotyczące "spraw utworzonych w zeszłym tygodniu" będą z czasem coraz mniej dokładne i mogą ostatecznie spowodować zmianę zapytania Oracle planuj negatywnie.

 1
Author: Justin Cave,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-17 20:18:16

W przypadku systemu typu hurtownia danych można rozważyć zbieranie żadnych statystyk i opieranie się na dynamicznym próbkowaniu (ustawienie optimizer_dynamic_sampling na poziomie 2 lub wyższym).

 0
Author: David Aldridge,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-03-08 13:34:18

Ogólnie nie zaleca się gromadzenia statystyk tak często w całej bazie danych, chyba że masz do tego silne uzasadnienie, takie jak masowa wstawka lub duża zmiana danych zdarza się często w bazie danych. zbieranie statystyk w bazie danych w tej częstotliwości może zmienić plan wykonania zapytań na nowe słabe plany wykonania, rzecz może kosztować dużo czasu, próbując dostroić każde zapytanie dotknięte nowymi słabymi planami, dlatego powinieneś przetestować wpływ zbierania nowych statystyki w testowej bazie danych lub w przypadku, gdy nie masz na to czasu lub siły roboczej, przynajmniej powinieneś zachować plan awaryjny, tworząc kopię zapasową oryginalnych statystyk, zanim zbierzesz nowe, więc w przypadku, gdy zbierzesz nowe statystyki, a następnie zapytania nie będą działać zgodnie z oczekiwaniami, możesz łatwo przywrócić oryginalne statystyki.

Istnieje bardzo przydatny skrypt, który pomoże Ci wykonać kopię zapasową oryginalnych statystyk i zebrać nowe i dostarczyć Ci polecenie SQL, którego możesz użyć do przywrócenia Przywróć oryginalną statykę na wypadek, gdyby coś nie poszło zgodnie z oczekiwaniami po zebraniu nowych statystyk. Skrypt znajdziesz pod tym linkiem: http://dba-tips.blogspot.com/2014/09/script-to-ease-gathering-statistics-on.html

 0
Author: Chion,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-09-22 11:54:35