Perspektywy (views) w Systemie Zarządzania Bazą Danych Oracle

część 2

Robert Wrembel
Politechnika Poznańska, Instytut Informatyki
ul. Piotrowo 3A, 60-965 Poznań
e-mail: Robert.Wrembel@cs.put.poznan.pl

W części pierwszej artykułu, która ukazała się w
poprzednim numerze czasopisma, omówiono koncepcję perspektywy relacyjnej, jej
własności i cele stosowania oraz wykorzystanie perspektyw w zapytaniach i
poleceniach modyfikacji danych. Część druga jest natomiast poświęcona
replikacji danych w Oracle. Zostaną tu przedstawione m.in.: koncepcja migawki,
sposoby jej definiowania i odświeżania oraz słownik bazy danych udostępniający
informacje na temat migawek.

W artykule zastosowano następującą notację w składni
poleceń języka SQL:

  • klauzule i słowa kluczowe są wytłuszczone np.
    drop table sklepy;

  • klauzule i słowa kluczowe opcjonalne są ograniczone
    nawiasami graniastymi, np.
    drop table pracownicy [including contents]…;

  • wartości domyślne w poleceniach są podkreślone, np.
    refresh {fast | complete | force}
    oznacza, że domyślnym słowem kluczowym jest force i nie
    trzeba go specyfikować;

  • możliwość wyspecyfikowania tylko jednego elementu z
    pewnego zbioru elementów jest oznaczana pionową kreską ( | ) oddzielającą
    te elementy, a same elementy są ograniczane nawiasami klamrowymi, np.
    refresh {fast | complete | force}
    oznacza, że w danym poleceniu można wyspecyfikować albo pierwsze słowo
    kluczowe (fast) albo drugie (complete), albo
    trzecie (force), ale nigdy kilku jednocześnie.

4. Replikacja danych

Intuicyjnie, replikacja danych polega na skopiowaniu pewnego
zbioru danych z jednego miejsca, tzw. źródła, do miejsca docelowego. W
kontekście relacyjnych baz danych, źródłem danych jest tabela, którą dalej
będziemy dalej nazywać tabelą źródłową. Obiektem docelowym jest również
tabela, którą dalej będziemy nazywać repliką.

Replikację danych najczęściej wykorzystuje się w
systemach rozproszonych baz danych, gdzie z jednego zdalnego węzła kopiuje się
dane do innych zdalnych węzłów. Celem replikacji w tych systemach jest, po
pierwsze, skrócenie czasu dostępu do danych. W tym przypadku uniezależniamy
się od przepustowości i aktualnego obciążenia sieci, oraz od wydajności
zdalnych węzłów i ich aktualnego obciążenia. Po drugie, dzięki replikacji
uniezależniamy się od czasowej niedostępności węzłów i awarii sieci.

Wadą replikacji jest konieczność uaktualniania repliki w
przypadku zmian w tabelach źródłowych. Taki proces uaktualniania będziemy również
nazywali synchronizacją (ang. synchronization) lub odświeżaniem (ang.
refreshing) repliki.

Z procesem odświeżania repliki są związane dwie kwestie
techniczne: moment synchronizacji i sposób odświeżenia. Ze względu na moment
synchronizacji odświeżanie dzielimy na synchroniczne i asynchroniczne.
W pierwszym przypadku, zawartość repliki jest synchronizowana z zawartością
jej tabel źródłowych natychmiast po modyfikacji danych źródłowych. W
drugim przypadku, zawartość repliki jest synchronizowana albo na żądanie użytkownika,
(jest to tzw. odświeżanie manualne), albo automatycznie przez system zarządzania
bazą danych – okresowo, z zadanym interwałem czasowym.

Ze względu na sposób, odświeżanie dzielimy na pełne
(ang. complete, full) i przyrostowe (ang. incremental, fast). Odświeżanie
pełne polega na skopiowaniu całej zawartości tabel źródłowych do repliki.
Natomiast przy odświeżaniu przyrostowym, do repliki kopiowane są wyłącznie
zmiany dokonane w tabelach źródłowych od czasu ostatniej synchronizacji.
Zmiany te będziemy dalej nazywać deltami (ang. deltas).

SZBD Oracle8i i Oracle9i wspiera mechanizm
replikacji zarówno synchronicznej, jak i asynchronicznej oraz odświeżanie pełne,
jak również przyrostowe. W systemie Oracle replika jest implementowana
jako tzw. migawka (ang. snapshot). W wersji Oracle8i wprowadzono
pojęcie perspektywy zmaterializowanej (ang. materialized view), będącej
synonimem migawki. Pojęcie migawki wykorzystuje się w kontekście
rozproszonych baz danych, natomiast perspektywę zmaterializowaną – w
kontekście magazynów danych i przetwarzania OLAP.

W SZBD Oracle, odświeżanie przyrostowe jest możliwe
dla ograniczonego rodzaju migawek, spełniających pewne warunki. Dodatkowo, aby
takie odświeżanie było możliwe, konieczne jest utworzenie w źródłowej
bazie danych pewnych dodatkowych obiektów, znanych dziennikami migawek.

W dalszej części tego punktu zostaną omówione zagadnienia
związane z definiowaniem, odświeżaniem i zarządzaniem migawkami
(perspektywami zmaterializowanymi).

5. Dziennik migawki

Dziennik migawki (ang. snapshot log, materialized view log) służy
do rejestrowania zmian dokonanych w zawartości tabeli – delt, dla której
zdefiniowano taki dziennik. Tabelę tę będziemy dalej nazywać tabelą
bazową dziennika
. Tabela bazowa może posiadać wyłącznie jeden dziennik.
Każde polecenie DML (insert, update, delete) jest
rejestrowane
w dzienniku. Informacje te są następnie wykorzystywane do odświeżania
przyrostowego migawki korzystającej z tabeli bazowej dziennika.

5.1. Definiowanie dziennika

Dziennik migawki tworzy się poleceniem SQL create
snapshot log
lub create materialized view log, którego
podstawową składnię przedstawiono poniżej. Pełną składnię tego polecenia
Czytelnik znajdzie w [O8SSql, O9SSql].

create snapshot log
on tabela_bazowa
[with { primary key |

ROWID |
primary key, ROWID |
ROWID (lista_kolumn_filtrujących) |
primary_key (lista_kolumn_filtrujących)}]

[{ including new values | excluding new values }];

Domyślna klauzula with primary key służy do
zdefiniowania dziennika dla migawki typu primary key (por. punkt 6.3). W
tym przypadku, rekordy dziennika i rekordy migawki z niego korzystającej są
identyfikowane za pomocą atrybutów kluczowych tabeli bazowej dziennika.
Klauzula with ROWID powoduje utworzenie dziennika dla migawki typu
ROWID. Jego rekordy są więc identyfikowane za pomocą wartości ROWID,
tj. fizycznego adresu rekordu. ROWID zawiera w sobie m.in. adres pliku i adres
bloku na dysku.

Możliwe jest również utworzenie dziennika zawierającego
zarówno atrybuty kluczowe, jak i ROWID (por. klauzula with primary key,
ROWID
). W takim przypadku, z tego samego dziennika mogą jednocześnie
korzystać migawki obu typów.

