[oracle] czas dzialania insertow na duzej tabeli
Paweł Dec - 05-07-2007 00:00
[oracle] czas dzialania insertow na duzej tabeli
Witam,
mam tabele z 80mln wierszy. 3 niewielkie kolumny, 3 indeksy. Insert 100 000
wierszy zajmuje ok 15 minut. Z prob ktore zrobilem wynika ze problemem jest
uaktualnienie indeksow.
(insert do pustej tabeli zajmuje 10sek, insert to pelnej tabeli bez indeksow
zajmuje < 1s)
Pytania:
1) czy rzeczywiscie przyczyna problemu jest ilosc danych w tabeli (moze te
15min to o wiele za dlugo i mozna cos poprawic?)
2) jesli to jest przyczyna, to jak sobie z tym poradzic? Od razu zaznaczam
ze pracuje na wersji Standard i nie mam mozliwosci uzycia partycjonowania
tabel.
Pawel Dec
szaman - 05-07-2007 00:00
Jak zwykle za mało danych :-)
Chciałem Ci zaproponować zrównoleglenie insertów ale przecież nie mam
pojęcia na jakiej to maszynie stoi a co dopiero o reszcie środowiska.
Do zrównoleglenia nie potrzeba partycjonować (chociaż wtedy osiąga sie
najlepsze efekty).
Czy napewno to jest istotne aby ten proces przyspieszyc,
czy to może tylko takie dywagacje?
Paweł Dec - 05-07-2007 00:01
>
> Chciałem Ci zaproponować zrównoleglenie insertów ale przecież nie mam
> pojęcia na jakiej to maszynie stoi a co dopiero o reszcie środowiska.
juz uzupelniam:
Oracle 8.1.7 Standard Edition na SunFire V440 (4 procesory), 4GB RAM, Sun
Solaris 5.9
> Do zrównoleglenia nie potrzeba partycjonować (chociaż wtedy osiąga sie
> najlepsze efekty).
>
dzieki, sprobuje
> Czy napewno to jest istotne aby ten proces przyspieszyc,
> czy to może tylko takie dywagacje?
To nie dywagacje. To jest czesc dluzszych przetwarzan i tracimy na tym
lacznie ok 4.5h
Pawel
=?iso-8859-2?Q?=A3ukasz?= - 05-07-2007 00:01
Dnia Wed, 4 Jul 2007 17:57:52 +0200, Paweł Dec napisał(a):
>
> To nie dywagacje. To jest czesc dluzszych przetwarzan i tracimy na tym
> lacznie ok 4.5h
> Pawel
Wnioskuję, że to może jakieś wsadowe przetwarzanie. To może spróbuj przed
insertami wyłączyć indeksy a po wpisaniu włączyć je. Baza niema wtedy
potrzeby na bieżąco aktualizować indeksów. Odbudowanie indeksu po
zainsertowaniu całej porcji danych powinno być szybsze niż bieżące
odświeżanie i cała operacja może przyśpieszyć.
Pozdrawiam
Łukasz
szaman - 06-07-2007 00:03
Łukasz pisze:
> Dnia Wed, 4 Jul 2007 17:57:52 +0200, Paweł Dec napisał(a):
>
>
>> To nie dywagacje. To jest czesc dluzszych przetwarzan i tracimy na tym
>> lacznie ok 4.5h
>> Pawel
>
> Wnioskuję, że to może jakieś wsadowe przetwarzanie. To może spróbuj przed
> insertami wyłączyć indeksy a po wpisaniu włączyć je.
O tym również myślałem pisząc że brak danych co do środowiska :-)
Jeżeli to jest tabela produkcyjna to odpada jakiekolwiek wyłączanie
indeksów i triggerów.
Ale jeżeli nie to jak najbardziej.
Następnym krokiem to może być dobranie do akurat tego procesu optymalnej
liczby rekordów w transakcji. Napewno nie jest optymalnym insertować po
jednym rekordzie a zbyd dużych transakcji na tysiące rekordów tez nie
należy budować. Optimum jest gdzieś pomiędzy ;-)
Niestety nie mogę sie zbytnio pochwalić doświadczeniem z taką dość już
leciwą wersją bazy - ale jeżeli rzeczywiście to jakieś przetwarzanie
"wsadowe" to zainteresuj się loadrem z sql plus'a albo czymś podobnym (w
nowszych wersjach bazy jest w czym przebierać).
Czy w wersji 8 była juz możliwość użycia tabel typu external?
Co do zrównoleglenia to te cztery procesory mogą rodzić nadzieję na
powodzenie zmniejszenia czasu importu - po zastosowaniu insertów na
kilku równoległych sesjach. Ważne aby te sesje miały tak dobrane dane
aby nie wchodziły sobie w paradę tzn. np nie blokowały czegoś jedna
drugiej - wtedy korzyści ze zrównoleglenia dotyczą nie tylko insertów a
wszystkich innych aspektów "przetwarzania wsadowego".
Mi się udało przyspieszyć i to czasem o dwa rzędy szybciej - no ale
procesorów było ponad 40 :-)
Paweł Dec - 11-07-2007 00:00
Dziekuje za pomoc. Tak naprawde bardziej inetersowalo mnie czy takie czasy
wykonania przy podanej ilosci wierszy uznacie za prawdopodobne.
To przetwarzanie nie jest wsadowe w takim sensie ze baza nic nie robi tylko
przyjmuje dane. Nie bardzo potrafie sobie wyobrazic zrownoleglenie tych
insertow. Przed nimi i za nimi sa inne zapytania i instrukcje DML. Zatem
rowniez niechetnie bym wstawial po kawalku i commitowal. Przez chwile mialem
nadzieje na rownolegle wykonanie tych insertow ale opcja parallel tez jest
tylko od wersji enterprise. Zreszta redukcja tego czasu powiedzmy o polowe
nie bardzo mnie satysfakcjonuje.
Sciaganie indeksow i ich ponowne zalozenie po insercie, mozliwe z punktu
widzenia "srodowiska" nie bedzie szybsze przy takich proporcjach danych: 80M
wierszy w tabeli do 100K wierszy wstawianych.
Nie wiem co sa tabele typu external, ale domyslam sie ze byc moze mialyby
zastosowanie przy przetwarzaniu wsadowym
Wydaje mi sie ze ostatecznie rozwiazaniem bedzie "zasymulowanie"
partycjonowania:
stworzenie nowej tabeli z danymi historycznymi, niepotrzebnymi do biezacych
przetwarzan i okresowe przerzucanie danych do tej tabeli, tak zeby tabela
"glowna" pozostawala wzglednie mala. I do tego view gdy chce ogladac dane
zarowno biezace jak i historyczne.
Taka operacja potrwa zapewne kilka godzin ale to jest do zaakceptowania
Pawel
15min -> To czesc dluzszych przetwarzan w ktorych procesu produkcyjnego
Użytkownik "szaman" <t.cwajda@datamining.com> napisał w wiadomości
news:f6i46l$kq5$1@atlantis.news.tpi.pl...
> Łukasz pisze:
>> Dnia Wed, 4 Jul 2007 17:57:52 +0200, Paweł Dec napisał(a):
>>
>>
>>> To nie dywagacje. To jest czesc dluzszych przetwarzan i tracimy na tym
>>> lacznie ok 4.5h
>>> Pawel
>>
>> Wnioskuję, że to może jakieś wsadowe przetwarzanie. To może spróbuj przed
>> insertami wyłączyć indeksy a po wpisaniu włączyć je.
>
> O tym również myślałem pisząc że brak danych co do środowiska :-)
> Jeżeli to jest tabela produkcyjna to odpada jakiekolwiek wyłączanie
> indeksów i triggerów.
> Ale jeżeli nie to jak najbardziej.
>
> Następnym krokiem to może być dobranie do akurat tego procesu optymalnej
> liczby rekordów w transakcji. Napewno nie jest optymalnym insertować po
> jednym rekordzie a zbyd dużych transakcji na tysiące rekordów tez nie
> należy budować. Optimum jest gdzieś pomiędzy ;-)
>
> Niestety nie mogę sie zbytnio pochwalić doświadczeniem z taką dość już
> leciwą wersją bazy - ale jeżeli rzeczywiście to jakieś przetwarzanie
> "wsadowe" to zainteresuj się loadrem z sql plus'a albo czymś podobnym (w
> nowszych wersjach bazy jest w czym przebierać).
>
> Czy w wersji 8 była juz możliwość użycia tabel typu external?
>
> Co do zrównoleglenia to te cztery procesory mogą rodzić nadzieję na
> powodzenie zmniejszenia czasu importu - po zastosowaniu insertów na kilku
> równoległych sesjach. Ważne aby te sesje miały tak dobrane dane aby nie
> wchodziły sobie w paradę tzn. np nie blokowały czegoś jedna drugiej -
> wtedy korzyści ze zrównoleglenia dotyczą nie tylko insertów a wszystkich
> innych aspektów "przetwarzania wsadowego".
>
> Mi się udało przyspieszyć i to czasem o dwa rzędy szybciej - no ale
> procesorów było ponad 40 :-)
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Oracle, SQL, PL/SQL. Jak =?ISO-8859-2?Q?napisa=E6_zapytanie=2C?==?ISO-8859-2?Q?_kt=F3re_zwr=F3ci_nazw=EA_atrybutu=2C_kt=F3reg o?==?ISO-8859-2?Q?_warto=B6ci_spe=B3niaj=B1_zadany_warunek?=
[Oracle] jak =?ISO-8859-2?Q?ograniczy=E6_pami=EA=E6_dla_se?==?ISO-8859-2?Q?rwera=3F?=
=?ISO-8859-2?Q?=5BOT=5D_Zdany_egzamin_Oracle_1Z0-007_a?==?ISO-8859-2?Q?_brak_informacji_na_stronie_Prometric_-_czy?==?ISO-8859-2?Q?_co=B6_nie_tak=3F?=
[oracle] czy da =?ISO-8859-2?Q?si=EA_z_poziomu_procedury_?==?ISO-8859-2?Q?zrobi=E6_kopi=EA_zapasow=B1=3F?=
[oracle 10g] czy =?ISO-8859-2?Q?mo=BFna_wy=B3=B1czy=E6_wszys?==?ISO-8859-2?Q?tkie_wi=EAzy_w_schemacie=3F?=
MSSQL Express czy Oracle Express
=?ISO-8859-2?Q?Poszukjue_ksi=B1=BFki_"Oracle_?= =?ISO-8859-2?Q?optymalizacja_wydajno=B6ci"..?=
[Oracle] =?ISO-8859-2?Q?=A3=B1czenie_wierszy_z_zapytania_?==?ISO-8859-2?Q?w_jeden_string?=
=?iso-8859-2?q?[oracle_10g]_jak_da=E6_grant_do_gv$=2E=2E=2E=2E_=3F?=
[Oracle] 10g wersja =?ISO-8859-2?Q?pe=B3na_i_Express_Editi?==?ISO-8859-2?Q?on?=
zanotowane.pldoc.pisz.plpdf.pisz.plmelooonka.opx.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 |
|
