ITIL w Oracle u incydenty, problemy i monitorowanie systemu

XVI Konferencja PLOUG Kościelisko Październik 2010 ITIL w Oracle u incydenty, problemy i monitorowanie systemu Jarosław Przybyszewski Accenture Services Sp. z o.o. jarek.przybyszewski@gmail.com Abstrakt. ITIL jest bez wątpienia najpowszechniej używanym standardem w zarządzaniu usługami IT. Popularność standardu wpływa na sposób świadczenia usług, ale także na oprogramowanie. Wpływ ITIL a na bazę danych Oracle jest widoczny od kilku lat. Najpierw pojawiły się elementy CMDB a w najnowszej wersji incydenty i problemy. Niniejsze opracowanie przybliża najnowsze elementy Oracle a 11g wchodzące w skład Fault Diagnosability Infrastructure, które są bardzo mocno związane z ITIL-em i można je bezpośrednio przełożyć na język tego standardu.. Informacja o autorze. Jarek Przybyszewski jest administratorem baz danych w Accenture Services. Specjalizuje się w problematyce związanej z eksploatacją systemów baz danych Oracle.

ITIL w Oracle u incydenty, problemy i monitorowanie systemu 113 1. ITIL i Oracle Historia informatyki od początku jej istnienia jest nierozerwalnie związana z różnymi standardami. Na przestrzeni ostatnich 10-20 lat trend ten został utrzymany a industrializacja całej branży zasadniczo wpłynęła na daleko posuniętą standaryzację i unifikację sposobu dostarczania usług przez większość dostawców. Jednak standaryzacja nie dotyczy jedynie samego sposobu świadczenia usług, ale także urządzeń i oprogramowania zarówno tych dostarczanych użytkownikom masowym jak i tych przeznaczonych dla firm. Częściowo jest to wymuszone przez różnego rodzaju urzędy (np. unifikacja ładowarek do telefonów komórkowych), w innych przypadkach wpływ mają różnego rodzaju orgranizacje branżowe lub standaryzacyjne. Zdarza się również, że standardami de facto stają się rozwiązania wprowadzone na rynek przez firmy komercyjne (np. BlueRay vs. Drugi standard). Popularność danego standardu, podobnie jak inne rozwiązania, podlegają prawom rynku oraz cyklowi życia produktów. Jedne standardy przegrywają z innymi, z kolei część standardów staje się przestarzała i wychodzi z użycia. Niebagatelne znaczenie ma również moda na dane rozwiązanie, która często wpływa na popularność konkretnego rozwiązania. Starając się umiejscowić najważniejszy (kiedyś, teraz może już niekoniecznie) produkt Oracle a w kontekście standardów i cyklu życia produktu można stwierdzić, że jest to przede wszystkim dominujący produkt na rynku baz danych, praktycznie niezagrożony ze względu na stopień zaawansowania oraz liczne przejęcia firm z nim konkurujących. Ponadto dzięki dominującej pozycji Oracle bardzo często wyznacza standardy i wprowadza nowe rozwiązania, które konkurenci lepiej lub gorzej kopiują i włączają do swoich silników baz danych. Podobna sytuacja jest ze standardem ITIL (IT information library), który jest fundamentem i zbiorem najlepszych praktyk wykorzystywanych w zarządzaniu szeroko rozumianym IT. Nie jest to co prawda produkt i nie można kupić ITIL-a w związku z tym trudno mówić o jego dominacji na rynku, jednakże większość dużych firm usługowych w różnym stopniu go wdrażają i z niego korzystają, a pozostałe organizacje albo myślą o wdrożeniu ITIL-a, albo już go wykorzystują. Istnieje kilka innych konkurencyjnych standardów, ale to właśnie ITIL wyróżnia się dominującą pozycją i aktualnie jest najmodniejszy. Kierunek rozwoju bazy danych Oracle nie mógł pozstać obojętny na ogólne tendencje panujące na rynku systemów i usług IT, w tym także na wykorzystanie standardów takich jak ITIL. Wpływ ITIL-a na bazę danych Oracle oraz na sposób świadczenia usług przez firmę Oracle jest doskonale widoczny i sam w sobie może być ciekawym materiałem analizy wdrożenia ITIL-a. W wersji 10 pojawiła się wersja graficzna Enterprise Menager a umożliwiająca zarządzanie infrastrukturą bazodanową, a później innymi produktami w sposób graficzny i często pozwalała na wykonanie wielu czynności administracyjnych bez znajomości szczegółów i sposobu w jaki dana operacja jest wykonywana. EM umożliwił delegowanie części operacji do mniej doświadczaonych i słabiej wykwalifikowanych działów lub tzw. tańszych lokalizacji. Można tu zauważyć analogię do ITIL-owego podziału na kilka linii wsparcia i przekazanie wstępnej analizy do działu operacyjnego, niekoniecznie wyspecjalizowanego w danej dziedzinie. W tej samej wersji Oracle wypuścił łatkę (poprawkę), którą przemycił razem z poprawką bezpieczeństwa, która jest właściwym fundamentem ITIL-a OCM (Oracle Configuration Management). Każdy kurs ITIL-a i każda osoba znająca ten standard potwierdzi, że pierwszym zadaniem podczas tworzenia podejścia usługowego w dziale IT jest stworzenie bazy danych jednostek konfiguracyjnych (ang. Configuration items, configuration and management database CMDB). Zgodnie z tym zaleceniem Oracle wymusił na swoich klientach zebranie i dostarczenie informacji dotyczących konfiguracji posiadanych systemów. Dzięki temu Oracle uzyskał dokładną listę środowisk dla każdego klienta ze wszystkimi istotnymi informacjami np. wersja bazy danych, system operacyjny, zaaplikowane poprawki, parametry konfiguracyjne itd. Natomiast klienci mają ułatwione zadanie w momencie wystąpienia problemów z bazą danych i konieczności otwarcia Service Request-u (SR-a) w dawnym Metalinku.