Jeżeli migawka oparta o podzapytania ma być odświeżana
przyrostowo (por. punkt 6.1), wówczas jej dziennik musi zawierać listę tzw. kolumn
filtrujących
(ang. filter columns). Kolumna filtrująca jest atrybutem występującym
w klauzuli where zapytania wykorzystywanego w migawce. W tym
przypadku należy zastosować jedną z dwóch klauzul: with ROWID (lista_kolumn_filtrująych)
lub with primary key (lista_kolumn_filtrujących). W
pierwszym przypadku jest tworzony dziennik zawierający ROWID i wszystkie
atrybuty tabeli bazowej wskazane w liście kolumn filtrujących.
W drugim przypadku, dziennik będzie zawierał atrybuty kluczowe i filtrujące.
Ponieważ domyślnie jest tworzony dziennik typu primary key, więc w tym
przypadku można pominąć słowa kluczowe primary key.

Należy zwrócić uwagę na fakt, że jeśli kolumna filtrująca
jest jednocześnie kluczem, bądź jego częścią, wówczas nie wolno jej
umieszczać w liście kolumn filtrujących dla dziennika typu primary key.
Kolumna ta zostanie bowiem umieszczona automatycznie w dzienniku, ponieważ jest
kluczową. Jako przykład ilustrujący tę zasadę rozważmy migawkę
wykorzystującą poniższe zapytanie (przedstawiono tu wyłącznie zapytanie
wykorzystywane w definicji migawki). Zapytanie to korzysta z tabel sklepy i
sprzedaz omówionych w pierwszej części artykułu (luty 2002). W
zapytaniu występują trzy następujące kolumny filtrujące: produkt_id,
data, l_sztuk. Obiekt lab81.ii.pp jest dołączeniem
bazodanowym (ang. database link) wskazującym na schemat użytkownika scott.

select sk.nazwa, sk.sklep_id
from scott.sklepy@lab81.ii.pp sk
where exists

(select sp.sklep_id
from scott.sprzedaz@lab81.ii.pp sp
where sp.sklep_id=sk.sklep_id
and sp.produkt_id=100
and sp.data='23.01.2002'
and sp.l_sztuk=2)

Próba zdefiniowania dziennika migawki na tabeli sprzedaz
w sposób przedstawiony niżej

create snapshot log on sprzedaz
with primary key (produkt_id, data, l_sztuk);

zakończy się następującym komunikatem błędu:

ORA-12026: invalid filter column detected

Przyczyną tego błędu jest umieszczenie w liście kolumn
filtrujących atrybutu produkt_id i data, które jednocześnie są
częścią klucza podstawowego tabeli sprzedaz, będą one więc
automatycznie umieszczone w dzienniku. W tym przypadku, poprawnym poleceniem
tworzącym dziennik jest:

create snapshot log on sprzedaz with (l_sztuk);

Opcjonalna klauzula including new values jest
konieczna w definicji dziennika w przypadku, gdy zamierza się stosować migawki
odświeżane przyrostowo, korzystające z tabeli bazowej dziennika. Opcjonalną
klauzulę excluding new values można natomiast stosować, jeżeli
migawki nie będą odświeżane przyrostowo.

5.2. Implementacja dziennika

Dziennik migawki jest implementowany jako tabela, której
nazwa składa się z nazwy tabeli bazowej dziennika poprzedzonej przyrostkiem MLOG$_.
Przykładowo, w wyniku utworzenia dziennika dla tabeli sprzedaz, za pomocą
polecenia omówionego w punkcie 5.1, zostanie utworzona tabela mlog$_sprzedaz
o następującym schemacie.

Name Null? Type



PRODUKT_ID   NUMBER(4)
DATA  DATE
SKLEP_ID NUMBER(3)
L_SZTUK NUMBER(3)
SNAPTIME$$ DATE
DMLTYPE$$ VARCHAR2(1)
OLD_NEW$$ VARCHAR2(1)
CHANGE_VECTOR$$ RAW(255)

Atrybuty produkt_id, data, sklep_id służą
do identyfikowania rekordów logu (są to atrybuty kluczowe tabeli sprzedaz),
natomiast l_sztuk jest kolumną filtrującą. Dla każdego wstawionego,
zmodyfikowanego, usuniętego rekordu z tabeli sprzedaz, zostanie
utworzony odpowiedni rekord w dzienniku. Jako przykład, rozważmy trzy następujące
polecenia DML:

insert into sprzedaz values (100, 2, 70,
'23.01.2002', 1);
update sprzedaz set cena_jedn=75 where produkt_id=100;
delete from sprzedaz where produkt_id=100;

W wyniku ich wykonania, do dziennika tabeli sprzedaz trafią
trzy rekordy opisujące powyższe operacje na danych. Przykładowe zapytanie do
dziennika i jego zawartość są następujące:

select * from mlog$_sprzedaz;

 

PRODUCT_ID DATA SKLEP_ID L_SZTUK SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$








100 23.01.2002 1 2 01.01.00 I N FE
100 23.01.2002 1 2 01.01.00 U U 08
100 23.01.2002 1 2 01.01.00 D O 00

Pierwszy rekord dziennika opisuje polecenie insert (DMLTYPE$$=I),
drugi – polecenie update (DMLTYPE$$=U), a trzeci –
delete (DMLTYPE$$=D). Wartość atrybutu OLD_NEW$$ informuje o
rodzaju danych, które są rejestrowane w dzienniku. Wartość N oznacza,
że zarejestrowano nowy rekord, U oznacza zarejestrowanie tylko zmian
wartości istniejącego rekordu, natomiast O oznacza zarejestrowanie
„starego”, nieistniejącego już w tabeli rekordu. Wartości
atrybutu CHANGE_VECTOR$$, reprezentowane w postaci heksadecymalnej,
zostaną wykorzystane do odświeżania przyrostowego. Sposób kodowania tych
wartości nie został opublikowany.

SNAPTIME$$ przechowuje datę i czas ostatniego odświeżenia
migawki z wykorzystaniem danego rekordu dziennika. Wartością atrybutu SNAPTIME$$
bezpośrednio po wpisaniu rekordu do dziennika, a przed odświeżeniem migawki
jest 01.01.00, zarówno w Oracle8i, rel. 8.1.6, jak i Oracle9i,
rel. 9.0.1. Wartość ta reprezentuje pełną datę 01.01.4000-00:00:00 (tu w
formacie dd.mm.yyyy-hh24:mi:ss). Data ta zmienia się na bieżącą dopiero po
odświeżeniu migawki z wykorzystaniem dziennika.

5.3. Modyfikowanie i usuwanie dziennika

Charakterystykę istniejącego już dziennika migawki można
zmienić za pomocą polecenia SQL alter snapshot log lub alter
materialized view log
. Podstawową składnię tego polecenia
przedstawiono poniżej, a jego pełną składnię Czytelnik znajdzie w [O8SSql,
O9SSql].

alter snapshot log
on
tabela_bazowa
add { primary key |

ROWID |
ROWID (lista_kolumn_filtrujących) |
primary_key (lista_kolumn_filtrujących)}

