Jednym z najbardziej interesujących rozwiązań technicznych dostępnych na platformie Oracle Exadata jest Smart Scan. Na początek małe przypomnienie: architektura sprzętowa platformy Oracle Exadata przewiduje podział na maszyny odpowiedzialne za fizyczne składowanie danych (Exadata Cell Server) i na maszyny, na których pracuje instancja serwera bazy danych (Database Machine). Te dwa rodzaje maszyn połączone są szybką siecią lokalną zrealizowaną w technologii Infiniband. Zarys tej architektury pokazuje poniższy rysunek.
Ponieważ, mimo wszystko, przepustowość Infiniband jest ograniczona, a jednocześnie każdy Exadata Cell Server posiada nawet 20-32 rdzenie procesorów Intel Xeon, Oracle postanowił „zrzucić” (offload) część zadań związanych z przetwarzaniem zapytań z poziomu Database Machine na poziom Exadata Cell Server. Właśnie w tym kontekście, jedną z głównych czynności realizowanych przez Exadata Cell Server jest Smart Scan, polegający na wstępnym filtrowaniu danych już w chwili ich odczytu z dysków. Można zaryzykować stwierdzenie, że Exadata Cell Server jest rodzajem inteligentnej macierzy dyskowej – inteligentnej, gdyż rozumie podstawowe operatory selekcji języka SQL i potrafi je realizować na poziomie dysków.
Smart Scan umożliwia „zrzucenie” na poziom Exadata Cell Server wykonania operatorów =, !=, <, >, <=, >=, IS NULL, IS NOT NULL, BETWEEN, NOT BETWEEN, IN, NOT IN, EXISTS, IS OF, NOT, AND, OR, a także „zrzucenie” wykonania wielu funkcji SQL (pełen wykaz: select * from v$sqlfn_metadata where offloadable=’YES’). Nie każde zapytanie (tylko pełen odczyt tabeli ścieżką bezpośrednią, ograniczenia składniowe) i nie w każdej sytuacji (np. przeciążony Exadata Cell Server) skorzystać może ze Smart Scan. Dziś zajmijmy się jednak tym, w jaki sposób programista lub administrator mogą zweryfikować, czy w realizacji ich zapytania został zastosowany mechanizm Smart Scan i w jakim zakresie.
Po pierwsze – możliwość użycia Smart Scan widoczna jest w planie wykonania zapytania, w którym w komentarzach pojawia się operacja STORAGE:
Predicate Information (identified by operation id):
--------------------------------------------------- 3 – storage(LOWER("FIRST_NAME")='jan')
filter(LOWER("FIRST_NAME")='jan')
Po drugie – wśród statystyk sesji dostępna jest „cell physical IO interconnect bytes returned by smart scan”, informująca nas o tym, ile bajtów przekazanych przez Exadata Cell Server stanowiło wynik operacji Smart Scan:
select name,value from v$mystat natural join v$statname
where (name like 'phy%' or name like 'cell%') and value>0;
NAME VALUE
------------------------------------------------------------ ----------
physical read total IO requests 34
physical read total multi block requests 8
physical read total bytes 9204688
cell physical IO interconnect bytes 9204688
physical reads 1000
physical reads direct 1000
physical read IO requests 14
physical read bytes 8192000
cell scans 1
cell blocks processed by cache layer 1000
cell blocks processed by txn layer 1000
cell blocks processed by data layer 1000
cell physical IO bytes eligible for predicate offload 8192000
cell physical IO interconnect bytes returned by smart scan 98960
cell IO uncompressed bytes 8192000
Po trzecie – skorzystać możemy też ze statystyk wykonania poleceń SQL, gromadzonych w V$SQL, a wśród nich „io_cell_offload_returned_bytes „:
SELECT sql_text,
io_cell_offload_eligible_bytes/1024/1024 offload_elig_mb,
io_cell_uncompressed_bytes/1024/1024 io_uncomp_mb,
io_interconnect_bytes/1024/1024 io_intercon_mb,
io_cell_offload_returned_bytes/1024/1024 cell_return_mb,
(physical_read_bytes + physical_write_bytes)/1024/1024 io_disk_mb
FROM v$sql WHERE sql_text LIKE '%from sales%';
SQL_TEXT
OFFLOAD_ELIG_MB IO_UNCOMP_MB IO_INTERCON_MB CELL_RETURN_MB IO_DISK_MB
--------------- ------------ -------------- -------------- ----------
select count(*) from sales
5283.06 5283.06 520.34 417.65 5385.75