=?ISO-8859-2?Q?Re:_DB2_-_niesp=F3jne_zapytanie_wg._asktom.oracle.com?=
Artur Wronski - 13-01-2007 00:01
=?ISO-8859-2?Q?Re:_DB2_-_niesp=F3jne_zapytanie_wg._asktom.oracle.com?=
krycek6@wp.pl napisał(a):
>A może ktoś potrafi podważyć opinię Tom'a.
Podważam obiektywność Toma w przedstawieniu tematu.
Zasadniczo są dwie metody kontroli współbieżności dostępu do danych: poprzez
blokady oraz poprzez wersjonowanie rekordów. Jedna i druga metoda ma swoje
wady i zalety. Zapoznaj się z publikacjami, które mówią o negatywnych stronach
wersjonowania danych:
ftp://ftp.software.ibm.com/software/...rs/locking.pdf
ftp://ftp.software.ibm.com/software/...onsistency.pdf
O plusach i minusach obu metod możesz rzeczowo przeczytać tutaj:
http://www.dbazine.com/db2/db2-disarticles/gulutzan6
Wracając do przykładu "there is 1600 in the bank" to interpretacja przykładu
jest bez sensu, ponieważ wybrany poziom izolacji "Read commited" z definicji
(tak jak definiuje to standard ANSI) dopuszcza niepowtarzalność odczytu oraz
fantomy. Spójność da się zagwarantować przy wyższym poziomie izolacji, bądź
poprzez odpowiedni model danych pozwalających na wykonywanie zestawień bez
kosztów blokowania. W przypadku małej liczby rekordów dotykanych przez
zestawienie, wstrzymanie zapisu na kilka milisekund by uzyskać spójny obraz
odczytu nie jest problemem. W przypadku raportowania z dużej ilości danych na
pewno poziom izolacji spójności odczytu jest wartościowy, bo ułatwia (i to
jest dobre określenie) oprogramowanie aplikacji -- choć i tak są z tym
problemy (np. ORA-01555) plus stosunkowo duży koszt wykonywania kopii danych w
trakcie wykonywania zapytania.
Podsumowując: tworzenie aplikacji pod DB2 wymaga innego podejścia niż w
Oracle, i na odwrót.
Pozdrawiam,
artur.wronski@gmail.com
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
krycek6@wp.pl - 16-01-2007 00:01
Witam
> krycek6@wp.pl napisał(a):
> >" db2 [...] returns answers that never existed ever -- eg, it makes up
> > answers"
> >i dalej przykład jak baza DB2 na poziomie izolacji transakcji read
> >commited potrafi (w szczególnym przypadku oczywiście) w trakcie
> >wykonywania zapytania do bazy odczytać dane częściowo zmodyfikowane
> >inną transakcją (która w między czasie wykonała commit) i
> >zwrócić wyniki niespójne i nie mające nic wspólnego z
> >rzeczywistością.
> >http://asktom.oracle.com/pls/asktom/
f?p=100:11:0::::P11_QUESTION_ID:3512484632553#4098 832642632
> >(wątek jest dość długi - warto poszukać hasła "there is 1600 in
> >the bank there right")
> >Pytam zatem użytkowników DB2 - na ile jest to prawda?
>
> >A może ktoś potrafi podważyć opinię Tom'a.
>
> Podważam obiektywność Toma w przedstawieniu tematu.
Czy zatem oznacza to że napisał nieprawdę czy przedstawił fakty prawdziwe, ale
nieobiektywne bo z punktu widzenia konkurencji? Jasne że Tom będzie twierdził
że Oracle jest lepszy od DB2 np w dyskusjach o wyższości blokowania na poziomie
wierszy bądź bloków. Pytanie tylko na ile ten konkretny przypadek opisany przez
niego jest możliwy.
>
> Zasadniczo są dwie metody kontroli współbieżności dostępu do danych: poprzez
> blokady oraz poprzez wersjonowanie rekordów. Jedna i druga metoda ma swoje
> wady i zalety.
To jest dla mnie jasne. Chodzi o to że obydwie metody powinny gwarantować
spełnianie jednoznacznych kryteriów na określonym poziomie izolacji transakcji.
> Zapoznaj się z publikacjami, które mówią o negatywnych stronach
> wersjonowania danych:
>
> ftp://ftp.software.ibm.com/software/...rs/locking.pdf
> ftp://ftp.software.ibm.com/software/...onsistency.pdf
>
> O plusach i minusach obu metod możesz rzeczowo przeczytać tutaj:
> http://www.dbazine.com/db2/db2-disarticles/gulutzan6
>
Za linki dziękuję - na pewno poczytam.
> Wracając do przykładu "there is 1600 in the bank" to interpretacja przykładu
> jest bez sensu, ponieważ wybrany poziom izolacji "Read commited" z definicji
> (tak jak definiuje to standard ANSI) dopuszcza niepowtarzalność odczytu oraz
> fantomy.
Jasne - tylko w przykładzie nie mamy doczynienia ani z jednym ani z drugim. Z
niepowtarzalnością odczytu nie mamy do czynienia gdyż jest wykonywany tylko
jeden. A fantom też nie ma miejsca bo też wymaga dwóch odczytów gdzie pojawią
się nowe wiersze (bądź znikną stare) chyba że ja czegoś nie rozumiem - jeśli
tak proszę o skorygowanie. Zgodnie z moją wiedzą wszelkie zjawiska dotyczą
tranzakcji i dwóch odczytów w jej ramach. Pojedyncze zapytanie zawsze powinno
zwrócić dane spójne, czyli takie które w pewnym momencie w bazie się faktycznie
pojawiły. Nawet na poziomie "read uncommited" żadne z poleceń DML'a nie powinno
"wejść w środek" DQL'a co najwyżej może "wejść między" 2 różne select'y. Może
się mylę ale wydaje mi się to zachowaniem naturalnym.
W tym sensie nie byłbym zdziwiony różnymi wynikami między np. Oracle'm a DB2
jeśli w jednym np. fantom by wystąpił, a w drugim nie (standard nie gwarantuje
wystąpienia negatywnych objawów) w przypadku dwóch róznych odczytów.
Tym co mnie tutaj szokuje to fakt iż zapytanie czyta dane _częściowo_
zmodyfikowane. Tzn - nie tyle tranzakcja jest niespójna co jedno pojedyncze
zapytanie gdyż w połowie czyta bloki niezmienione a w drugiej połowie zmienione.
W dokumentach podesłanych przez Ciebie jest napisane:
"[...]With Oracle, the data you see in any query is the data as it existed at
the start
of that query. This does not conform to any ANSI standard isolation level,
nor is it the way other RDBMSs work[...]"
oraz
"[...]Even committed transactions are not seen by the reader if the reading
statement started before the updating statement.[...]"
Polemizowałbym z tym gdyż standard mówi iż:
"For certain
SQL-statements, the execution context is always atomic. A routine execution
context is either
atomic or non-atomic. Every trigger execution context is atomic."
oraz
"The execution of all SQL-statements other than SQL-control statements is
atomic with respect to
recovery. Such an SQL-statement is called an atomic SQL-statement."
> Spójność da się zagwarantować przy wyższym poziomie izolacji, bądź
> poprzez odpowiedni model danych pozwalających na wykonywanie zestawień bez
> kosztów blokowania. W przypadku małej liczby rekordów dotykanych przez
> zestawienie, wstrzymanie zapisu na kilka milisekund by uzyskać spójny obraz
> odczytu nie jest problemem. W przypadku raportowania z dużej ilości danych na
> pewno poziom izolacji spójności odczytu jest wartościowy, bo ułatwia (i to
> jest dobre określenie) oprogramowanie aplikacji -- choć i tak są z tym
> problemy (np. ORA-01555) plus stosunkowo duży koszt wykonywania kopii danych w
> trakcie wykonywania zapytania.
Wszystko to zgoda i zgadzam się że gwarancja spójności na określonym poziomie
wymaga czasem poświęceń niezależnie od wewnętrznego sposobu w jaki obsługiwana
jest wielodostępowość (concurency) - np. oracle pójdzie dalej a DB2 zawiśnie na
lock'u. Albo DB2 skończy a Oracle rzuci ORA. W tym sensie jak najbardziej się
zgadzam.
>
> Podsumowując: tworzenie aplikacji pod DB2 wymaga innego podejścia niż *w
> Oracle, i na odwrót.
W ogólnym przypadku zgoda - zwłaszcza jeśli chodzi o blokady. Pytanie jednak o
zapytanie podane w przykładzie i toi czy wykonanie powinno być atomowe, a wynik
spójny pozostaje otwarte.
>
> Pozdrawiam,
> artur.wronski@gmail.com
>
Również pozdrawiam
Przemysław Kantyka
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Artur - 16-01-2007 00:01
=?iso-8859-2?q?Re:_DB2_-_niesp=F3jne_zapytanie_wg._asktom.oracle.com?=
Przemek,
> > racając do przykładu "there is 1600 in the bank" to interpretacja przykładu
> > jest bez sensu, ponieważ wybrany poziom izolacji "Read commited" z definicji
> > (tak jak definiuje to standard ANSI) dopuszcza niepowtarzalność odczytu oraz
> > fantomy.
>
> Jasne - tylko w przykładzie nie mamy doczynienia ani z jednym ani z drugim. Z
> niepowtarzalnością odczytu nie mamy do czynienia gdyż jest wykonywany tylko
> jeden. A fantom też nie ma miejsca bo też wymaga dwóch odczytów gdzie pojawią
> się nowe wiersze (bądź znikną stare) chyba że ja czegoś nie rozumiem - jeśli
> tak proszę o skorygowanie. Zgodnie z moją wiedzą wszelkie zjawiska dotyczą
> tranzakcji i dwóch odczytów w jej ramach. Pojedyncze zapytanie zawszepowinno
> zwrócić dane spójne, czyli takie które w pewnym momencie w bazie się faktycznie
> pojawiły. Nawet na poziomie "read uncommited" żadne z poleceń DML'anie powinno
> "wejść w środek" DQL'a co najwyżej może "wejść między" 2 różne select'y. Może
> się mylę ale wydaje mi się to zachowaniem naturalnym.
Obstaję przy tym, co napisałem wcześniej. Tak naprawdę jest to
tylko kwestia zrozumienia poziomów izolacji ANSI:
Jeśli wybierzesz read uncommited, to w zapytaniu czytasz wszystko jak
leci, bez sprawdzania blokad. Innymi słowy spójność, w rozumieniu
zatwierdzonego zestawu danych nie jest gwarantowana nawet na poziomie
przetwarzanego rekordu. Zapytanie, które pracuje w tym poziomie
izolacji odczytuje rekordy zatwierdzone oraz niezatwierdzone.
Jeśli wybierzesz read committed, wtedy masz gwarancję, że odczytasz
tylko zatwierdzone rekordy -- blokada jest zakładana tylko na
aktualnie przetwarzanym przez zapytanie rekordzie. W takcie
przetwarzania zapytania przy przejściu do następnego rekordu blokada
jest zwalniana i zakładana na następnym rekordzie. Z definicji w
przypadku tego poziomu izolacji wcale nie masz gwarancji, że odczytany
przez zapytanie zestaw danych jest spójny w sensie określonych reguł
agregacji zbioru wynikowego -- zawsze inny użytkownik może w
międzyczasie zmodyfikować rekordy, które zostały już przez
zapytanie przetworzone albo będą dopiero przetworzone.
Jeśli wybierzesz poziom repetable read, wtedy każdy już przetworzony
przez zapytanie rekord zostanie zabezpieczony blokadą przed zapisem.
Ten poziom izolacji powoduje, że czytasz tylko rekordy zatwierdzone a
inni użytkownicy nie mogą już zmienić tego, co odczytałeś. To
zapewnia, że odczytane rekordy będą spójne w sensie wykonywanych
przez Ciebie agregacji (nikt nie będzie mógł zmodyfikować tego, co
odczytałeś a potem zmodyfikować to co pozostało do odczytania).
Oczywiście w tym poziomie izolacji ktoś może zmodyfikować rekordy,
które jeszcze nie zostały przetworzone przez zapytanie, np.
przeczytałeś dopiero pierwszy rekord, a ktoś inny modyfikuje i
zatwierdza ostatni rekord. W następnym poziomie izolacji, czyli
serializable nie dość, że zabezpieczasz się przed modyfikacją
tego, co odczytałeś to dodatkowo baza zabezpiecza przez modyfikacją
rekordów, które dopiero odczytasz. Jeśli inny użytkownik będzie
chciał zmodyfikować rekord, który pasuje do twojego zbioru
wynikowego, wtedy taki użytkownik zostanie ustawiony w kolejce i
będzie musiał czekać, aż zapytanie o tym poziomie izolacji zostanie
przetworzone.
Podsumowując: to poziomy izolacji w implementacji ANSI decydują o
spójności zapytań (jednego bądź wielu w transakcji). W
przykładzie Toma spójność zapytania definiowana jest jako suma
wartości odczytanych z wielu rekordów, więc należało wykorzystać
poziom izolacji ansi repetable read. To co nie podoba mi się w
sposobie przedstawienia tematu przez Toma, to budowanie wrażenia, że
jakoby DB2 w jakiś specyficzny, właściwy tylko sobie sposób
zapewnia spójność zapytań. DB2 implementuje poziomy izolacji ansi i
nie jest jedyną bazą na rynku, która tak działa. Tom w przykładzie
mógł także wykorzystać poziom read uncommited, a potem zadziwiać
czytelników, że udało mu się odczytać bieżącą, niezatwierdzoną
wartość -- czego oczywiście w Oracle zrobić się nie da.
Jak wspomniałem w poprzedniej wiadomości w praktyce bardzo często
odpowiednio modeluje się dane, tak by można było wykonywać spójne
agregacje bez konieczności blokowania. Zwróć uwagę, że pobranie
danej kwoty z konta, nigdy nie jest wykonywane po stronie bazy danych
jako pojedynczy update, tak jak to przedstawił Tom. Np. odkładana
jest historia operacji, pozwalająca na odpowiednie aplikacyjne
wersjonowanie danych.
Mam nadzieję, że trochę wyjaśniłem. Pozdrawiam,
Artur Wronski
krycek6@wp.pl - 17-01-2007 00:05
> Podsumowując: to poziomy izolacji w implementacji ANSI decydują o
> spójności zapytań (_jednego_ bądź wielu w transakcji). W
> przykładzie Toma spójność zapytania definiowana jest jako suma
> wartości odczytanych z wielu rekordów, więc należało wykorzystać
> poziom izolacji ansi repetable read.
Dziękuję za poświęcony czas i obszerne przypomnienie tematu. Nic poza
podkreślonym wyrazem w wypowiedzi nie było mi w sumie obce. Zawsze jednak
odnosiłem tą wiedzę do transakcji rozumianej jako seria zapytań SQL'a, a nie
seria odczytów pojedynczych krotek. Generalnie wnioski jakie wysuwam z Twojej
wypowiedzi to to że:
- Oracle gwarantuje spójność zapytań agregujących na dowolnym poziomie izolacji
wspieranym przez tą bazę ze względu na mechanizm MVCC i odczytywanie stanu z
bazy na moment startu zapytania. W przypadku wielu zapytań oczywiście problem
poziomu izolacji zostaje otwarty.
- DB2 ze względu na inne rozwiązanie wielodostępu tego nie gwarantuje, bez
odpowiedniego ustawienia poziomu izolacji.
Moje wątpliwości jednak (już teraz czysto akademickie) dotyczą zgodności obu
tych podejść ze standardem SQL'a. Mianowicie w opisie fenomenów jake mogą
wystąpić na poszczególnych poziomach transakcji standard mówi o odczycie i
zapisie rekordów w poszczególnych transakcjach (a nie wykonaniu pojedynczych
zapytań). Oznacza to iż podejście DB2 jest z tym zgodne, a podejście Oracle'a
nie - bo np. w trybie read commited Oracle nie odczyta już zatwierdzonego
rekordu jeśli zapytanie rozpoczeło się wcześniej (chociaż konkretny wiersz
został przeczytany później). I to miał na myśli jeden z dokumentów podesłanych
mi przez Ciebie w linkach mówiąc "[...]With Oracle, the data you see in any
query is the data as it existed at the start of that query. This does not
conform to any ANSI standard isolation level, nor is it the way other RDBMSs
work[...]". Dobrze rozumiem?
Tu muszę zaznaczyć, że wspomniana przeze mnie w poprzednim poście kwestia
atomiczności zapytań (atomicity), która pojawia się w standardzie SQL99
("4.30.4 SQL-statement atomicity") dotyczy modyfikacji danych w ramach
odpowiedniego kontekstu oraz zachowania w przypadku przerwania takiego
kontekstu, a nie czytania danych w tym kontekście.
> To co nie podoba mi się w
> sposobie przedstawienia tematu przez Toma, to budowanie wrażenia, że
> jakoby DB2 w jakiś specyficzny, właściwy tylko sobie sposób
> zapewnia spójność zapytań.
Nie no - jasne że Tom jest stronniczy i nie twierdzę że jest inaczej - w końcu
pracuje dla Oracle'a. Podobnie Ktoś pracujący dla IBM będzie mówił że DB2 jest
lepsze, co nie jest oczywiście niczym złym (o ile jakoś odnosi się do
rzeczywistości). Mnie bardziej chodzi o ustalenie faktów niż politykę i
marketing.
Zachowanie przedstawione przez Tom'a DB2 wydawało mi się nieintuicyjne (ze
względu na długie przyzwyczajenie do Oracle'a) i chciałem dowiedzieć się z
czego wynika.
> DB2 implementuje poziomy izolacji ansi i
> nie jest jedyną bazą na rynku, która tak działa.
Ale Oracle też nie jest sam. Podobnie działa np. PostgreSQL z tego co się
orientuję ale to już inna kwestia.
>
> Jak wspomniałem w poprzedniej wiadomości w praktyce bardzo często
> odpowiednio modeluje się dane, tak by można było wykonywać spójne
> agregacje bez konieczności blokowania.
To zdanie jest bardzo ciekawe i interesujące. Jeśli mógłbym prosić o jakieś
materiały w zakresie przemodelowywania struktury bazy gwarantujące uzyskanie
spójnych wyników zapytań agregujących bez konieczności blokowania to będę
wdzięczny.
> Zwróć uwagę, że pobranie
> danej kwoty z konta, nigdy nie jest wykonywane po stronie bazy danych
> jako pojedynczy update, tak jak to przedstawił Tom. Np. odkładana
> jest historia operacji, pozwalająca na odpowiednie aplikacyjne
> wersjonowanie danych.
No nie da się ukryć że przykład Tom'a był uproszczony.
> Mam nadzieję, że trochę wyjaśniłem. Pozdrawiam,
> Artur Wronski
Jak najbardziej.
Dziękuję za poświęcony czas i również pozdrawiam.
Przemysław Kantyka
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Oracle 19g +Insert +Insert +Insert...
Wydajność baz danych w zależności od poziomu izolacji ANSI/ISO
MSSQL Express czy Oracle Express
Czy zna (obsługuje) ktoś program Iso Draw ?
MYSQL - kodowanie w ISO-PL
strona plus baza w iso do utf-8
Kodowanie: z iso na utf
[Oracle, Toad] Zaladowanie obiektu w TOAD
[Oracle][Reports30] 10G nie dziala razem z Reports3.0
[Oracle] catalog.sql i catproc.sql - bledy
zanotowane.pldoc.pisz.plpdf.pisz.plptsite.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
