2009-10-03 6 views
6

W tej chwili proces, w którym używamy do wstawiania zestawów rekordów, jest podobny do tego:Czy mogę zastąpić punkty zapisu w celu rozpoczęcia nowych transakcji w Oracle?

(i należy pamiętać, że "zestaw rekordów" oznacza coś w rodzaju rekordu osoby wraz z ich adresami, numerami telefonów lub dowolnymi danymi; inne połączone tabele).

  1. Rozpocznij transakcję.
  2. Włóż zestaw powiązanych rekordów.
  3. Zatwierdź, jeśli wszystko przebiegło pomyślnie, cofnij się w inny sposób.
  4. Powróć do kroku 1, aby uzyskać następny zestaw rekordów.

Czy powinniśmy robić coś takiego?

  1. Zacznij transakcję na początku skryptu
  2. Zacznij oszczędzać punkt dla każdego zestawu rekordów.
  3. Włóż zestaw powiązanych rekordów.
  4. Jeśli wystąpi błąd, powróć do punktu zapisu, jeśli wszystko przebiegło pomyślnie.
  5. Zatwierdź transakcję na początku skryptu.

Po problemach z ORA-01555 i przeczytaniu kilku artykułów Ask Tom (takich jak this one), myślę o wypróbowaniu drugiego procesu. Oczywiście, jak podkreśla Tom, rozpoczęcie nowej transakcji jest czymś, co powinno być zdefiniowane przez potrzeby biznesowe. Czy warto przetestować drugi proces, czy też jest to zły pomysł?

+1

+1, interesujące pytanie (także do dyskusji na temat asktom) – DCookie

+0

Przydałoby się, jeśli wprowadzisz bieżącą wartość dla parametru UNDO_RETENTION i czas potrzebny na uruchomienie całego skryptu i przetwarzanie każdego zestawu. –

Odpowiedz

5

Transakcja powinna być znaczącą jednostką pracy. Ale to, co stanowi Jednostkę Pracy, zależy od kontekstu. W systemie OLTP Jednostką Pracy byłaby jedna Osoba wraz z ich informacją adresową itp. Ale brzmi to tak, jakbyś implementował jakąś formę przetwarzania wsadowego, która ładuje wiele Osób.

Jeśli masz problemy z ORA-1555, to prawie na pewno, ponieważ masz długie zapytanie dostarczające dane, które są aktualizowane przez inne transakcje. Zaangażowanie wewnątrz pętli przyczynia się do cyklicznego wykorzystania segmentów UNDO, a więc zwiększa prawdopodobieństwo, że segmenty, na których polegasz, aby zapewnić spójność odczytu, zostaną ponownie wykorzystane. Tak więc, nie robienie tego jest prawdopodobnie dobrym pomysłem.

Niezależnie od tego, czy używasz SAVEPOINT, rozwiązanie to inna sprawa. Nie jestem pewien, jaką przewagę otrzymasz w swojej sytuacji. Ponieważ pracujesz z Oracle10g, być może powinieneś rozważyć użycie zamiast tego zbiorczej wersji DML error logging.

Alternatywnie można napisać zapytanie dotyczące jazdy, aby działało z mniejszymi porcjami danych. Nie wiedząc więcej o specyfice procesu, nie mogę udzielić konkretnej porady. Generalnie, zamiast otwierania jednego kursora na 10000 rekordów, może być lepiej otworzyć go dwadzieścia razy na 500 wierszy. Inną rzeczą, którą należy wziąć pod uwagę, jest to, czy proces wstawiania może być bardziej wydajny, na przykład przy użyciu kolekcji zbiorczych i FORALL.

+0

+1 dla zatwierdzenia w pętli. Zazwyczaj dzieje się tak, gdy aktualizujesz rekordy, które wybierasz w pętli. Nadal sprowadza się do cofnięcia retencji i rozmiaru. Zobacz inny link Burlesona (który odwołuje się do innych): http://www.dba-oracle.com/t_ora_01555_snapshot_old.htm – DCookie

+0

Zaletą punktów zapisu byłoby, gdyby nie zobowiązanie Oracle byłaby zmuszona do dłuższego przechowywania informacji w systemie UNDO. Podejrzewam, że w twoim konturze brakuje kroku 0 z "Otwórz kursor". W oryginalnej metodzie może utracić cofnięcie za każdym razem, gdy trafi w krok 3, więc kursor od kroku 0 może podnieść 1555. W nowej metodzie musi on zachować cofnięcie aż do końca skryptu. –

1

Niektóre myśli ...

  1. Wydaje mi się jeden z punktów link asktom było wielkości Twój wycofywania/cofnąć odpowiednio, aby uniknąć 1555-tych. Czy jest jakiś powód, dla którego nie jest to możliwe? Jak zauważa, znacznie taniej jest kupić dysk niż pisać/utrzymywać kod, aby poradzić sobie z obejściem ograniczeń przywracania (chociaż musiałem zrobić podwójne podsumowanie po przeczytaniu cennika $ 250 za napęd o pojemności 36 GB - ten wątek rozpoczął się w 2002 r. ! Dobra ilustracja Prawa Moore'a!)
  2. pokazuje jeden z możliwych problemów z punktami zapisu.
  3. Czy Twoja transakcja jest w rzeczywistości krokami 2,3 i 5 w drugim scenariuszu? Jeśli tak, to ja bym zrobił - zatwierdzić każdą transakcję. Brzmi dla mnie trochę tak, jak scenariusz 1 to zbiór transakcji połączonych w jeden?
+0

Myślę, że mogłem nie być wystarczająco jasne w pierwszym scenariuszu. Zasadniczo, w tej chwili zobowiązujemy się do każdego zestawu rekordów (według zbioru rekordów mam na myśli coś takiego jak powiedzmy osobę, jej adresy i numery telefonów). To, co myślałem, czyniło to bardziej jak jedną dużą transakcją, która używa punktów zapisu. –

+0

Nie rozumiem, dlaczego masz wtedy 1555 lat. Co próbujesz zyskać dzięki punktom zapisu? Wydaje mi się, że jesteś bardziej prawdopodobne, że dostaniesz błędy 1555 w drugim scenariuszu? – DCookie

+0

Zbyt częste zatwierdzanie spowoduje rozproszenie rekordów w kilku segmentach cofania. To sprawia, że ​​bardziej prawdopodobne jest, że transakcje zostaną nadpisane i zwiększą prawdopodobieństwo ORA-01555. W rzeczywistości, częstsze zatwierdzenia zajmują * więcej * cofnij przestrzeń: http://oradbdev.blogspot.com/2007/04/commit-frequency-and-undo.html –

Powiązane problemy