Einfrieren von Navision PAGEIOLATCH_SH

Hallo,

da ich mit meinem Latein am Ende bin wende ich mich an euch.
Wir haben im März 2012 unser Nav auf eine neue Datenbank gelegt. SQL 2008 SP1. Zuvor SQL 2005 (an der logic bzw. der Programmierung von Nav wurde nichts verändert).

Seit dem Umzug haben wir folgendes Problem:
Wenn wir größere Tabellen (Sachposten/Artikelposten/Verkaufslieferzeilen usw.) öffnen kann es zum einfrieren von Navision kommen. Auch das Ändern der Sortierung führt zu längeren wartezeiten.
Herauskristalisiert hat sich, das dieses Verhalten immer mit Lesen von der DB zu tun hat.
Der SQL Activity Monitor weisst immer den PAGEIOLATCH_SH auf, wenn dieses Verhalten eintritt.
Die Datenbanken liegen auf einer eigenen Festplatte "Dell Compellent S40 Storage", 64kb Cluster Size formatiert. Getrennt von Systemdatenbanken, Tempdb und Log files.
Komischerweise gab es dieses einfrieren auf SQL 2005 nicht. Der damalige server hatte eine langsamere Storage, weniger Speicher und weniger Prozessoren.

hat jemand ne idee wo ich ansetzten könnte, bzw. kennt jemand dieses Verhalten.

Bin um jeden Rat froh.

sg aaron

Welche NAV 5 version? SP1 oder ohne?

Hy,

Nav. 5.00 SP1

lg aaron

Wie habt ihr die Datenbank umgezogen?
Als SQL-Backup oder als native Sicherung?
Im zweiten Fall würden alle manuel angelegten SQL-Keys verloren gehen was zu dem Problem mit den längeren Zeiten bei Postentabellen und Sortierung führen kann.

Der Umzug erfolgte über ein SQL Backup.
Das Compatibility Level der DB's wurde danach auf 100 gesetzt.

Habt ihr schonmal alle Tabellen auf SQL-Seite reindiziert?

Wie sieht die Last auf dem Plattensystem aus?

jeden Samstag läuft ein rebuild/reorganize job von Jörg Stryk.

was für eine kennzahl bezgl. Plattenlast hättest du gerne?
lt. unserer It - die mir die Platten zur verfügungstellt seinen die Datenmengen nicht groß bzw. die storage würde noch viel mehr i/O's verkraften.

Wenn die Platte noch einiges mehr an I/O verträgt klingt das jetzt nicht so als wäre hier die Bremse.

jeden Samstag läuft ein rebuild/reorganize job von Jörg Stryk.

Heisst das jetzt, dass Jörg Stryk schon auf eurer neuen Datenbank mal Optimierung für euch gemacht hat?

die jobs liefen schon auf unserem "alten server", jörg hat uns nur quasi die neuinstallation der aktuellen jobs gemacht. habe aber übernächste woche einen termin mit ihm.

die jobs liefen schon auf unserem "alten server", jörg hat uns nur quasi die neuinstallation der aktuellen jobs gemacht. habe aber übernächste woche einen termin mit ihm.

Dann wage ich jetzt einmal zu behaupten, dass dabei sicherlich mehr brauchbare Tipps und Optimierungne rauskommen als hier ;)

ok... :)

bin trotzdem um jede idee froh.
stehe leider alleine da. auch unsere beratungsfirmen kennen das phänoman nicht..

Welchen NAV- Build verwendet Ihr?

Was steht unter "Datei\Datenbank\Ändern" Reiter "Erweitert" bei Datensatzmenge?

Gruß, Fiddi

build 29736
Datensatzmenge 500

lg aaron

Der Build ist ja schon ein bisschen alt. Evtl. hilft ein Update auf ein neueres Build (33335 ist aktuell).

Zum zweiten verwendet NAV2009 eine geringere Datensatzmenge von 50, evtl. hilft das.

Gruß, Fiddi

bzgl. update, dass steht schon in diskussion... nur leider wird sich das sicherlich noch ziehen..

Was passiert, wenn du die Datensatzmenge reduzierst?

Gruß, fiddi

kann ich solch eine änderung im "livebetrieb" durchführen?
was ändert sich dadurch?

lg aaron

kann ich solch eine änderung im "livebetrieb" durchführen?

Ich denke ja, bei 2009 geht es zumindest.

Damit wird gesteuert, wie viele Datensätze beim Lesen aus der SQL-DB am Stück in den Cache gelesen werden. Bei ungünstiger Programmierung kann das dazu führen, dass der SQL-Server dauernd Daten in den Cache liest, und danach wieder verwerfen muss, weil Sie nicht mehr benötigt werden.
Ob du den Wert hier auch auf 50 ändern kannst, weiß ich bei 5.0 jetzt nicht. Versuche ihn aber zu reduzieren.

