Działanie kosztowego optymalizatora zapytań w uproszczeniu polega na: (1) transformacji tekstu zapytania SQL, (2) generowaniu alternatywnych planów wykonania zapytania, (3) estymacji ich kosztów, (4) wyborze tego planu wykonania, którego estymowany koszt jest najniższy. Transformacja tekstu zapytania SQL może obejmować np. scalanie definicji perspektywy, „wpychanie” predykatów, rozwijanie podzapytań, przepisywanie zapytań na perspektywy materializowane. Z kolei alternatywne plany wykonania zapytania mogą się różnić np. kolejnością łączenia tabel, algorytmami łączenia tabel, wyborem indeksów. Programista/administrator może oczywiście w łatwy sposób poznać zwycięski plan wykonania zapytania. Ale jak śledzić pośrednie czynności wykonywane przez optymalizator na drodze do tego planu? Pomocą może być niejawna funkcja serwera bazy danych: zdarzenie 10053.
Po wykonaniu w bieżącej sesji polecenia:
alter session set events '10053 trace name context forever, level 1';
serwer utworzy plik śladu (w lokalizacji USER_DUMP_DEST), w którym opisywane będą wewnętrzne czynności optymalizatora zapytań (aż do zakończenia sesji). Zawartość pliku śladu obejmie: parametry optymalizatora, statystyki indeksów, statystyki kolumn, koszty operacji odczytu i łączenia tabel, kolejności i algorytmy łączenia tabel. Lektura tego pliku pozwala lepiej rozumieć subtelności funkcjonowania optymalizatora, a także rozpoznawać powody jego nierzadkich błędnych wyborów.