Schlechte interne Datenbank - austauschen oder Hardware einspannen?

Also - wir haben eine interne Firmendatenbank, die üblichen Dinge: Verwaltung von Kunden, Telefongesprächen, Verkaufsabschlüssen und Kundenvereinbarungen / -programmen.

Es ist ein Access 2000-Front-End und ein SQL Server 2000 Standard-Back-End. Ein einziger Server, zwei Xeon-Prozessoren mit 3,2 GHz, 2 GB RAM und Windows Server 2003 bieten den ganzen Tag über eine CPU-Auslastung von ca. 40%, verteilt auf die 4 für das Betriebssystem (HT) sichtbaren Kerne.

Die Back-End-Datenbank ist schlecht konzipiert und über 10 Jahre organisch gewachsen. Sie wird von weniger erfahrenen Personen verwaltet. Es ist schlecht normalisiert, und einige der offensichtlichen Probleme sind Tabellen mit Zehntausenden von Zeilen ohne Primärschlüssel oder Index, die auch in Verknüpfungen mit mehreren Tabellen für einige der am häufigsten verwendeten Teile des Systems verwendet werden (z. B. a Call Manager-Anwendung, die 8 Stunden am Tag auf dem zweiten Monitor eines jeden Benutzers sitzt und alle paar Sekunden eine große ineffiziente Abfrage ausführt).

Das Front-End ist nicht viel besser, es ist das typische Durcheinander von Hunderten von Formularen, verschachtelten gespeicherten Abfragen, schlecht geschriebenem Embedded SQL im VBA-Code, Dutzenden von "Macken" usw., und wann immer eine Änderung vorgenommen wird, scheint etwas, das nichts damit zu tun hat, zu brechen. Wir haben uns für eine MDB entschieden, die "gut genug" funktioniert, und haben jetzt eine unveränderte Richtlinie, da wir keine internen Access-Schwergewichte haben (und auch keine Pläne, eine zu engagieren).

Das Unternehmen wächst langsam, die Anzahl der Kunden, Anrufe usw. sowie die Anzahl der gleichzeitig angemeldeten Benutzer nehmen geringfügig zu, und die Leistung hat sich in letzter Zeit merklich verschlechtert (warten auf den Wechsel zwischen Formularen, warten auf das Auffüllen von Listen usw.) )

Perfmon sagt:

• Datenträgerübertragungen pro Sekunde: zwischen 0 und 30, durchschnittlich 4.
• Aktuelle Warteschlangenlänge: Schwebt um 1

Der SQL Server-Profiler sieht jede Minute Hunderttausende von Abfragen. Die CPU-Auslastung auf den Clients ist so gut wie Null, was darauf hinweist, dass serverseitige Abfragen ausgeführt werden müssen. Ich habe diese Arbeit über den DB Engine Tuning Advisor abgewickelt und seine Vorschläge auf eine Testsicherung angewendet, aber das hat nicht wirklich viel geändert.

Übrigens, wir haben eine Mischung aus 100 MB und Gigabit-Ethernet, alle in einem Subnetz, 40 ish-Benutzer auf zwei Etagen.

Zur Frage.

Meines Erachtens haben wir zwei Möglichkeiten, um diese Situation zu lösen / zu verbessern.

• Wir können es verschrotten und durch ein komplett neues CRM-System ersetzen, entweder nach Maß oder teilweise nach Maß
• Wir können die Lebensdauer dieses Systems verlängern, indem wir Hardware daran befestigen.

Wir können ein Intel i7-System mit verrückten Leistungszahlen für eine Größenordnung weniger Kosten als das Ersetzen der Software bauen.

Wenn ein neues System entwickelt wird, kann es auf dieser Box gehostet werden, sodass keine Hardware verschwendet wird. Ein neues CRM-System wird immer schlechter - ich sehe das erst nach einem Jahr.

Über Gedanken zu dieser Situation, insbesondere wenn Sie selbst hier waren, würden wir uns sehr freuen.

Vielen Dank

