#ghostdata – czyli jak odzyskać stracony kod PL/SQL

Są takie chwile, w których żałujemy, że systemy klasy Enterprise nie pytają 27 razy, czy aby na pewno chcemy wykonać żądaną akcję. Dzieje się tak zwykle w okolicach wczesnych godzin porannych, kiedy kolejna kawa straciła nie tylko swój wymiar fizyczny, ale również działanie placebo.

Nazywam takie chwile „o jeden drop za daleko” lub „o jeden enter za daleko”. W takich sytuacjach bazy produkcyjne – działające w trybie 24/7 – mają okazję wykorzystać te 0,03% czasu SLA, a deweloperzy zyskują niebywałą przyjemność przemyślenia swojego kodu po raz kolejny. Myślę, że był to jeden z powodów wprowadzenia przez Oracle opcji kosza dla tabel i ich zależności.

Niestety polecenie SHOW RECYCLEBIN nie zwróci nam pożądanych wyników po usunięciu ciężko stworzonego pakietu, procedury lub funkcji PL/SQL. Większość artykułów, które można znaleźć w internecie, rozwiązuje ten problem, opierając się na użyciu tzw. FLASHBACK QUERY, wykonanego na perspektywie DBA_SOURCE. Tego typu zapytanie miałoby następującą konstrukcję:

Problem z tego typu rozwiązaniem polega na tym, że jesteśmy bardzo uzależnieni od wielkości przestrzeni tabel UNDO oraz ilości transakcji, które odbywają się teraz na bazie. To znaczy, że jeśli mieliśmy pecha, dostaniemy komunikat ORA-01555 Snapshot Too Old.

Jak pominąć UNDO

Na szczęście w takiej sytuacji mamy jeszcze jedną możliwość odzyskania naszego kodu i odłożenia na później decyzji o powrocie do palenia lub wyprowadzenia się w Bieszczady. Każda linijka naszego kodu jest przechowywana jako wiersz w tabeli SOURCE$, która jest podstawą dla widoku DBA_SOURCE. Jeśli więc stworzę testowy pakiet…

…będę mógł sprawdzić jego fizyczne położenie w przestrzeni tabel SYSTEM, posługując się jednym zapytaniem:

Wynik powyższego zapytania pokazuje mi, że treść mojego pakietu znajduje się w całości w bloku 100234 w wierszach od 40 do 48.

Przyjrzyjmy się teraz heksadecymalnemu zrzutowi tego fragmentu pliku przestrzeni tabel SYSTEM przed usunięciem pakietu.

Oraz po jego usunięciu.

Uważniejsza analiza pokaże nam, że jedyne, co uległo zmianie, to dwa pierwsze bajty – z 2c00 na 3c01. Flaga 3c oznacza, że wiersz jest usunięty, więc nie jest widoczny dla bazy danych i jego przestrzeń w bloku może być ponownie wykorzystana.

Jeśli się więc pospieszymy – możemy odzyskać nasz pakiet. W 2015 roku stworzyłem narzędzie RICO (fani pingwinów z Madagaskaru wiedzą, że Rico zwracał przydatne rzeczy na żądanie). Dzięki niemu możemy odtwarzać dane z uszkodzonych – lub osieroconych plików – nie posiadając backupu, a znając jedynie fizyczną strukturę tabeli wraz z typami danych w poszczególnych kolumnach.

Ostatnio postanowiłem zmodyfikować RICO i wypuścić jego wersję demo, która skanuje przestrzeń tabel SYSTEM i odtwarza usunięty kod PL/SQL (oznaczony flagą 3c), który znajduje w blokach należących do tabeli SOURCE$. Jeśli więc mamy szczęście, a nasze dane nie zostały jeszcze nadpisane przez inne fragmenty kodu, możemy postarać się o ostateczny krok na drodze odtwarzania – binarne przeszukanie pliku danych.

Jak widać, użycie narzędzia jest trywialne. Pytanie brzmi – czy mamy tego dnia szczęście? Narzędzie rico_source.x86_64 skompilowane dla systemów RedHat, można pobrać bezpłatnie ze strony: http://ora-600.pl/oinstall/rico_source.x86_64.

Jak rozpoznać usunięty wiersz tabeli

W trakcie wielu prowadzonych przeze mnie szkoleń spotykam się z pytaniem: Skąd wiesz, że akurat flaga 3c oznacza wiersz usunięty, przecież to wiedza tajemna!? Wyjaśniając, mówię, że są dwie uzupełniające się możliwości dojścia do rzeczy ukrytych w zamkniętym oprogramowaniu. Pierwsza to zaawansowany profiling z użyciem takich narzędzi jak perf, GDB, systemtap czy DTrace. Wiele godzin przebijania się przez kod w uroczej, czarnej konsoli z zielonymi literkami i szukania prawidłowości – oto co napędza dzień każdego administratora i programistę! Jeśli jednak nie płacą nam za poświęcanie swojego czasu na zabawy na granicy reverse engineering – a wieczorami preferujemy towarzystwo znajomych lub dobrej książki nad zgłębianiem tajemnic Wyroczni – pozostaje pozyskanie wiedzy od ludzi, którzy już to kiedyś zrobili, a teraz chętnie tą wiedzą się podzielą.

Każdy ze światowej sławy ekspertów prowadzi swój blog lub wydaje książki, w których możemy dotrzeć do rzeczy nieujawnianych w oficjalnej dokumentacji produktu. Każdy z nich jeździ również po świecie i daje wykłady na przeróżnych konferencjach, po których można wieczorem porozmawiać o nurtujących nas problemach. Poznałem większość z nich i zapewniam, że są to sympatyczni ludzie, którzy chętnie zawierają znajomości i dzielą się swoją specjalistyczną wiedzą.

Niestety do tej pory żaden z nich nie odwiedził Polski, a podróż np. do Birmingham na konferencję UKOUG może przerosnąć wydatki, które mógłby zaakceptować nasz menedżer. Standardowy bilet na tę konferencję kosztuje prawie 1000 funtów, a do tego należy dorzucić koszt zakwaterowania i podróży.

Dlatego poświęciłem ostatni rok na zbudowanie społeczności Oracle w Polsce pod nazwą POUG, czyli inaczej „Browar z Wyrocznią” (Pint with Oracle Users Group). Wynikiem moich prac jest nadchodząca w październiku dwudniowa konferencja, podczas której będziemy mogli spotkać osobiście ludzi, z których książek uczymy się na co dzień rozwiązywać problemy w administrowaniu bazami danych, i nawiązać kontakty, które mogą okazać się więcej warte niż kilkudniowe szkolenie z najlepszym specjalistą. Serdecznie zapraszam!