[{including new values | excluding new values}];

Poniższe przykładowe polecenie dodaje atrybut rowid
do dziennika typu primary key dla tabeli sprzedaz.

alter snapshot log on sprzedaz
add rowid;

Dziennik migawki usuwa się za pomocą polecenia SQL:

drop snapshot log on tabela_bazowa;

lub

drop materialized view log on tabela_bazowa;

Dziennik migawki jest usuwany automatycznie w wyniku usunięcia
jego tabeli bazowej.

5.4. Słownik bazy danych

Informacje na temat dzienników migawek istniejących w
sys-temie bazy danych można uzyskać za pomocą zapytania skierowanego do
perspektyw słownika bazy danych: DBA_, ALL_, bądź USER_SNAPSHOT_LOGS.
Schemat ostatniej z nich jest następujący:

log_owner – nazwa użytkownika będącego właścicielem
dziennika migawki;

master – nazwa tabeli, dla której utworzono
dziennik;

log_table – nazwa tabeli implementującej dziennik;

log_trigger – począwszy od wersji Oracle8i
nie jest wykorzystywany, przyjmuje wartość null;

rowids – przyjmuje wartość YES dla
dziennika utworzonego z klauzulą with ROWID, w przeciwnym
przypadku przyjmuje wartość NO;

primary_key – przyjmuje wartość YES dla
dziennika utworzonego z klauzulą with primary key, w przeciwnym
przypadku przyjmuje wartość NO;

filter_columns – przyjmuje wartość YES dla
dziennika zawierającego kolumny filtrujące;

current_snapshots – data ostatniego odświeżenia
migawki z wykorzystaniem zawartości dziennika;

snapshot_id – identyfikator migawki, która
korzysta z dziennika;

Przykładowo, bezpośrednio po utworzeniu omówionego w punkcie 5.1 dziennika migawki na tabeli
sprzedaz, zawartość USER_SNAPSHOT_LOGS będzie następująca:

LOG 
OWNER
MASTER LOG_TABLE LOG TRIGGER ROWIDS KEY PRIMARY COLUMNS FILTER SNAPSHOTS CURRENT ID SNAPSHOT









USER SPRZEDAZ MLOG$_SPRZEDAZ   NO YES YES    

Utworzenie dwóch różnych migawek odświeżanych w trybie przyrostowym, których tabelą źródłową jest sprzedaz powoduje zapisanie w
USER_SNAPSHOT_LOGS dwóch rekordów, jak pokazano niżej. Każdy z tych rekordów opisuje jedną migawkę korzystającą z dziennika
MLOG$_SPRZEDAZ. Data odświeżenia, wraz z dokładnym czasem, jest uaktualniana po każdorazowym odświeżeniu przez daną migawkę. 

select master, log_table,

to_char(current_snapshots, «dd.mm.yyyy-hh24:mi:ss»)
"REFRESHED",
snapshot_id

from user_snapshot_logs;

MASTER LOG_TABLE REFRESHED

SNAPSHOT
ID





SPRZEDAZ MLOG$_SPRZEDAZ 11.02.2002-18:28:13 65
SPRZEDAZ MLOG$_SPRZEDAZ 11.02.2002-18:28:34 66

   

Jak widać z przykładowych danych, migawki korzystające
z dziennika mają numery 65 i 66. Ich nazwy można otrzymać wydając zapytanie
do perspektywy słownika bazy danych DBA_REGISTERED_SNAPSHOTS (por. punkt
6.7.2).

6. Migawka – perspektywa zmaterializowana

Jak wspomniano, mechanizmem wykorzystywanym w SZBD Oracle do
replikacji danych jest migawka (perspektywa zmaterializowana). Migawka może być
indeksowana i partycjonowana, podobnie jak tabela. Można również dla niej
zdefiniować parametry składowania i przestrzeń tabel.

W najprostszym przypadku, definicja migawki Oracle składa
się z następujących elementów:

  • nazwy migawki,
  • specyfikacji sposobu odświeżania,
  • specyfikacji momentu pierwszego odświeżenia,
  • specyfikacji częstotliwości odświeżania,
  • specyfikacji typu migawki,
  • zapytania określającego zakres danych dostępnych w
    migawce.

Migawkę tworzy się poleceniem SQL create snapshot lub
create materialized view, którego podstawową składnię
przedstawiono poniżej. Pełną składnię tego polecenia Czytelnik znajdzie w
[O8SSql, O9SSql].

create snapshot nazwa_migawki
refresh sposób_odświeżania

start with data_pierwszego_odświeżenia
next częstotliwość_odświeżania

with typ_migawki

as zapytanie;

Użytkownicy tworzący migawki, oprócz roli CONNECT
muszą posiadać uprawnienie systemowe CREATE SNAPSHOT lub CREATE ANY
SNAPSHOT

6.1. Odświeżanie migawki

Specyfikacja sposobu odświeżania migawki (klauzula sposób_odświeżania)
umożliwia określenie, czy migawka ma być odświeżana w sposób pełny, czy
przyrostowy.

6.1.1. Odświeżanie przyrostowe i pełne

Odświeżanie przyrostowe jest możliwe jeśli po pierwsze,
na tabeli źródłowej migawki został utworzony dziennik migawki (por. punkt
5.1) i po drugie, migawka jest typu prostego. Pełną listę warunków na to,
aby migawkę można było odświeżać przyrostowo Czytelnik może znaleźć w
[O8Rep, O9Rep, O8DW, O9DW]. W artykule ograniczymy się do podania najważniejszych
kryteriów.

Migawkę nazywamy typu prostego, jeśli zapytanie ją
definiujące spełnia następujące warunki:

  • nie zawiera standardowych operacji połączenia,
  • nie zawiera klauzuli connect by,
  • nie zawiera operatorów zbiorowych (union, union
    all
    , intersect, minus),
  • nie zawiera, w większości, przypadków funkcji
    grupowych.

W pewnych przypadkach, powyższe ogólne ograniczenia na odświeżanie
przyrostowe migawki mogą zostać osłabione.

1. Po pierwsze, zapytanie korzystające z wielu tabel ze
standardowymi operacjami połączenia należy zastąpić podzapytaniami
skorelowanymi. Przykładowo, migawka oparta
o następujące zapytanie nie będzie migawką prostą. Zapytanie to wyznacza
nazwę i identyfikator tego sklepu, który sprzedał produkt o identyfikatorze
100 (produkt_id) dnia 23 stycznia, 2002 (data) w liczbie 2 sztuk (l_sztuk).

select sk.nazwa, sk.sklep_id
from scott.sklepy@lab81.ii.pp sk, scott.sprzedaz@lab81.ii.pp sp
where sp.sklep_id=sk.sklep_id
and sp.produkt_id=100
and sp.data='23.01.2002'
and sp.l_sztuk=2;

Jeśli zdefiniowano migawkę odświeżaną w trybie
przyrostowym, to w czasie tworzenia tej migawki, moduł wykonawczy SQL sprawdza,
czy może ona być odświeżana w tym trybie. Test negatywny kończy się
przerwaniem wykonywania polecenia i wyświetleniem stosownego komunikatu o błędzie.
Przykładowo, próba utworzenia migawki odświeżanej przyrostowo i wykorzystującej
wspomniane wyżej zapytanie zakończy się następującym błędem:

