Hej! Om du redan lokaliserat problemet med lite minne kanske just en uppgradering till 4gb är något att föredra? Du kan även ställa in hur mycket minne sql-servern skall använda om du vill ha ett fast tak. Sen har vi ju problemet med 32-bitars sql som bara adresserar 2Gb (3 vid Enterprise) men det är ju en helt annan sak. Hej Hmm >SQL skriver till datafilen och logfilen samtidigt < stänga av loggfilen Her det inte framför mig men det är i databasinställningarna någonstans. Simple = auto-tömHårdvara - rekommendation för SQL server
Vet någon här om det finns någon generell rekommendation för hårdvaran i en SQL Server 2000? Anledningen till frågan är att vi har en SQL Server 2000 med flera databaser, där den största är ca 3,5 GB. Den börjar gå dåligt pga minnesbrist (2GB ram i servern).
Mvh
RickardSv: Hårdvara - rekommendation för SQL server
När det gäller gå dåligt kan du även titta på index och optimeringar men det kanske du redan gjort?Sv:Hårdvara - rekommendation för SQL server
En databas på 3.5 GB skall inte behöva mer minne egentligen
Jag håller med: Index och frågor. Villkor och Joins. Kolla upp det först.
/mickeSv: Hårdvara - rekommendation för SQL server
SQL skriver till datafilen och logfilen samtidigt det ställer till problem för för diskar för finns alla diskar på en kanal så får de vänta. Moderna kontrollerkort fixar detta med stora cachminnen men man behöver ändå dela upp log,databas och os i tre olika raidset. Bästa fart får man om man använder raid 1 eller raid 10 (fyra diskar i raid 10 är snabbare än 2 diskar i raid 1)
Om man har äldre kontrollerkort får man använda flera kanaler alltså flera kontroler kort eller kort med flera kanaler på.
Diskar som snurrar i 15k med mycket cachminne på är betydligt snabbare än äldre 10k diskar.
Sen har vi det där med minnet självfallet är detta ett direkt problem
Kör du enterprisemodellen så kan det hjälpa lite men generellt har SQL 2000 sina begränsningar
/MarkusSv: Hårdvara - rekommendation för SQL server
Har man verkligrn konstaterat att det är minnesbrist? Vad har gett upphov till dena minnesbrist i sådana fall? Varför gick det snabbt innan och långsamt nu? Det är nog mer saker på denna nivå som bör redas ut.
Är du 100% säker på att du har index där du ska ha dem? Då tänker jag framförallt på foreign key index. Hur ser det it i tabelldefinitionerna? Använder man rätt datatyper och är storlekarna de rätta? Hur är sql-satserna skrivna, är de optimala? Hur anropar man daabasen, ad-hoc sqler eller prepared statements (återvändning av exekveringsplaner)? När uppdaterades statistiken senast så att optimeraren kan välja vettiga exekveringsplaner.
De sakerna jag tar upp ovan brukar vara viktigare ur performance synpunkt än det fysiska minnet så som jag upplever det. Det finns säkert mycket mer att lägga till den listan detta var bara lite jag tog ur huvudet för att leda in dig på rätt väg.Sv:Hårdvara - rekommendation för SQL server
Beror på applikationen förståss men en idé kan vara att stänga av loggfilen. Behovet och kunskapen att kunna återställa till en viss tidpunkt kanske inte finns.Sv: Hårdvara - rekommendation för SQL server
Hur gör man då? Mig veterligen kan man bara auto-tömma den, inte stänga av den.
/mickeSv:Hårdvara - rekommendation för SQL server
Recovery model - "simple" eller "full"Sv: Hårdvara - rekommendation för SQL server
Full = töm aldrig
Att stänga av loggen går inte, eftersom den är en essentiell del av SQL och transaktionshantering...
/micke