SQL, Parametrisierung, Raidlevel, Cache ?

Mal wieder ! Ich weiß, daß diese Fragen häufig gestellt werden. Jedoch ich kriegs nich auf die Beine. Folgender Hardwarezustand : Supermicro DualXeon 2GHz, 2GB Ram, eine IDE HD, Dualchannel Raid ( Adaptek 2000s ), 2x 5 Festplatten (18GB IBM 15K rpm), mehrere NIC… meine Einstellungen : -Boot & Systemplatte = IDE -SQL Datenbank aufgeteilt auf zwei Raid 5 Arrays á 5 Platten. Defaulteinstellungen vom Kotroller für Cache beibehalten. -keine weitere parametrisierung vorgenommen. Folge : -wesentlich schneller bei Reports usw, jedoch extrem langsam als Navision DB beim Buchen, blättern und filtern in Tabellen. Meine Fragen : liegt es am Raidlevel, wenn ja welche wären zu empfehlen ? wie sollten die Cacheeinstellungen für Software, HDs und Controller lauten ? Wie sollte die Datenbank auf Arrays aufgeteilt werden ? Welche Speichereinstellung ist optimal ? Welche Optimierung von SQL ist machbar ? wie kann ich Key-Probleme ausfindig machen und beseitigen ? sovielen Fragen auf einmal !!

Hallo, generell solltest du folgendes beachten: 1. system / boot platten sollten recht flott sein. (warum hier ne IDE gurke?) 2. schmeiss das windows swapp file auf eine separate (echte) platte am besten 1. + 2. auf jeweils ne flotte SCSI Platte (zur sicherheit gespiegelt) 3. wenn du wirklich ne DB-rakete willst, dann kein RAID 5 sonder spiegeln … pirmin

Hallo, Unsere Konfiguration: Datenbank: Windows 2000 SP2 MS SQL Server 2000 SP2 Navision 2.65 (Runtime ist 3.10A) 70 User 50 GB Datenbank ca. 25000 Posten am Tag Hardware: Supermicro Server 2 CPUs (1266 MHz Tualatin-S, 512k cache) 2 GB Ram 6 Kanal Raid Controller 128 MB cache 20 15k HDs System und pagefile RAID1 Log RAID1 (ohne HD und Controller Schreibcache) Data RAID10 Temp 1 HD Hotifx 1 HD 1000 MBit Ethernet (Backbone) RAID5 ist beim Schreiben sehr langsam! Besser ist RAID 0/1/10 Die Geschwindigkeit des Client ist bei SQL-Option wichtiger als bei Navision DB. Reports, Forms, Filter und alle Lesezugriffe sollten extrem schnell sein. Bei Buchungen (Schreibzugriffe) ist es möglich, dass die SQL-Option langsamer als die Navision DB ist. Das liegt daran, dass bei Änderugen auf Tabellen mit SHIFT Feldern sehr viel mehr in der Datenbank geschrieben wird als nur die einentlichen “Nutzdaten”. Dies ist über Trigger im SQL Server realisiert. Unnötige Summenfelder sollte man also vermeiden. Bei der Tabellendefinition in Navision hat man auch die Möglicheit die Erstellung von SHIFT Tabellen im SQL Server abzuschalten kann aber Trotzdem die Summenfelder verwenden. Dann laufen Schreibvorgänge deutlich schneller aber Auswertungen werden langsamer, da der SQL-Server dann alle Datensätze selbst summieren muss. Der Profiler des SQL Server ist ein sehr gutes tool um solche Engpässe aufzuspüren. Problematische Funktionen sollte man sich auch in C/Side näher anschauen. Manches ist halt nur nicht gut (für die SQL-Option???) programmiert. Wir haben auch negative Erfahrungen mit den SQL Parametern “Statistiken automatisch erstellen/aktuallisieren” gemacht. Das hat teilweise zur Auswahl “falscher” Schlüssel durch den Optimierer des SQL Server geführt. Wir haben alle erstellten Statistiken gelöscht. Seit Version 3.10A gibt es auch einen neuen Srollbalken auf der rechten Seite in Forms, der nicht gerade Elegant in der SQL-Option programmiert ist und auch zu Performance Problemen beim “Blättern” durch Forms führen kann. Wir sind mit der Geschindigkeit der SQL Option sehr zufrieden. Die Zuverlässigkeit, Datensicherheit (Transaction Logs und Datensicherung) und “Offenheit” der SQL Option waren für uns aber ausschlaggebend. Gruss Samy

