Wpisy z tagiem: dba4dev

4 poziomy izolacji standardu ANSI + 3 zjawiska towarzyszące

Zilustrowane:

Kluczem do zrozumienia poziomów izolacji jest zaakceptowanie faktu, że to Ty decydujesz na jakim poziomie wykona się Twoja transakcja. Robisz to po to aby ODIZOLOWAĆ dane, na których Twoja transakcja pracuje, od wpływu innych transakcji. Innymi słowy ustanawiając poziom izolacji dla SWOJEJ transakcji, ograniczasz możliwość wykonania zmian, innym transakcjom, na danych potrzebnych TWOJEJ transakcji.

Poziomy izolacji mają duży wpływ na współbieżność transakcji działających na bazie danych. Jeśli więc chcesz aby Twoja aplikacja działała wydajnie i miała wielu zadowolonych użytkowników to używaj najniższego z możliwych poziomów izolacji. W niektórych przypadkach może być korzystne użycie niższego poziomu izolacji i zabezpieczenie Twojej transkacji, czy aplikacji, przed konsekwencjami zjawisk towarzyszących.

► READ UNCOMMITTED - najniższy poziom izolacji. Odczytuje nie commit'owane zmiany dokonane przez inną transakcję.
► READ COMMITTED - poziom izolacji zapewniający odczyt tylko commit'owanych zmian innych transakcji
► REPEATABLE READ - poziom izolacji zawierający READ COMMITTED oraz zapewniający niezmienność jakości danych pomiędzy odczytami tych samych danych
► SERIALIZABLE - poziom izolacji zawierający REPEATABLE READ oraz zapewniający brak różnicy w ilości rekordów pomiędzy kolejnymi odczytami tych samych danych
► DIRTY READ - zjawisko odczytu nie commit'owanych zmian innych transakcji
► NON-REPEATABLE READ - zjawisko różnicy jakościowej pomiędzy kolejnymi odczytami tych samych danych przez jedną transakcję
► PHANTOM READ - zjawisko różnicy ilościowej pomiędzy kolejnymi odczytami tych samych danych przez jedną transakcję

Keywords: #database #rdbms #mysql #postgresql #sqlserver #oracle #oracledatabase #oracledba #programming #coding #development #sql #plsql #backend #programowanie #poziomyizolacji #isolationlevels #bazadanych #bazydanych

Masz dość tnsnames.ora ?

Nie potrzebujesz go, ani zmiennej TNS_ADMIN, używając EZConnect - Easy Connect.

Przykład:

sql użytkownik/hasło@[//]host[:port][/service_name]

service_name - jeśli pominiesz to podłączysz się o ile w listener jest poprawnie zdefiniowana domyślna baza danych.
port - jeśli pominiesz to podłączysz się jeśli listener słucha na 1521
// - możesz dodać jak lubisz notację URL ;-)

Działa, również z: rman, sqlplus, tnsping czy Twoją aplikacją.

Możesz nie używać ani tnsnames.ora ani EZConnect:

sql użytkownik/hasło@(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=<service_name>))(ADDRESS=(PROTOCOL=tcp)(HOST=<host>)(PORT=<port>)))

A jeśli używasz 19c to możesz wykorzystać load balancing w connect stringu:

