3. Mai 2012 13:01
fiddi hat geschrieben:bei einer 260 GB großen Datenbank ist 30GB Arbeitsspeicher nicht gerade viel. Ich denke der Rechner ist eine 2 Prozessor- Maschine mit jeweils 12 Kernen pro Prozessor.
Habt ihr irgendwelche Sicherungsmaßnahmen wie Logshipping oder SQL- Server- Synchronisation Edit: (mirroring)an?
Prüfe doch bitte mal die "cache hit ratio" des SQL- Servers. Alles was unter 95 % ist, ist bedenklich.
Gruß, Fiddi
3. Mai 2012 13:06
vsnase hat geschrieben:Hi,
bin mir da jetzt nicht ganz sicher, aber kann der SQL-Server nicht eigentlich nur bis 20 Kerne? Könnte mir vorstellen, dass zuviele Kerne ggf. zu so lustigen Ergebnissen führen wie zuviel RAM im Rechner (z. B. 40 GB in Win2008Std=max32GB). Eigentlich klappt alles, nur halt doch irgendwie nicht.
Das meiste was Tante google unter dem Stichwort PAGEIOLATCH_SH liefert läuft immer wieder auf einen zu kleinen Buffer raus.
Gibt es denn evtl. auch noch andere Fehlermeldungen oder Einträge im Ereignis-Log auf dem SQL-Server?
Volker
3. Mai 2012 13:50
habe die buffer cache hit ration seit deinem eintrag beobachtet und der average wert liegt bei 99.940
3. Mai 2012 13:54
3. Mai 2012 14:00
3. Mai 2012 14:22
3. Mai 2012 14:28
3. Mai 2012 14:54
fiddi hat geschrieben:habe die buffer cache hit ration seit deinem eintrag beobachtet und der average wert liegt bei 99.940
Der Wert ist eigentlich gut, ist während der Zeit dein Problem aufgetreten?
Gruß, Fiddi
3. Mai 2012 14:59
Wollte die sortierung auf Laufende Nummer ändern. Navision hing für dann knapp 3 min.
Wärend sie hing, bin ich auf den Selben artikel und hab ident das selbe gemacht... ich hing dabei aber nicht mehr.
3. Mai 2012 15:10
fiddi hat geschrieben:Wollte die sortierung auf Laufende Nummer ändern. Navision hing für dann knapp 3 min.
Wärend sie hing, bin ich auf den Selben artikel und hab ident das selbe gemacht... ich hing dabei aber nicht mehr.
Das deutet für mich darauf hin, dass da irgendwo Requests verworfen oder ausgebremst werden, sei es auf Plattenebene oder im SQL- Server, wobei ich eher ersteres vermute.
Gruß, Fiddi
3. Mai 2012 15:12
3. Mai 2012 15:15
hast du mir ne idee wie ich das rausfinden kann
3. Mai 2012 15:17
vsnase hat geschrieben:Ist den immer der gleiche Rechner(-Gruppe) langsam? Oder immer der gleiche User(-Gruppe)? Kann ein Hardwareproblem (Kabel, Switch, Netzukarte,...) ausgeschlossen werden?
Volker
3. Mai 2012 15:20
fiddi hat geschrieben:hast du mir ne idee wie ich das rausfinden kann
Ideen, eine ganze Menge, aber das sollte sich jemand anschauen, der sich mit eurer Hardware sehr gut auskennt, und auch keine Angst vor einem SQL-Server hat.
Gruß, fiddi
3. Mai 2012 15:25
3. Mai 2012 15:38
4. Mai 2012 07:42
vsnase hat geschrieben:Noch eine Frage, warum habt Ihr noch SP1 auf dem SQL-Server installiert? Aktuell wäre doch SP3. Habe allerdings jetzt nicht nach gesehen, was mit SP2 und SP3 behoben wude.
Volker
4. Mai 2012 07:48
fiddi hat geschrieben:Hab hier gerade noch was gefunden.
das würde das auch erklären. Auch wenn du das im Anschluss machst, hat er die Daten im Cache.
Bei eurer Anzahl Posten (ich vermute mal jeweils weit jenseits der 20 Mio.) kann das schon zu einem Problem führen, wenn die Querry nicht optimal ist, oder Speicher nicht ausreicht.
Gruß, fiddi
4. Mai 2012 08:09
die artikelposten haben 14 mio einträge
4. Mai 2012 08:37
fiddi hat geschrieben:die artikelposten haben 14 mio einträge
Wo verteilen sich denn dann die anderen Daten?
Ich gehe jetzt mal davon aus, dass Ihr Tabellen- Statistiken regelmäßig aktualisiert.
Gruß, Fiddi
4. Mai 2012 08:49
8. Mai 2012 08:58
vsnase hat geschrieben:Ich kann mir nicht vorstellen, dass es an der NAV-DB selbst liegt. Es ist doch ein neuer Server (Hard und Software), oder? Meine Vermutung geht eher dahin, dass am alten Server eine Einstellung vorhanden war, die am neuen noch nicht gesetzt wurde. Meine Frage nach möglichen Fehlern im Log zielte auf http://support.microsoft.com/kb/918483/en-us ab. Wir hatten aber auch schon das Phänomen, dass ein aufgehängter Switch zwar Verbindungen zugelassen hatte, aber nur DHCP nicht mehr funktioniert hatte - Switch-Reboot und gut. Defekte Platten/RAID-Controller sollte eure IT ja erkennen und denke ich kann man ausschließen. Ich würde auch versuchen das mit den maximalen Kernen auszuschließen und dem SQL mal nur wir früher nur 16 Kerne zur Verfügung stellen.
Volker
8. Mai 2012 09:02