Hej Jeg har en procedure, som ikke kan køre mere. Efter ca. 15 minutter, så fejler scriptet med: ORA-1652: unable to extend temp segment by 128 in tablespace TEMP TEMP tablespacet er 24 GB stort, og det er global temporary tables, som jeg forsøger at indsætte rækker i. Jeg forsøger at indsætte 62500 rækker i tabellen og joiner på tværs af flere tabeller. Jeg har ikke, at jeg ved af, lavet ændringer på databasen.
Det er iøvrigt forskellige explain planer, når jeg kører sql'en i henholdsvis i TOAD og via JAVA.
Når jeg kører scriptet i TOAD, så bruger det ca. 1 minut, og så er den færdig succesfuldt.
Når jeg kører proceduren via JAVA, så fejler den.
Det er iøvrigt forskellige explain planer, når jeg kører sql'en i henholdsvis i TOAD og via JAVA.
Ved godt det er meget sparsomt med oplysninger, men skriv, så skal jeg forsøge at indhente informationer.
Udfordringerne hober sig op i fødevare- og drikkevareindustrien og gør den til en af de mest sårbare.
24. oktober 2024
Slettet bruger
09. april 2008 - 08:39#1
Det lyder som om at Java og TOAD arbejder med forskellige language settings og at der derfor laves ekstra konvreteringer i JAVA-versionen. På grund af den forkerte language setting vil Oracle derfor skulle lave ekstra sorteringer, for at få data sortere anderledes end binary sort order.
er det en anonym procedure? Måske at du skal gemme den i basen som en pl/sql procedure og afvikle den. Det skulle gerne give samme resultat fra TOAD/Java/m.v. Dit kæmpe TEMP tablepsace er måske ikke trunkeret. Andre sessioner kan benytte samme tablespace mens du bruger det. Mængderne tyder på at du mangler en join og får at katetisk produkt.
teepee -> Det er ikke en anonym procedure. Den ligger allerede i basen, og har altid gjort det. TEMP tablespaceet er trunkeret når jeg starter, men bliver fyldt rimelig hurtigt. Når jeg kører i TOAD, så skrive den, at der er en masse nested loops. Når jeg kører via JAVA, så kommer der et katetisk produkt.
Jeg har fået løst det. Det kan være fordi vi kører med Thin client version 9, men på den anden side, så har det virket. Lige nu var løsningen, at sætte et hint på SQL'en, så den ikke kørte All_rows, men istedet kørte nested_loops /*+ join_nl */, så kom Cost'en ned på 31k. nu kører statementet uden problemer igen.
Synes godt om
Ny brugerNybegynder
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.