Prüfe bitte außerdem, ob bei euch die Sift- Tabellen noch als Tabellen oder als Views angelegt sind. Ich binn mir nicht ganz sicher, wann MS bei NAV 5.0 umgestellt hat. Sollten noch Sift- Tabellen vorhanden sein, sollte ein technisches Update auf den aktuellen Build, und danach ein "Compile All" die Tabellen beseitigen (aber Vorsicht: evtl. lassen sich nicht alle Objekte kompilieren, die bisher funktionierten. Daher den "Compile All" erst einmal auf einer Datenbank durchführen, die nicht produktiv ist)

Gruß, Fiddi

kann ich solch eine änderung im "livebetrieb" durchführen?

Ich denke ja, bei 2009 geht es zumindest.

Damit wird gesteuert, wie viele Datensätze beim Lesen aus der SQL-DB am Stück in den Cache gelesen werden. Bei ungünstiger Programmierung kann das dazu führen, dass der SQL-Server dauernd Daten in den Cache liest, und danach wieder verwerfen muss, weil Sie nicht mehr benötigt werden.
Ob du den Wert hier auch auf 50 ändern kannst, weiß ich bei 5.0 jetzt nicht. Versuche ihn aber zu reduzieren.

Prüfe bitte außerdem, ob bei euch die Sift- Tabellen noch als Tabellen oder als Views angelegt sind. Ich binn mir nicht ganz sicher, wann MS bei NAV 5.0 umgestellt hat. Sollten noch Sift- Tabellen vorhanden sein, sollte ein technisches Update auf den aktuellen Build, und danach ein "Compile All" die Tabellen beseitigen (aber Vorsicht: evtl. lassen sich nicht alle Objekte kompilieren, die bisher funktionierten. Daher den "Compile All" erst einmal auf einer Datenbank durchführen, die nicht produktiv ist)

Gruß, Fiddi

Hy Fiddi,

hab die Datensatzmenge auf die Hälfte reduziert, leider keine Verbesserung.

bzgl. SIFT: das sind alles Views....

lg aaron

Prüfe bitte mal die Warteschlangenlängen der Datenträger mit Perfmon oder dem Resourcenmonitor des Taskmanagers.

Außerdem, wie ist die Storrage an den Server angebunden? ISCSI? mit mehreren Servern auf dem gleichen Kanal? Wie groß ist eure DB?

Gruß, Fiddi

Kurze Frage zur Konfiguration des SQL-Servers.

1. der neue SQL-Server ist auf einer anderen Hardware?
2. Welche Version war SQL 2005?
3. Welche Version ist SQL 2008? Standard, Enterprise, 32.bit,...?
4. Welche Windowsversion ist drunter?

Volker

Prüfe bitte mal die Warteschlangenlängen der Datenträger mit Perfmon oder dem Resourcenmonitor des Taskmanagers.

Außerdem, wie ist die Storrage an den Server angebunden? ISCSI? mit mehreren Servern auf dem gleichen Kanal? Wie groß ist eure DB?

Gruß, Fiddi

die read queue length ist zu 80% immer im positiven bereich - sprich ich nehme die anhaltspunkte aus dem Performance File Guide von Stryk.
die Storrage ist über Fibrechannel angebunden. Im server sind 2 Fibrechannel adabpter. Selbiges gilt für die Storrage

Was meinst du mit mehreren Servern auf dem gleichen Kanal?

Das DB File ist 296 GB groß und verwendet sind etwa 260 gb.

lg aaron

Kurze Frage zur Konfiguration des SQL-Servers.

1. der neue SQL-Server ist auf einer anderen Hardware?
2. Welche Version war SQL 2005?
3. Welche Version ist SQL 2008? Standard, Enterprise, 32.bit,...?
4. Welche Windowsversion ist drunter?

Volker

1. Ja der neue SQL-Server liegt auf einem neuen Cluster - intel xeon CPU E7450, 32 GB Ram - SQL Server hat ein Max. von 30 GB - 4 Processoren mit 6 Kernen
2. SQL 2005 SP3 64-bit auf folgendem Cluster - IBM Xseries_3850M2 Intel Xeon, 24 GB Ram - SQL Server hat ein Max. von 21 GB - 4 Processoren mit 2 Kernen (Threads 4)
3. SQL 2008 SP1 Enterprise 64-bit
4. Läuft auf Win 2003 R2 Enterprice 64-Bit SP2

lg aaron

Zuletzt geändert von aaron am 3. Mai 2012 13:20, insgesamt 1-mal geändert.

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

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