Oracle 11g nowe cechy, cz. 1.

Oracle 11g nowe cechy, cz. 1. Image courtesy of by twobee/FreeDigitalPhotos.net

Baza danych Oracle 11g dostarcza wielu nowych funkcjonalności oraz rozwiązań problemów, które do tej pory stanowiły zmorę deweloperów.

Dzięki nowym opcjom obsługi triggerów, tabelom read-only, ulepszoną obsługą wyrażeń regularnych oraz kilku kosmetycznym poprawkom zaimplementowanym w nowej wersji bazy danych odczujemy poprawę komfortu programowania. Wygodą stały się też nowe możliwości optymalizacji wydajności kodu, oraz testowania aplikacji. „Niewidzialne” indexy, ulepszona natywna kompilacja PL/SQL, czy bufor Result Cache powinny pozytywnie wpłynąć na nasz codzienny kontakt z bazą Oracle.

Przyjrzyjmy się zatem kilku ciekawszym właściwościom najnowszej bazy danych firmy Oracle.

SQL *PLUS

„Najprostszym i najprzyjemniejszym” narzędziem do obsługi bazy danych Oracle zawsze był SQL*Plus – narzędzie tekstowe o przyjaźnie migającym kursorku. Szczerze mówiąc myślałem, że w Oracle 11g ktoś wpadnie na pomysł, żeby dostarczać to narzędzie z jakże prostą, acz przyjemną opcją historii poleceń, czy dopełniania składni, jednak moje nadzieje okazały się płonne. Zamiast tego otrzymaliśmy produkt wzbogacony o kilka zacnych funkcjonalności, które w ostatecznym rozrachunku mogą być nam wielce przydatne.

set errorlogging on

Całkiem pożyteczna opcja, która upraszcza wykrywanie błędów w skryptach; wiele razy się zdarzało, że pisałem skrypt administracyjny, który powstawał w celu wykonania określonych zadań migracyjnych, aplikacyjnych lub po prostu dla symulacji obciążenia testowej bazy danych. Wiele razy zdarzyło się, że skrypt generował serię błędów, które łatwo było przeoczyć, jeśli nie napisało się do nich własnej obsługi. Dzięki temu nowemu poleceniu, wszystkie błędy powstałe w wyniku poleceń wydawanych w SQL*Plus zostają zapisane do tabeli o nazwie „SPERRORLOG”. Znajdziemy tam informacje o użytkowniku, poleceniu oraz komunikacie błędu zwróconego przez Oracle. Tabela jest zwykłą tabelą, podlegającą normalnym zasadom tranzakcyjności – naturalnie oznacza to, że jeżeli po serii powstałych błędów nasza sesja ulegnie brutalnemu zamknięciu, nie zobaczymy cennych informacji, mogących naprowadzić nas na stosowny trop. Nie mniej jednak jest to opcja, która może w szczególnych przypadkach znacznie ułatwić proces poszukiwania błędów w skryptach.

Przykład:

SQL> set errorlogging on
SQL> desc sperrorlog
Nazwa Wartosc NULL? Typ
----------------------------- -------- --------------------
USERNAME VARCHAR2(256)
TIMESTAMP TIMESTAMP(6)
SCRIPT VARCHAR2(1024)
IDENTIFIER VARCHAR2(256)
MESSAGE CLOB
STATEMENT CLOB
SQL> l
1 select username, timestamp, statement, message
2 from sperrorlog
3* where rownum=1
SQL> /
US TIMESTAMP STATEMENT MESSAGE
-- ------------------------------ --------------------
------------------------------------------------------------------------------------------
HR 08/09/20 13:49:52,000000 delete employees ORA-12081: operacja aktualizacji nie jest

Podobne artykuły:

Szkoła Informatyki IT School Kamil Kozieł