114 Jarosław Przybyszewski Kolejna wersja systemu bazy danych Oracle, 11g, to już cały pakiet istotnych zmian, które wprowadzają pojęcie incydentu i problemu do świata, który już od dawna się nimi posługiwał. W wersji 11g Oracle stworzył kolejny zestaw narzędzi nazywanych Fault Diagnosability Infrastructure (FDI), która grupuje i porządkuje wiele elementów istniejących w poprzednich wersjach (np. pliki zrzutów pamięci, pliki śladu, logi bazy danych) oraz dodaje nowe elementy (np. Incident Packaging Service IPS, ADR Automatic Diagnostic Repository). Pojęcia incydentu i problemu są doskonale znane w standardzie ITIL, posiadają dobrze zdefiniowane i opisane procesy powiązane ze sobą, których celem jest przywrócenie usługi do pełnej sprawności. Kolejne punkty zostaną poświęcone dokładniejszemu przyjrzeniu się nowym cechom Oracle 11g w kontekście ITIL a oraz w zastosowaniach praktycznych. Rozważania zostały podzielone na wprowadzenie teoretyczne, czyli opis grupy nowych funkcjonalności w Oracle u 11g Fault Diagnosability Infrastructury, następnie pokazany został sposób wykorzystania informacji gromadzonych przez ADR do rozwiązania rzeczywistych problemów napotykanych w codziennej administracji bazami danych, a na koniec całość rozważań zostanie podsumowana i przedstawione zostaną dalsze możliwości rozwoju tej części bazy danych. 2. Oracle Database Fault Diagnosability Infrastructure Fault Diagnosability Infrastructure (FDI) w bazie danych Oracle ma za zadanie wspomagać zapobieganie, wykrywanie, analizę i rozwiązywanie problemów. Ze szczególną uwagą są traktowane błędy krytyczne oraz wszelkiego rodzaju uszkodzenia danych. W przypadku wystąpienia błędu Oracle automatycznie zbiera wszelkie dostępne informacje mogące wspomóc znalezienie przyczyny błędu i zapisuje je w repozytorium zwanym Automatic Diagnostic Repository (ADR). Dzięki takiemu podejściu możliwe ma być: łatwiejsza analiza wstępna problemu, szybsze znalezienie sposobu uniknięcia błędu, ograniczenie szkód wyrządzonych przez wystąpienie błędu, skrócenie czasu analizy problemu, skrócenie czasu rozwiązania problemu łatwiejsza komunikacja ze wsparciem Oracle a. Komponenty FDI FDI składa się z kilku komponentów, które współtworzą nowy system rozwiązywania problemów z bazą danych. W Tabeli 1 znajduje się opis najważniejszych komponentów. Dokładniejsza analiza możliwości poszczególnych komponentów znalazła się w kolejnych rozdziałach niniejszego opracowania. Tabela 1. Komponenty systemu Fault Diagnosability Infrastructure Nazwa komponentu Automatic diagnostic repository Automatic capture of diagnostic data upon first failure Opis Kluczowy element FDI, czyli repozytorium plików, w którym przechowywane są wszystkie informacje zbierane przez komponenty FDI. Komponent jest odpowiedzialny za zebranie wszystkich możliwych informacji, które mogą ułatwić analizę problemu. Jest aktywowany automatycznie w przypadku wystąpienia krytycznego błędu np. ORA-600 lub ORA-7445. Zbierane są podobne informacje, jak w starszych wersjach Oracle a, czyli zrzuty pamięci,