ORA-12015: cannot create a fast refresh snapshot from a complex query

W takim przypadku zapytanie z połączeniem należy zastąpić
podzapytaniem skorelowanym, jak pokazano niżej, a odświeżanie przyrostowe
takiej migawki stanie się możliwe.

select sk.nazwa, sk.sklep_id
from scott.sklepy@lab81.ii.pp sk
where exists

(select sp.sklep_id
from scott.sprzedaz@lab81.ii.pp sp
where sp.sklep_id=sk.sklep_id
and sp.produkt_id=100
and sp.data='23.01.2002'
and sp.l_sztuk=2);

2. Po drugie, migawka która jest oparta o jedną tabelę
źródłową i która wykorzystuje następujące funkcje grupowe: count,
sum, avg, variance, stdev,
może być odświeżana przyrostowo jeśli [O8DW, O9DW]:

  • dziennik migawki tabeli źródłowej został utworzony z
    klauzulą including new values;
  • dziennik migawki zawiera wszystkie atrybuty występujące
    w klauzuli select zapytania definiującego tę migawkę, również
    atrybuty będące argumentami funkcji grupowych.

Dodatkowo, jeżeli zapytanie korzysta z sum, avg,
variance, stdev, to w celu umożliwienia odświeżania
przyrostowego należy w zapytaniu umieścić dodatkowo funkcję count.

Jeżeli w definicji migawki są wykorzystywane podzapytania,
wówczas podzapytania te muszą spełniać dodatkowe warunki. Najważniejsze z
nich podano poniżej, natomiast pełna lista tych warunków jest dostępna w
dokumentacji technicznej systemu[O8Rep, O9Rep].

  1. Migawka musi być zdefiniowana z klauzulą with
    primary key
    .
  2. Dozwolone jest korzystanie w podzapytaniach jedynie z
    operatora exists, a nie jest możliwa jego negacja, tj. not
    exitst
    .
  3. Tabele do których odwołuje się każde z podzapytań w
    klauzuli where (realizującej połączenie tych tabel), muszą
    być powiązane kluczem obcym, tj. posiadać ograniczenia integralnościowe
    typu primary key i foreign key.

Migawka, której definicja nie spełnia warunków odświeżania
przyrostowego, może jedynie być odświeżana w sposób pełny.

6.1.2. Wskazanie preferowanego sposobu odświeżania

Wybór sposobu odświeżania migawki realizuje się za pomocą
klauzuli refresh sposób_doświeżania. Jej składnia jest
następująca:

refresh {fast | complete | force}

Klauzula refresh fast definiuje odświeżanie
przyrostowe, natomiast refresh complete definiuje odświeżanie pełne.
Klauzula refresh force (przyjmowana domyślnie) umożliwia
dynamiczny wybór sposobu odświeżania. Jeżeli możliwe będzie odświeżenie
migawki w sposób przyrostowy, tzn. spełnione będą warunki niezbędne do
takiego odświeżenia, to system zastosuje taki sposób. W przeciwnym przypadku
zastosowane zostanie odświeżanie pełne.

6.2. Moment i częstotliwość odświeżania

Jak wspomniano, migawka może być odświeżana: (1)
automatycznie z zadaną częstotliwością, (2) na żądanie użytkownika, (3) w
momencie zatwierdzenia transakcji modyfikującej dane źródłowe, lub może nie
być nigdy odświeżona.

W definicji migawki można określić moment i częstotliwość
jej odświeżania. Służy do tego celu klauzula refresh o następującej
składni:

refresh

{fast | complete | force}] [{on demand | on
commit
}]
[start with data_pierwszego_odświeżenia]
[next częstotliwość_odświeżania]

6.2.1. Odświeżanie manualne

Użycie on demand w klauzuli refresh spowoduje
utworzenie migawki odświeżanej manualnie – na żądanie użytkownika.
Klauzule fast, complete, force można
dowolnie stosować z on demand.

Manualne odświeżanie migawki realizuje się za pomocą
procedury refresh znajdującej się w pakiecie dbms_snapshot. W
systemie dostępny jest również pakiet dbms_mview, który jest
synonimem do dbms_snapshot. Procedura refresh posiada 9 argumentów
wywołania, z których tylko jeden – pierwszy o nazwie list – jest
wymagany. Jest nim nazwa odświeżanej migawki lub lista migawek lub też
zmienna typu tablica PL/SQL zawierająca nazwy migawek. Z pozostałych argumentów
najczęściej wykorzystywanym jest drugi – o nazwie method. Umożliwia
on wskazanie sposobu odświeżania migawek przekazanych pierwszym argumentem.
Wartością argumentu method mogą być:

  • C lub c – oznaczające odświeżanie
    pełne (complete),
  • F lub f – oznaczające odświeżanie
    przyrostowe (fast),
  • ? – oznaczający odświeżanie określone w
    definicji migawki, wartość przyjmowana domyślnie.

Przykładowe wywołania procedury refresh podano poniżej.

  1. exec dbms_snapshot.refresh('MV_SPRZEDAZ', 'C')
  2. exec dbms_snapshot.refresh('MV_SKLEPY', 'f')
  3. exec dbms_snapshot.refresh('MV_SPRZEDAZ, MV_SKLEPY, MV_FIRMA',
    'FF')
  4. exec dbms_snapshot.refresh('MV_SPRZEDAZ, MV_SKLEPY, MV_FIRMA')
  5. exec dbms_snapshot.refresh('MV_SPRZEDAZ, MV_SKLEPY, MV_FIRMA',
    'ffc')
  6. exec dbms_snapshot.refresh('MV_SPRZEDAZ, MV_SKLEPY',
    'f?')

W linii pierwszej odświeżana jest migawka mv_sprzedaz w
trybie pełnym, a w linii drugiej – migawka mv_sklepy w trybie
przyrostowym. Linia trzecia prezentuje sposób odświeżenia trzech migawek, tj.
mv_sprzedaz, mv_sklepy i mv_firma, przy czym dwie pierwsze
odświeżane są w trybie przyrostowym, a trzecia w trybie domyślnym. Linia
czwarta, to wywołanie procedury odświeżającej trzy migawki w trybie domyślnym.
W linii piątej odświeżane są trzy migawki – dwie pierwsze w trybie
przyrostowym, a trzecia w trybie pełnym. Linia numer 6 prezentuje odświeżanie
dwóch migawek – pierwszej w trybie przyrostowym, a drugiej w trybie domyślnym.

Pełen opis pakietu dbms_snapshot Czytelnik znajdzie w
dokumentacji technicznej Oracle [O8Pac, O9Pac].

6.2.2. Odświeżanie automatyczne po zatwierdzeniu transakcji

Użycie on commit w klauzuli refresh spowoduje
utworzenie migawki odświeżanej automatycznie po zatwierdzeniu transakcji
modyfikującej tabele źródłowe migawki.