Ich werde mit allen hier nicht einverstanden sein. Chuck etwas Hardware dran. Es ist billig, schnell und einfach und verschafft Ihnen die Zeit, die Sie für die Implementierung einer geeigneten CRM-Lösung benötigen. Der Grund, warum ich etwas befürworte, das nicht nur für dieses Board, sondern auch für den Stackoverflow für nahezu jeden von Belang ist, ist, dass ich ein Projektmanager / Manager war und eine Weile auf der "Business" - Seite war (Business) ist in Anführungszeichen wegen meines Hasses für das Wort). Basierend auf Ihrer Beschreibung der Software wird es fast ein Jahr dauern, bis etwas anderes wiederhergestellt ist. Das Entdecken / Dokumentieren der Geschäftsregeln / Macken wird wahrscheinlich 2 Monate dauern. Es wird auch unglaublich teuer sein, es zu entwickeln. Vor allem im Vergleich zu den Kosten eines ausgetricksten Servers.

Genau aus diesem Grund werde ich eine Reihe von Web-Apps für ein Unternehmen hosten. Die interne IT-Abteilung wird es nicht auf eine bessere Hardware verschieben, da sie diese auf einer neuen Plattform neu entwickeln möchte. Diese Kosten sind ungefähr dreimal so hoch wie die Kosten für den Umstieg auf neue Hardware. Ganz zu schweigen davon, dass das Unternehmen den Vertrag möglicherweise nicht innerhalb eines Jahres erneuert.

Möglicherweise müssen Sie dies auch nicht tun. Mein Vorschlag ist, einfach einige Indizes / Schlüssel zur Tabelle hinzuzufügen.

Tabellen mit Zehntausenden von Zeilen ohne Primärschlüssel oder Index, die auch häufig in Joins mit mehreren Tabellen verwendet werden

Nehmen Sie sich ein paar Stunden Zeit und fügen Sie Indizes (oder Primärschlüssel, falls möglich) zu Tabellen hinzu, die an diesen Joins beteiligt sind. Dies gilt insbesondere für Spalten, die in einer where-Klausel verwendet werden. Sie können die Leistung in wenigen Stunden problemlos um den Faktor 10 steigern.

Das Fehlen von Festplatten-E / A impliziert, dass Abfragen größtenteils aus dem RAM gespeist werden. Wenn Sie plötzlich feststellen, dass Ihre Hot Tables nicht mehr in den Arbeitsspeicher passen und der Server die Festplatten in Betrieb nimmt, kann es sein, dass Sie einen schlechten Lauf haben. 2 GB oder RAM sind heutzutage nicht sehr viel, aber in der SQL2000-Ära wäre es beträchtlich gewesen. Ich vermute, dass die Datenmenge, die die Anwendung normalerweise bearbeitet, kleiner ist als der Arbeitsspeicher, den Sie haben. Möglicherweise möchten Sie die Menge an "verwendetem" Speicherplatz in den Datendateien anzeigen. Auf diese Weise erhalten Sie eine Vorstellung davon, wie viel RAM die Datenbank im schlimmsten Fall verbrauchen könnte. SQL Server speichert nicht die Daten, die nicht im RAM benötigt werden, aber es kann schwierig sein zu wissen, welche Tabellen wann verwendet werden.

Hyperthreading ist bei SQL Server nicht immer hilfreich. Möglicherweise erhalten Sie eine bessere Leistung beim Ausschalten. Es ist schwer zu testen, da das Aus- und Einschalten einen Neustart erfordert, und das ist ein großer Aufwand auf einem Produktionsserver.

"Hunderttausende Anfragen pro Minute" bedeutet Tausende Anfragen pro Sekunde. Das hört sich ziemlich beschäftigt an, aber ein Großteil des Datenverkehrs wird möglicherweise nur von Cursors über Access abgerufen. Der Zugriff ist besonders schlecht, wenn Ergebnismengen effizient aus SQL abgerufen werden sollen. Möglicherweise erzielen Sie eine bessere Leistung, wenn Sie die Einstellung für die SQL Server-Parallelisierung deaktivieren.

Sie möchten auch nach Blockierungen suchen. Wenn Sie Hardware auf ein Blockierungsproblem werfen, führt dies nicht immer zu der erhofften dramatischen Verbesserung. Wenn der Arbeitsspeicher nicht viel blockiert und die Abfragen vom Arbeitsspeicher erfüllt werden, verlassen Sie sich im Grunde auf das Grunzen des Prozessors und dessen Fähigkeit, Daten über die Speicherkanäle zu übertragen. In diesem Fall sollte eine schnellere Hardware eine gute Verbesserung bringen. Wenn Sie es eilig haben (um dieses Problem zu überwinden) und langsam wachsen, ist dies möglicherweise gut genug.

Als Lösung ist das Hinzufügen von Hardware nicht so skalierbar wie Datenbankverbesserungen. Wenn Sie einen Wachstumsschub erleben, kann es zu Problemen mit Ihrer neuen Hardware kommen. Ein weiterer Gedanke ist, dass erfolgreiche Anwendungen Benutzer anziehen. Wenn die Anwendung schneller reagiert, können Benutzer mit größerer Wahrscheinlichkeit mehr Berichte und dergleichen darauf ausführen, als wenn sie auf einen Kaffee warten müssten, bis der Bericht fertig ist.

Wenn das Datenbankschema wirklich schlecht ist, können Sie möglicherweise einige Leistungsgewinne erzielen, indem Sie sich die Indexierung der Tabellen ansehen. Konzentrieren Sie sich auf Tabellen, von denen Sie wissen, dass sie häufig abgefragt werden. Sie können Profiler verwenden, um Abfragen zu überwachen, die auf dem Server ausgeführt werden. Sie müssen nur nach Abfragen suchen, die viele Daten lesen (z. B. 100.000 Seiten), und dann auf Abfragen hinarbeiten, die nicht viel lesen. Sie haben erwähnt, dass einige Tabellen keine Schlüssel haben. Befinden sich natürliche Schlüssel in den Daten, die nicht durch Einschränkungen oder eindeutige Indizes erzwungen werden?

Haben die Tabellen Clustered-Indizes? Das Fehlen einer gruppierten Indizierung kann alle möglichen Sekundäreffekte verursachen.

Gibt es viele nicht gruppierte Indizes mit vielen Spalten? Dies ist oft ein Versuch, viele abdeckende Indizes zu erstellen, anstatt eine effektivere Indexierungsstrategie zu implementieren. SQL Server kann während einer Abfrage schnell und effektiv abdeckende Indizes erstellen, wenn dies sinnvoll ist und nicht gruppierte und gruppierte Indizes unterstützt werden.

Abschließend ist zu fragen: Werden die Tabellen gewartet (neu indiziert und / oder Statistiken aktualisiert)?

Dies ist eine Geschäftsfrage, keine technische Frage.

Als Geschäftsinhaber: Wie strategisch ist das System für das Geschäft? Je weniger strategisch, je weniger es mich kümmert, und je weniger Geld ausgegeben wird, desto mehr Geld könnte ich an anderer Stelle einsetzen, um mein Geschäft auszubauen.

Computervölker machen mir Angst, als sie alle in einen großen Raum kommen und über Design streiten und mir ein Vermögen kosten. Halten Sie das System am Laufen! Unabhängig davon, ob dies eine Leistungsoptimierung (ohne Neuarchitektur) oder das Aussetzen weiterer Hardware bedeutet, ist es nur vorrangig, wenn sie nicht mehr funktioniert.

Als IT-Berater: Ihr System ist Legacy und hat versteckte Betriebskosten. Wir können ein für Sie geeignetes System entwerfen, das skaliert und eine Plattform für zukünftiges Wachstum und strategische Vorteile bietet. Unterschreiben Sie hier und alle Ihre Träume werden wahr.

Als IT-Mitarbeiter: Ich kann hier der Superheld sein und das Unternehmen retten, indem ich eine bevorstehende Katastrophe abwehre, indem ich die Hölle aus dieser Sache heraus optimiere! Mein Vorgesetzter überschüttet mich mit Geschenken und Lob, da ich die Firma zu Tausenden gerettet habe.

Ich sage mach beides.

Im Moment sind Sie bei 40% oder so CPU, sagten Sie? Beschweren sich Ihre Benutzer (viel) schon? Wenn nicht, haben Sie noch Luft zum Atmen. Möglicherweise reicht mehr Speicher für eine Weile aus.

Frage für den Weg zu gehen, haben Sie hausinterne Software-Entwickler? Wenn die Antwort NEIN lautet, versuchen Sie nicht einmal, sie zu wiederholen. Sie landen genau dort, wo Sie jetzt sind.