ITIL w Oracle u incydenty, problemy i monitorowanie systemu 115 Health checks Incident packaging services (IPS) Data recovery advisor (DRA) SQL Test Case Builder pliki śladu oraz nowe elementy np. raporty dotyczące stanu systemu. W przypadku wystąpienia poważnego incydentu Oracle może automatycznie uruchomić zbieranie danych dotyczących stanu systemu, przy czym jest to głównie analizy spójności różnych elementów bazy danych np. plików dziennika powtórzeń, segmentów wycofania, słownika. IPS jest jednym z ciekawszych elementów FDI, gdyż umożliwia automatyczne tworzenie paczek zawierających wszystkie dostępne pliki i raporty dotyczące konkretnego incydentu lub problemu. Dzięki temu dużo łatwiej jest znaleźć pliki dotyczące konkretnego problemu oraz szybciej można je dostarczyć do wsparcia technicznego firmy Oracle. Ponieważ FDI ma za zadanie przede wszystkim wspomagać rozwiązywanie poważnych problemów w jej skład wchodzi DRA, który analizuje raporty tworzone przez FDI dotyczące spójności bazy danych i potrafi przedstawić możliwe sposoby rozwiązania problemu, wpływ uszkodzeń na bazę danych oraz ich priorytet. Od bardzo dawna problemem było stworzenie reprodukowanego przykładu zapytania, z którym występuje problem lub które ma być zoptymalizowane. SQL Test Case Builder wspomaga ten proces i umożliwia szybkie i łatwe zebranie wszystkich koniecznych informacji. Problemy i incydenty W poprzednich rozdziałach pojawiły się już terminy problemu i incydentu, ale nie zostały one wyjaśnione i często były używane wymiennie, co jest nie do końca precyzyjne i wymaga pewnych wyjaśnień. W Tabeli 2 znalazły się wyjaśnienia obu pojęć zgodne ze Słownikiem Języka Polskiego. Pojęcie Incydent Problem Tabela 2. Pojęcia incydentu i problemu na podstawie SJP [SJP10] Znaczenie Nieprzyjemne wydarzenie Wydarzenie mało ważne Trudna sytuacja, z której należy znaleźć jakieś wyjście Poważna sprawa, która wymaga przemyślenia i rozstrzygnięcia Zarówno Oracle jak i standard ITIL definiują oba pojęcia i obie definicje są do siebie zbliżone. Wydaje się, że Oracle wzorował się na ITIL u i przełożył definicję ze standardu na język bazy danych. W Tabeli 3 znajdują się definicje obu pojęć na podstawie dokumentacji Oracle a i standardu ITIL wraz z krótkim komentarzem. Tabela 3. Definicje problemu i incydentu wg Oracle a i wg ITIL a Pojęcie Definicja wg Oracle a Definicja wg ITIL a Incydent Jest to pojedyncze wystąpienie problemu. Jeżeli problem występuje wiele razy incydent jest tworzony dla każdego wystąpienia. Każdy incydent jest zapisywany w repozytorium ADR i jest znakowany czasem. Incydenty są identyfikowane przez unikalny w skali ADR Niezaplanowana przerwa w działaniu usługi IT lub pogorszenie jej jakości. Defekt w działaniu jednostki konfiguracyjnej, który jeszcze nie

