Wpisy z tagiem: oracle

W Oracle można podejrzeć plan wykonania komendy SQL na 2 sposoby:

• używając polecenia EXPLAIN PLAN FOR
• wyszukując informacje w V$SQL_PLAN

Warto pamiętać, że EXPLAIN PLAN FOR pokazuje hipotetyczny plan wykonania. Bazuje on, oczywiście na statystykach i metadanych odczytanych z bazy danych. Jest bardzo prawdopodobny, ale nigdy nie został wykonany.

W V$SQL_PLAN, dla odmiany, znajdują się plany wykonania faktycznie użyte do wykonania komendy SQL.

Kiedy ta różnica jest najbardziej istotna ? Wtedy kiedy używamy zmiennych wiązanych. Optymalizator wie, wg jakich kolumn wynik komendy SQL będzie ograniczany. Ale nie zna wartości, które będą podstawione pod zmienne wiązane. W związku z tym nie może, ze 100% trafnością, zdecydować o użyciu indeksu lub jego nie używaniu.

Dopiero faktyczne wykonanie komendy SQL z podstawionymi pod zmienne wartościami spowoduje wygenerowanie i wykonanie optymalnego planu. Będzie on wtedy dostępny w V$SQL_PLAN.

W przypadku systemów hurtownianych, gdzie częstotliwość komend SQL jest stosunkowo niska, używanie zmiennych wiązanych nie zawsze wiąże się ze wzrostem wydajności. O tyle w systemach OLTP używanie zmiennych wiązanych bardzo wydajność poprawia.

Do uzyskania raportu o planie wykonania służy pakiet DBMS_XPLAN i jego dwie podstawowe funkcje:

• DISPLAY - wykonana zaraz po komendzie EXPLAIN PLAN FOR generuje raport z jej wykonania
• DISPLAY_CURSOR - generuje raport o dwolnej komendzie SQL na podstawie widoku V$SQL_PLAN

Można ich użyć w, na przykład, taki sposób:

select * from table(dbms_xplan.display);

Pakiet DBMS_XPLAN dysponuje znacznie większymi możliwościami niż, jedynie, powyższe. Oprócz wymienionych źródeł może sięgać, również po plany wykonania do:

• Automatic Workload Repository (AWR)
• SQL Tuning Set (STS)
• SQL Plan Baseline (SPM)

Czego Ty używasz do generowania planów wykonania ?

Jak odtworzyć spfile - plik konfiguracyjny instancji bazy danych Oracle ?

Instancja bazy danych Oracle może współpracować z plikiem konfiguracyjnym w postaci tekstowej: pfile oraz w postaci binarnej: spfile. Tylko plik binarny - spfile może być automatycznie backup'owany przez RMAN'a. Scenariusze odtworzenia z automatycznego backup'u:

1. Jeśli straciliśmy całą bazę danych razem z binariami, a automatyczny backup pliku kontrolnego nie jest we FRA

Aby móc korzystać z RMAN'a musimy mieć działającą instancję Oracle. UWAGA: nie instancję bazy danych. Chodzi jedynie o procesy i struktury pamięci. Bez danych ani tego co pamiętamy o naszej wyjątkowej konfiguracji. Wystarczy uruchomienie instancji z podstawową konfiguracją i zmienną ORACLE_SID ustawioną na nazwę bazy danych jaką chcemy odtwarzać. Dzięki temu mamy dostęp do funkcjonalności RMAN'a. Innymi słowy startujemy instancję bez montowania bazy danych: 'startup nomount'. DYGRESJA: montowanie bazy danych to otwarcie pliku kontrolnego. A ten nie jest jeszcze dostępny.

Aby RMAN wiedział, spfile której instancji ma odtworzyć, należy najpierw ustawić wartość DBID w sesji rman'a komendą 'set DBID'. Dlatego warto pamiętać jakie DBID mają nasze bazy danych ;-) Następnie komendą 'restore spfile from autobackup' odtwarzamy spfile z najnowszej dostępnej kopii. DYGRESJA: ustawienie DBID potrzebne jest RMAN'owi aby znaleźć odpowiedni backup piece - plik z backup'em. O backup piece mowa w: . Informacje o backup'ach przechowywane są w pliku kontrolnym, a ten jest niedostępny. RMAN wykorzystuje, więc konwencję nazewniczą automatycznych backup'ów w celu znalezienia właściwego. Kluczowym fragmentem nazwy takiego pliku backup'u jest DBID.

1. Straciliśmy całą bazę danych, ale automatyczny backup pliku kontrolnego jest we FRA

Początek jak w punkcie #1 - trzeba uruchomić tymczasową instancję aby móc korzystać z funkcjonalności RMAN'a. Z jedną różnicą - w tymczasowym pliku konfiguracyjnym trzeba wskazać na FRA w którym znajdują się backup'y pliku kontrolnego.

Następnie wystarczy komenda 'restore spfile from autobackup' i RMAN znajdzie i odtworzy dla nas najświeższy spfile.

1. Straciliśmy całą baze danych i chcemy odtworzyć spfile z konkretnego backup piece

Co to backup piece: . Podobnie jak w punkcie #1 trzeba wystartować instancję Oracle. Podobnie trzeba ustawić DBID komendą 'set DBID'. Tym razem składnia komendy 'restore', jednak wskazuje konkretną nazwę pliku z backup'em. Nazwę backup piece. Np. restore spfile from '/ora_backup/C-1029394857-20201212-00';. Dostępne od wersji 10g.

1. Straciliśmy całą bazę danych, automatyczny backup pliku kontrolnego jest gdziekolwiek dostępny, ale używamy recovery catalog

Początek jak w punkcie #2. Różnica taka, że zamiast wskazywania FRA, w tymczasowym pliku konfiguracyjnym, musimy podłączyć się rman'em oprócz bazy target, również do recovery catalog. Dalej równie prosto: 'restore spfile from autobackup'.

1. Baza danych jest nieuszkodzona, a instancja działa i automatyczny backup pliku kontrolnego jest gdziekolwiek dostępny

Nie trzeba startować instancji bo działa. Plik kontrolny jest dostępny, więc RMAN wie gdzie znaleźć backup. Wtedy wystarczy komenda: restore spfile to pfile '/tmp from autobackup';. Należy pamiętać, że tak odtworzony plik konfiguracyjny jest w postaci tekstowej - inaczej jak spfile, który jest w binarnej.

Jeśli utracie uległa cała baza danych to następnym krokiem jest odtworzenie z backup'u pliku kontrolnego (control file). W nim zawarte są informacje o lokalizacji plików bazodanowych i ich kopiach w backup'ach.

Keywords: #database #oracle #rman #backup #restore #backend #rdbms #dba4dev #marcinbadtke