Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


26.10.2020

Nowa wersja nVision

Można już pobierać nową wersję nVision
26.10.2020

Monitorowanie infrastruktury

Vertiv Environet Alert
23.10.2020

Telefonia w chmurze

NFON Cloudya
23.10.2020

Nowości w EDR

Bitdefender GravityZone
23.10.2020

Wykrywanie anomalii

Flowmon ADS11
23.10.2020

Mobilny monitor

AOC 16T2
22.10.2020

HP Pavilion

HP zaprezentowało nowe laptopy z linii Pavilion.
22.10.2020

Inteligentny monitoring

WD Purple SC QD101
22.10.2020

Przełącznik 2,5GbE

QNAP QSW-1105-5T

Podstawy korzystania z DTrace

Data publikacji: 31-03-2017 Autor: Kamil Stawiarski

Odkrywamy tajemnice zamkniętego oprogramowania na przykładzie silnika baz danych Oracle oraz narzędzia DTrace umożliwiającego zaawansowaną diagnostykę systemu operacyjnego i śledzenie wykonania kodu.

Żyjemy w świecie ogólnego dostępu do informacji – wystarczy włączyć Google i zadać pytanie, żeby odnaleźć setki „faktów”. Jeśli coś zostało napisane w oficjalnej dokumentacji lub – jeszcze lepiej – w książce, stanowi to niepodważalny dowód. Często, niestety, zadowalamy się samymi hasłami, etykietkami, nie do końca rozumiejąc, co one w praktyce oznaczają. Jeśli zostanę zapytany, co to jest SCN, i odpowiem, że jest to „System Change Number” wiele osób pokiwa głowami i zapamięta hasło, nie przejmując się zrozumieniem działania tego mechanizmu. Niestety, podobne podejście cechuje wielu producentów oprogramowania podczas tworzenia dokumentacji do swoich produktów.

Oracle nie jest tu wyjątkiem – możemy znaleźć wiele wspaniałych wpisów w dokumentacji, takich jak: „Subsequent invocations of other subprograms in same the package require no disk I/O” albo: „The UDF pragma tells the compiler that the PL/SQL unit is a user defined function that is used primarily in SQL statements, which might improve its performance” czy też: „Oracle Database 10g will automatically optimize my cursor FOR loops to perform at speeds comparable to bulk collect”. Wszystkie powyższe stwierdzenia są prawdziwe, jednak próby głębszego zrozumienia opisanych mechanizmów i reguł, które nimi rządzą, doprowadzą nas do wniosku, że w rzeczywistości niczego nie rozumiemy. W przypadku otwartego oprogramowania można w miarę łatwo dojść do prawdy, analizując jego kod, ale aby odkryć tajemnicę zamkniętego kodu, jesteśmy zdani na łaskę i niełaskę oficjalnych szkoleń i publikacji. Na szczęście dostępne są też narzędzia typu DTrace, które pozwalają na uchylenie rąbka tajemnicy.

> Przygotowania

Najłatwiej rozpocząć pracę z narzędziem DTrace na Solarisie. System operacyjny można pobrać ze strony Oracle i zainstalować na przykład w postaci maszyny wirtualnej na VirtualBoksie. Potem instalacja bazy i jesteśmy gotowi do testowania.

DTrace (Dynamic Tracing Framework) jest narzędziem, które pozwala na zaawansowaną diagnostykę systemu operacyjnego i odkrywanie tajemnic oprogramowania działającego na Solarisie. Dzięki niemu możemy wiele wydedukować na temat wewnętrznych mechanizmów systemu i aplikacji.

Dedukcja nazw wewnętrznych funkcji Oracle

W publikacjach technicznych wielokrotnie można znaleźć informację, że np. funkcja kcbgtcr odpowiada za spójny odczyt bloku danych. Po samej nazwie trudno to zgadnąć. Skąd więc pewność? Spójrzmy na prosty skrypt D, który pozwala na sprawdzenie liczby wykonań poszczególnych funkcji C:

#!/usr/sbin/dtrace -s
pid$1:::entry
{
@fcount[probemod,probefunc]=count();
}

Ten krótki skrypcik DTrace, pozwoli nam na wyświetlenie nazwy funkcji C i informacji, ile razy nastąpiło wywołanie tej funkcji. Rozbijmy je na części pierwsze:

#!/usr/sbin/dtrace –s

Kolejna linia to wskazanie interpretera skryptu:

pid$1:::entry

Standardowa składnia tej linii wygląda następująco:

PROVIDER:MODULE:FUNCTION:NAME>

Zapis ten identyfikuje tzw. próbkę, którą można porównać ze swego rodzaju breakpointem. To hierarchiczny zapis tego, co tak naprawdę chcemy śledzić. Oto wyjaśnienie poszczególnych składowych komendy:

 

  • PROVIDER – główny komponent, zbiór próbek; należy traktować go jako największy kontener w kategoryzacji próbek. Przykłady: FBT, SYSCALL itp.;
  • MODULE – zbiór funkcji pogrupowanych logicznie, takich jak np. funkcje w pakiecie a.out;
  • FUNCTION – nazwa funkcji;
  • NAME – nazwa punktu wywołania próbki, np. ENTRY (punkt wejścia do funkcji) lub RETURN (miejsce opuszczenia funkcji).

 

Jeśli opuścimy dowolny element składni, będzie to równoważne z wpisaniem symbolu * – co oznacza, że interesuje nas wszystko, co w danej kategorii będzie można przechwycić.

W ten sposób zapis pid$1:::entry oznacza, że PROVIDER to PID procesu, który zostanie podany do skryptu jako pierwszy argument, interesują nas wszystkie jego moduły i wszystkie funkcje, ale śledzić chcemy tylko wejścia do funkcji.

[...]

Autor jest jedynym w Polsce zdobywcą tytułu Oracle ACE, posiadającym jednocześnie tytuł Oracle Certified Master.

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"