C5 SQL 'performance'

Problemet med Native i forhold til SQL versionen når vi snakker XAL/C5 kernen er den, at kernen ikke kan finde ud af at lave fornuftige joins til SQLdatabasen.

Ligeså snart du har en struktur som f.eks.:

SEARCH kart USING Idx
  WHERE ....
    SEARCH kartb USING Idx
        where kartb.felt == karta.felt
    END
END

Så kan XAL kernen ikke finde ud af at lave en join ud af det.

Typisk ville man i SQL skrive noget i retningen af

SELECT kart.felt,kart.felt1,kart.felt2,kartb.felt1,kartb.felt2,kartb.felt3 from kart,kartb where kart.felt == kartb.felt

men det kan XAL/C5 ikke finde ud af, hvorfor der bliver mange flere database-"trips" for at få de ønskede data, hvor en join måske kan nøjes med et trip som returnerer det ønskede datasæt.

Hmm, det er jo lidt af et problem, da jeg går ud fra at den eneste måde at få mere fart på dyret, er at skrive XAL'en om til f.eks. stored procedures?

Et andet spørgsmål vedr. SQL'en, er der nogen bestemt grund til jeg ikke kan 'trace' hvad der sker i C5 SQL'en? Når jeg kører profileren på den, viser den kun nogle cursorfetch osv. og ikke selects, som jeg er vant til. Kan det passe den vælger den første record, og så triller den igennem de resterende ved hjælp af cursors?

Hvad hardware er der på den SQL server? Og hvad laver den ellers? Hvordan ser dine kørsler ud? (Og sig ikke at du ikke har RAID, og at datafilen og logfilen ligger på samme drev)

Til det sidste spørgsmål: Ja, det er DM i client-cursors. Du kan evt. starte den på med -zX for at aktivere tracing...

Evt. kan du starte den op med -zSQL -zLsqldump.txt

Logfilen ligger på samme drev som datafilen (det er ikke samme som at den bliver ved med det, hvis vi går i drift med C5 SQL). 2x2 GHz Xeon (DP), 1,5 GB RAM, og RAID 1 til OS og RAID 10 til databaserne, mv. Så vi har hardwaren til at få nogenlunde hastighed ud af SQL'en, men det er jo heller ikke det problemet tyder på at være (mere at C5 ikke bruger SQL'en optimalt).

Der er masser af eksempler på at SQL er langsommere end Native - det er derfor man ikke automatisk køber en SQL med til en C5 (ud over prisen, altså).
Kernen i C5 er udviklet til Native - og da der er flere kunder på Native end på SQL, så er fordelen for de fleste.

Det hele bunder i at det er to forskellige opbygninger: C5 Native database er en recordbaseret ISAM database, hvor klienten behandler een record ad gangen. SQL Server er en recordSÆTbaseret database, hvor een kommando kan påvirke mange records.

Broen imellem disse to verdener er cursors. Derfor bruger C5 SQL masser af dem og bruger ikke joins mv., da dette begreb ikke findes i ISAM databaser.

Hvad nu hvis vi ændrer eksemplet foroven til:

SEARCH kart USING Idx
  WHERE ....

    SET kart.x = kart.x*2
    UPDATE kart

    #Prompt()
      ... //Bruger taster data ind
    #PromptAbort

    SEARCH kartb USING Idx
        where kartb.felt == karta.felt

       
    END
END

Hvordan skal dette kunne laves med en JOIN? Kernen oversætter koden til SQL runtime. Derfor bliver 1 SEARCH -> 1 SELECT (og INTRODUCE, FIND og direkte opslag)

Dermed ikke sagt at man ikke kan klemme mere performance ud af det. Der findes masser af eksempler i XAL applikation, som er kodet anderledes og bedre end C5 med henblik på SQL databaser. Dette har INTET med kernen at gøre, da C5 og XAL kernerne er ens (bortset fra et par enkelte kommandoer).

Det første man kan gøre er at minimere antallet af SELECT's. Noget andet er at bruge temporære kartoteker mere, da disse stadig kører i native.

Eksemplet kunne skrives om til (hvis "kart" ikke indeholder at for mange poster):

[Overfør poster fra "kart" til "tmpkart"]
INTRODUCE tmpkart
SEARCH kartb USING Idx ORDER BY felt
    IF tmpkart.felt <> kartb.felt THEN
        FIND tmpkart[Idx == kartb.felt]
    ENDIF
END

Nu er der kun 2 SELECT's til SQL databasen.

-Broholm

Hov, glemte lige at sige tak for svar, det er dejligt med en masse tekniske detaljer!