Langsom forspørgsel via java, men ik via TOAD

Toad og Java program paa samme maskine?

Type 2 (OCI) eller type 4 (thin) driver?

Maaler du i Java hele program udfoersel eller maaler du kun det samme som Toad d.v.s. kald af SP og laese svar?

ja samme maskine.
type 2 (OCI) driver
måler kun på det samme som i toad, fra den bliver kaldt til den returnerer

Det lyder godt nok mystisk.

Har du mulighed for at prøve med andre sprog: C#, C/C++, PHP ?

Fandt muligvis løsningen fredag på arbejde, men nåede ik at gennemteste det helt.
Men den stored procedure jeg har problemer med modtager 3 parameter, nemlig 1 varchar2 og 2 date typer. Men da jeg ændrede date til timestamp virkede det somom at den kørte nøjagtig som i TOAD. Jeg ved ik hvorfor det skulle være løsningen måske du ved det?
Når jeg har kørt den i TOAD har jeg nemlig bare hardcoded parameterne til to_date('31-12-2009', 'dd-mm-yyyy')

Det lyder endnu mere mystisk.

Men virker det så virker det.

Jeg brainstormer her.

Kunne det ikke være et alternativ at at du smider din procedure over i en ny tråd. På den måde vil brugeren af dit program ikke bemærke den lange svartid.
jeg tænkte bare at hvis man ikke kan finde en umiddelbar forklaring så må man jo forbedre brugervenligheden.

fandt ud af min løsning ikke virker alligevel, nu er den langsom igen, virkelig underligt. Det unnderlige er at nogle gange så kører den fint (lige hurtigt i TOAD og java) men så tilfældigt en gang i mellem, så er den ufatteligt langsom via java, men kun via java.

koden ser sådan ud:

            CallableStatement stmt = db.getRapCon().prepareCall("BEGIN BM_BEREGN(?, ?, ?, ?, ?); END;");
            stmt.registerOutParameter(1, OracleTypes.CURSOR); //REF CURSOR
            java.sql.Date sqlFraDato = (java.sql.Date) info[0];
            java.sql.Date sqlTilDato = (java.sql.Date) info[1];
            stmt.setString(2, sqlFraDato.toString());
            stmt.setString(3, sqlTilDato.toString());

            stmt.setString(4, "%");

            if (info[5].equals("STANDARD")) {

                stmt.setString(5, "DKK");
            } else {
                stmt.setString(5, (String) info[5]);
            }


            stmt.execute();
            ResultSet rs = ((OracleCallableStatement) stmt).getCursor(1);

Kan du enable noget trace på databasen siden som sladrer om hvad der sker og hvor lang tid det tager?

kan ik gøre det på arbejdet, da jeg ikke har rettigheder, men har en kopi derhjemme hvor jeg godt kan, må bare vente til den er langsom der.

Jeg har dog måske løst det, da den driver jeg bruge hed ojdbc14.jar og nu hentede jeg en der hed ojdbc6.jar og den gør at forespørgslen nu er færdig på under 1 sek, hvor den før tog 7 sek når jeg kørte den her hjemme. lidt vild hastighedforbedring synes jeg. nogle kommentar til det? det er oracle 11g jeg bruger

Fandt ud af at den ikke er blevet så meget hurtigere, men efter jeg bruger den nye driver så start fetch først når jeg begynder at læse rækkerne, men med den gamle driver begynder den at fetch med det sammen åbenbart

Tallet er Java versionen, så du skal bruge den version der passer til den Java version du bruger !

aaaahh okay, troede 14 var til oracle 10 og før og ojdbc var til oracle 11g. min java version er 6, så måske derfor den har været langsom.
Det skal dog lige siges at jeg connecter via OCI, så min connectionstring ser sådan ud:
rapCon = DriverManager.getConnection("jdbc:oracle:oci:@ORCL","RRITU","rritu");

så jeg kan ikke helt finde ud af hvor driver ligger som jeg bruger. altså fordi at OCI driveren vel ligger i et oracledirectory på min computer, men alligevel har jeg også tilføjet ojdbc6.jar til min javakode i netbeans?

Du bruger den version af JDBC sióm du har i classpath og den version af Oracle Client som er installeret på PC (ved OCI).

prøve den på arbejdet nu, og der er den staadig langsom selvom jeg bruger ojdbc6, i min javakode kalder jeg en stored procedure, hvis jeg istedet smider SQL'en direkte ind i java koden og kalder den som "normal" SQL og IKKE en stored procedure, så er den ikke langsom...????

Gad vide om JDBC driveren forsøger at hente en masse meta data omkring den SP.

fandt ud af det det måske kan være tilfældigheder der gør det. kan se i toad at den nogle gange har en "latch: cache buffers chains" når den laver det nummer

nogle ide til hvordan jeg undgår det?

Det emne ligger uden for mit ekspertise område.

Googling antyder at det er hardcore DBA arbejde.

Læs f.eks.:

http://www.pythian.com/news/1135/tuning-latch-contention-cache-buffers-chain-latches/

fandt ud af at det var execution plan der var forskellig. da oracle brugte den samme til den stored procedure lige meget vilke parameter den fik. da jeg bruge bind variables og det gjorde jeg ikke ved toad. men tak for indsatsen