GoldenLine
Zaloguj się
Michał Kowalski

Michał Kowalski Bazy danych

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

Witam,
Na bazie z której raportuje przeciętnie raz na godzinę są robione update'y, które blokują użytkownikom generowanie raportów.
Jak mógłbym napisać select tak by użytkownik nigdy nie musiał czekać na wynik z powodu locków, związanych z updatem czy inseretem tabeli?

Najczęściej tabele:
tab_pełna
tab_z_przyrostem
aktualizowane są w następujący sposób:

BEGIN
delete from tab_pelna e where exists (select 1 from tab_z_przyrostem i where e.id = i.id);
insert /*+ APPEND */ into tab_pelna (select * from tab_z_przyrostem);
COMMIT;
END;

Czy przy takim typie updatowania można zapewnić ciągły dostęp do danych? Jeśli dobrze rozumiem do chwili commita krotki które zostaną usunięte i zastąpione nowymi są nadal dostępne, jak na nich pracować, godząc się na nieaktualne dane.
Link do wypowiedziLink

konto usunięte

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

Czyli chcesz czytać i pisać do tych danych jednocześnie? Jak dla mnie to się dnie da. Możesz duplikować tabele z danymi i raporty robić z kopi, tylko tu masz zawsze możliwość ze w kopi dane będą nie aktualne z dokładnością do czasów robienia kopi. Mieszanie na danych które tyką pól na których są indeksy wymaga uaktualnienia indeksów a co z tym idzie wymaga więcej czasu niż jak nie ma indeksów a przede wszystkim taki indeks jest lokowany przy nierozpoczęciu operacji co za tym idzie nie da się generować raportów z takiej tabelki do momentu zwolnienia loka.
Link do wypowiedziLink
Michał Kowalski

Michał Kowalski Bazy danych

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

W międzyczasie wyszukałem artykuł o dirty read i dwóch innych sposobach dostępu do danych, czy miał ktoś z Was do czynienia z tym?

Dirty read,
Fuzzy or non-repeatable reads,
Phantom reads

http://www.dba-oracle.com/t_oracle_dirty_reads.htm
Link do wypowiedziLink
Marcin Mackiewicz

Marcin Mackiewicz Programista JAVA, RS
Adware Polska

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

Aktualizacje danych robisz na transakcji która blokuje obiekt tabeli przed czytaniem na czas dokonywania zmian. Możesz rozwiązać na dwa sposoby.
Pierwszy to taki, że operacje aktualizacji wykonujesz bez transakcji co pozwoli czytać tabelę ponieważ ta nie otrzyma lock'a. Drugim sposobem jest obniżenie w konfiguracji serwera separacji transakcji właśnie do poziomu izolacji "Read uncommited" lub jak kto woli "Dirty reads". Jeżeli ta baza jest także bazą produkcyjną to gorąco odradzam ten poziom izolacji bo może to spowodować wiele niefajnych sytuacji. User będzie mógł czytać dane z niezaakceptowanej transakcji , przetwarzać je i zapisywać wyniki. Po wycofaniu transakcji dane zostaną wycofane ale efekty pracy na nich mogą pozostać w innych częściach bazy.

Mogę nie mieć racji w 100% bo z Oracle nie miałem dużo do czynienia.Ten post został edytowany przez Autora dnia 14.06.16 o godzinie 21:26
Link do wypowiedziLink

konto usunięte

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

1. Czy to jest wersja Standard Edition?
Jeśli masz EE i licencje na partycjonowanie to jest rozwiązanie dla Ciebie.

Jeśli nadal siedzisz w Standard Edition to zapoznaj się z Partition Views
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_...

A z dirty read daj se spokój bo se jeszcze krzywde zrobisz :)Ten post został edytowany przez Autora dnia 14.06.16 o godzinie 22:53
Link do wypowiedziLink

konto usunięte

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

Michał K.:
BEGIN
delete from tab_pelna e where exists (select 1 from tab_z_przyrostem i where e.id = i.id);
insert /*+ APPEND */ into tab_pelna (select * from tab_z_przyrostem);
COMMIT;
END;

A nie zauważyłeś przypadkiem, że zapytania na tab_pelna trwają tak jakby coraz dłużej?
Link do wypowiedziLink
Michał Kowalski

