Avatar billede splatter Nybegynder
14. februar 2002 - 12:54 Der er 23 kommentarer og
2 løsninger

Performance..

Jeg har en tabel med 8,3 millioner rækker... på denne køres disse tre update statements.. Det tager ialt 4 timer og 40 minutter at køre disse tre hvilket virker som utrolig lang tid...(det er vist den første og sidste statement der tager det meste af tiden) Virker det fornuftigt at det skal tage så lang tid eller er der noget helt galt??? (det tager 7 minutter at loade alle rækkerne ind hvilket svarer til 1,6 GB data)


update trafic set time = to_date('2001-01-01')+timecode/(60*60*24);

update trafic set week = to_char(time,'WW');

update trafic set session_id = to_char(time,'ddmmyy')||session_id;

Findes der derudover nogle gode steder hvor jeg kan læse noget om performance vedrørende Oracle og (PL/)SQL? Eller evt. en god bog om emnet...
Avatar billede degn Nybegynder
14. februar 2002 - 12:58 #1
Har du styr på dine indexes, det kunne måske hjælpe at optimere lidt der....
Avatar billede splatter Nybegynder
14. februar 2002 - 13:02 #2
Efter at data er loadet ind bliver der lagt 3 index på de kolonner som anvendes i SQL statements senere.. dvs. der er lagt index på time og session_id som bliver anvendt i det ovenstående.
Avatar billede coily Nybegynder
14. februar 2002 - 13:11 #3
Hej
Hvorfor ikke lave en update, fx.

update trafic set
        time = to_date('2001-01-01')+timecode/(60*60*24),
        week = to_char(time,'WW'),
        session_id = to_char(time,'ddmmyy')||session_id
;
og JA det kan godt ta' lang tid at lave en update, der skrives i tabellen, rollback, redolog og index

du skriver at første og sidste tager lang tid det er sikkert fordi der er index på disse felter og det skal også opdateres.

Prøv evt. at droppe dine index for du laver update og lav dem igen når du er færdig.

Til degn
Vedr. index, Der kan IKKE anvendes index da der ikke er nogen where....
Avatar billede degn Nybegynder
14. februar 2002 - 13:22 #4
Nej - jeg tænkte også mest på om der blev brugt meget tid på at vedligeholde indexes, og det kan det jo tyde på da der er index på de 2 updates der tager længst tid men ikke på den hurtige update.

Prøv at fjerne de 2 index på time og session_id.....
Avatar billede teepee Nybegynder
14. februar 2002 - 13:29 #5
Du skal helt klart samle sql'en i en statement, men dette er ikke nok.

Hvad bliver indexes brugt til når der skal stå det samme i alle rækkerne?

Prøv at køre (muligvis syntaxfejl, ret selv)

analyze table traffic estimate statistics 25%

og kør igen. Virker nok ikke når du ikke bruger WHERE clause men prøv alligevel.
Avatar billede teepee Nybegynder
14. februar 2002 - 13:31 #6
"Hvad bliver indexes brugt til når der skal stå det samme i alle rækkerne?
" Sorry, my bad, jeg havde ikke lige set at du har et timestamp
Avatar billede teepee Nybegynder
14. februar 2002 - 13:35 #7
Brug

alter index [index] unusable

før du opdaterer, hvor [index] erstattes med navnene på alle indexes på tabellen (et ad gangen)

Gentag med

alter index [index] rebuild

efter opdateringen
Avatar billede teepee Nybegynder
14. februar 2002 - 13:36 #8
Hvis updaten fejlen så kør

alter session set skip_unusable_indexes = true

før updaten
Avatar billede splatter Nybegynder
14. februar 2002 - 13:50 #9
Jeg er interesseret i at updaten går så hurtigt som overhovedet muligt, og det er ikke nødvendigt at kunne foretage f.eks rollback... (data kan jo loades ind igen på 7 min hvis der skulle gå noget galt)

Er det muligt at slå rollback, redolog osv fra inden dette køres??
Avatar billede teepee Nybegynder
14. februar 2002 - 14:14 #10
Kun hvis du flytter data ind i en temporær tabel, ellers ikke
Avatar billede splatter Nybegynder
14. februar 2002 - 14:27 #11
teepee> Dvs. det er nogle attributer som kan sættes på en tabel? hvordan sættes dette?
Avatar billede coily Nybegynder
14. februar 2002 - 14:43 #12
Dette vil ikke skrive ret meget i redo og rollback og mit gæt er at det vil ta' 20 min.
Men kan du ikke sætte time, week og session_id når/før du loader ?