sql użytkownik/hasło@[//]host1,host2[:port][/service_name]

O ile listener'y słuchają na tym samym porcie. Bo jeśli na różnych to:

sql użytkownik/hasło@[//]host1:port1,host2:port2[/service_name]

Notacja testowana z SQLcl - klient w Java. Trzyma historię, pozwala na edycję komend i dokańcza/podpowiada nazwy obiektów oraz słowa kluczowe - klawisz TAB. Możesz też pisać skrypty, uruchamiane po stronie klienta, w JavaScript. Przydatne np. do obróbki wyników.
Do pobrania stąd:
https://www.oracle.com/database/technologies/appdev/sqlcl.html

#dba4dev #marcinbadtke #sqlplus #sqlcl #oracle #oracledatabase #oracledba #sql #tnsnames #ezconnect

MVCC - Multi-Version Concurrency Control w bazach danych

Wideo:

Dawno temu, gdy bazy były małe, a niewielu użytkowników sporadycznie generowało transakcje, instancja bazy danych mogła sobie pozwolić aby blokować dostęp do danych dla każdej transakcji. Nawet do odczytu. Dane blokowane były na krótkie odcinki czasu, a z deadlock'ami nauczono się żyć.

Wraz z globalizacją, postępem technologicznym, rozwojem i upowszechnieniem internetu bazy danych urosły, a liczba ich użytkowników wzrosła wielokrotnie. Generowali oni tak olbrzymie ilości transakcji, że blokowanie danych na czas dostępu powodowało wymierne opóźnienia w ich przetwarzaniu.

W sukurs przyszli producenci baz danych implementując technologię MVCC - Multi-Version Concurrency Control. Technologię umożliwiającą każdej transakcji dostęp do danych bez konieczności ich blokowania na czas dostępu. Znacząco poprawia to współbieżność transakcji oraz praktycznie eliminuje prawdopodobieństwo wystąpienia deadlock'u. Niemniej trzeba mieć na uwadze, że w takim przypadku każda transakcja widzi SWOJĄ wersję danych. Prezentowaną przez instancję bazy danych wg stanu na czas rozpoczęcia danej transakcji.

Różni producenci różnie MVCC implementują. Dla przykładu:

• PostgreSQL przechowuje poprzednie wersje zmienionych rekordów w tej samej przestrzeni co dane
• MySQL w InnoDB przechowuje jedynie fragment informacji o zmianach w rekordzie, w innym segmencie - rollback segmencie - niż dane, ale w tym samym tablespace
• SQL Server przechowuje poprzednie wersje zmienionych rekordów w tempdb. MVCC trzeba ręcznie włączać dla każdej bazy danych
• Oracle przechowuje fragmenty informacji o zmianach w rekordzie w innym tablespace - UNDO - niż dane

Różne podejścia do implementacji implikują różne konsekwencje. Jedną z konsekwencji jest wydajność wprowadzenia zmiany. Inną wydajność odczytu poprzedniej wersji rekordu. W bazach jak PostgreSQL czy SQL Server, gdzie przechowywane są całe rekordy, odczyt poprzedniej wersji jest mało kosztowny - natychmiast dostępna jest poprzednia wersja całego rekordu.

MySQL i Oracle, natomiast generują poprzednie wersje rekordu 'w locie' - gdy transakcja ich potrzebuje - na podstawie informacji z rollbacksegmentu i UNDO. Powoduje to zwiększone zużycie zasobów CPU oraz IO podczas odczytu zmienianych danych.

PostgreSQL, MySQL i SQL Server - mają osobne procesy garbage collector (SQL Server wątek), które co określony czas czyszczą bazę z niepotrzebnych rekordów. Starają się to zrobić jak najszybciej aby zwolnić miejsce dla kolejnych informacji o zmianach w rekordach. Producenci tych baz zalecają wręcz częsty commit aby baza danych nie rozrastała się niepotrzebnie. Informacje o poprzednich wersjach rekordów znikają z tych baz jak tylko przestaną być potrzebne transakcjom.

Zupełnie inne podejście prezentuje Oracle. W ogóle nie usuwa informacji z UNDO. Nadpisuje jedynie najstarsze najnowszymi. Dzięki takiemu podejściu oszczędza zasoby potrzebne dla garbage collector'a. Bonusem jest ciągła dostępność poprzednich wersji rekordów. Technologia pozwalająca do nich sięgnąć nazywa się FLASHBACK QUERY. Pozwala sprawdzić jak wyglądały dane w przeszłości. W przeszłość można sięgnąć tak daleko na ile pozwala miejsce w tablespace UNDO.

W Oracle dostępne są, również inne możliwości FLASHBACK:

• table - pozwala na 'przewijanie' zmian w całej tabeli do dowolnego punktu w czasie (o ile dostępny w UNDO). Oparta na 'row movement' i UNDO.
• transaction - pozwala wycofać dowolną transakcję. Oparta na informacji z REDO (więcej o logu transakcyjnym: ) i UNDO.
• drop - pozwala na odzyskanie dropniętej tabeli. Oparta na RECYCLEBIN.
• database - pozwala na przywrócenie całej bazy danych do stanu z określonego punktu w czasie bez konieczności odtwarzania z backup'u. Oparta na specjalnych logach zapisanych na dysku.

#database #rdbms #oracle #mysql #postgresql #sqlserver #mvcc #flashback #oracledatabase #oracledba #sql #plsql #backend #coding #development #programming