Klauzule fast, complete, force
można stosować z on commit. Należy jednak zwrócić uwagę na
fakt, że stosowanie klauzuli on commit jest ograniczone. Po
pierwsze, nie można stosować tej klauzuli, jeżeli zapytanie definiujące
perspektywę odwołuje się do tabel źródłowych za pośrednictwem dołączeń
bazodanowych. Próba utworzenia takiej perspektywy zakończy się następującym
błędem:

ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized
view

Po drugie, on commit w można stosować jedynie
dla:

  • migawek opartych o jedną tabelę, bez wyliczania agregatów;
  • migawek, których zapytanie wyznacza agregaty w oparciu o
    pojedynczą tabelę;
  • migawek których zapytanie wykorzystuje łączenie tabel,
    ale bez wyliczania agregatów.

Próba utworzenia migawki z klauzulą on commit,
która nie spełnia jednego z powyższych warunku zakończy się następującym
błędem:

ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized
view

6.2.3. Odświeżanie automatyczne z zadaną częstotliwością

Jeżeli migawka ma być odświeżana automatycznie z zadaną
częstotliwością, wówczas w jej definicji należy umieścić klauzule: start
with
i next. Składnia klauzuli refresh jest
w tym przypadku następująca:

refresh {fast | complete | force}
start with data
next częstotliwość

Klauzula start with data umożliwia określenie
momentu rozpoczęcia odświeżania automatycznego, po utworzeniu migawki.
Klauzula next częstotliwość umożliwia
wyspecyfikowanie częstotliwości odświeżania

Przykładowo, migawka zdefiniowana w poniższy sposób po raz
pierwszy zostanie odświeżona 20 sekund po jej utworzeniu i będzie następnie
odświeżana przyrostowo co 5 sekund. Wyrażenia określające moment pierwszego
i częstotliwość odświeżania należy rozumieć następująco: sysdate
jest zmienną systemową zawierającą aktualną datę i czas w bazie danych, sysdate
+ 1
oznacza dodanie jednego dnia do aktualnej daty. Jeśli dalej podzielimy
dzień przez iloczyn 24*60*3 (24 godziny * 60 minut * 3) to otrzymamy 20 sekund.
Podobnie wyliczona została częstotliwość odświeżania.

refresh fast
start with sysdate + (1/(24*60*3))
next sysdate + (1/(24*60*12))

Kolejny przykład ilustruje fragment definicji migawki odświeżanej
w każdą środę o godzinie 18:30, przy czym pierwsze odświeżenie migawki
nastąpi następnego dnia, licząc od momentu jej utworzenia, o godzinie 9:00.

refresh fast
start with trunc (sysdate + 1) + 9/24
next trunc (next_day (sysdate, «Wednesday»)) + 18/24 +
(1/(24*2))

Należy zwrócić uwagę, że ani z klauzulą start
with
, ani z next nie może wystąpić klauzula on
commit
. Próba utworzenia migawki nie spełniającej tego warunku zakończy
się błędem:

ORA-12051: ON COMMIT attribute is incompatible with other options

Natomiast klauzula on demand może wystąpić z
klauzulami fast, complete, force oraz start
with
i next. Doświadczenia z Oracle8i rel. 8.1.6
wykazują, że w takim przypadku migawka zachowuje się tak, jakby nie istniała
klauzula on demand, to znaczy jest odświeżana automatycznie
zgodnie ze specyfikacją w klauzulach start with i next.

Migawka będzie odświeżana automatycznie z zadaną częstotliwością
jeżeli spełnione zostaną następujące warunki.

  1. W definicji migawki musi być wyspecyfikowana częstotliwość
    jej odświeżania, tj. klauzula next. Jeżeli zostanie
    wyspecyfikowana klauzula next bez start with, wówczas
    system przyjmuje moment utworzenia migawki jako moment pierwszego odświeżenia
    i wykorzystuje go do wyznaczenia czasu następnego odświeżenia (por.
    O8SSql, O9SSql]).
  2. Instancja Oracle [O8Con, O9Con, O8Dba, O9Dba,
    WJZ99] musi posiadać co najmniej jeden drugoplanowy proces odświeżający
    (ang. background refresh process). Włączanie procesów drugoplanowych odświeżających
    migawki omówiono w punkcie 6.2.6.

Jeśli choć jeden z powyższych warunków nie jest spełniony,
wówczas migawka nie jest odświeżana. Jedynym sposobem utrzymywania spójności
danych migawki z danymi źródłowymi jest w takim przypadku jej manualne odświeżenie.

6.2.4. Brak odświeżania

Możliwe jest również zdefiniowanie migawki, która nigdy
nie zostanie odświeżona. Wykorzystuje się w tym celu klauzulę never
refresh
. Tak utworzona migawka zostanie wypełniona danymi raz – w
momencie jej utworzenia. Manualne wywołanie procedury odświeżającej jest możliwe
dla takiej migawki lecz nie powoduje jej odświeżenia. Klauzula never
refresh
(jeśli jest stosowana) zastępuje klauzulę refresh.
Oznacza, to że obie klauzule wzajemnie się wykluczają.

Przykład migawki wykorzystującej klauzulę never
refresh
przedstawiono poniżej.

create materialized view mv_test
never refresh
as
select * from user1.sklepy@dbl1;

6.2.5. Moment wypełnienia migawki danymi

W definicji migawki można również umieścić klauzulę
określającą, czy migawka ma zostać wypełniona danymi natychmiast po jej
utworzeniu, czy też dopiero w momencie jej pierwszego odświeżenia. Do tego
celu służą odpowiednio klauzule build immediate i build
deferred
. Pierwsza z nich jest klauzulą domyślną. Przykładowo, poniższa
migawka zostanie wypełniona danymi dopiero w momencie jej pierwszego odświeżenia,
tj. 10 minut po jej utworzeniu:

create snapshot mv_sprzedaz_1
build deferred
refresh force
start with sysdate + (1/(24*6))
next sysdate+(1/(24*60))
with primary key
as

select produkt_id, l_sztuk, cena_jedn, data, sklep_id
from user1.sprzedaz@dbl1
where sklep_id=1;

6.2.6. Konfigurowanie drugoplanowych procesów odświeżających

W celu uruchomienia drugoplanowych procesów odświeżających
dla instancji bazy danych Oracle, należy w pliku parametrów konfiguracyjnych init.ora
instancji umieścić parametr JOB_QUEUE_PROCESSES [O8Sref, O9Serf] z
wartością całkowitą z przedziału od 1 do 36. Jeśli wartość tego
parametru wynosi 0, wówczas żaden z drugoplanowych procesów odświeżania
migawek nie jest uruchamiany w momencie startowania instancji. Maksymalnie
procesów odświeżających może być 36.

Parametr JOB_QUEUE_PROCESSES ma charakter dynamiczny.
Oznacza to, że można zmieniać jego wartość w trakcie pracy instancji bazy
danych. Służy do tego celu polecenie SQL alter system [O8SSql,
O9SSql]. Poniższe przykładowe polecenie zmienia wartość tego parametru na 2,
co wymusi pracę dwóch procesów odświeżających.

alter system set job_queue_processes=2;