Unter der Annahme, dass Sie interne Entwickler haben, haben Ihre internen Entwickler die Fähigkeit, ein Projekt ordnungsgemäß durchzuführen? Ich spreche von einem vollständigen (relistischen) Zeitplan, der im Grunde genommen dem Projekt eines Kunden gleicht. Wenn nicht, dann kümmere dich nicht darum, oder es wird wieder dort enden, wo du jetzt bist.

Solange Unternehmen nicht selbst Kunden sind und die gleichen Ressourcen für interne Projekte benötigen, landen Sie genau dort, wo Sie sich gerade befinden. Als ich dort war, bekam ich eine ganze Kommode mit T-Shirts.

Wenn Sie es also nicht richtig machen können, stehen Ihnen zwei sofort einsatzbereite Optionen zur Verfügung, die Ihre Mitarbeiter hassen werden, da sie jetzt in die Form des von Ihnen gekauften Systems passen müssen. Oder es kann angepasst werden und Sie müssen noch PROJECT-Zeit damit verbringen, es anzupassen.

ODER Refactor, was Sie haben. Denken Sie daran, dass die Leute beim Eintreffen der neuen Funktion die gleiche vollständige Funktionalität erwarten, weshalb Sie auf jede andere Weise alles auf einmal erledigen müssen. Wenn Sie es überdenken, haben Sie die Möglichkeit, herauszufinden, wie es funktioniert. Stattdessen planen Sie Ad-hoc-Änderungen in viele kleine Unterprojekte.

Ohne das System zu sehen, würde ich wahrscheinlich versuchen, so viel wie möglich im Back-End zu normalisieren und so viel wie möglich von SQL in gespeicherte Procs zu verschieben. Erstellen Sie dann ein neues Frontend entweder aus C # Forms oder einer Webanwendung. Wenn Sie Ihre Geschäftslogik und SQL aus dem Front-End herausholen können, ist es einfacher, sie später erneut auszuführen. Indem Sie Ihre Arbeit an kleinen Projekten beibehalten und diese jederzeit beiseite schieben oder stoppen, haben Sie Fortschritte erzielt, die verwendet werden.

Einige gute Antworten hier bereits - aber ich möchte nur darauf hinweisen, dass (vorausgesetzt, es gibt interne Entwickler) ein relativ geringer Arbeitsaufwand große Auswirkungen hat. Fügen Sie Primärschlüssel hinzu (Sie sollten nicht einmal alle Ihre Abfragen in ändern müssen) Verwenden Sie sie), fügen Sie den von Ihnen verwendeten Feldern Indizes hinzu, optimieren Sie Ihre Abfragen ein wenig, und Sie könnten einen absolut enormen Anstieg feststellen. Kaufen Sie sich jetzt etwas RAM, um die Zeit und den Headroom zu erhalten, die Sie benötigen, um das Problem zu beheben, und dann können Sie arbeiten.

Wenn die Funktionen des Systems im Grunde genommen für Sie funktionieren und das tun, was Sie brauchen, schreiben Sie das Rad nicht um. Wenn Ihre Benutzer turnen müssen, um das Ding zu benutzen, weil es nicht Ihren Bedürfnissen entspricht, dann macht es keinen Sinn, sich Mühe zu geben.

Nun ... das ist jetzt eine Weile her, aber ich dachte, ich würde das Ergebnis hier aufzeichnen.

Am Ende bin ich Zeile für Zeile durch das VBA gegangen, um ein anderes Problem zu lösen. In diesem Moment wurde mir klar, dass einige Aufrufe zum Abrufen von Rowsets für mehr als 20-30 Sekunden blockiert waren.

Als ich mich damit befasste, stellte ich fest, dass das Rowset auf einer MS Access-Abfrage basierte.

Das war die Auswahl von Daten aus einer anderen Access-Abfrage.

Das war die Auswahl von Daten aus einer weiteren Access-Abfrage.

All dies sah aus, als wären sie mit dem Abfrage-Designer per Drag & Drop zusammengefügt worden.

Ich habe das halbe Dutzend Anwenderprobleme durchgesehen und festgestellt, dass sie alle genau gleich waren.