116 Jarosław Przybyszewski Problem numer incydentu. W przypadku wystąpienia incydentu baza danych: zapisuje informacje o wystąpieniu incydentu w alert logu, wysyłany jest alert do Oracle Enterprise Manager a, zbierane są informacje diagnostyczne w postaci plików zrzutu, śladu itp., oznakowuje informacje diagnostyczne numerem incydentu, zapisuje pliki diagnostyczne w repozytorium ADR w podkatalogu tworzonym dla incydentu Jest to błąd krytyczny w instancji bazy danych, instancji ASM lub w innym produkcie lub komponencie Oracle a. Objawia się poprzez błędy takie jak ORA- 00600, ORA-07445 lub ORA-04031. Informacje dotyczące problemów są przechowywane w ADR. Każdy problem posiada identyfikator w postaci ciągu znaków. Identyfikator zawiera kod błędu oraz opcjonalnie jeden lub więcej parametrów.[oda10] ma wpływu na dostarczanie usług IT jest również incydentem np. uszkodzenie dysku w konfiguracji RA- ID1.[OGC07] Przyczyna jednego lub więcej incydentów. Przyczyna nie jest zazwyczaj znana w momencie tworzenia Problem rekordu. Proces zarządzania problemami jest odpowiedzialny za dalszą analizę.[ogc07] Na pierwszy rzut oka wydaje się, że konsorcjum OGC (zarządzające standardem ITIL) oraz firma Oracle zdefiniowały problem i incydent nieco odmiennie. Jednakże po uważniejszym przestudiowaniu standardu ITIL a można dojść do wniosku, że chodzi tak naprawdę o to samo. Różnice tak naprawdę wynikają z tego, że standard ITIL opisuje wszystkie możliwe usługi IT, a firma Oracle doprecyzowała oba pojęcia na swoje potrzeby. W przypadku ITIL a o problemie można dopiero mówić, jeżeli wystąpił jeden lub więcej incydentów, których przyczyna jest nieznana. W związku z tym nie każdy incydent musi powodować uruchomienie procesu zarządzania problemami i nie dla każdego incydentu konieczne jest tworzenie problemu. Oracle natomiast w swojej implementacji standardu ITIL na poziomie bazy danych tworzy problem dla każdego incydentu. Wynika to głównie z tego, że incydenty są otwierane automatycznie jedynie dla najpoważniejszych błędów, które zazwyczaj są wynikiem usterki w silniku bazy danych i w związku z tym można spodziewać się ponownego wystąpienia incydentu. W przypadku incydentów obie definicje (Oracle a i ITIL a) są takie same, a definicja Oracle a zawiera jedynie elementy specyficzne dla bazy danych. W dalszej części rozważań, jeżeli nie będzie to wyraźnie powiedziane, stosowane będą pojęcia zdefiniowane przez firmę Oracle. 3. ADR Command Interpreter W poprzednich rozdziałach opisano nową strukturę katalogów z plikami diagnostycznymi bazy danych. Administratorom przyzwyczajonym do starej konfiguracji może być trudno znaleźć pliki, które dawniej znajdowały się w katalogach definiowanychwedle własnego upodobania. Na szczęście Orcle zadbał o wygodę administratorów, którzy nie zawsze mają możliwość skorzystania z graficznych narzędzi, takich jak Enterprise Manager lub po prostu wolą przeglądać pliki diagnostyczne bezpośrednio na serwerze bazy danych. Razem z bazą instalowane jest niewielkie narzędzie, Automatic Diagnosability Repository Command Interpreter (ADRCI), które umożliwia sprawny dostęp do plików zgromadzonych w ADR oraz dostarcza kilku interesujących narzędzi

