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
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
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
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
1 Plik BCT OPITZ CONSULTING Kraków 2011 Strona 5
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
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
2 Mechanizm działania OPITZ CONSULTING Kraków 2011 Strona 8
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
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
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
3 Konfiguracja OPITZ CONSULTING Kraków 2011 Strona 12
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
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
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
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
4 Testy OPITZ CONSULTING Kraków 2011 Strona 17
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
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
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
5 Spadek / wzrost wydajności OPITZ CONSULTING Kraków 2011 Strona 21
Wyniki testu obciążenie BCT DISABLED Event Waits Time(s) Avg wait (ms) % DB time DB CPU 201 77.6 log buffer space 226 51 227 19.8 db file sequential read 307 1 3.3 log file switch (private stran 8 0 53.2 log file switch completion 2 0 77.1 BCT ENABLED Event Waits Time(s) Avg wait (ms) % DB time DB CPU 203 79.5 log buffer space 178 48 269 18.8 block change tracking buffer s 4 1 250.4 log file switch (private stran 10 1 71.3 db file sequential read 230 0 1.1 BCT DISABLED BCT ENABLED Per Per Load Profile Per Second Transaction Per Second Transaction DB Time(s): 0.7 0.1 0.7 0.1 DB CPU(s): 0.5 0.0 0.5 0.0 Redo size: 4,068,064. 8 307,902.7 4,104,014. 4 307,702.9 Logical reads: 14,528.1 1,099.6 14,659.3 1,099.1 Block changes: 27,174.6 2,056.8 27,416.1 2,055.6 Physical reads: 0.8 0.1 0.6 0.1 Physical writes: 171.0 12.9 169.9 12.7 User calls: 0.1 0.0 0.1 0.0 Parses: 1.7 0.1 1.6 0.1 Hard parses: 0.0 0.0 0.0 0.0 W/A MB processed: 0.1 0.0 0.1 0.0 Logons: 0.0 0.0 0.0 0.0 Executes: 13,182.8 997.8 13,299.9 997.2 Rollbacks: 0.0 0.0 0.0 0.0 Transactions: 13.2 13.3 OPITZ CONSULTING Kraków 2011 Strona 22
6 Czas wykonania backupu OPITZ CONSULTING Kraków 2011 Strona 23
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
Wyniki testu - insert OPITZ CONSULTING Kraków 2011 Strona 25
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
Wyniki testu - update OPITZ CONSULTING Kraków 2011 Strona 27
Kontakt Jakub Szepietowski Młodszy konsultant działu Service Engineering OPITZ CONSULTING Kraków jakub.szepietowski@opitz-consulting.com tel. +48 12 617 1819 OPITZ CONSULTING Kraków 2011 Strona 28
Pytania OPITZ CONSULTING Kraków 2011 Strona 29