[SQL server 2000] maximaal aantal regels

[lexited]

ik probeer al een tijdje een immense hoeveelheid data in een databse te proppen.
Nu heb ik het probleem dat als ik over een x aantal regels data ben, de databse time-outs geeft bij het opvragen van de resultaten.
Ik heb in mijn programma's al de time-out vehoogd, maar na nog meer data kreeg ik weer time-out's.

Ik heb de database staan op een p4 1,7 ghz, en het gaat hier om meer dan een meerdere miljoenen regels.

zou een snellere pc (dual opstelling) helpen of zie ik iets over het hoofd?

[ACM]

Probeer eerst es je queries te optimaliseren?
Als je geen goede indices hebt/gebruikt zal je database weinig sneller worden op een dual-cpu machine

En wat voor applicaties geven timeouts? Webapplicaties in browsers? Of gewoon vb/delphi etc desktop apps?

Als het goed is krijg je bij het eerste gevonden resultaat al antwoord namelijk en blijkbaar duurt dat al enorm lang...

[Verwijderd]

Ik weet niet precies wat je wilt, als je echt al die miljoenen regels terug wilt hebben kan je de timout wellicht wel wat ophogen, maar als je wat spannende query's los laat op die data haal je de meeste winst door wat strategishe indexen te plaatsen

[Verwijderd]

Een update van rows in een table van meerdere miljoenen regels waarbij je een where clause opgeeft die niet een index bevat, resulteert in het inladen van de complete tabel in memory. ALs je bv 128MB memory hebt, dan is dat snel op.

SQLServer komt niet voor niks met een profiler. Run de queries en check waar de bottlenecks zitten.

Een database met miljoenen rows vreet memory, zorg ervoor dat je server voldoende memory heeft, bij voorkeer 512MB or meer.

[lexited]

ik heb er 512 MB inzitten.
dus ik dacht dat het in eerste instantie voldoende was.

elke regel heeft een unieke key.

ik lees de data uit dmv vb.

[Crazy D]

Je bent met een progje data van de ene naar de andere db aan het overgooien? Moet dat per se via het progje? Je zou ook eens naar de mogelijkheden van SQL zelf kunnen kijken (over pompen van de ene naar de andere SQL Server, of exporteren naar csv en later weer inlezen, of desnoods database detachen kopieeren en weer attachen ).

[lexited]

ik pomp het niet over,

Het zijn activiteiten-gegevens die dagelijks worden bijgevoegd.
per dag is het een kleine 50 mb aan gegevens, wat zich dus laat vertellen in deze hoeveelheid regels.
de bedoeling van mijn prog is dat ik er dus 1 regel uit licht.
uiteindelijk moet er een jaar rapportage uit halen.

helaas werkte mijn programma prima toen de databse nog klein was.
maar naarmate er regels bij kwamen, kreeg ik time-out's.
ik heb dus de time-out opgehoogd. met later weer hetzelfde resultaat.
mijn vrees is dus dat het een keer ophoudt hiermee.
maar ik denk niet dat ik uniek ben dat ik een dergelijke hoeveelheid data wil parkeren.
en vroeg mij dus al af of ik iets verkeerds deed.
het zijn geen gekoppelde tabellen oid.

voor de query's gebruik ik trouwens een dsn-less connectie

[Verwijderd]

Ik zou eens beginnen met wat stored procedures, nu takel je waarschijnlijk al die rows uit de database naar je client.

[gotcha]

je progje is vb dus zal wel gebruik maken van ado 2.x
open je een recordset en doe je dat dan met een clientside of serverside cursor ? wil nog wel eens erg veel verschil maken namelijk ...

[lexited]

Ado 2.7 gebruik ik.

ik test de programma's nu nog lokaal, dus dan maakt client of server side niet uit dacht ik?
(heb er ook nog niet heel veel ervaring mee)

ik probeer maar enkel records uit de hele berg te zoeken.

maar goed ik zal wel verder stoeien..

lees trouwens net op msdn dat het maximum aantal records van een tabel 16,777,216 mag zijn..
daar zit ik nog niet op dus er zal wel wat zijn wat ik over het hoofd zie.

[Verwijderd]

Stel jezelf de volgende vragen:
1) Staan mijn indexen goed? (zie stukje in FAQ)
2) Gebruik ik in mijn query onnodige zaken, zodat er niet optimaal van de indexen gebruik gemaakt kunnen worden?
3) Heb ik voldoende geheugen in mijn machine? (data cache, cursor space, etc)
4) Gebruik ik voor lees acties de juiste cursor? (ReadOnly, ForwardOnly) Wordt de cursor op de juiste plaats bijgehouden? (afhankelijk van de situatie, client side of server side) zie http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsentpro/html/veconchoosingmanagingcursors.asp
6) Is mijn I/O systeem wel snel genoeg (UltraSCSI-160 (of hoger), liever geen RAID 5)
7) Is ADO wel 'de' manier om naar mijn DB te connecten?
Kan ik niet beter een stored procedure gebruiken?
9) Kan SQL Server beter getuned worden?
10) Moet mijn DB niet anders ingedeeld worden, bijv. door onnodige/verouderde data te archiveren zodat de table size kleiner wordt?
11) Heb ik wel alle gegevens nodig in een database om die vervolgens te gaan queryen voor een rapportage, of kan ik op een andere, slimmere manier de gegevens van de rapportage bijhouden met iedere data upload ipv alles te verzamelen en daarna de rapportage op te stellen?

HTH

edit:

Kijk ook eens hier: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/maintain/optimize/default.asp

[Verwijderd]

Op woensdag 17 juli 2002 23:45 schreef lexited het volgende:
ik test de programma's nu nog lokaal, dus dan maakt client of server side niet uit dacht ik?
(heb er ook nog niet heel veel ervaring mee)

Niet echt nee. Serverside cursors is meer dat je de driver opdracht geeft de dataset cursor op de server te houden, maar 1 shot queries gaan echt het netwerk over, ook met serverside cursors.

ik probeer maar enkel records uit de hele berg te zoeken.
maar goed ik zal wel verder stoeien..
lees trouwens net op msdn dat het maximum aantal records van een tabel 16,777,216 mag zijn..
daar zit ik nog niet op dus er zal wel wat zijn wat ik over het hoofd zie.

Dat getal is niet voor SQLServer's tabellen, maar voor ADO's recordset object (En .NET's DataTable). SQLServer kan in theorie oneindig veel rows in een table kwijt.

[Kama]

Zoals gezegd moet je een Stored Procedure het werk laten doen (die ene regel eruit vissen) en die dan weer naar je VB applicatie laten sturen...