Uwaga: informacje na temat procesów drugoplanowych można
wyświetlić wydając zapytanie do dynamicznej perspektywy słownika danych
(ang. dynamic performance view) V$BGPROCESS [O8SRef, O9SRef].

6.3. Typ migawki

Typ migawki (klauzula with typ_migawki)
określa sposób identyfikowania rekordów w tabeli źródłowej, rekordów w
migawce i rekordów w dzienniku migawki (por. punkt 5.1). Możliwe są tu dwa
sposoby identyfikacji. Pierwszy z nich wykorzystuje fizyczne adresy rekordów na
dysku – ROWID, podobnie jak w przypadku dziennika migawki. Ponieważ ROWID
zawiera w sobie m.in. adres pliku i adres bloku na dysku, więc przeniesienie
tabeli np. z jednego pliku do innego wiąże się ze zmianą adresów rekordów
tej tabeli. Podobnie, eksport tabeli wraz z jej zawartością, a następnie jej
import powodują zmianę wartości ROWID. Jeśli na takiej eksportowanej tabeli
była zdefiniowana migawka, to po imporcie tej tabeli gubione są powiązania między
rekordami tabeli, a odpowiadającymi im rekordami migawki. W rezultacie, migawki
nie da się odświeżyć przyrostowo, a jedynym sposobem jej synchronizacji po
imporcie tabeli jest odświeżenie pełne. Takiej wady nie posiada migawka typu primary
key
. Tu, do identyfikacji rekordów źródłowych i migawki, są stosowane
wartości klucza podstawowego tabeli źródłowej, podobnie jak w przypadku
dziennika migawki. Zmiana adresu rekordów źródłowych nie wpływa więc na
wartości identyfikujące te rekordy. Producent oprogramowania Oracle nie
zaleca stosowania migawek typu ROWID. Począwszy od wersji Oracle 8.0
udostępnione zostały migawki typu primary key, jako domyślny i
zalecany typ.

Należy zwrócić uwagę, że migawka typu primary key
musi udostępniać wszystkie atrybuty wchodzące w skład klucza tabeli źródłowej,
w przeciwnym przypadku tworzenie migawki zakończy się błędem. Przykładowo,
rozważmy prostą migawkę będącą częściową repliką tabeli sklepy,
jak pokazano niżej.

create snapshot snp_1
with primary key
as
select nazwa from scott.sklepy@lab81.ii.pp;

Migawka ta nie udostępnia atrybutu kluczowego jej tabeli źródłowej,
tj. sklep_id (por. część I artykułu, luty 2002). W konsekwencji
system zgłosi błąd:

ORA-12016: snapshot does not include all primary key columns

Rozwiązaniem tego problemu jest dodanie atrybutu sklep_id
do klauzuli select.

6.4. Implementacja migawki

Migawka w Oracle8i i Oracle9i jest
implementowana jako: (1) tabela o nazwie identycznej z nazwą migawki i (2)
indeks założony na atrybucie jednoznacznie identyfikującym rekordy tej
tabeli. Przykładowo, rozważmy migawkę typu rowid zdefiniowaną jak niżej.

create materialized view mv_sprzedaz
refresh force
start with sysdate
next sysdate + (1/(24*60*30))
with rowid
as
select produkt_id, l_sztuk, cena_jedn, data, sklep_id
from scott.sprzedaz@lab81.ii.pp;

W rezultacie wykonania tego polecenia, w bazie Oracle8i,
zostanie utworzona tabela mv_sprzedaz i indeks. Tabela mv_sprzedaz
zawiera atrybuty wyspecyfikowane w klauzuli select i jeden dodatkowy
atrybut o nazwie M_ROW$$. Atrybut ten pojawia się w tabeli mv_sprzedaz,
ponieważ utworzono migawkę z klauzulą with rowid. Wartość M_ROW$$
jest wykorzystywana do identyfikacji rekordów migawki i odpowiadających im
rekordów w tabeli źródłowej. Indeks jest zdefiniowany na atrybucie M_ROW$$.
Dodatkowo, w Oracle8i pojawia się obiekt o nazwie identycznej z nazwą
tabeli, lecz typu UNDEFINED, natomiast w Oracle9i obiekt ten jest
typu MATERIALIZED VIEW. Obiekty użytkownika można zobaczyć korzystając
z perspektywy słownika bazy danych USER_OBJECTS.

W wersji Oracle8i i Oracle9i atrybut
M_ROW$$ nie pojawia się ani w opisie tabeli uzyskanym za pomocą
polecenia describe, ani w perspektywie słownika bazy danych USER_TAB_COLUMNS,
ale znajduje się on w tabeli MV_SPRZEDAZ. Wartość tego atrybutu można
wyświetlić odwołując się do niego bezpośrednio w zapytaniu, jak niżej.

select M_ROW$$, produkt_id, l_sztuk, cena_jedn, data, sklep_id
from mv_sprzedaz;

Przykładowy wynik tego zapytania przedstawiono na dole
strony. Wartość M_ROW$$ jest reprezentowana w postaci heksadecymalnej.

Należy zwrócić uwagę na fakt, że wartości atrybutu ROWID
w tabeli źródłowej powyższej migawki są identyczne z wartościami M_ROW$$.

W przypadku utworzenia perspektywy z klauzulą with
primary key
, rekordy tabeli źródłowej i rekordy migawki są
identyfikowane za pomocą atrybutów wchodzących w skład klucza tabeli źródłowej.
W tym przypadku tabela implementująca migawkę nie zawiera atrybutu M_ROW$$,
a indeks jest zakładany na atrybutach kluczowych. Indeks taki przyjmuje nazwę
ograniczenia integralnościowego definiującego klucz podstawowy tabeli źródłowej.
W naszym przykładzie, indeks ten zostanie założony na trójce atrybutów produkt_id,
sklep_id, data.

6.5. Rejestrowanie migawki w zdalnej bazie danych

W rezultacie utworzenia migawki, informacja o niej jest
zapisywana w źródłowej bazie danych, tj. tej bazie, w której znajdują się
tabele źródłowe migawki. Jest to tzw. proces rejestrowania migawki. W
dokumentacji technicznej [O8Rep] podaje się, że migawki założone mogą nie
być automatycznie rejestrowane. W takim przypadku, migawkę można „ręcznie”
zarejestrować w bazie źródłowej. Należy jednak zwrócić uwagę na fakt, że
zarejestrowanie bądź niezarejestrowanie migawki w źródłowej bazie danych
nie ma żadnego wpływu na odświeżanie tej migawki.

Do rejestrowania migawki służy procedura register_snapshot
(register_mview) pakietu systemowego dbms_snapshot (dbms_mview)
[O8Pac, O9Pac]. Procedurę tę należy wywołać w bazie źródłowej. Procedura
ta wymaga przekazania siedmiu argumentów wejściowych w następującej kolejności:
nazwa właściciela migawki (argument mviewowner), nazwa migawki (mviewname),
nazwa bazy danych w której utworzono migawkę (mviewsite), identyfikator
migawki (mview_id), opis własności migawki (flag), tekst
zapytania definiującego migawkę (qry_txt) i wersja migawki (rep_type).
Wartością argumentu flag jest jedna ze stałych predefiniowanych w
pakiecie dbms_mview, m.in.:

  • reg_primary_key_mview – oznacza migawkę
    typu primary key;
  • reg_fast_refreshable_mview – oznacza migawkę
    odświeżaną przyrostowo;
  • reg_updatable_mview – oznacza migawkę z możliwością
    modyfikowania jej danych.

