Archief - Oracle vraagske voor de experts :)

Heb niet echt een probleem, tis gewoon kwestie van performance

heb een table [A] heeft een aantal rijen in table in grid-formaat
en table [A] heeft info over de grid bv dat hem een 32 x 48 grid heeft van objecten in

Heb dus een lijst van [A] als ik er op klik wil ik een gridje tonen met kleurkes en text die ik opmaak uit zaken die ik ophaal uit

Probleem is nu als ik derop klik voor dus een 32 x 48 grid, zijn dus 1536 volledige rows van table ophalen uit een DB in de US duurt zo'n 2,25 sec
Den grid heeft ook nog een 0.6 sec nodig om al die text te zetten dus tis al een 3 sec ofzo om die dialog te tonen

Sinds 1 veld uit een number is waarmee ik de kleur van een cell in de grid bepaal was ik dus aant denken om enkel die kleur-info op te halen en dan in de background de volledige row-info op te halen

wat ik mij dus afvraag is hoe ik het snelste zo iets zou kunnen doen, kan dat veld voor al die rows concaten met een cursor en een string teruggeven (zal nooit meer dan 1536 zijn)
-Maar ben altijd een beetje twijfelachtig tov cursors
-mischiens zijn der snellere dingen om zo iets te doen in PL/SQL ?
-die 2,25 zal ook wel data-transport zijn dus kleiner is hopelijk een pakske sneller
-Ga ik mij zelf niet te fel onder de voeten loop als ik 2 keer dezelfde rijen ga willen ophalen ?

in PL/SQL zijn cursors niet de performantste manier van werken.

Dingen zoals
open c_cursor;
fetch c_cursor into ...
close c_cursor;

Als je die fetch in een loopje steekt zal het minder snel gaan dan wanneer je

for x in c_cursor loop
...
end loop;

die for loop is dus het beste. Interne mensen bij Oracle zeggen dat die open/fetch methode zal memory leaks kan geven dus zeker die for gebruiken

1536 rijen ophalen mag absoluut geen prob zijn voor oracle. Misschien dat het probleem de geografische locatie is van de DB ipv de DB zelf.
Als je kn moet je eens remote proberen inloggen op die server (als het kan) en daar lokaal de query uitvoeren. ALs die daar traag is dan is er idd een probleem.

Eerst en vooral kan je best indexen leggen op de belangrijkste velden. Je kan in een IDE voor oracle ook meestal een explain plan doen. Dan zie je echt waardoor hij vertraagd wordt.

kheb net even een testje gedaan op onze server:

Query die ik uitgevoerd heb is op onze users tabel waar 20k records zitten.
Dan heb ik een where clause gebruikt op een veld waar geen index zit:
select * from users where internal = 'N'

Resultaat => 17027 records in 30ms. Ik denk dus dat het probleem niet direct aan de performantie van de query ligt tenzij je een ingewikkelde query gebruikt.
Kan je die mss eens posten? Misschien dat we daar dan zwakke delen kunnen uithalen

De query gaat snel ze, (in die 2,2 sec zit ook het serializen naar objecten btw)
Indexen en alles derop en hem is poepsimpel

In de US gaat het bv ook een pak sneller vraag mij gewoon af wat de network overhead is
bv als ik string-concat doe van de velden in een for-loop vs network-overhead van rows doorsturen
Denk dat ik gewoon maar eens beide ga uitproberen

als je een query uitvoert met een stringconcat dan is er geen networkoverhead omdat die verwerking volledig op de server komt... Uiteindelijk krijg je gewoon je string. Tis niet dat hij eerst het eerste deel stuurt, dan het 2de met nog een aantal berichten tussen...

Alle ik snap niet wat je huidige vraag dan met oracle te maken heeft

Het serializen van objecten gebeurt in een andere taal? Misschien zit daar de performantie?

de overhead die oracle heeft om een tabel met 1 column en 1500+ rows te maken qua groote om over het netwerk te sturen vs de tijd + cpu + resources van string concat van 1500+ rijen om zo misschiens minder data over het netwerk te sturen

Heb er nog nooit bij stil gestaan hoe de groote van die objecten berekend kunnen worden, maarja zal misschiens eerder van de provider afhangen dan van de oracle-db zelf