ITIL w Oracle u incydenty, problemy i monitorowanie systemu 117 usprawniających pracę administratora. Niniejszy rozdział został poświęcony przyjrzeniu się bliżej najważniejszym funkcjom ADRCI. Przeglądanie Alert Loga Do najczęściej wykonywanych zadań przez administratorów baz danych należy regularne przeglądanie logów bazy danych, w szczególności alert logu i reagowanie na zaobserwowane błędy. W starszych wersjach Oracle a wystarczyło sprawdzić ustawienie parametru BACKGRO- UND_DUMP_DEST, żeby zorientować się gdzie znajduje się alert.log. W Oracle 11g można również sprawdzić wartość tego parametru, ale nie jest on już dłużej wymagany i jest parametrem typu DEPRECATED. Lepszym rozwiązaniem jest uruchmienie ADRCI i przeglądanie alert logu za pomocą tego narzędzia. Rys. 1. przedstawia uruchomienie ADRCI oraz listę dostępnych poleceń. Aby uruchomić ADRCI wystarczy na serwerze bazy danych wpisać adrci w dowolnym katalogu na serwerze bazy danych. Uruchamiany jest interpreter, który umożliwia pracę z repozytorium ADR. Zgodnie ze standardem Oracle a poleceniem HELP można wyświetlić listę dostępnych komend, a szczegóły dla danego polecenia wyświetlimy za pomocą polecenia HELP <nazwa komendy>. Aby przejrzeć Alert Log z poziomu ADRCI wystarczy wykonać polecenie SHOW ALERT. ADRCI prosi wtedy o wybranie Alert Loga, który ma być wyświetlony a następnie uruchamia domyślny edytor i otwiera plik dziennika bazy danych (patrz Rys. 2. ). Takie podejście jest bardzo wygodne, ponieważ umożliwia jednakowy sposób dostępu do wszystkich Alert Logów (ASM a, procesu nasłuchu, instancji bazy danych) z jednego miejsca i w jednolity sposób. W przypadku wystąpienia krytycznego błędu Oracle, podobnie jak w starszych wersjach, dodaje informację na ten temat do Alert Logu z kodem błędu, pełną nazwą pliku śladu i dodatkowo numerem incydentu utworzonego w ADR (patrz Rys. 3. ). Jeżeli administrator chce przejrzeć pliki śladu może to zrobić niestety tylko w tradycyjny sposób, czyli otworzyć plik tak jak w poprzednich wersjach korzystając z dowolnego edytora tekstowego.

118 Jarosław Przybyszewski Rys. 1. Uruchomianie ADRCI Rys. 2. Wyświetlanie Alert Loga

