Strategia odświeżania zmaterializowanych widoków w hurtowni danych

Question

Mam system, który ma zmaterializowany widok, który zawiera około 1 miliarda przedmiotów, w ciągu dwóch godzin co godzinę muszę zaktualizować około 200 milionów (20% rekordów). Moje pytanie brzmi: jak powinna wyglądać strategia odświeżania mojego materializowanego widoku? Od tej chwili jest odświeżany z przerwą. Jestem ciekawy co do wpływu wydajności pomiędzy odświeżaniem w czasie odświeżania w czasie interwału, a zmianą/zastąpieniem starego zmaterializowanego widoku nowym. Podstawową kwestią są indeksy, które są używane przez Oracle, co powoduje ogromną ilość powtórzeń. Wszelkie sugestie są mile widziane.

UPDATE
Ponieważ niektórzy ludzie zdają się myśleć, że to jest off topic mój obecny punkt widzenia jest, aby wykonać następujące czynności:

utworzenie harmonogramu Chain Oracle, który wywołuje szereg PL/SQL (programowania języka I obietnica) służy do odświeżania zmaterializowanego widoku w sposób pseudo-równoległy. Jednak będąc tak, jakbym wpadł na stanowisko pewnego rodzaju DBA, szukam rozwiązania problemu z danymi z algorytmu i/lub jakiegoś kodu.

Answer 1

OK, więc tutaj jest rozwiązanie, które wymyśliłem, twój przebieg może się różnić, a wszelkie opinie są doceniane po fakcie. Ogólna strategia było wykonać następujące czynności:

1) wykorzystują Oracle Scheduler korzystającą z równoległego wykonywania łańcuchów (Praca)
2) wykorzystać widoki (regularne naturze) jak interfejs z aplikacji do bazy
3) Oparcie zmaterializowanych widoków ma zostać zbudowany w następujący sposób

create materialized view foo 
    parallel 
    nologging 
    never refresh 
    as 
    select statement 

jako niezbędnego użytku, co następuje:

create index baz on foo(bar) nologging 

advantag Chodzi o to, że możemy zbudować zmaterializowany widok w tle przed upuszczeniem + odtworzeniem widoku, jak opisano w kroku 2. Teraz zaletą jest tworzenie dynamicznie nazwanych zmaterializowanych widoków przy zachowaniu widoku o tej samej nazwie. Kluczem jest, aby nie wysadzić oryginalnego zmaterializowanego widoku, dopóki ten nowy nie zostanie ukończony. Pozwala to również na szybkie upuszczenie, ponieważ istnieje minimalny czas oczekiwania na opiekę. Umożliwiło to zmaterializowane tworzenie widoku na ~ 1 miliarda rekordów w ciągu 5 minut, co spełniało nasze wymagania dotyczące "odświeżania" co trzydzieści minut. Ponadto jest to możliwe do obsłużenia w jednym węźle bazy danych, więc nawet przy ograniczonym sprzęcie jest to możliwe.

Oto funkcja PL/SQL, który stworzy dla Ciebie:

CREATE OR REPLACE procedure foo_bar as 
foo_view varchar2(500) := 'foo_'|| to_char(sysdate,'dd_MON_yyyy_hh_mi_ss'); 
BEGIN 
execute immediate 
'Create materialized view '|| foo_view || ' 
    parallel 
    nologging 
    never refresh 
    as 
    select * from cats'; 
END foo_bar;