Co warto monitorować w Bazach Danych Oracle

[ArturB]

Po raz kolejny jeśli chodzi o same wtyczki znajdziemy ich całe mnóstwo na Nagios Exchange. Moim faworytem jest wtyczka check_oracle_health] z nazwy przypominająca docenianą przeze mnie wcześnie metodę check_mssql_health. Ten artykuł jednak będzie nieco odmienny względem tych o monitoringu MSSQL, skupimy się na najbardziej podstawowych parametrach monitoringu, wraz z sugerowanymi zapytaniami SQL, pozwalającymi na odczytanie pożądanej wartości.
Taki wstęp powinien pozwolić na skuteczne napisanie krótkiej metody, czy krótkich metod.
1. Liczba wszystkich sesji

KOD: ZAZNACZ CAŁY

Code:

select count(*) from v\$session;

2. Liczba aktywnych sesji

KOD: ZAZNACZ CAŁY

Code:

select count(*) from v\$session where status='ACTIVE' and username is not null;

3. Sprawdzenie log mode

KOD: ZAZNACZ CAŁY

Code:

select log_mode from v\$database;"

4. Sprawdzenie jakie tabele są w backup mode

KOD: ZAZNACZ CAŁY

Code:

select a.tablespace_name from (select file_id, tablespace_name from dba_data_files) a, (select file# from v\$backup where status like 'ACTIVE') b where a.file_ID = b.file# group by tablespace_name;

5. Sprawdzenie ilości invalid object.

KOD: ZAZNACZ CAŁY

Code:

select count(object_name) from  dba_objects where  status = 'INVALID';

6. Sprawdzenie wolnego miejsca w tablespace’ach. Tutaj zatrzymamy się na nieco dłużej.
Temat monitoringu tablespace’ów jest dość ważny z perspektywy poprawnego działania baz danych. Trzeba tutaj powiedzieć o tym że tablespace’y możemy podzielić na trzy typy:
a) PERMAMENT
b) TEMPORARY
c) UNDO
Samą listę tablespace’ów możemy dostać korzystając z tabeli dba_tablespaces, krótka tablespace_name zdradzi nam nazwy poszczególnych tablespace’ów. W tej samej tabeli znajdziemy również kolumnę contents, w której powinny się znajdować właśnie oczekiwane trzy typy.
Praktyka jednak pokazuje że nie zawsze tak jest. W bazie danych nie musi być jako takiej tabeli TEMPORARY czy UNDO. Jeśli tabela tymczasowa będzie DMT (dictionary-managed), jej typem będzie PERMAMENT. Różnice pomiędzy LMT (local-managed) a DMT nie są tematem tego artykułu, więc nie będziemy się zagłębiać.
W przypadku UNDO również, szczególnie w przypadku starszych baz danych, możemy spotkać się z sytuacją w której takowych nie ma, bowiem Oracle dopuszcza używanie tzw. rollback segments również w tabelach typu PERMAMENT.
No dobrze do czego potrzebny jest nam taki podział. Jak pokazują wdrożenia często nie ma sensu alarmować o zapełnieniu tablespaców typu TEMPORARY i UNDO, jednak same wartości historyczne mogą pozwolić administratorowi na zaobserwowanie anomalii i poprawienie konfiguracji serwera.
Drugim ważnym elementem przy monitorowaniu konkretnego tablespace’a jest to, czy znajduje się on w datafile’u, który jest autoextensible (AE) czy nie. W pierwszym przypadku bez wątpienia ilość wolnego miejsca w datafile’u nie jest miarodajna, ponieważ może on automatycznie się powiększyć, także rozmiar musi być skalowany względem dostępnego dla datafile’a. Inna sytuacja ma miejsce w przypadku gdy data file ma ustalony rozmiar. Informację o typie datafile’a możemy wyciągnąć z systemowej tabeli dba_data_files.

KOD: ZAZNACZ CAŁY

Code:

select distinct tablespace_name, autoextensible from dba_data_files

Wielokrotnie spotkamy się z sytuacją, kiedy nasz tablespace jest rozsiany po kilku data_file’ach, stąd dla porządku słowo distinct. Większym problemem jest niestety sytuacja gdy tablespace jest zarówno na datafile’u który jest AE jak i na takim który nie jest AE.
Z taką wiedzą myślę, że możemy zająć się sformułowaniem odpowiednich zapytań odpowiadających nam po pierwsze jaki jest rozmiar tablespace’a a po drugie ile znajdziemy dla niego dostępnego miejsca.
Rozważmy 4 przypadki:
1. Nie AE , nie TEMPORARY
2. Nie AE, TEMPORARY
3. AE
Poniższe SQL’e wyciągnięte są z wtyczki check_oracle z Nagios Exchange autorstwa „latigid010”. Pierwsza kolumna to wolne miejsce, druga całkowite, a trzecia procentowa.
Ani AE ani TEMPORARY:

KOD: ZAZNACZ CAŁY

Code:

select nvl(sum(bytes_free/1024/1024),0.0) a,sum(bytes_used/1024/1024)+sum(bytes_free/1024/1024) b,(100-(trunk(nvl(sum(bytes_free/1024/1024),0.0))/(sum(bytes_used/1024/1024)+sum(bytes_free/1024/1024))*1000)/10) prc from v\\$temp_space_header WHERE tablespace_name='NAZWA’;

TEMPORARY:

KOD: ZAZNACZ CAŁY

Code:

select to_char(nvl(b.free,0.0),'9999999.99'),to_char(a.total,'9999999.99'),to_char(100 - trunc(nvl(b.free,0.0)/a.total * 1000) / 10,'9999999.99') into r1,r2,r3
from (
select tablespace_name,sum(bytes)/1024/1024 total
from dba_data_files group by tablespace_name) a
left outer join
( select tablespace_name,sum(bytes)/1024/1024 free
from dba_free_space group by tablespace_name) b
on a.tablespace_name=b.tablespace_name where a.tablespace_name=tb_name;
dbms_output.put_line(r1||' '||r2||' '||r3);

AE

KOD: ZAZNACZ CAŁY

Code:

begin
select to_char(sum(greatest(a.AE_free, NVL(b.free,0.0))),'9999999.99') as eff_free, to_char(sum(greatest(a.maxfree, a.total)),'9999999.99') as eff_total, to_char(100 - trunc(sum(greatest(a.AE_free, NVL(b.free,0.0)))/sum(greatest(a.maxfree, a.total)) * 1000)/10,'9999999.99') as eff_prc into eff_free, eff_total, eff_prc
from (
select tablespace_name,file_id,bytes/1024/1024 total,
(nvl(maxbytes, 0.0) - bytes) / 1024 /1024 as ae_free, nvl(maxbytes, 0.0) / 1024 / 1024 as maxfree
from dba_data_files ) a
left outer join
( select tablespace_name,file_id,sum(bytes)/1024/1024 free
from dba_free_space
group by tablespace_name, file_id ) b
on a.tablespace_name=b.tablespace_name and a.file_id = b.file_id
where a.tablespace_name=tb_name;
dbms_output.put_line(eff_free || ' ' || eff_total || ' ' || eff_prc);
end;

Przedstawione parametry powinny zaspokoić co najmniej minimum potrzeb w zakresie monitoringu serwera Oracle.