[SQL] 2000 > 7 of 2005 > 7 veel verschil?

[Verwijderd]

Hallo,

de titel is misschien een beetje vreemd, maar een betere omschrijving kon ik momenteel niet verzinnen.

Tot oktober 2008 hadden wij diversen servers waar SQL 2000 op draaide. Dit werkte aardig, maar niet snel genoeg. (Te veel data)

Per 1 november zijn de overgegaan naar SQL 2005. Alles werkt nu een stuk beter en stabieler.

1 van de SQL servers kopieert de data via een DTS ook naar een webserver (windows 2000 met SQL 7) . Op deze server wordt gebruik gemaakt van ASP en ASP.net applicatie's. Dit werkte altijd aardig / goed. Weinig tot geen Time-Out's, enkel met grootte selectie die we opvroegen via de .net applicatie's

Hier is verder niks in veranderd. Dus nu wordt de data van een SQL 2005 server overgepompt naar SQL 7 via de DTS. Dit werkt allemaal goed.

Het probleem is nu dat na 1 november we comtinue time-out's krijgen en alles op de webserver velen malen trager is geworden.

Voor dat er iets wordt gezegd over SQL 7. Er komt over een aantal weken (waarschijnlijk 5) nu ook een nieuwe webserver met Windows 2003 en SQL 2005. Maar daar heb ik dit probleem / oorzaak nog niet mee gevonden. Diversen time-out's heb ik al op 5 minuten gezet en het gaat nu iets beter, maar de problemen zijn er nog steeds.

SQl 2005 zal een iets andere indeling hebben, maar aan de sleutels, indexen en andere zaken is helemaal niks veranderd. Het enige is de upgrade van SQL 2000 naar SQL 2005.

Ik hoop dat ik het duidelijk heb uitgelegd en of dat iemand ook zoiets heeft meegemaakt?

[ Voor 0% gewijzigd door Verwijderd op 12-12-2008 11:35 . Reden: Type fout ]

[MaZo]

Wat zegt je SQL activity monitor? Veel dead-locks? En de event viewers?

[ Voor 17% gewijzigd door MaZo op 12-12-2008 11:27 ]

[Verwijderd]

Nee, deze hou ik wel goed in de gaten. De eventviewer geeft ook geen problemen weer.

1 van de query's in een Query analyzer geeft de volgende output:

59% van de cpu voor deze regel: "Insert each input row into a hash table, grouping on the GROUP BY columns and computing aggregate expressions"

13% van de cpu voor deze regel: "An operation involving parallelism"

Ik denk dat het iets is met de inhoud / opbouw van de data. Dat Sql 2000 anders met de data omgaat dan SQL 2005

[ Voor 110% gewijzigd door Verwijderd op 12-12-2008 11:52 ]

[leuk_he]

http://www.microsoft.com/..._tuning_waits_queues.mspx

Je zult toch naar specifieke queries moeten kijken.

[Verwijderd]

Hoe kan het dan dat dezelfde query op 31 oktober nog snel is en op 1 november niet meer op SQL 7?

Het enigste verschil is dat de data van een SQL 2005 is gekopieerd ipv een SQL 2000 server.

Het kan dus niet aan de opbouw van een query komen.

[Woy]

Verwijderd schreef op vrijdag 12 december 2008 @ 12:24:
Het kan dus niet aan de opbouw van een query komen.

Dat is natuurlijk een gevaarlijke uistpraak

Maar als het niks met de query's te maken heeft, dan is het niet echt een programming vraag, maar meer een configuratie vraag.

[leuk_he]

Nou is mijn sql tuning kennis beperkt, maar het kan zijn dat een subtiele verandering in de data of een GROTE wijzing in de omgeving (SQL server is wel degelijk veranderd) gevolg heeft voor het executie plan van een specifieke query (of een beperkt aantal queries).

Echter daar in generiek termen iets over zeggen is moeilijk. Draait je sql compaibly mode?

De oplossing lijkt me toch echt uit te zoeken waar je grootste bottleneck zit en uit te zoeken waarom die nu plotseling zo lang draait. Er zijn honderden verschillen tussen 7, 2000 en 2005, en bepalen wat jou nou bijt is niet te vertellen.

[Niemand_Anders]

Het verhogen van een timeout is nooit een oplossing. Op welke manier hebben jullie de migratie van 2000 naar 2005 uitgevoerd? DTS of SSIS maakt bijvoorbeeld gebruik van een bulk import. Het opnieuw opbouwen van de indexen is dan vaak geen overbodige luxe.

Heb je bijvoorbeeld als eens een 'dbcc checkdb' uitgevoerd?

Schiet mij nog iets te binnen? Hoe staat het met de instellingen van 'tempdb'? Heeft deze voldoende ruimte of moet deze steeds harddisk ruimte claimen?


offtopic:
Is er trouwens nog een reden dat er in november voor SQL2005 ipv SQL2008 is gekozen? In november gaf MS namelijk ook de rtm versies via technet en msdn vrij. De prijsstelling van beide versies is gelijk, dus ben best wel benieuwd naar de achterliggende gedachte van die keuze.

[Verwijderd]

Niemand_Anders schreef op vrijdag 12 december 2008 @ 14:48:
Het verhogen van een timeout is nooit een oplossing. Op welke manier hebben jullie de migratie van 2000 naar 2005 uitgevoerd? DTS of SSIS maakt bijvoorbeeld gebruik van een bulk import. Het opnieuw opbouwen van de indexen is dan vaak geen overbodige luxe.

Heb je bijvoorbeeld als eens een 'dbcc checkdb' uitgevoerd?

Schiet mij nog iets te binnen? Hoe staat het met de instellingen van 'tempdb'? Heeft deze voldoende ruimte of moet deze steeds harddisk ruimte claimen?


offtopic:
Is er trouwens nog een reden dat er in november voor SQL2005 ipv SQL2008 is gekozen? In november gaf MS namelijk ook de rtm versies via technet en msdn vrij. De prijsstelling van beide versies is gelijk, dus ben best wel benieuwd naar de achterliggende gedachte van die keuze.

De rede: Een groot bedrijf gaat meestal niet over op een nieuw software pakket wat net uit is. Ik ken niemand die bijvoorbeeld toen Vista uitkwam gelijk compleet over ging. Van SQL 2005 weten we dat het nu goed is en de belangrijkste rede:

De test omgeving voor een pakket draait al een half jaar. Toen was er nog geen 2008.

De time-outs werken wel, de query's hebben nu genoeg tij dom wel de data te laten zien.

Ik ben al wel meer druk aan het zetten om de 2003 server eerder te krijgen. Indexen zijn op de webserver opnieuw opgebouwd. De migratie is gegaan: Alles van sql 2000 eraf, sql 2005 installeren en data importeren. (extern bedrijf heeft dit gedaan)

[Verwijderd]

Echter daar in generiek termen iets over zeggen is moeilijk. Draait je sql compaibly mode?

Na het lezen van deze pagina, denk ik dat het daar de oorzaak zit. Dit ga ik eerst verder uitzoeken