ITIL w Oracle u incydenty, problemy i monitorowanie systemu 119 Problemy i incydenty Rys. 3. Przeglądanie Alert Loga incydent Wydaje się, że głównym celem wprowadzenia nowego komponentu do bazy danych przez Oracle a jest usprawnienie współpracy pomiędzy klientem i działem wspracia w trakcie rozwiązywania problemów. Dzięki ADR klienci są w stanie w łatwy i szybki sposób znaleźć krytyczny błąd w swoich systemach, orkeślić częstotliwość jego występowania oraz przygotować wszystkie możliwe pliki śladu, logi zrzuty pamięci itp. do przesłania do działu wspracia firmy Oracle. W dalszej części rozdziału prześledzona zostanie hipotetyczna sytuacja tworzenia paczki z użyciem ADRCI. Załóżmy zatem, że błąd z Rysunku 3 spowodował błąd w aplikacji uniemożliwiający użytkownikom wykonywanie ich normalnej pracy. Administrator po upewnieniu się, że błąd nie pasuje do żadnego znanego wcześniej błędu bazy danych, postanawia otworzyść zgłoszenie serwisowe korzystając ze strony http://support.oracle.com. Ponieważ administrator chce przyspieszyć rozwiązanie problemu,postanawia wykorzystać z ADRCI, aby przygotować niezbędne pliki. Na początek sprawdza, czy błąd został zarejestrowany w repozytorium ADR (patrz Rys. 4. ) wykonuje polecenie SHOW PROBLEM. Rys. 4. Wyświetlanie listy problemów dla danej bazy danych Kolejnym krokiem powinno być sprawdzenie czy ten błąd występował wielokrotnie w danej bazie danych. Do tego celu można wykorzystać polecenie SHOW INCIDENT w kilku różnych postaciach (patrz Rys. 5., Rys. 6. i Rys. 7. ). W podstawowej formie polecenie SHOW INCIDENT wyświetla ostatnie 50 incydentów w kolejności chronologicznej. Za pomocą dodatkowych opcji możliwe jest wyselekcjonowanie tylko części z nich lub zmiana ilości informacji wyświetlanych na ekranie. Na rysunkach widać różny stopień szczegółowości informacji przedstawionych przez polecenie SHOW INCIDENT. Kolejne zrzuty ekranu przedstawiają coraz dokładniejszą formę, która może pomóc w znalezieniu informacji dotyczących konkretnego incydentu w Internecie lub na stronach wsparcia firmy Oracle.

120 Jarosław Przybyszewski Rys. 5. Wyświetlanie incydentów forma podstawowa

ITIL w Oracle u incydenty, problemy i monitorowanie systemu 121 Rys. 6. Wyświetlanie incydentu forma skrócona

122 Jarosław Przybyszewski Rys. 7. Wyświetlanie incydentu forma szczegółowa Kolejnym krokiem może być przejrzenie plików śladu związanych z konkretnymi incydentami, które potencjalnie mogą być związane z błędem w aplikacji. Wyświetlenie listy plików śladu dla danego incydentu następuje poprzez wykonanie polecenia SHOW TRACEFILE I <numer_ incydentu> (patrz Rys. 8. ). Rys. 8. Lista plików śladu dla konkretnego incydentu Pliki śladu można tak jak w poprzednich wersjach bazy danych przeglądać za pomocą dowolnego edytora. Po upewnieniu się, że bez pomocy wsparcia niemożliwe jest rozwiązanie problemu, administrator postanawia przygotować wszystkie niezbędne pliki do wysłania wykorzystując ADRCI. W tym celu tworzy paczkę (ang. Package) z wykorzystaniem polecenia IPS CREATE PACKA- GE (patrz Rys. 9. ). Wykonanie tego polecenia powoduje jedynie utworzenie logicznego rekordu na poziomie metadanych i przypisanie mu kolejnego numeru. Utworzenie fizycznego pliku, który można wysłać następuje dopiero później. Paczkę można utworzyć na bazie incydentu, problemu lub na podstawie przedziału czasu. Rys. 9. Tworzenie paczki

