Block Change Tracking

Transkrypt

1 Czym jest i czy warto stosować? OPITZ CONSULTING Kraków Przybliżenie technologii i analiza testów Jakub Szepietowski (Młodszy konsultant SE) OPITZ CONSULTING Kraków 2011 Strona 1

2 Agenda 1. Plik BCT 2. Mechanizm działania 3. Konfiguracja 4. Testy 5. Spadek / wzrost wydajności 6. Czas wykonania backup OPITZ CONSULTING Kraków 2011 Strona 2

3 Krótko o (BCT) Od kiedy? od wydania wersji Oracle 10g Po co? żeby zwiększyć wydajności inkrementalnego backupu Kto może z niego korzystać? dostępny jedynie w wersji Enterprise Edition Domyślna konfiguracja? wyłączony Jak działa? śledzi zmiany w blokach danych i zapisuje ślad do tworzonego przez siebie pliku Jak wpływa na działanie RMAN? RMAN nie skanuje wszystkich bloków danych tylko korzysta z pliku BCT OPITZ CONSULTING Kraków 2011 Strona 3

4 Zanim zrobisz pomyśl... Jaka jest charakterystyka aplikacji? Jaki jest model/tryb przetwarzania danych? Jaki jest wolumen spodziewanych zmian w stosunku do całkowitej wielkości bazy danych? OPITZ CONSULTING Kraków 2011 Strona 4

5 1 Plik BCT OPITZ CONSULTING Kraków 2011 Strona 5

6 Zawartość pliku BLOCK CHANGE TRACKING jeden centralny plik BCT informacje przechowywane w postaci bitmapy koszt przechowywania pliku jest znikomy dostęp do bitmapy jest wysoce efektywny plik domyślnie zawiera 8 wersji bitmap dla każdego pliku danych bazy danych OPITZ CONSULTING Kraków 2011 Strona 6

7 Plik BCT po sporządzeniu kolejnego (9) backupu, najstarsza bitmapa zostaje nadpisana przez najnowszą RMAN nie wspiera backupowania pliku BCT po odtworzeniu całej lub części bazy danych plik jest tworzony na nowo BCT zacznie działać ponownie dopiero po przeprowadzeniu backupu poziomu 0 OPITZ CONSULTING Kraków 2011 Strona 7

8 2 Mechanizm działania OPITZ CONSULTING Kraków 2011 Strona 8

9 Jak działa BCT? mechanizm jest prosty: pierwszy backup poziomu 0 (FULL BACKUP) skanuje wszystkie bloki danych plików bazy danych przeznaczonych do backupu. kolejny, inkrementalny backup na poziomie 1 sięga tylko do tych bloków, których referencje zostały zapisane w pliku BCT OPITZ CONSULTING Kraków 2011 Strona 9

10 Mechanizm działania szczegóły Blok podlegający zmianom trafia z pliku danych do buffer cache w SGA następnie wektor zmian (change vector) wpisywany jest do bloku, zmieniając go w tzw. brudny blok (dirty block) Później, podczas zdarzenia CHECKPOINT brudne bloki zostają przepisane przez (jeden z procesów) DBWR na dysk ani DBWR, ani proces odpowiedzialny za wpisanie wektora zmian do bloku w buffer cache nie przekazuje informacji o zmianach do pliku BCT OPITZ CONSULTING Kraków 2011 Strona 10

11 Mechanizm działania szczegóły Change Tracking Writer (CTWR) proces wpisujący wektor zmian do bloku danych zapisuje jednocześnie informację redo do obszaru Log Buffer i dodatkowo - wpisuje informację o zmienionych blokach do specjalnie zaalokowanego obszaru pamięci CTWR dba buffer w Large Pool (SGA) CTWR dowiaduje się o zmianach skanując CTWR dba buffer i aktualizuje bitmapy w pliku BCT CTWR uaktualnia plik BCT (generuje I/O) asynchroniczne w stosunku do LGWR IO nie jest generowane przy każdym COMMIT OPITZ CONSULTING Kraków 2011 Strona 11

12 3 Konfiguracja OPITZ CONSULTING Kraków 2011 Strona 12

13 Konfiguracja włączenie opcji BCT trybie OPEN lub MOUNT (bez konieczności restartu instancji) ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/app/oracle/oradata/testora22/bctf01.log' REUSE; Wyłączenie opcji BCT jedynie w trybie OPEN lub MOUNT ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; składnia poleceń RMAN po włączeniu opcji BCT nie zmiania się OPITZ CONSULTING Kraków 2011 Strona 13