Also habe ich die Stapel verketteter Abfragen vollständig entfernt und durch eine einzelne Pass-Through-Abfrage ersetzt, die in T-SQL geschrieben und direkt auf dem Server ausgeführt werden konnte.

Die Verbesserung war in jedem Fall absolut gewaltig und es gab kein Warten mehr auf Fragen für irgendjemanden.

Und dann habe ich die Firma verlassen. Keine Ahnung, ob es noch da ist ... aber ich vermisse es nicht.

Ich veröffentliche eine separate Antwort, anstatt nur an Daytons Antwort anzuhängen, da die Kosten nicht von den ersten Personen berücksichtigt werden, die eine Antwort veröffentlichen: Die Kosten für die Umschulung der Benutzer und die Kosten für die Anpassung Ihrer Geschäftsabläufe an die Anforderungen ein neues Softwareprogramm. Ansonsten was er gesagt hat.

Einer der Hauptgründe, warum Unternehmen ihre eigene Software entwickeln, ist, dass sie Geschäftsabläufe haben, die nicht mit denen auf dem Markt übereinstimmen. Was großartig ist - die individuellen Geschäftsabläufe eines Unternehmens sind ein wesentlicher Teil des Wertes, den ein Unternehmen mit sich bringt, und SIND der Wettbewerbsvorteil, den ein Unternehmen gegenüber dem Rest seines Marktes hat. Um die Software durch etwas Allgemeines zu ersetzen, müssen Sie Ihre Mitarbeiter neu schulen und den Wettbewerbsvorteil opfern, oder Sie müssen die Lösung an Ihre Geschäftsprozesse anpassen. Beides ist teuer und zeitaufwändig. Als Unternehmensberater und als Systemadministrator habe ich gesehen, dass diese Kosten kleine Unternehmen von selbst töten.

Aus Ihren Aussagen geht hervor, dass Sie ziemlich prozessor- / softwaregebunden sind. Ich würde zwei Dinge tun - Hinzufügen von Indizes (innerhalb von Grenzen), insbesondere zu Spalten, die sie derzeit nicht verwenden. Und ich würde die schnellsten Prozessoren auswählen, die Sie verwenden können, denn anscheinend sind Sie dort gebunden, wenn Sie nicht so viele Laufwerkslesevorgänge zu Spitzenzeiten haben.

(Außerdem würde ich die Server-Edition so weit wie möglich aktualisieren. Wenn Sie diese installieren, sind Access 2000 und SQL Server 2000 zehn Jahre alt. Das ist in Computerjahren ALT!)

Dies erfordert eine vollständige Umstrukturierung (Re-Architecturing). Bauen Sie das System von Grund auf neu auf. Dadurch sparen Sie auf lange Sicht viel (Overhead-Kosten bei der Wartung). In der Zwischenzeit füttere Hardware dran. Ich denke, diese Frage ist eher ein "Business Case" als eine technische Anfrage. Technisch gesehen ist die Antwort ein klares "mehr Kraft darauf geben". Geschäftlich gesehen, baue ein neues System!

Technische Antwort:

Sie haben eine Reihe von Vorschlägen, in denen Primärschlüssel angegeben sind, und die Indizierung sollte gründlich überprüft werden. Access verwendet auch sehr gerne eine SQL Server TimeStamp-Spalte (auch bekannt als RowVersion-Spalte) für jede Tabelle, da Access dadurch viel weniger Zeit für die Entscheidung benötigt, ob ein Datensatz geändert wurde, wenn die Datensätze aktualisiert werden.

Geschäftsantwort:

Eine neue CRM-Lösung ist eine Menge Schulungsarbeit und Sie werden nie mit einem System enden, das genau Ihren Geschäftsanforderungen entspricht.

Ich würde eine gute Access-Person finden, die auch sehr gut mit SQL Server vertraut ist, und sie dazu bringen, 3 oder 6 Monate damit zu verbringen, die Tabellen zu normalisieren und die Probleme der Benutzer zu beheben. Stellen Sie sicher, dass diese Person auf den Saem-Etagen als Benutzer arbeitet, obwohl sie sich in einem ruhigen Raum befindet und zugänglich ist. Obwohl nicht allzu leicht zugänglich. Entwickler mögen keine Unterbrechungen. S

