Wpisy z tagiem: dba4dev

Jak spowodować aby baza danych zapomniała o swojej przeszłości ?

Kto nigdy nie chciał zapomnieć o jakiejś sytuacji z przeszłości ? No tak, ja też czasem chciałem ;-)
Ilustracja:

Podobnie jest z bazami danych Oracle. Czasem spotykamy sie z sytuacją, w której potrzebujemy odtworzyć bazę danych do punktu w czasie (PITR).

W tym celu odtwarzmy bazę danych z backup'u, przy pomocy RMAN (więcej o RMAN na playliście: ), i uspójniamy do najbliższego, ale nie nowszego SCN niż wskazany. Wtedy możemy wydać instancji bazy danych komendę 'open' otwierającą bazę danych do użycia. Ale podczas otwierania bazy danych instancja znajduje w plikach REDO zapisy o zmianach wykonanych po wskazanym przez nas punkcie w czasie. Nich chcemy ich naniesienia na bazę. Zazwyczaj nie jest to nawet możliwe.

Trzeba instancji bazy danych powiedzieć, że zmiany znajdujące się w REDO (więcej o logu transakcyjnym: ) nas nie interesują i mogą zostać usunięte. Służy do tego opcja 'resetlogs' komendy 'open'. Użycie 'resetlogs' spowoduje, również reset numeracji REDO logów.

Każdorazowe użycie opcji 'resetlogs' powoduje powstanie kolejnej inkarnacji bazy danych. Jest to zrozumiałe - kasujemy niepotrzebny fragment przeszłości i baza rozpoczyna nowe życie z czystą kartą ;-) Trzeba mieć, jednak na uwadze, że numeracja SCN nie ulega resetowi. Ma to swoje zalety - możemy odtworzyć bazę danych sprzed momentu otwarcia bazy danych z opcją 'resetlogs'. Musimy tylko wskazać odpowiedni numer SCN.

Wskazanie punktu odtwarzania bazy danych przy pomocy daty lub numeru sekwencyjnego nie działa poprzez inkarnacje. Punkt w czasie lub numer logu możemy wskazać jedynie w obrębie danej inkarnacji bazy danych.

Różnica pomiędzy TRUNCATE tabeli a DELETE wszystkich rekordów

Ilustracja: . Opis:

Najważniejsza różnica pomiędzy komendą TRUNCATE, a DELETE, implikującą wszystkie pozostałe różnice, jest taka, że TRUNCATE to operacja DDL, a DELETE DML. O różnicy między DDL, a DML: .

Innymi słowy TRUNCATE operuje na fizycznych strukturach bazy danych - blokach bazodanowych i słowniku, podczas gdy DELETE operuje na samych danych - rekordach.

To, że TRUNCATE jest operacją, której nie można wycofać - rollback'ować - jest częściową prawdą. Nie można jej wycofać w bazie danych Oracle. W Oracle TRUNCATE jest zatwierdzany (commit'owany) 2 razy - na początku i na końcu. Nawet awaryjne zakończenie TRUNCATE w Oracle skutkuje końcowym commit'em. W PostgreSQL i SQL Server jak najbardziej możesz zrobić rollback operacji TRUNCATE.

Różnicą, która budzi największe zainteresowanie jest szybkość wykonania. TRUNCATE jest operacją minimalnie logowaną. Innymi słowy logowana jest jedynie informacja o wykonaniu komendy. Wykonanie operacji TRUNCATE polega na zmianie w słowniku bazy danych informacji o zaalokowanych blokach bazodanowych.

Tymczasem wykonując operację DELETE motor bazy danych musi wczytać do cache każdy blok bazodanowy w którym znajdują się rekordy czyszczonej tabeli. Zmodyfikować zawartość tych bloków, zapisać informacje o zmianie do logu transakcyjnego i na końcu zapisać zmieniony blok bazodanowy z powrotem na dysk. Znacznie więcej pracy niż w przypadku TRUNCATE. I znacznie więcej wygenerowanej objętości logu transakcyjnego. O logu transakcyjnym:

Kosztem wykorzystania TRUNCATE i zarazem konsekwencją tego, że jest to operacja DDL jest nieuruchomienie triggerów oraz więzów integralności typu FOREIGN KEY. Aby zachować spójność instancja bazy danych nie pozwoli na TRUNCATE tabeli z włączonymi FOREIGN KEY. O kluczach głównych i obcych:

Innym kosztem jest poziom blokowania. Podczas operacji TRUNCATE zakładanych jest exclusive lock na całej tabeli. Podczas gdy operacja DELETE zakłada jedynie shared table lock.

Zyskiem, natomiast jest przesunięcie znacznika wysokiej wody czyli uwolnienie bloków bazodanowych, wcześniej należących do tabeli, do ponownego użycie dla innych obiektów. Może to być zablokowane w Oracle gdy zostanie użyta klauzula 'REUSE STORAGE'.

Innym zyskiem może być przywrócenie ustawień początkowych typowi IDENTITY w SQL Server.

Konsekwencją działania na innych poziomach jest również konieczność nadawania innych przywilejów. Uprawnienia do operacji DELETE można nadać użytkownikowi i/lub roli. Natomiast TRUNCATE wymaga nadania przywileju systemowego 'DROP ANY TABLE' w Oracle.

Warto też pamiętać, że w większości implementacji operacja DELETE może zwrócić klientowi informację o usuniętych rekordach czego TRUNCATE nie robi.

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 ?