quote:


Originally posted by samy: Dann laufen Schreibvorgänge deutlich schneller aber Auswertungen werden langsamer, da der SQL-Server dann alle Datensätze selbst summieren muss.


Das mit den Auswertungen ist wohl ein böses Gerücht, oder hast Du das selber so festgestellt? Ich habe (an einigen Beispielen) den gegenteiligen Effekt beobachtet: z.B. eine Statusübersicht, die für 6 bis 8 Konstellationen (Filterkombinationen) ein paar Artikelmengen berechnet. Laufzeit mit Bordmitteln >= 3 Minuten, als SQL-Script (aus dem Navision-Client heraus abgesetzt) maximal 2 Sekunden.

quote:


Originally posted by samy: Manches ist halt nur nicht gut (für die SQL-Option???) programmiert.


Das ist aber sehr freundlich ausgedrückt! Auf mich wirkt die SQL-Option irgendwie krampfhaft aufgepfropft, Hauptsache “Wir unterstützen SQL”. Die Möglichkeiten, die so ein SQL-Server bietet werden jedenfalls nicht ansatzweise genutzt. Und das Client/Server-Thema wird in Dänemark wohl auch anders interpretiert… (Just my €0,02) Gruß, Thomas

Hallo Thomas, Das die SQL-Option bei Auswertungen schnell ist habe ich auf einen Vergleich zwischen Native DB und SQL-Option bezogen. Das ein SQL script auch 100 mal schneller sein kann ist klar. Das Problem oder der Vorteil der SQL-Option ist die Kompatibilität! Fast der komplette code kann sowohl in der Native DB als auch in der SQL-Option verwendet werden. Man kann also den Server “frei” wählen ohne eine Zeile code anzupassen. Wie du schon bemerkt hast ist C/SIDE sehr Clientlastig. Mich würde es aber sehr interessieren wie du SQL scripts in Navision verwendest. Denn in einigen Fällen macht es sicher Sinn Programme speziell für den SQL-Server anzupassen. Gruss Samy

Hallo Samy,

quote:


Originally posted by samy: Das Problem oder der Vorteil der SQL-Option ist die Kompatibilität! Fast der komplette code kann sowohl in der Native DB als auch in der SQL-Option verwendet werden. Man kann also den Server “frei” wählen ohne eine Zeile code anzupassen. Wie du schon bemerkt hast ist C/SIDE sehr Clientlastig.


Eben 'drum, diese Client-Lastigkeit ist etwas, das man mit Bordmitteln leider nicht beeinflussen kann. Hier wäre Dänemark gefragt, denn wenn ich mir die Umsetzung auf SQL ansehe, wird mir schlecht. Im von mir angeführten Beispiel lautete die Aufgabe: zähle die Artikel, die dem Kriterium X entsprechen und einen Bestand innerhalb der Filterbedingung Y haben. Der Client schickt für JEDEN einzelnen Artikel eine Query ab, um den Bestand zu berechnen. Völlig absurd, wenn wir von SQL und Client/Server sprechen!

quote:


Originally posted by samy: Mich würde es aber sehr interessieren wie du SQL scripts in Navision verwendest. Denn in einigen Fällen macht es sicher Sinn Programme speziell für den SQL-Server anzupassen. Gruss Samy


Ich benutze Automation-Variablen vom Typ “Microsoft SQLDMO Object Library”. (Die stammen, wenn ich mich recht erinnere, aus der Installation der SQL-Server Client Tools) Darin gibt es Klassen wie SQLServer und QueryResult. Im Prinzip sieht das so aus: Clear(SQLServer); Create(SQLServer); SQLServer.Connect(Server Name, User, Passwort); SQLQueryResult := SQLServer.ExecuteWithResults(Query-Text); Anzahl := SQLQueryResult.GetColumnLong(1,1); wobei die letzte Zeile spezifisch und ausreichend für meine Aufgabe ist. Da gibt es aber sicherlich noch andere Möglichkeiten, auf das Ergebnis zuzugreifen. (In einem anderen Fall habe ich einen OLE-DB-Provider benutzt, um auf eine Oracle-Datenbank zuzugreifen. Du siehst also, Möglichkeiten gibt es genug:-) HTH, Thomas