drop eller set unusable alle index op trafic

create table tmp_trafic as select * from trafic where 1=0;

insert /*+ APPEND */ into tmp_trafic (time,week,session_id,felt4,felt5..)
select
    to_date('2001-01-01')+timecode/(60*60*24),
    to_char(time,'WW'),
    to_char(time,'ddmmyy')||session_id,
    felt4,felt5.....
from trafic;
commit;
truncate table trafic;

insert /*+ APPEND */ into trafic select * from tmp_trafic;
commit;

drop table tmp_trafic;
Avatar billede teepee Nybegynder
14. februar 2002 - 14:44 #13
Rolback er ikke slået fra, men redo-log benyttes ikke til temporære tabeller. Sådan er det bare. Men det kan altså ikke betale sig at flytte data over i en temporær tabel for at opdatere og flytte dem tilbage igen. Sæt indexes unusable, skriv at du vil ignorere unusable indexes, kør opdatering, og rebuild indexes. Det må være måden. Det er i hvert fald sådan man gør ved Data Mart opdateringer.
Avatar billede teepee Nybegynder
14. februar 2002 - 14:52 #14
Måske er coily's ok hvis du dropper tabel#1 og omdøber tabel#2 til tabel#1 i stedet for at flytte dem tilbage.
Avatar billede teepee Nybegynder
14. februar 2002 - 14:57 #15
Hvor mange % tror du at en række udvider sig efter opdateringen?
Avatar billede coily Nybegynder
14. februar 2002 - 14:57 #16
teepee det er ikke helt rigtigt

når du laver en update vil du skrive alle blokke det bliver ændret over i rollback

når du bruger truncate og insert /*+ APPEND */ laver du kun rollback på ændringer i data dictionary

Når du bruger /*+ APPEND */ bliver det indsat over tabel's high water mark
og der anvendes direct path write og man kan ikke se data før commit;
Avatar billede teepee Nybegynder
14. februar 2002 - 15:03 #17
coily => men din metode kræver at man har dobbelt så meget plads som man egentligt skal bruge, idet at tablespacet udviddes med tabel#2 (faktisk er det filen der udviddes)
Avatar billede coily Nybegynder
14. februar 2002 - 15:16 #18
Ja, det er rigtigt, men hvad koster disk i disse dage :)
Avatar billede teepee Nybegynder
14. februar 2002 - 15:37 #19
coily => ja, men du arbejder med et tablespace der efter opdatering STADIG fylder det dobbelte
splatter => nogen ide om den procentlige udvidelse ved en updatering?
Avatar billede teepee Nybegynder
14. februar 2002 - 15:48 #20
Jeg fik et lille tip fra en kollega.
Når man trunkerer tabellen så tilføj reuse storage,  så den ikke først deallokerer blokkene for derefter at skulle allokere dem igen.
Avatar billede coily Nybegynder
14. februar 2002 - 16:06 #21
man kan lave et tablespace til dette og droppe det bag efter
ja reuse storage er nok en god ide, endnu mindre rollback :)
Avatar billede splatter Nybegynder
14. februar 2002 - 16:37 #22
Jeg takker mange gange for svarene :)
Avatar billede teepee Nybegynder
14. februar 2002 - 17:12 #23
splatter => jeg spurgte om den procentlige udvidelse fordi det kan være at blokkene er for fyldte til at updaten kan indeholdes i de samme blokke og dermed skal flytte rækker til andre blokke. Dette tager 100 år. Så check at din PCTFREE på tabellen er større en den procentlige udvidelse i rækkerne. Husk lige at ledig plads ikke helt det samme som tilladt udvidelsesprocent, idet at 10% ledig betyder at der kan udvides med ((100/100-10)-1)*100=11,1% i rækkerne
Avatar billede lyders Nybegynder
14. februar 2002 - 18:04 #24
ups havde jeg faktisk overset at du spurgte om det...
Der skulle være nok plads.
Endnu engang tak for svarene
Avatar billede lyders Nybegynder
14. februar 2002 - 18:05 #25
lyders = splatter.. = min hjemmebruger...
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester