[C#] DataTable load Memory over load bij 1,4 miljoen rijen.

[linuxontherocks]

Probeer doormiddel van een query gevens op te halen voor een draaitabel. De query genergeert ongeveer 1000 tot 3 miljoen regels aan gegevens. Alleen zodra hij de 1,4 miljoen passeert krijg ik een exeption 'system.outofmemory'. Het geheugen heeft nog 4GB vrij en heb al rond gezocht op internet maar kan niet de juiste oplossing vinden.

Ik heb een klein stukje code toevoegd en het gaat fout bij table.Load(cmd.ExecuteReader()); en om precies te zijn bij de table.Load();

Zou iemand mij een zetje in de goede richting kunnen geven? Het moet toch wel mogelijk zijn om meer dan 1,4 miljoen rijen in te lezen?

• Microsoft Visual Studio 2012
• Microsoft SQL Server 2012 Standaard
• Microsoft .NET Framework 3.5

C#:

DataSet ds = new DataSet();
                        using (SqlCommand cmd = new SqlCommand(as_Query, isql_Connection))
                        {
                            DataTable table = new DataTable();
                            table.Load(cmd.ExecuteReader());
                            ds.Tables.Add(table);
                            if (table.Rows.Count > 0)
                            {
                                pivotGridControl1.DataSource = table;
                                Cursor.Current = oldCursor;
                                return true;
                            }
                            else
                            {
                                Cursor.Current = oldCursor;
                                return false;
                            }
                        }

[HMS]

Heb je het gecompiled als een 32bit of 64bit executable?

[RobIII]

Begrijp ik goed dat je 3 miljoen rijen in een control probeert te gooien? 1e vraag: why? Hoe is dat voor een gebruiker handig of relevant om doorheen te kunnen scrollen? Waarom geef je de gebruiker geen filter of zoekoptie o.i.d.?

Als je dan toch zo'n bak data wil gaan laten doorspitten door je gebruikers moet je eens kijken naar 't 'virtualizen' van je control; je laadt dan alleen de rijen in de control die op dat moment ook daadwerkelijk in beeld zijn en scrollbalken e.d. doe je dan 'handmatig' bijwerken zodat ze wel de juiste indicatie geven van 'waar' je in de bak data (ongeveer) zit te kijken.

Een howto / inleiding / uitleg over 't concept (maar dan voor een DataGridView i.p.v. een "pivotGridControl" vind je hier en hier.

Hoewel HMS' hint naar 32/64 bit waarschijnlijk correct is en je probleem zal oplossen denk ik dat 't je eigenlijke probleem niet (goed) oplost.

[ Voor 12% gewijzigd door RobIII op 03-05-2013 16:06 ]

[linuxontherocks]

Sorry voor mijn verlate reactie, bedankt voor jullie reactie.

@HMS
Het gaat om een 32bit exe vanwege dat dit een component is dat we gebruiken in Powerbuilder

@Robll
Deze informatie worden verwerkt in een draaitabel component van DevExpress zodat we management informatie kunnen tonen. Dus de eind gebruiker zal niet 3 miljoen rijen te zien krijgen maar een opsomming of andere manier hoe de draaitabel in elkaar wordt gezet.

Het virtualizen heb ik al wat overgelezen en mee getest met de datagridview en dat werkt ook alleen het component van DevExpress ondersteund dat niet. Ze adviseren mij om een OLAP server te gebruiken maar dan loop ik weer tot beperkingen aan.

[Coca-Cola]

linuxontherocks schreef op woensdag 15 mei 2013 @ 12:21:
Sorry voor mijn verlate reactie, bedankt voor jullie reactie.

@HMS
Het gaat om een 32bit exe vanwege dat dit een component is dat we gebruiken in Powerbuilder

@Robll
Deze informatie worden verwerkt in een draaitabel component van DevExpress zodat we management informatie kunnen tonen. Dus de eind gebruiker zal niet 3 miljoen rijen te zien krijgen maar een opsomming of andere manier hoe de draaitabel in elkaar wordt gezet.

Het virtualizen heb ik al wat overgelezen en mee getest met de datagridview en dat werkt ook alleen het component van DevExpress ondersteund dat niet. Ze adviseren mij om een OLAP server te gebruiken maar dan loop ik weer tot beperkingen aan.

Tja, als je met een 32 bit executable zit dan ben je beperkt tot 2 GB aan geheugen voor je applicatie. Je zou even moeten kijken hoeveel records je in het geheugen kan laden als je OOM gaat en misschien je gebruikte datastructuren wat optimaliseren, maar je bent niet op de goede weg als je echt zoveel records in je geheugen nodig hebt. Normaal toon je data met een sortering (en dus gedeeltelijk) of gegroepeerd en doe je de daadwerkelijke operaties op de data op de database....

[ZaZ]

Devexpress past al by default virtualisatie toe als je 'm een IEnumerable voert.
Ik heb wel eens 10 miljoen rows in zo'n ding gepropt met nog steeds behoorlijke performance.
Jouw probleem is niet het grid, maar dat je je hele resultset uit je database in een datatable zit te proppen.
Ik denk ook dat ie op deze regel valt

code:

table.Load(cmd.ExecuteReader());

en niet op deze

code:

pivotGridControl1.DataSource = table;

Je hebt wel trucjes dat je met het scrollen in het grid je cursor verplaatst, maar dan verlies je vaak de mogelijkheid tot groeperen/filteren etc in je grid (die heeft namelijk niet alle data)
En dan heb je er dus niets aan, want door miljoenen rijen scrollen slaat nergens op.

Enige echte oplossing is je resultset kleiner maken door voorafgaand aan te geven waar je (ongeveer) mee wil gaan werken. Dan kan je de handige filtertjes etc op het grid gebruiken om te finetunen

[ Voor 4% gewijzigd door ZaZ op 16-05-2013 17:03 ]

[Gomez12]

ZaZ schreef op donderdag 16 mei 2013 @ 17:02:
Je hebt wel trucjes dat je met het scrollen in het grid je cursor verplaatst, maar dan verlies je vaak de mogelijkheid tot groeperen/filteren etc in je grid (die heeft namelijk niet alle data)
En dan heb je er dus niets aan, want door miljoenen rijen scrollen slaat nergens op.

Enige echte oplossing is je resultset kleiner maken door voorafgaand aan te geven waar je (ongeveer) mee wil gaan werken. Dan kan je de handige filtertjes etc op het grid gebruiken om te finetunen

You're doing it wrong...

Die handige filtertjes kan je ook gewoon doorverwijzen richting je db waardoor ze wel de toegang hebben tot alle data

[EfBe]

Je kunt ook Pivot gebruiken in SQL Server, zodat de draaitabel in SQL Server wordt gegenereerd. Daar zou ik dan een paging techniek op loslaten. Omdat de Pivot wellicht tijd kost om te berekenen, kun je die in een temptable plaatsen. Doe dit dmv een INSERT INTO #mytemptable (...) SELECT ... pivot query; waarbij je eerst een CREATE TABLE statement uitvoert voor de temptable, en daarbij een identity field erbij plaatst.

Dit identity field kun je nu gebruiken voor 'paging', zodat je elke keer een page aan data ophaalt uit de temptable en welke rows dat zijn kun je makkelijk dmv de identity column bepalen in een where clause. Let er wel op dat wanneer je duplicate rows krijgt in je pivot tabel resultset, je die beter eerst eruit kunt filteren dmv DISTINCT, en uiteraard sorteer je de rows ook op de juiste volgorde.

Zie voor pivot tables in sql server o.a.: http://blogs.msdn.com/b/s...rver-a-simple-sample.aspx

NOOIT duizenden rows ophalen uit een database. Ook niet de excuses zoeken om dat wel te doen: duizenden rows ophalen is zelden nodig en al helemaal niet voor het plaatsen van data in UI controls!

[CMG]

Die out of memory exception komt waarschijnlijk omdat bepaalde data types (ook lijsten) sequentieele blokken geheugen nodig hebben. Omdat er op een gegeven moment geen aaneengesloten geheugen ruimte over is, krijg je die out of memory exception.

Oplossen met paging

[urk_forever]

Ik ben het eens met wat iedereen hierboven zegt, je kan het beste je XtraPivotGrid(?) direct aan je database binden en niet eerst handmatig de data inladen en daarna binden.

Hier staan wat diverse binding scenario's voor het XtraPivotGrid control van DevExpress: http://documentation.deve...sForms/CustomDocument9404

Hier trouwens een uitleg waarom je die OutOfMemory exception krijgt terwijl je nog genoeg geheugen vrij lijkt te hebben.

[ Voor 26% gewijzigd door urk_forever op 17-05-2013 10:50 ]