Aufgrund der gegebenen Informationen würde ich das System ersetzen. Am besten mit einem anderen CRM, das eine flexible Integration in andere Systeme ermöglicht (was Ihren ERP-IS gefährden würde ).

Der schwierigste Teil besteht darin, das Management und die Benutzer davon zu überzeugen, dass sie ein Upgrade benötigen.

Verwaltung

Bringen Sie Ihre Bedenken hinsichtlich technischer Probleme, geringer Leistung, Angst vor byzantinischen Ausfällen usw. zum Ausdruck. Stellen Sie anschließend zwei alternative CRMs vor. Sprechen Sie über die Geschäftsintegration, die ERP-Gesamtstrategie für das Unternehmen und vor allem darüber, wie Mitarbeiter dadurch produktiver und profitabler werden. Anwendungsfallstudien. Machen Sie dies nicht länger als 15 Minuten (es sei denn, sie möchten mehr Informationen). Dann müssen Sie die Benutzer überzeugen.

Benutzer

Schulungspläne (die ein Anbieter möglicherweise bereitstellt (und die das Management unterstützen müsste)), kontinuierliche Kommunikation mit den besten 20% Ihrer Benutzer (den Hauptbenutzern, denjenigen, die Probleme verursachen) und eine solide Verpflichtung, das System zu 100% betriebsbereit zu halten für den ersten Monat (der erste Monat wird jeden neuen IS machen oder brechen).

Es gibt eine Vielzahl von CRM-Produkten, wählen Sie eines aus, das Ihren geschäftlichen Anforderungen am besten entspricht.

Wenn Sie Hardware einsetzen, werden nur schlechtere Designs und schlechtere Verwaltungsergebnisse erzielt, bis das System so erbärmlich ist, dass es selbst mit der neuesten und besten Hardware nicht mehr funktioniert. Es ist Zeit, sich eine bessere Implementierung anzusehen. Analysieren Sie zunächst, was erforderlich ist. Erst wenn Sie die Anforderungen vollständig verstanden haben, können Sie nach dem besten Weg suchen, sie umzusetzen. Sobald Sie sicher sind, dass Sie die Anforderungen verstanden haben, sollten Sie sich überlegen, ob es besser / kostengünstiger ist, Ihre vorhandenen Daten zu ändern oder von vorne zu beginnen, möglicherweise mit etwas völlig anderem.

Auf lange Sicht sind Sie wahrscheinlich am besten in der Lage, die Datenbank zu wiederholen. Wenn Sie mehr Hardware einsetzen, wird Ihr Problem für eine Weile gelöst. Wenn Sie es jedoch weiterhin verwenden, müssen Sie nach einer Weile mehr Hardware einsetzen.

Wenn es Leistungsprobleme gibt, müssen Sie in der Regel Dinge wie E / A-Engpässe auf Festplatten / RAID, das Sharding der Datenbank usw. untersuchen. Bei Sharding-Problemen muss die Datenbank jedoch so konzipiert sein, dass sie die Vorteile ausnutzt. Aufgrund der Geräusche wird Ihre Anwendung niemals skalierbar sein.

Auf lange Sicht können Sie die Datenbank und die Front-End-Software so ändern, dass sie Ihre aktuellen Geschäftsanforderungen besser widerspiegeln. Ihre Benutzer werden es Ihnen danken, Ihre Hardware wird länger halten und auf lange Sicht viel mehr Geld sparen als gigantische Hardware.

In Anbetracht Ihrer Beschreibung ist die Schaffung eines völlig neuen, maßgeschneiderten Systems sinnlos - Sie werden dort landen, wo Sie begonnen haben, oder vielleicht sogar schlechter dran als jetzt. Wenn Sie also niemanden davon überzeugen können, eine Lösung eines Drittanbieters zu kaufen, sollten Sie am besten so gut wie möglich umgestalten und Hardware darauf werfen.