Stałe te można łączyć, uzyskując migawki o różnych własnościach,
np. dbms_mview.reg_primary_key_mview + dbms_mview.reg_fast_refreshable_mview
oznacza migawkę typu primary key, odświeżaną przyrostowo.

Wartością qry_txt jest klauzula select
o maksymalnej długości 32000B.

Wartością flag jest jedna ze stałych
predefiniowanych w pakiecie dbms_mview, m.in.: reg_v7_snapshot
oznaczająca migawkę wersji Oracle7, reg_v8_snapshot
oznaczająca migawkę wersji Oracle8.

Przykładowo, zadaniem poniższego polecenia jest
zarejestrowanie migawki mv_sklepy w bazie źródłowej lab81.ii.pp.

exec dbms_mview.register_mview ( -

'demo', -
'mv_sklepy', -
'dmine', -
100, -
dbms_mview.reg_rowid_mview, -
'select sklep_id, nazwa from user1.sklepy@dmine', -

dbms_mview.reg_v8_snapshot)

Eksperymenty z Oracle9i, rel. 9.0.1, w systemie Linux,
pokazują jednak, że pomimo bezbłędnego wykonania powyższego polecenia,
informacje o zarejestrowanej migawce nie pojawiają się w żadnej z perspektyw DBA_,
ALL_, USER_REGISTERED_SNAPSHOTS.

Migawka powinna zostać automatycznie wyrejestrowana ze
zdalnej bazy w wyniku usunięcia migawki. Doświadczenia z bazą Oracle8i (rel.
8.1.6.) pokazują jednak, że tak się nie dzieje. W takim przypadku można
migawkę wyrejestrować „ręcznie” korzystając z procedury unregister_snapshot
(unregister_mview), pakietu systemowego dbms_snapshot (dbms_mview).
Procedurę tę należy wywołać w bazie źródłowej. Procedura ta wymaga
przekazania trzech argumentów wejściowych w następującej kolejności: nazwa
właściciela migawki (argument snapowner), nazwa migawki (argument snapname)
i nazwa bazy danych w której utworzono migawkę (argument snapsite).
Wartość snapsite będzie identyczna z wartością atrybutu snapshot_site
perspektywy USER_REGISTERED_SNAPSHOTS (por. punkt 6.7.2). Przykładowe
wywołanie tej procedury w celu wyrejestrowania migawki mv_sprzedaz jest
następujące:

exec dbms_mview.unregister_mview(‚DEMO’, ‚MV_SPRZEDAZ’,
‚LAB81.II.PP’)

6.6. Modyfikowanie i usuwanie migawki

Charakterystykę istniejącej migawki można zmienić za
pomocą polecenia SQL alter snapshot lub alter materialized
view
. Podstawową składnię tego polecenia przedstawiono poniżej. Pełną
składnię tego polecenia Czytelnik znajdzie w [O8SSql, O9SSql].

alter snapshot nazwa_migawki
[refresh

{fast | complete | force}] [{on demand | on
commit
}]
[start with data_pierwszego_odświeżenia]
[next częstotliwość_odświeżania]
[with primary key];

Jak wynika z powyższego polecenia w istniejącej migawce można:

  • zmodyfikować sposób jej odświeżania,

  • wyspecyfikować moment pierwszego odświeżenia po
    modyfikacji;

  • zmodyfikować częstotliwość odświeżania.

Ostatnia klauzula polecenia sugeruje możliwość zmiany typu
migawki z rowid na primary key. Doświadczenia z Oracle8i,
rel. 8.1.6 i Oracle9i, rel. 9.0.1 pokazują jednak, że taka
operacja kończy się błędem.

Poniżej podano przykład polecenia modyfikującego migawkę mv_produkty.

alter materialized view mv_produkty
refresh complete on demand
start with sysdate+(1/(24*60*2))
next sysdate+(1/(24*60*20));

Migawkę usuwa się za pomocą polecenia SQL:

drop snapshot nazwa;

lub

drop materialized view nazwa;

6.7. Słownik bazy danych

6.7.1. Informacje o utworzonych migawkach

Informacje na temat migawek istniejących w systemie bazy
danych można uzyskać za pomocą zapytania skierowanego do perspektyw słownika
bazy danych: DBA_, ALL_, lub USER_SNAPSHOTS [O8SRef,
O9SRef]. Najczęściej wykorzystywane atrybuty tych perspektyw to:

name – nazwa migawki; wartość tego atrybutu jest
identyczna z wartością table_name; we wcześniejszych wersjach SZBD
Oracle, wartością name była nazwa perspektywy przez którą
realizowano dostęp do tabeli implementującej migawkę;

table_name – nazwa tabeli implementującej migawkę;
wartość tego atrybutu jest identyczna z wartością name;

master – nazwa tabeli źródłowej migawki; w
przypadku, gdy migawka posiada kilka tabel źródłowych, jako wartość master
pojawia się nazwa tej tabeli, którą wymieniono jako ostatnią w klauzuli from
zapytania definiującego migawkę;

master_link – nazwa dołączenia bazodanowego,
wykorzystywanego do zrealizowania dostępu do ostatniej tabeli wymienionej w
klauzuli from zapytania definiującego migawkę;

updatable – przyjmuje wartość YES dla
migawki modyfikowalnej, w przeciwnym przypadku przyjmuje NO; migawki
modyfikowalne są wykorzystywane w tzw. zaawansowanej opcji replikacji (ang.
advanced repliacation option), której omówienie wykracza poza zakres
niniejszego artykułu, więcej informacji na ten temat Czytelnik znajdzie w
[O8Rep, O9Rep];

refresh_method – określa sposób identyfikacji
rekordów migawki dla odświeżania przyrostowego; przyjmuje wartość PRIMARY
KEY
dla migawki odświeżanej przyrostowo, zdefiniowanej z klauzulą with
primary key
; przyjmuje wartość ROWID dla migawki odświeżanej
przyrostowo, zdefiniowanej z klauzulą with rowid; przyjmuje wartość
COMPLEX dla migawek odświeżanych w pełni, niezawierających funkcji
agregujących, niezależnie od klauzuli with; natomiast wartość AGGREGATE
jest ustawiana dla migawek zawierających funkcje agregujące, niezależnie od
klauzuli with;

type – określa sposób odświeżania i może przyjąć
jedną z czterech wartości: FAST, FORCE, COMPLETE, NEVER;

next – wartość wyspecyfikowana w klauzuli next;

start_with – wartość wyspecyfikowana w klauzuli start
with
;

refresh_group – numer grupy odświeżania, do której
należy migawka (zostanie omówiona w trzeciej części artykułu);

query – tekst zapytania (klauzula select)
definiującego migawkę;