ITIL w Oracle u incydenty, problemy i monitorowanie systemu 123 Zanim paczka zostanie ostatecznie skompletowana możliwe jest dodawani plików spoza repozytorium do niego i dowiązywanie ich do istniejącej paczki i incydentu (patrz Rys. 10. ). W przykładzie pokazano jak można dodać plik tekstowy zawierający zapytanie powodujące wystąpienie problemu do paczki. Rys. 10. Dodawanie pliku spoza repozytorium do paczki Po wyświetleniu listy wszystkich plików wchodzących w skład paczki widać, że nowo dodany plik zewnętrzny znajduje się na liście (patrz Rys. 11. ). Rys. 11. Lista plików dla danej paczki z uwzględnieniem dodanego pliku zewnętrznego Postępując w ten sposób można dodać do paczki wszystkie niezbędne pliki np. logi procesu nasłuchu, pliki śladu wygenerowane własnoręcznie, opisy procedur, procesów, opis problemu i wszystkie inne pliki, które mogą przyspieszyć rozwiązanie problemu. Po skompletowaniu wszystkich niezbędnych plików przychodzi czas na utworzenie fizycznego pliku zawierającego wszystkie dane. W tym celu wystarczy wykonanie polecenia IPS GENERA- TE PACKAGE (patrz Rys. 12. ). Zależnie od rozmiaru i ilości plików po pewnym czasie ADRCI informuje o utworzeniu pliku i jego bezwzględnej ścieżce. Rys. 12. Utworzenie fizycznej packi Tak przygotowaną paczkę można wykorzystać w trakcie tworzenia zgłoszenia serwisowego i z pewnością będzie to szybsze niż dosyłanie kolejnych plików związanych z danym błędem tak jak miało to w poprzednich wersjach bazy danych Oracle. Dla miłośników GUI-a słów kilka Oczywiście cały powyżej opisany proces można wykonać za pomocą Oracle Enterprise Manager a i może to być pod wieloma względami łatwiejsze, szybsze i przyjemniejsze. Jednakże z uwagi na znaczny konserwatyzm autora, prezentacja graficznych narzędzi została celowo pominięta w niniejszym opracowaniu.

124 Jarosław Przybyszewski 4. Monitorowanie stanu systemu Jednym z komponentów nowego systemu monitoringu bazy danych są testy stanu systemu (ang. Health checks), które mogą być uruchamiane automatycznie przez FDI w przypadku wykrycia poważnego błędu w systemie lub manualnie przez administratora. W wersji 11gR1 lista dostępnych testów jest dosyć ograniczona, ale należy się spodziewać, że będzie systematycznie rozbudowywana i uzupełniana. Przedstawia aktualnie dostępne testy i ich krótki opis. Tabela 4. Lista testów dostępnych w Health Check Monitorze w Oracle 11gR1 Nazwa testu DB Structure Integrity Check Data Block Integrity Check Redo Integrity Check Undo Segment Integrity Check Transaction Integrity Check Dictionary Integrity Check Opis Test sprawdza dostępność i spójność plików wchodzących w skład bazy danych. Jeżeli baza danych jest zamontowana, sprawdzana są logi, pliki danych oraz pliki kontrolna. W przypadku bazy w trybie niezamontowanym sprawdzane są tylko pliki kontrolne. Jest to test podobobny do tego, który przeprowadza DBVERIFY lub do testu dostępnego w RMANie. Następuje sprawdzenie fizyczne błędów na poziomie bloków oraz spójność logiczna plików. Uszkodzone bloki są raportowane za pośrednictwem widoku V$DATABASE_BLOCK_CORRUPTION. Test sprawdza dostęność i spójność plików dziennika powtórzeń i zarchiwizowanych plików dziennika powtórzeń. Sprawdzenie logicznej spójności segmentów wycofania. W przypadku wykrycia uszkodzonych tranzakcji są one czyszczone za pomocą PMON-a i/lub SMON-a. Jeżeli się to nie powiedzie, błędy są raportowane za pomocą widoku V$CORRUPT_XID_LIST. Jest to identyczne test jak Undo Segment Integrity Check, ale wykonywany dla pojedynczej transakcji Sprawdzenie integralności słownika danych. Sprawdzane jest zawartość wszystkich słowników danych, ograniczenia i zależności między poszczególnymi tabelami. Uruchamianie testów z poziomu SQL a Jak zawsze w najnowszych wersjach Oracle a można uruchamiać testy Health Check Monitora z poziomu Enterprise Manager a, ale z powodów opisanych w rozdziale 3.3 ten sposób został pominięty. W poniższym rozdziale został pokazany sposób uruchamiania testów i wyświetlania raportów z poziomu SQLPLUS a i ADRCI. Oracle udostępnia interfejs do uruchamiania testów poprzez pakiet DBMS_HM, który posiada jedynie jedną procedurę i jedną funkcję, które powinny być wykorzystywane przez administratorów: RUN_CHECK służy do uruchamiania testu. Procedura posiada trzy parametry: o CHECK_NAME nazwę testu np. Undo Segment Integrity Check, o RUN_NAME nazwę konkretnego uruchomienia np. Test1, o TIMEOUT maksymalny czas w sekundach, w którym test powinien się zakończyć, o INPUT_PARAMETERS parametry testu, o ile test przewiduje taką możliwość,