14 Status widok V$BLOCK_CHANGE_TRACKING. SQL> select STATUS, FILENAME, BYTES from V$BLOCK_CHANGE_TRACKING; STATUS Filename BYTES ENABLED /u01/app/oracle/oradata/testora22/bctf01.log 11,599,872 Domyślnie alokowanych jest 10 MB przestrzeni OPITZ CONSULTING Kraków 2011 Strona 14

15 Bufor CTWR SQL> SELECT * FROM v$sgastat WHERE name like 'CTWR%'; POOL NAME BYTES Large pool CTWR dba buffer 286,720 rywalizacja >> WAIT EVENT --- Buffer Space niska wydajność podsystemu dyskowego lub zbyt mały bufor CTWR dba buffer plik BCT umieszczamy na najszybszym dysku w środowisku Oracle RAC plik BCT w miejscu dostępnym ze wszystkich nodów w klastrze OPITZ CONSULTING Kraków 2011 Strona 15

16 Ukryte parametry _bct_bitmaps_per_file określa maksymalną ilość wersji bitmap przypadającą na jeden plik danych _bct_public_dba_buffer_size określa wielkość bufora CTWR OPITZ CONSULTING Kraków 2011 Strona 16

17 4 Testy OPITZ CONSULTING Kraków 2011 Strona 17

18 O teście o teściowej Czy narzut związany z uaktywnieniem BCT jest na tyle mały, a spodziewane korzyści na tyle duże, by korzystać z BCT? Dwa środowiska testowe: z BCT i bez BCT Procedura obciążająca bazę danych OPITZ CONSULTING Kraków 2011 Strona 18

19 Przebieg testu 1. Migawka do raportu AWR 2. Uruchamiamy procedurę STRESS - generujemy obciążenie 3. Po zakończeniu procedury STRESS - kolejna migawka do raportu AWR 4. Backup inkrementalny 0 5. Ponownie uruchamiamy procedurę STRESS 6. Tworzymy backup inkrementalny poziomu 1 OPITZ CONSULTING Kraków 2011 Strona 19

20 Nic za darmo??? Ile to kosztuje zwiększenie wykorzystania zasobów serwera? śledzenie i zapisywanie zmian do pliku BCT? proces tła Change Tracking Writer?? wydłużenie czasu obsługi transakcji?? OPITZ CONSULTING Kraków 2011 Strona 20

21 5 Spadek / wzrost wydajności OPITZ CONSULTING Kraków 2011 Strona 21

22 Wyniki testu obciążenie BCT DISABLED Event Waits Time(s) Avg wait (ms) % DB time DB CPU log buffer space db file sequential read log file switch (private stran log file switch completion BCT ENABLED Event Waits Time(s) Avg wait (ms) % DB time DB CPU log buffer space block change tracking buffer s log file switch (private stran db file sequential read BCT DISABLED BCT ENABLED Per Per Load Profile Per Second Transaction Per Second Transaction DB Time(s): DB CPU(s): Redo size: 4,068, , ,104, ,702.9 Logical reads: 14, , , ,099.1 Block changes: 27, , , ,055.6 Physical reads: Physical writes: User calls: Parses: Hard parses: W/A MB processed: Logons: Executes: 13, , Rollbacks: Transactions: OPITZ CONSULTING Kraków 2011 Strona 22

23 6 Czas wykonania backupu OPITZ CONSULTING Kraków 2011 Strona 23

24 Wyniki testu - insert Przyrost danych wygenerowanych przez procedurę STRESS BCT wyłączony (czas trwania backup u inkrementalnego) BCT włączony (czas trwania backup u inkrementalnego) 380MB 03:45,3 00:51,4 1140MB 04:44,2 02:32,0 2280MB 05:54,8 04:37,2 OPITZ CONSULTING Kraków 2011 Strona 24

25 Wyniki testu - insert OPITZ CONSULTING Kraków 2011 Strona 25

26 Wyniki testu - update Przyrost danych wygenerowanych przez procedurę STRESS_UPDATE BCT wyłączony (czas trwania backup u inkrementalnego) BCT włączony (czas trwania backup u inkrementalnego) 380MB 02:24,0 00:34,6 1140MB 03:34,8 01:27,8 2280MB 05:31,0 02:49,0 OPITZ CONSULTING Kraków 2011 Strona 26

27 Wyniki testu - update OPITZ CONSULTING Kraków 2011 Strona 27

28 Kontakt Jakub Szepietowski Młodszy konsultant działu Service Engineering OPITZ CONSULTING Kraków tel OPITZ CONSULTING Kraków 2011 Strona 28

29 Pytania OPITZ CONSULTING Kraków 2011 Strona 29