Michał Kowalski Bazy danych

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

Marcin M.:
(...) Możesz rozwiązać na dwa sposoby.
Pierwszy to taki, że operacje aktualizacji wykonujesz bez transakcji co pozwoli czytać tabelę ponieważ ta nie otrzyma lock'a. (...)

A jak mogę zdefiniować procedurę, która wykona aktualizację bez transakcji? Czy to w ogóle możliwe?
Link do wypowiedziLink
Michał Kowalski

Michał Kowalski Bazy danych

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

Ireneusz P.:
Michał K.:
BEGIN
delete from tab_pelna e where exists (select 1 from tab_z_przyrostem i where e.id = i.id);
insert /*+ APPEND */ into tab_pelna (select * from tab_z_przyrostem);
COMMIT;
END;

A nie zauważyłeś przypadkiem, że zapytania na tab_pelna trwają tak jakby coraz dłużej?

Nie, nie zauważyłem, możesz wyjaśnić co masz na myśli? Tabela przyrostowa ma tylko te wiersze, które zmieniły się między poprzednią a obecną synchronizacją, ich liczba jest mniej więcej stała np 4 tys.
Link do wypowiedziLink

konto usunięte

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

Michał K.:
Ireneusz P.:
Michał K.:
BEGIN
delete from tab_pelna e where exists (select 1 from tab_z_przyrostem i where e.id = i.id);
insert /*+ APPEND */ into tab_pelna (select * from tab_z_przyrostem);
COMMIT;
END;

A nie zauważyłeś przypadkiem, że zapytania na tab_pelna trwają tak jakby coraz dłużej?

Nie, nie zauważyłem, możesz wyjaśnić co masz na myśli? Tabela przyrostowa ma tylko te wiersze, które zmieniły się między poprzednią a obecną synchronizacją, ich liczba jest mniej więcej stała np 4 tys.

Przeczytaj sobie, w jaki sposób działa direct path insert, to się domyślisz co mam na myśli (chociaż przy 4k rekordów to można rzeczywiście nie zauważyć).
Przy okazji możesz też wyjaśnić, w jaki sposób DML na tabeli blokuje Ci wykonywanie selecta...
Link do wypowiedziLink
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

Tu chyba problemem jest ten APPEND, który blokuje tabelę dla innych operacji DML.

Czy potrafisz uzasadnić dlaczego potrzebujesz APPENDA ?

Rozważałeś przepisanie tej funkcjonalności na MERGE?

-- edited:
Co do dirty-readów, to proponuję doczytać o podstawach architektury Oracle, wtedy nie będzie tematu dirty readów i rozważań o poziomach izolacji transakcji ;-) Ten post został edytowany przez Autora dnia 17.06.16 o godzinie 13:02
Link do wypowiedziLink

konto usunięte

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

Paweł Grzegorz K.:
Tu chyba problemem jest ten APPEND, który blokuje tabelę dla innych operacji DML.
A niby dlaczego APPEND miałby blokować?

https://oracle-base.com/articles/misc/append-hint#how-t...
Link do wypowiedziLink
Paweł Grzegorz Kwiatkowski

Paweł Grzegorz Kwiatkowski Architekt
oprogramowania,
Ericsson

Temat: [Oracle] Zapytania które nie byłyby blokowane przez...

Bartosz Z.:
Paweł Grzegorz K.:
Tu chyba problemem jest ten APPEND, który blokuje tabelę dla innych operacji DML.
A niby dlaczego APPEND miałby blokować?

https://oracle-base.com/articles/misc/append-hint#how-t...

http://docs.oracle.com/cd/B19306_01/server.102/b14231/...



During direct-path INSERT, the database obtains exclusive locks on the table (or on all partitions of a partitioned table). As a result, users cannot perform any concurrent insert, update, or delete operations on the table, and concurrent index creation and build operations are not permitted. Concurrent queries, however, are supported, but the query will return only the information before the insert operation.


Jeśli więc jakaś inna sesja chce coś zrobić (poza zapytaniem, ale bez FOR UPDATE) na tabeli, do której coś appendem jest dodawane, to musi poczekać na zakończenie operacji.

Ja bym wyszedł od wait interface, żeby zobaczyć co się dzieje w konkretnym przypadku, tak żeby nie zgadywać ;-)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj