Är det ngn som känner till ngt referens verk vad gäller sql7:ans prestanda?

Vill veta vad som är rimligt att begära av en sql7:a i relation till serverns hårdvara .. Då med fokus på sökningar och uppdateringar ..

Börjar gå lite slött när vi närmar oss tabell storlekar på 1,4 - 1,5 miljoner poster och att söka ut block därifrån .. trots indexeringar ...

tips ??

Känner inte till ngt referensverk. Men gott om minne på servern är alltid viktigt, hjälper dock inte alltid.

Vi hade tidigare prestanda bekymmer med databaser som hade tabeller med runt 4-4,5 miljoner poster i. Där hjälpte det inte med att uppdatera statistik osv... Saker och ting tog sin tid. Vi bytte hårdvara, det hjälpte delvis men vissa frågor gick otroligt slött ändå.
Jag tror att det i detta läge är viktigt man tittar på databas designen och framför allt på hur frågorna/sp är uppbyggda (används #temp-tabeller?, joins osv...). Frågor/sp som fungerar bra med ett par tusen poster i tabellerna kan sänka servern när datamängden ökar.

MVH // Jonas

Jag skulle varmt rekomendera dig att om du kör IIS och SQL-Server på samma maskin så betyder det oerhört mycket på prestandan.

Samtidigt är det också så att med defragmenterade diskar så kan det gå långsammare. Tänk att du har tabeller där dess data ligger spritt på hela disken - skrivhuvuden måste hoppa fram å tillbaks. Det finns något defragmenteringsverktyg för NT.

Du då även tänka på att loggningarna som görs innebär att extra data skrivs till disk varje gång - du skulle temporärt kunna stänga av detta och se om prestandan ökar.

Ytterligare ett tips är att lägga databasen, indexet och loggfilen på varsin fysisk (förslagsvis IBM 7200 varvare eller snabbare). Detta gör att controllerkortet ser till att diskarna arbetar paralellt. Nu tror jag dock Oracle endast har separata indexdatabaser, men du förstår i alla fall principen.

Hälsningar
/Pelle

Som övriga talare säger så finns det massor av bra tips för att förbättra diverse saker. Men det visste du alldeles säkert redan.

Något referensverk känner jag inte till, och det vore nästan omöjligt att göra ett, eftersom prestandan beror på så ofantligt många faktorer. Man kan ha bästa hårdvaran men om man inte utnyttjar den rätt eller har en felkonstruerad DB så lär man inte få bra resultat ändå. Dock kan jag säga att det ska inte vara några större problem att ha 1,5 miljoner rader i en tabell. Självklart ställer det höga krav på design och utnyttjande, men det är inget ovanligt. Det blir ju inte mer än drygt 10 GB data, om raderna är fulla.

Vad har ni för indexstrategi på dem? Ni använder väl inte fritextsökningen i SQL Server?

Muchos Gracias,

skönt att hitta ngt bollplank i sql träsket ...

DB'n är indexerad både manuellt och via index tuning wizard. Det är en fristående tabell och sökningarna innefattar inga joins. Mao en väldigt simple sökning görs. Maskinen ligger idag och kör win2000 server med 380mb internt.

Applikationen som kör är ett billingsystem och com+ är den som frågar efter information, komponenterna är oerhört snåla resurs mässigt så de tar inte så mycket. För övrigt är maskinen tom...

Skall kolla alla era tips, vi tittar också på att splitta tabellen i två. En tabell för historia, dvs det som redan är fakturerat, och en för det som inte är ..

Problemet uppstår i COM+ och ADO, eftersom svaret tar tid på sig. Just nu använder vi en workaround som tripplar commandtimeout varje gång timeout felet uppståe.. Men detta får inte vara en permanet lösning ...

fler ideer välkommnas varmt...

Uppstår timeouten när flera användare söker i tabellen samtidigt?

det är ett billing system som sagt, vilekt innebär att bara en komponent pratar mot fakturaunderlaget åt gången ..

Att dela på tabellen låter som en alldeles utomordentlig idé, om ni inte har många frågor som behöver både och, för ni vill inte börja joina då.

Maskinen låter inte som nån värsting precis, men det är väl inte en 'skitmaskin' heller. Mer minne skulle dock inte skada.

Är ni säkra att indexen används som ni vill? Har ni kontrollerat att exekveringsplanen ser ut som den borde? Hur är fragmenteringen på disken, t ex om ni kör DBCC SHOWCONTIG, vad säger den då?

Förutsätter att ni analyserat alla externa anrop och SPs så att den inte håller på med tunga och onödiga table scans. Vi har haft problem med Sps som syntaxmässigt sett helt ok ut men som vi fått ägna mycket tid åt för att få dem optimerade.

/Joakim

>det är ett billing system som sagt, vilekt innebär att bara en komponent pratar mot fakturaunderlaget åt gången ..

Men varje komponent körs väl i en instans per ansluten klient precis som i MTS? Titta i taskmanager.