refresh_mode – przyjmuje jedną z trzech wartości:
PERIODIC – jeśli wyspecyfikowano zarówno klauzulę start
with
, jak i next; COMMIT – jeśli
wyspecyfikowano klauzulę on commit; NEVER – jeśli
wyspecyfikowano klauzulę never refresh, DEMAND
w pozostałych przypadkach.

6.7.2. Informacje o migawkach zarejestrowanych w bazie źródłowej

Informacje o wszystkich migawkach zarejestrowanych w bazie źródłowej
są dostępne za pomocą perspektywy słownika bazy danych DBA_, ALL_,
lub USER_REGISTERED_SNAPSHOTS. Schemat tej ostatniej jest następujący.

Name  Null? Type



OWNER  NOT NULL VARCHAR2(30)
NAME NOT NULL VARCHAR2(30)
SNAPSHOT_SITE NOT NULL VARCHAR2(128)
CAN_USE_LOG   VARCHAR2(3)
UPDATABLE    VARCHAR2(3)
REFRESH_METHOD   VARCHAR2(11)
SNAPSHOT_ID   NUMBER(38)
VERSION VARCHAR2(17)
QUERY_TXT LONG

 

owner – przechowuje nazwę użytkownika, w którego
schemacie utworzono migawkę;

name – jest nazwą migawki;

snapshot_site – jest nazwą bazy danych, w której
znajduje się migawka;

can_use_log – przyjmuje wartość YES dla
migawki, która może być odświeżana przyrostowo; w przeciwnym przypadku
przyjmuje wartość NO;

updatable – przyjmuje wartość YES dla
migawki modyfikowalnej, a NO dla standardowej migawki, której zawartości
nie daje się modyfikować;

refresh_method – oznacza typ migawki, tj. albo primary
key
albo rowid;

snapshot_id – jest systemowym identyfikatorem
zarejestrowanej migawki;

version – oznacza wersję migawki, tj. Oracle7,
Oracle8
;

query_text – udostępnia tekst zapytania definiującego
migawkę.

Jako przykład rozważmy migawkę mv_sprzedaz zdefiniowaną
w bazie danych dmine.ii.pp, w sposób przedstawiony poniżej. Dołączenie
bazodanowe dbl1 wskazuje na schemat użytkownika demo w bazie lab81.ii.pp.
Po utworzeniu migawki jest ona rejestrowana w bazie lab81.ii.pp.

create materialized view mv_sprzedaz
refresh force
start with sysdate
next sysdate+(1/(24*60*30))
with primary key
as
select produkt_id, l_sztuk, cena_jedn, data, sklep_id
from user1.sprzedaz@dbl1;

Przykładowe zapytanie do USER_REGISTERED_SNAPSHOTS, w
bazie źródłowej lab81.ii.pp, wyświetlające opis
zarejestrowanej migawki mv_sprzedaz i jego wynik.

select ownr, name, snpshot_site, can_use_log,
updatable,
refresh_method, snapshot_id
from user_registered_snapshots
where name='MV_SPRZEDAZ';

OWNER NAME SNAPSHOT CAN UPD REFRESH_MET SNAPSHOT_ID







DEMO MV_SPRZEDAZ DMINE.II.PP YES NO PRIMARY KEY 45

6.7.3. Informacje o odświeżaniu migawek

Informacje na temat czasu ostatniego odświeżenia migawki są
dostępne za pomocą perspektywy słownika danych DBA_, ALL_, lub
USER_SNAPSHOT_REFRESH_TIMES
. Przykładowe zapytanie do tej perspektywy i
jego wynik przedstawiono poniżej.

select owner, name, master_owner, master,
to_char(last_refresh, «dd.mm.yyyy:hh24:mi:ss»)
last_refresh
from user_snapshot_refresh_times;

 

OWNER NAME MASTER_OWNER MASTER LAST_REFRESH





DEMO  MV_SKLEPY USER1 SKLEPY 12.02.2002:18:05:00

 

owner – jest właścicielem migawki;

name – jest nazwą migawki;

master_owner – oznacza właściciela tabeli źródłowej
migawki;

master – jest nazwą tabeli źródłowej migawki; w
przypadku gdy migawka posiada kilka tabel źródłowych, jako wartość master
pojawia się nazwa tej tabeli, którą wymieniono jako ostatnią w klauzuli from
zapytania definiującego migawkę;

last_refresh – przechowuje datę i czas ostatniego
odświeżenia danej migawki.

W części trzeciej artykułu zostaną omówione grupy odświeżania
oraz wykorzystanie perspektyw zmaterializowanych w optymalizacji zapytań.


Bibliografia

[Au00] Ault M.: Oracle8i Administration and Management. Wiley
Computer Publishing, 2000, ISBN 0-471-35453-8

[Dye99] Dye C.: Oracle Distributed Systems. O’Reilly
& Associates, 1999, ISBN 1-56592-432-0

[O8Con] Dokumentacja techniczna. Oracle9i Database Concepts,
rel. 9.0.1

[O8Dba] Dokumentacja techniczna. Oracle9i Database
Administrator’s Guide, rel. 9.0.1

[O8DW] Dokumentacja techniczna. Oracle8i Data Warehousing
Guide, rel. 8.1.6

[O8Pac] Dokumentacja techniczna – Oracle8i Supplied PL/SQL
Packages Reference, rel. 8.1.6

[O8Rep] Dokumentacja techniczna – Oracle8i Server.
Oracle8i Replication, rel. 8.1.6

[O8SRef] Dokumentacja techniczna – Oracle8i Server.
Oracle8i Reference, rel. 8.1.6

[O8SSql] Dokumentacja techniczna – Oracle8i Server.
Oracle8i SQL Reference, rel. 8.1.6

[O9Con] Dokumentacja techniczna. Oracle9i Database Concepts,
rel. 9.0.1

[O9Dba] Dokumentacja techniczna. Oracle9i Database
Administrator’s Guide, rel. 9.0.1

[O9DW] Dokumentacja techniczna. Oracle9i Data Warehousing
Guide, rel. 9.0.1

[O9Pac] Dokumentacja techniczna. Oracle9i Supplied PL/SQL
Packages and Types Reference, rel. 9.0.1

[O9Rep] Dokumentacja techniczna. Oracle9i Replication, rel.
9.0.1

[O9SRef] Dokumentacja techniczna – Oracle9i Server.
Oracle9i Database Reference, rel. 9.0.1

[O9SSql] Dokumentacja techniczna – Oracle9i Server.
Oracle9i SQL Reference, rel. 9.0.1

[Ora8i] Dokumentacja DBMS Oracle8i, rel. 8.1.6

[Ora9i] Dokumentacja DBMS Oracle9i, rel. 9.0.1

[OraMsz] Materiały szkoleniowe Oracle Polska: Oracle8i: New
Features for Administrators

[WJZ99] Wrembel R. Jezierski J., Zakrzewicz M.: System Zarządzania
Bazą Danych Oracle7 i Oracle8. Wydawnictwo NAKOM, 1999, ISBN 83-86969-34-2

[Wre00] Wrembel R.: Perspektywy (views) w systemach baz
danych: aktualny stan technologii. VI Konferencja Użytkowników i Deweloperów
Oracle – PLOUG’00, Zakopane, październik 2000, pp. 83-98, ISSN
1641-2117