27. januar 2004 - 15:47Der er
13 kommentarer og 1 løsning
SQL på meget store tabeller
Fra en ASP-side skal jeg udføre følgende SQL på to Oracle 8 tabeller (derfor ikke brugt INNER JOIN):
SQLTekst = "SELECT MCH1.CHARG, MCH1.MATNR, MCHB.WERKS, MCH1.FVDT1, MCH1.QNDAT, MCH1.VFDAT, " & _ MCHB.CLABS + MCHB.CINSM + MCHB.CEINM + MCHB.CSPEM AS Stock FROM ENLIST_WH.MCH1, ENLIST_WH.MCHB WHERE MCH1.CHARG = MCHB.CHARG AND MCH1.MATNR = MCHB.MATNR AND MCH1.QNDAT > '20040123' AND MCH1.QNDAT < '20040223' AND MCHB.CLABS + MCHB.CINSM + MCHB.CEINM + MCHB.CSPEM > 0 AND MCHB.WERKS = '" & PlantEntered & "' ORDER BY MCH1.CHARG"
Set rst = objConn.Execute(SQLTekst)
Den ene tabel er voldsom stor (MCH1: 900.000 linier) og den anden knapt så stor (MCHB: 40.000 linier) og hvis jeg kører den med 2 kriterier ad gangen, udføres den på omkring 10 sekunder, men hvis alle kriterier er på (som vist overfor), så 'dør' den.
Kan man skrive SQL´en på en anden måde, så den kan køre med alle kriterierne på en rimelig tid? (Jeg har ikke mulighed for at få den lagt ind som en stored procedure).
Teknologi, AI og forretning er i centrum på Computerworlds Cloud og AI Festival i København d. 18. og 19. september. Se hele programmet for den store konference om strategisk brug af Cloud og AI på: www.cloud-festival.dk
Uden at kende din hw - tabeller med 900.000 og 40.000 rækker bør ikke opfattes som specielt stort i Oracle. Og når du kører ENLIST, thja, så gætter jeg på at du er på en Unix kværn hvor de rækkeantal slet ikke er et problem.
Hvad kører du optimizeren som - Cost based eller rule based?
Har du indeks på alle kolonner der indgår i join-kriteriet? Og hvis du har, har du så opdateret statistikker på de indeks for nylig?
Når jeg kigger på tabelstrukturen via en Access ODBC link, står der 'no' til indeks på join-kriteriet, så der er formodentlig ikke et indeks - kan det give den helt umulige tid?
Mht. optimizer er jeg ikke klar over det, men vil prøve at finde ud af det i IT afdelingen.
Hmm... Hvis det er den it afdeling jeg tror det er, så er det cost based :-) Sidder du i NN?
Mht Access som interface, så er jeg ikke sikker på at den kan give indeks-informationer. Jeg ville tro, at det du får at vide er, at Access ikke har indeks. Access aner jo reelt set ikke noget om den Oracle db der ligger under...
Men ja, hvis der ikke er indeks, eller statistikkerne ikke er opdaterede, så kan det nemt give den umulige tid. Værre er, hvis der er statistikker på en enkelt af tabellerne / indeks - og ikke på de andre. Så vil Oracle nemlig temporært danne de manglende statistikker - og det tager en hulens tid.
Uden at vide det 100%, ser det ud som om det er SAP tabeller du forsøger at kigge i. Er det ikke en ide at gøre det gennem query værktøjet direkte i SAP, og så få eksporteret dine resultater? Alternativt findes der små kode-stumper der direkte i Access kan snakke med SAP og trække relevant tabelinformation ud.
Jeg sidder faktisk i NNIT, men er p.t. på fædreorlov :-) Tror jeg vil foreslå, at du griber fat i DBA_VAGT vedr. dit performance-problemet. Det burde kunne løses ret nemt.
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.
