Koszt zapytania a szybkość wykonania + paralelizm

Question

Mój wydział został niedawno upomniany (ładnie) przez nasz dział IT za prowadzenie zapytań o bardzo wysokie koszty przy założeniu, że nasze zapytania mają realną możliwość destabilizacji i/lub awarii bazy danych. Nikt z nas nie jest administratorem DBA; byli tylko badaczami, którzy piszą i wykonują zapytania w bazie danych i prawdopodobnie jestem jedynym, który kiedykolwiek spojrzał na plan wyjaśniający przed reprymendą.

Powiedziano nam, że koszty zapytania powyżej 100 powinny być bardzo rzadkie, a zapytania o kosztach powyżej 1000 nigdy nie powinny być uruchamiane. Problemy, które napotykam, są takie, że koszt wydaje się nie mieć korelacji z czasem realizacji, a tracę wydajność, próbując zoptymalizować moje zapytania.

Jako przykład mam zapytanie, które wykonuje się w czasie poniżej 5 sekund z kosztem 10844. Przepisałem zapytanie, aby użyć widoku zawierającego większość potrzebnych informacji, i obniżyłem koszt do 109, ale nowe zapytanie, które pobiera te same wyniki, trwa 40 sekund. Znalazłem tu pytanie z możliwych wyjaśnień:

Measuring Query Performance : "Execution Plan Query Cost" vs "Time Taken"

Pytanie to doprowadziło mnie do podpowiedzi równoległości. Próbowałem użyć /*+ no_parallel*/ w zapytaniu o cenę 10884, ale koszt się nie zmienił, ani też czasu wykonania, więc nie jestem pewien, czy równoległość jest wytłumaczeniem dla szybszego czasu wykonania, ale wyższego kosztu. Następnie próbowałem użyć podpowiedzi /*+ parallel(n)*/ i stwierdziłem, że im wyższa wartość jest n, tym niższy koszt zapytania. W przypadku zapytania o koszt 10844 stwierdziłem, że /*+ parallel(140)*/ obniżył koszt do 97, z bardzo niewielkim wzrostem czasu realizacji.

To wydawało się idealne „oszukać” w celu spełnienia wymagań, że nasz dział IT określone, ale potem czytam to:

http://www.oracle.com/technetwork/articles/datawarehouse/twp-parallel-execution-fundamentals-133639.pdf

Artykuł zawiera zdanie:

Parallel wykonanie może umożliwić pojedynczym operacjom wykorzystanie wszystkich zasobów systemowych.

Więc moje pytania to:

jestem faktycznie umieszczenie więcej obciążenie zasobów serwerów za pomocą wskazówkę /*+ parallel(n)*/ z bardzo wysokim stopniem równoległości, chociaż jestem obniżenie kosztów?

Zakładając, że nie ma równoległości, czy szybkość wykonania jest lepszą miarą używanych zasobów niż kosztów?

Answer 1

Reguła, którą dała ci DBA, nie ma większego sensu. Martwienie się o koszt zgłoszony w zapytaniu jest bardzo mało wydajne. Po pierwsze, nie można bezpośrednio porównać kosztu dwóch różnych zapytań - jedna kwerenda, której koszt w milionach może działać bardzo szybko i zużywać bardzo mało zasobów systemowych, inne zapytanie, które ma koszt w setkach, może działać przez wiele godzin i przynieść serwer na kolana. Po drugie, koszt jest oszacowaniem. Jeśli optymalizator dokonał dokładnego oszacowania kosztu, oznacza to, że opracował optymalny plan kwerend, co oznacza, że ​​jest mało prawdopodobne, aby można było zmodyfikować zapytanie, aby uzyskać te same wyniki przy mniejszej liczbie zasobów . Jeśli optymalizator dokonał niedokładnego oszacowania kosztu, to silnie sugeruje, że opracował słaby plan zapytań, w którym to przypadku zgłoszony koszt nie miałby związku z żadnymi użytecznymi danymi, które wymyśliłeś. W większości przypadków zapytania, które próbujesz zoptymalizować, to zapytania, w których optymalizator wygenerował nieprawidłowy plan kwerend, ponieważ niepoprawnie oszacował koszt różnych kroków.

Trapowanie optymalizatora za pomocą wskazówek, które mogą lub nie mogą zmienić planu kwerendy (na przykład w zależności od konfiguracji równoległości) jest mało prawdopodobne, aby rozwiązać problem - jest o wiele bardziej prawdopodobne, że prognozy optymalizatora być mniej dokładne i bardziej prawdopodobne, że wybierze plan kwerendy, który zużywa znacznie więcej zasobów, niż potrzebuje. Na przykład podpowiedź o wysokim stopniu równoległości oznacza, że ​​Oracle drastycznie obniży koszt pełnego skanowania tabeli, co bardziej prawdopodobne, że optymalizator wybierze to podczas skanowania indeksu. To rzadko coś, co chcielibyśmy zobaczyć w twoich DBA.

Jeśli szukasz pojedynczej metryki, która mówi, czy plan zapytania jest rozsądny, użyłbym ilości logicznych operacji we/wy. Logiczne operacje we/wy są bardzo dobrze skorelowane z rzeczywistą wydajnością zapytań i ilością zasobów zużywanych przez zapytanie. Patrzenie na czas wykonania może być problematyczne, ponieważ różni się znacząco w zależności od tego, jakie dane są buforowane (dlatego zapytania są często uruchamiane znacznie szybciej przy drugim uruchomieniu), podczas gdy logiczne operacje we/wy nie zmieniają się w zależności od danych. w pamięci podręcznej. Pozwala także na skalowanie oczekiwań jako liczbę wierszy potrzebnych do przetworzenia zmian. Jeśli piszesz zapytanie, które na przykład wymaga zagregowania danych z 1 miliona wierszy, powinno zużyć znacznie więcej zasobów niż zapytanie, które musi zwrócić 100 wierszy danych z tabeli bez agregacji. Jeśli patrzysz na logiczne operacje we/wy, możesz łatwo skalować swoje oczekiwania do rozmiaru problemu, aby dowiedzieć się, jak efektywne mogą być twoje zapytania.

W Christian Antognini w „Troubleshooting Oracle Performance” (strona 450), na przykład, daje zasada, która jest dość rozsądne

• 5 logiczne czyta na wiersz, który jest zwracany/zagregowane jest prawdopodobnie bardzo dobry
• 10 logicznych odczytów dla każdego rzędu, który jest zwracany/zespolonego prawdopodobnie odpowiednie
• 20+ logicznych odczytów dla każdego rzędu, który jest zwracany/agregowana prawdopodobnie nieefektywny i musi być nastawione

Różne systemy z różnymi modelami danych mogą wymagać nieco szczypania wiaderka, ale mogą to być dobre punkty początkowe.

Domyślam się, że jeśli jesteście naukowcami, którzy nie są programistami, prawdopodobnie uruchamiacie zapytania, które muszą agregować lub pobrać stosunkowo duże zbiory danych, przynajmniej w porównaniu do tych, które często piszą twórcy aplikacji. Jeśli skanujesz milion wierszy danych w celu wygenerowania zbiorczych wyników, twoje zapytania będą naturalnie zużywać znacznie więcej zasobów niż programista aplikacji, którego zapytania odczytują lub zapisują kilka wierszy. Być może piszesz zapytania, które są równie skuteczne z logicznej perspektywy we/wy na wiersz, możesz po prostu patrzeć na wiele innych wierszy.

Jeśli korzystasz z zapytań dotyczących bazy danych produkcji na żywo, być może zdarzy się sytuacja, że ​​rozpoczęcie segregacji zadań jest uzasadnione. Większość organizacji osiąga punkt, w którym uruchamianie raportów raportowania w bazie danych na żywo zaczyna powodować problemy z systemem produkcyjnym. Jednym z typowych rozwiązań tego problemu jest utworzenie osobnej bazy danych raportowania, która jest pobierana z systemu produkcyjnego (za pośrednictwem nocnej migawki lub przez trwający proces replikacji), gdzie zapytania raportujące mogą być uruchamiane bez zakłócania działania aplikacji produkcyjnej. Innym powszechnym rozwiązaniem jest użycie czegoś takiego jak Oracle Resource Manager, aby ograniczyć ilość zasobów dostępnych dla jednej grupy użytkowników (w tym przypadku twórców raportów) w celu zminimalizowania wpływu na użytkowników o wyższym priorytecie (w tym przypadku użytkownicy produkcji system).