[DB]SQL cursors: voor- en nadelen?

[RetepV]

Hi,

Ik ben geen newbie meer in databaseland, maar ik heb het me allemaal zelf moeten aanleren, waardoor ik toch bepaalde afwegingen niet zo goed kan maken...

De vraag is, wat zijn de voor- en nadelen van SQL cursors? Voordelen zie ik wel, maar ik lees weinig over nadelen.

Dit alles in het kader van dat ik in C++ classes wil schrijven om mijn tabellen te beheren. Ik wil dus weten of ik daarbij cursors kan/moet gebruiken of dat ik het beter op een andere manier kan oplossen.

Ik ben vooral bang voor performanceproblemen door memory-fragmentatie in de SQL databaseserver (PostgreSQL), het systeem (Linux) moet jaren achtereen draaien zonder tussenkomst van een operator. In mijn eigen programma kan ik zelf de memory fragmentatie in de hand houden door slim te alloceren...

Ik meen dat OLE DB met SQL server weer wel gebruik maakt van server-side cursors, maar bij Microsoft maken ze wel vaker rare beslissingen, dus ik weet niet of ik dat als leidraad moet gebruiken :):).

[Verwijderd]

Voorbeeld. Probeer jij maar eens te pagen zonder cursors, beetje lastig, kan wel maar dan heb je helemaal een performance probleem. Ik gebruik zelf ASP en SQL 2000 en ik heb nooit cursor problemen of problemen met performance of stabiliteit.

Hoe dat zit met postgres weet ik niet, zal wel hetzelfde werken denk ik.

[RetepV]

Op woensdag 19 juni 2002 13:12 schreef voetenzalf het volgende:
Voorbeeld. Probeer jij maar eens te pagen zonder cursors, beetje lastig, kan wel maar dan heb je helemaal een performance probleem. Ik gebruik zelf ASP en SQL 2000 en ik heb nooit cursor problemen of problemen met performance of stabiliteit.

Wat bedoel je precies met 'pagen'? Resultaten groepsgewijs opvragen?

Hmm. Laat ik eens wat proberen te beredeneren, ik denk dat het een afweging moet worden tussen geheugengebruik op de DBclient (mijn applicatie), het geheugengebruik op de DBserver en de communicatie tussen de DBclient en de DBserver. In de volgende punten ga ik er van uit dat de queries slim zijn en niet meer records opleveren dan absoluut nodig is.

1) Bij een cursor wordt het resultaat van de query op de DBserver opgeslagen. Met de FETCH instructie haal je één voor één de data op. Hierbij is het geheugengebruik op de DBclient minimaal, op de DBserver optimaal en de is ook de communicatie minimaal.
2) Met de FETCH instructie kun je ook delen van het resultaat opvragen. Hierbij is het geheugengebruik op de DBserver nog steeds optimaal, maar op de DBclient niet minimaal en is de communicatie ook niet meer minimaal.
3) Als je geen cursor gebruikt is het geheugengebruik op de
DBclient optimaal, op de DBserver minimaal en is de communicatie optimaal.

Als ik het zo op een rijtje zet, dan zou ik zelf voor punt 3) gaan.

Eigenlijk is de vraag: kan ik de SQL server vertrouwen dat hij het geheugen niet fragmenteert. Bij fragmentatie zullen geheugenallocaties op de DBserver steeds langzamer gaan. Ook loop je de kans dat er geheugen blijft hangen waardoor je DBserver instabiel wordt.

Ik denk dus zelf dat ik beter het geheugen kan gaan beheren in mijn DBclient dan het aan de DBserver overlaten.

Communicatie optimaal maken is niet zo belangrijk, DBclient en DBserver zitten op dezelfde machine, en als ze later eens gescheiden gaan worden, dan kan er een gigabit netwerkinterface tussen.

edit:


Let op: ik gebruik C++, ik ben dus niet afhankelijk van classes van een ander, ik kan/moet alles zelf beheren. In een webscript heb je daar dus geen controle over, dus ik denk dat voor databases in samenwerking met scripts andere regels gelden.

[RetepV]

[ik blijf nadenken :)]

Bij ASP heb je al een objectmodel waarmee je met je database praat. Ik moet zelf zo'n objectmodel bedenken en wil het optimaal hebben. Het objectmodel van ASP is een grote gemene deler, daar zal weinig optimalisatie in zitten omdat het voor alle gevallen bruikbaar moet zijn. Ik kan mijn database classes zelf optimaliseren voor mijn probleem/uitdaging .

Ik zal waarschijnlijk ook veel korte queries hebben, losse records opvragen. Op zich zorgt dat al voor veel overhead. Cursors gebruiken lijkt me dan alleen nog maar voor meer overhead zorgen.

Ik zit nu te denken aan gewoon SQL, zonder cursors en de resultaten in mijn class in een array of STL map te stoppen. Een array heeft het voordeel dat mijn geheugenallocaties 'voorspelbaar' zijn, dwz. ik kan er voor zorgen dat het geheugen niet gefragmenteerd raakt.

Wat is nou precies het probleem waar cursors voor bedacht zijn?

[RetepV]

[yep, nog meer info, er zijn vast wel meer mensen die zich dit afvragen (of het zich _zouden moeten afvragen_)]

http://www.sql-server-performance.com/cursors.asp

De eerste alinea is nogal veelzeggend. Maar ik heb liever nog een second-opinion .

Niet helemaal relevant maar:

http://www.teratech.com/coldcuts/cutdetail.cfm?cutid=30

