Kürzlich haben wir mit einem Client zusammengearbeitet, um Probleme mit einer SQL Server-Instanz zu beheben. Der Client hat SQL Server 2012 auf einem virtuellen Computer ausgeführt. Bei den auf dem SQL Server ausgeführten Anwendungen traten Probleme auf, und der Client war sich nicht sicher, was die Ursache der Probleme war.
Zunächst haben wir die Webanwendungsüberwachung mit dem Client eingerichtet, um Warnungen zu senden, wenn die Webanwendung langsamer als normal ausgeführt wird, sodass wir das nächste Mal, wenn ein Problem auftritt, darüber informiert werden. Durch Festlegen eines Timeoutschwellenwerts für die Seitenladegeschwindigkeit konnten wir verschiedene Zeiträume identifizieren, in denen das System ein Problem beim Zugriff auf Daten vom SQL-Server zu haben schien. Mit den integrierten Benachrichtigungen haben wir E-Mails erhalten, sobald ein Problem erkannt wurde.
Als Nächstes wollten wir die SQL Server-Überwachung einrichten, daher haben wir dem Client geholfen, den MetricsView-Agent zu installieren, um Windows-Leistungsindikatordaten vom SQL-Server zu sammeln. Nach der erfolgreichen Installation des MetricsView-Agenten konnten wir alle Daten sammeln, die von Windows-Leistungsindikatoren gemeldet werden, einschließlich SQL Server-Nutzung, Prozessorauslastung, Bandbreitennutzung, Speicherzuweisung und Verfügbarkeit von Festplattenspeicherplatz.
Als wir alle diese Metriken überwachten, haben wir maximale und minimale Schwellenwerte für jeden Datensatz eingerichtet, sodass wir benachrichtigt werden, wenn eine der kritischen Metriken die erwarteten Grenzen überschreitet. Was wir fast sofort herausfanden, war, dass es sich in der Tat überhaupt nicht um ein SQL-Problem handelte, sondern um ein einfaches Problem mit der Art und Weise, wie der virtuelle Server erstellt und die Festplatten partitioniert wurden.
Dieser spezielle Client hatte zwei Partitionen auf dem Laufwerk erstellt, die erste für einfach das Betriebssystem und das zweite Laufwerk war für die Datenspeicherung. Was wir schnell festgestellt haben, war, dass das Betriebssystemlaufwerk noch einige SQL-Protokolle auf dem Datenlaufwerk hatte, die eigentlich auf dem Datenlaufwerk hätten gespeichert werden sollen, und die SQL-Protokolle verursachten, dass das Laufwerk seine Kapazität traf. Der Benutzer hatte mehrere Optionen, um dieses Problem zu beheben. Sie können die Partition des virtuellen Laufwerks erhöhen, je nachdem, ob es als dynamisches Laufwerk eingerichtet wurde, oder sie können ihre SQL-Servereinstellungen ändern, um die Protokolle auf dem Datenlaufwerk zu speichern, und die automatische Kürzung der Protokolle nach einem bestimmten Zeitraum einrichten.
Die Tatsache, dass wir mehrere Komponenten der Dotcom-Monitor-Tools nutzen konnten, um dem Client zu helfen, das Problem zu lokalisieren, spricht Bände über die Fähigkeit von Dotcom-Monitor, über die einfache Überwachung der Betriebszeit/Ausfallzeiten hinauszugehen, die wir vor über 15 Jahren begonnen haben. Die Tools wurden wirklich weiterentwickelt, um Tools zur Fehlerbehebung und Anleitungen zur Leistungsoptimierung zu enthalten, mit denen Sie einen vollständigen 360-Grad-Überblick darüber erhalten können, wie Ihre Infrastruktur funktioniert und wie sie sich auf Ihre Websites und Webanwendungen auswirkt.
Registrieren Sie sich jetzt für eine kostenlose 30-Tage-Testversion, um Webanwendungen und Websiteszu überwachen, von der Hardware über das Netzwerk bis hin zur tatsächlichen Reaktionsfähigkeit von SQL-Servern und jeder Seitenlast von Dutzenden von Standorten auf der ganzen Welt.
