Hej!

Vet att SQL Server 7 på Windows 2003 Server inte stöds av MS med hänvisning till säkerhetsaspekter.

Pga diverse omständigheter kör jag tyvärr en ASP.NET 1.1-applikation mot just den kombinationen, och har hittat en del allvarliga prestandaproblem med queries som tar vääääldigt lång tid.

Det kan naturligtvis vara ett problem med nåt index el.dyl. Jag har små möjligheter mecka med databasen just nu eftersom kunden använder den ganska intensivt, så alla sådana möjligheter har jag inte undersökt färdigt.

Men misstanken infinner sig förstås att det kan ha att göra med någon inkompatibilitet mellan SQL Server 7 och Windows 2003 Server.

Har googlat en hel del utan att hitta nåt. Nån här som känner till något om detta?

MVH
/Jonas

Har servern flera processorer?

Svar ja, 2 st. SQL 7 är inställt på att använda båda, jag har inte ändrat några av defaultinställningarna för CPU.
Är det ett känt problem? Jag såg att W2003 SP1RC skulle fixa något multiprocessor-problem.

MVH
/Jonas

OK. Testa att höja värdet under "Query plan threshold for considering queries for parallell execution" (eller vad det nu heter). Defaultvärdet är 5. Jag skulle direkt ifrån det du säger råda dig att testa med värden kring 20.
Man kan nästan kalla det ett känt fel. SQL Server kan ibland lägga oerhört mycket tid på att fördela arbeten mellan processorer.

Jag gissar dock att detta inte är det enda som måste göras, men det är ju något att testa till en början.

/Pelle

Hej Pelle och stort tack!

Jag har testat att ratta lite fram och tillbaka på tröskelvärdet utan att uppnå förändringar som ligger utanför nån sorts rimlig felmarginal. Jag har dock rattat i blindo så tillvida att jag inte vet vad tröskelvärdet är i för enhet. Procents vinst? Antal procent som (sub)queryn kostar i exekveringsplanen?

Vad som dock gjorde en enorm skillnad var att sätta SQL Server till att bara använda en processor. Jag har en batch med queries jag använt för att testa, via Query Analyser. Batchen tar c:a 1 min 40 s på mina (enprocessors) utvecklingsburkar, men hisnande 17 minuter på produktionsservern. I stort sett hela den diffen utraderas om jag kör på endast en processor.

När jag tittar i exekveringsplanen för batchen stöds också din tes, det finns några queries som har parallell processning planerad och det är de större av dem som drar den extra kvarten...

Nu ligger (dessvärre) ASP.NET-applikationen som jobbar mot databasen på samma server och det går ju att styra den att exklusivt använda den andra processorn. Så det kanske är en bra lösning trots allt, att låta ASP.NET och SQL Server använda varsin processor. Men jag är ändå nyfiken på mer info om detta fenomen, inte minst som jag hoppas så småningom kunna få loss en server till från kunden och då kunna separera SQL Server från ASP.NET/IIS.

Tack igen!
/Jonas

Kul att kunna vara till hjälp!

Jag vill dock varna för att helt styra bort sql server från att använda två processorer. Det fungerar nämligen så att varje session som loggar på styrs till en viss processor och här sker en lastbalansering, så att jobben fördelas jämnt mellan processorerna. Dock så väljer sql server att lastbalansera även tunga jobb. Vad som är ett tungt jobb styrs av ovan nämnda parameter (enheten är i sekunder uppskattad exekveringstid). Det man kan göra är att hindra att flera processorer används för parallellexekvering.

Testa lite och se vad som hjälper. En risk med batchtestet som du gjort är att det är svårt att simulera samtidiga användare. Kör det samtidigt i flera fönster i query analyser så borde det ge en rättvisande bild.

Lycka till!

/Pelle

"Det man kan göra är att hindra att flera processorer används för parallellexekvering."

Ok, ska testa mer med detta. Är det enda sättet att hindra parallellexekvering att laborera med tröskelvärdet? (Har för mycket queries för att ha tid att ratta med hintar i dem.)

Ledsen om detta är frågor av RTFM-karaktär, jag är egentligen bara en enkel utvecklare på okänd mark, alls ingen dba! :-) Det är helt ok att bara svara med hänvisning till andra resurser.

mvh
/Jonas

Jag är också en utvecklare som har sprungit på problemen! Ibland i sitt arbete tvingas man ju som bekant lösa problem som man tycker hör till andra...

Vad betyder RTFM?

I Enterprise Manager, fliken Processor, rutan Parallellism: Välj Use [1] processor(s).

/Pelle

RTFM = Read The Fine/F*cking/(vad du vill som börjar på F) Manual

Usch, vilket språk! Read The FINE Manual betyder det naturligtvis!
;-D
Vad jag menade med "frågor av RTFM-karaktär" var alltså frågor så grundläggande att en något mer kunnig person än jag kan frestas utropa just RTFM!

mvh
/Jonas

<code>
USE master
EXEC sp_configure 'show advanced option', '1'
RECONFIGURE

EXEC sp_configure 'max degree of parallelism', '1'
RECONFIGURE
</code>


Följande, skrivet av Brian Moran (SQL Server MVP) i ett SQL Magazine nyhetsbrev, kan också vara av generellt intresse:

"When sharing TPC-C full disclosure information with my customers, I refer most to the configuration setting for max degree of parallelism (MAXDOP). Many customers are surprised that almost every published Microsoft TPC-C score has the MAXDOP set equal to 1. This setting means that SQL Server won't use a parallel execution plan for any query. You might ask, "Aren't parallel queries faster than a serial counterpart for an execution plan?" The answer to that question, of course, is, "It depends." The TPC-C benchmark measures performance for an online transaction processing (OLTP) workload, and most OLTP workloads don't benefit from parallel queries. For example, if a particular expensive parallel plan decides to chew up all eight processors in the middle of a peak transaction-processing time, your overall throughput can dramatically drop. I usually recommend that my customers set the MAXDOP value equal to 1 (disabling parallelism) for most OLTP workloads. I recommend you do the same unless you've performed serious in-depth testing to prove that keeping parallelism enabled is the right choice for your environment. Even then, your testing becomes obsolete and meaningless if you introduce new queries, which can change your well-thought-out plans. It's better to disable parallelism for OLTP workloads."

Per, Christoffer, tack!

Nu rullar det både på bättre och jag förstår t.o.m varför! :-)

mvh
/Jonas