ALWAYS use a client-side cursor, if you have the option, ESPECIALLY when ODBC connecting to SQL Server or Access97 using VB or ASP Not necessary in Access since the DB is usually local already. I tried using a client-side cursor on my ASP calendar page and saw speed increased by by 400%!!!

[RetepV]

Ik denk dat ik wel de conclusie mag trekken dat de communicatie minder belangrijk is dan database-performance. Zeker als die database server meerdere databases voor meerdere applicaties implementeert. In dat geval zou een applicatie die heel veel server-side cursors open houdt de performance van de andere applicaties negatief beinvloeden.

Mijn conclusie dus: laat de database server dat doen waar hij goed in is: data in tabellen beheren, concurrency oplossen (met locks) en ingewikkelde queries uitvoeren. Het beheren en bewerken van resultaten is iets wat je in de client moet doen.

Ik weet nog steeds niet waarom cursors ooit bedacht zijn, maar ik _vermoed_ dat ze alleen maar bestaan om stored procedures mogelijk te maken.

Ok, kom maar op: wie ontkracht mijn conclusies effe?

[RetepV]

(zou ik nou gelijk hebben, of gaat dit mensen boven de pet )

[Verwijderd]

(1. misschien moet je effe wat langer wachten.)
2. misschien moet je de edit knop leren gebruiken.

Edit in punt 1: is al een oud topic.

[Verwijderd]

Cursors hebben wel zeker een bestaansrecht. Ze bieden een hoger nivo van abstractie van data, die door veel ontwikkelaars als prettig gezien wordt. Veel database systemen zijn meer en meer ingericht om ook cursor-management te doen, waardoor dit ook sneller en efficienter wordt.

Natuurlijk zul je, als je op een lager nivo instapt, een betere performance uit een database kunnen halen, maar dit maakt het bouwen en onderhouden van je software een meer intensieve taak.

Over database performance, tuning & optimalisatie kun je overigens boeken vol schrijven, en zijn er zelden algemeen geldende antwoorden. Adviezen met "gebruik ALTIJD ..." zijn dan ook vaak simplificaties van de werkelijkdeid, waarbij er wel degelijk situaties te bedenken zijn waarvoor die regel niet geldt.

Kortom: voor een specifieke situatie kan je een zinvolle discussie houden over wat nou het beste zou zijn, maar zonder zo'n case wordt de discussie al snel zinloos.

[Verwijderd]

Op woensdag 19 juni 2002 13:05 schreef RetepV het volgende:
De vraag is, wat zijn de voor- en nadelen van SQL cursors? Voordelen zie ik wel, maar ik lees weinig over nadelen.

Wat versta jij onder een database cursor? Want t.a.t. heb je een cursor nodig wil je datasets returnen mbv een query, hoe wil je anders je dataset aan kunnen wijzen

Dit alles in het kader van dat ik in C++ classes wil schrijven om mijn tabellen te beheren. Ik wil dus weten of ik daarbij cursors kan/moet gebruiken of dat ik het beter op een andere manier kan oplossen.
Ik ben vooral bang voor performanceproblemen door memory-fragmentatie in de SQL databaseserver (PostgreSQL), het systeem (Linux) moet jaren achtereen draaien zonder tussenkomst van een operator. In mijn eigen programma kan ik zelf de memory fragmentatie in de hand houden door slim te alloceren...

Mja, ik ga nu geen open deur opentrappen, maar als ik je een tip mag geven: gebruik een library voor dit soort zaken en ga zelf niet allerlei zaken opnieuw bouwen. Een goede databaselibrary zou toereikend moeten zijn.

Ik meen dat OLE DB met SQL server weer wel gebruik maakt van server-side cursors, maar bij Microsoft maken ze wel vaker rare beslissingen, dus ik weet niet of ik dat als leidraad moet gebruiken :):).

Wat is er raar aan een serverside cursor? Als je dataset operaties uitvoert en daarna 1 getal oid terugwilt, dan is een clientside cursor niet zo handig, denk je wel?

Maar nogmaals: je vraagt de voor/nadelen van 'cursors', terwijl je niet weet wat het zijn. Want, hebben we het over cursors die gedeclareerd worden in jouw stored procs? (En dus tempdb space vreten?) wil je cursors in triggers gaan gebruiken (zou ik niet doen) of praten we over cursors mbt recordsets die je terugkrijgt van de dbdriver?

Either way, ADO does the trick, helaas niet op jouw OS.

[Verwijderd]

Op woensdag 19 juni 2002 14:45 schreef RetepV het volgende:
Ik denk dat ik wel de conclusie mag trekken dat de communicatie minder belangrijk is dan database-performance. Zeker als die database server meerdere databases voor meerdere applicaties implementeert. In dat geval zou een applicatie die heel veel server-side cursors open houdt de performance van de andere applicaties negatief beinvloeden.

Ooit van stored procedures gehoord? Niemand die een solide database applicatie wil bouwen gaat queries afvuren vanuit client code buiten een databaseserver. Je gebruikt postgresql, dus gebruik de features van die database. Ben je meteen klaar met je cursors.

Mijn conclusie dus: laat de database server dat doen waar hij goed in is: data in tabellen beheren, concurrency oplossen (met locks) en ingewikkelde queries uitvoeren. Het beheren en bewerken van resultaten is iets wat je in de client moet doen.

joh Maar, 'resultaten' houdt toch wel in dat je een stored proc uitvoert en die de resultaten teruggeeft?

Ik weet nog steeds niet waarom cursors ooit bedacht zijn, maar ik _vermoed_ dat ze alleen maar bestaan om stored procedures mogelijk te maken.

Als jij een andere manier weet om door een recordset te wandelen dan hoor ik het graag.