Ich würde sagen, dass Sie zwei Dinge tun sollten: 1) Leistungsanalyse auf dem SQL Server. Sie haben anscheinend die Serverseite als Quelle für die Verzögerungen identifiziert. Jetzt müssen Sie wissen, welche Abfragen hinterherhinken und warum. Höchstwahrscheinlich finden Sie einige Hot-Spot-Abfragen zur Optimierung, die Ihnen große Vorteile bringen würden. Wenn Sie Clients haben, die alle paar Sekunden aktualisiert werden, prüfen Sie, ob Sie die Aktualisierungsrate verringern können (Muss die Liste auf dem Bildschirm WIRKLICH alle 5 Sekunden aktualisiert werden? Wäre 30 in Ordnung? Wenn nicht, wie wäre es mit 15? ). Dummes Zeug wie das Erhöhen von Refresh-Timern kann Ihnen viel Overhead ersparen, wenn Sie damit davonkommen können.

2) Wirf mehr Hardware drauf. WIRF INSBESONDERE Unmengen von Widdern darauf. Sie möchten so viel Speicher, dass die Datenbank vollständig in den Arbeitsspeicher passt. Behalten Sie Ihr Betriebssystem und Ihre Softwareversionen im Auge (es gibt anscheinend eine ganze Reihe von Regeln für Windows-Versionen und welche Hardware sie tatsächlich unterstützen). Wenn Sie sich davon überzeugen können, dass mehr Kerne helfen würden, werfen Sie so viele CPUs und Kerne, wie Sie können.

Sie haben RAM und Prozessoren erwähnt, aber keine Festplatten. Ich gebe zu, es ist fast ein Jahrzehnt her, seit ich mich mit dem SQL Server von MS befasst habe, aber er ist genauso an die Datenträger gebunden wie jede andere Datenbank, wenn nicht alles in den Speicher passt.

Ich würde wahrscheinlich zuerst versuchen, den Computer mit so viel RAM wie möglich zu füllen. Dann würde ich sicherstellen, dass die Protokolle auf Datenträger geschrieben werden, die nicht für Tabellen oder Indizes verwendet werden. Ich würde dann versuchen, sicherzustellen, dass keine Tabellen ihre Indizes auf der gleichen Spindel haben.

Danach würde ich mich um die Optimierung auf Datenbankebene kümmern, aber dann müssen Sie Ihre Tests und ein Optimierungsziel definieren, damit Sie nichts kaputtmachen oder Abfragen verschlimmern. Obwohl Sie sagten, dass die Primärschlüssel in Ihrer Testdatenbank keinen großen Vorteil zeigten, sollten Sie sich Ihre Testmethode ansehen. Mit Primärschlüsseln können einige Datenbanken (die nicht sicher sind, ob MS SQL einer von ihnen ist) das Sperren auf Datensatzebene verwenden Dies kann Konflikte reduzieren, die beim Testen mit nur wenigen Benutzern möglicherweise nicht angezeigt werden.

Zunächst stimme ich Kyle Hodgson zu und füge PKs hinzu. Es ist billig (nur Zeit) und Sie sehen möglicherweise einen Schub bei Ihren Abfragen. Was ist mit den Indizes für Join-Spalten in Ihren 10 hässlichsten Abfragen? Wo sind die Tischscans?

Zweitens, wie sieht es mit dem Zuschneiden von Daten in der Datenbank aus? Werden in den Abfragen mehr Zeilen zurückgegeben, als wirklich benötigt werden? Ich stimme auch Kyles Vorschlag von RAM (zwei weitere GB) zu.

Schreiben Sie all dies in Ihren Bericht (Joseph Kern) darüber, was Sie für die Zwischenzeit vorschlagen, während Sie die Zukunft planen. Fragen Sie das Management und die Benutzer, was mit der Organisation passiert, wenn die aktuelle CRM-App nicht verfügbar ist. Vielleicht hilft das ihnen, über die Zukunft nachzudenken.

Holen Sie sich die Hardware!

Zinn ist im Moment nicht nur sehr billig, wenn Sie sich für einen Chip der Xeon 55xx-Serie entscheiden, wird er nach allem schreien, was Sie darauf werfen können.

Es ist nur eine Risiko- / Belohnungssache - Sie können Geld und viel Zeit darauf verwenden, die DB zu verbessern oder sich schneller und billiger dorthin zu begeben.

Ziehen Sie in Betracht, den 3- GB-Speicherschalter umzudrehen und weitere 2 GB Speicher hinzuzufügen.