ITIL w Oracle u incydenty, problemy i monitorowanie systemu 125 GET_RUN_REPORT służy do wyświetlenia raportu dla określonego testu. Funkcja posiada następujące parametry: o RUN_NAME nazwę uruchomienia, o TYPE format w jakim raport ma być wyświetlony, przy czym może być to format tekstowy, HTML lub XML, o LEVEL poziom szczegółowości raportu, przy czym aktualnie jedynie poziom podstawowy jest dostępny. Rys. 13. przedstawia przykładowe uruchomienie testu Dictionary Integrity Check i wyświetlenie raportu. Raport przedstawia podstawowe informacje ogólne na temat testu oraz listę znalezionych błędów. Na testowanej bazie danych znaleziono kilka problemów związanych z integralnością słownika, które należałoby rozwiązać. Raport może zostać również wyświetlony z poziomu ADRCI, ale w tym przypadku jedynym wspieranym formatem jest format XML (patrz Rys. 14. ). Po zapisaniu raporu w formacie XML można go wyświetlić w dowolnym narzędziu, które wspiera ten format np. Microsoft Word (patrz Rys. 15. ).

126 Jarosław Przybyszewski Rys. 13. Uruchomienie testu i wyświetlenie raportu za pmocą SQL a

ITIL w Oracle u incydenty, problemy i monitorowanie systemu 127 Rys. 14. Wyświetlenie raportu z poziomu ADRCI

128 Jarosław Przybyszewski Rys. 15. Raport z uruchomienia testu w formacie XML wyświetlony w programie MS Word 2007 5. Podsumowanie Elementy ITIL a zaimplementowane w Oracle u 11g nie tylko ułatwiają pracę administratorów, ale także interakcję między klientami a wsparciem technicznym firmy Oracle. Całość Fault Diagnosability Infrastructure posiada jeszcze dosyć mocno ograniczone możliwości, ale na pewno wraz z kolejnymi wersjami będzie rozwijana. Wydaje się, że jest to kolejny ciekawy krok wyprzedzający konkurencję. Należy spodziewać się, że Oracle będzie rozwijał listę dostępnych testów, które będą dostępne za pomocą Health Check Monitora, będą one również coraz bardziej skomplikowane i rozbudowane. Ponadto można się spodziewać dalszego rozwoju ITIL a w Oracle u. Bardzo przydatne byłoby zaimplementowanie zmian na poziomie Oracle a, tak aby każda zmiana konfiguracji, dodanie plików do przestrzeni tabel itd. były zapisywane w zewnętrznym repozytorium. Dzięki temu łatwiej byłoby zrozumieć problemy wynikające ze zmian wprowadzonych bez przestrzegania procedur. Z kolei Oracle mógłby w łatwy sposób sprawdzić co klient robił w ostat-

ITIL w Oracle u incydenty, problemy i monitorowanie systemu 129 nim czasie i dlaczego pojawiają się nowe błędy w serwerze bazy danych i dlaczego klient prosi o pomoc techniczną. Bibliografia [ODA07] Oracle Database Administrator s Guide 11g Release 2 (11.2) Part Number E10595-07 [SOOGC07] Service Operation, OGC, 2007 [SJP10] Słownik Języka Polskiego, sjp.pwn.pl, stan na dzień 1.08.2010