Wir haben kürzlich unsere SharePoint 2007-Datenbank von einem SQL 2000-Server auf einen 2008 x64 SQL-Server verschoben. Alles scheint in Ordnung zu sein, aber es gibt ein Problem, bei dem der SQL-Server nicht mehr läuft und der Dienst neu gestartet werden muss. Die Fehler erwähnen unzureichenden internen Speicher usw. Ich habe versucht, die Datenbank mit -g384 zu starten, was die Standardeinstellung in SQL 2000 ist, aber 256 ist meines Wissens die Standardeinstellung für 2008. Das hat das Problem nicht behoben. Mir wurde gesagt, dass das Problem vielleicht durch ein Upgrade auf WSS 3.0 SP2 behoben werden könnte, aber als ich versucht habe, dies zu installieren, habe ich nach dem SP2-Update einen weiteren Fehler erhalten und muss auf einen VM-Snapshot zurückgreifen. Der Fehler nach dem Service Pack ist Serverfehler:http://go.microsoft.com/fwlink?LinkID=96177 Ich habe also ein paar Fragen: Wie kann ich das erste und das zweite Problem beheben? Ich habe viele Foren und Beiträge durchgesehen und ein paar Dinge ausprobiert, aber es hat immer noch nichts gebracht. Jede Hilfe wäre großartig.
UPDATE: Ich habe den Serverfehler behoben:http://go.microsoft.com/fwlink?LinkID=96177ich musste sowohl WSS SP2 als auch Office Server SP2 ausführen, dann funktionierte der Konfigurationsassistent und dann die Moss-Konfiguration. Die Fehler, die ich in SQL bekomme, sind
SQL Server konnte eine neue Systemaufgabe nicht ausführen, entweder weil nicht genügend Arbeitsspeicher vorhanden ist oder die Anzahl der konfigurierten Sitzungen die maximal zulässige Anzahl auf dem Server überschreitet. Überprüfen Sie, ob der Server über ausreichend Arbeitsspeicher verfügt. Verwenden Sie sp_configure mit der Option „Benutzerverbindungen“, um die maximal zulässige Anzahl von Benutzerverbindungen zu überprüfen. Verwenden Sie sys.dm_exec_sessions, um die aktuelle Anzahl von Sitzungen, einschließlich Benutzerprozessen, zu überprüfen.
Beim Senden von Daten an den Client ist ein Lesevorgang für ein großes Objekt fehlgeschlagen. Eine häufige Ursache hierfür ist, dass die Anwendung auf der Isolationsebene READ UNCOMMITED ausgeführt wird. Die Verbindung wird beendet.
Im Ressourcenpool „intern“ ist nicht genügend Systemspeicher vorhanden, um diese Abfrage auszuführen.
Diese Fehler werden von einem Benutzer verursacht, der als Dienst für SharePoint erstellt wurde.
Antwort1
Ich habe herausgefunden, dass der Server alle 4 GB RAM verwendet hat, kurz bevor der SQL Server-Dienst gestoppt wurde. Also habe ich ihn heruntergefahren (er ist virtuell) und 4 GB RAM hinzugefügt, sodass er insgesamt 8 GB hat. Er läuft jetzt seit 2 Tagen und es gibt keinen Fehler im Protokoll (toi, toi, toi). Aber ich habe bemerkt, dass der Server während der Zeit, in der der Ausfall normalerweise auftritt, 4 GB RAM erreicht hat.
Ich beobachte also weiterhin und veröffentliche die Ergebnisse.
Das Problem wurde dadurch nicht behoben. Als ich 8 GB SQL eingegeben habe, wurden nur 8 GB verwendet.
Ich weiß nicht, was ich sonst noch versuchen soll. Ich denke, es ist Zeit für einen SQL-Guru
Antwort2
Welche konkrete Fehlermeldung erhalten Sie im SQL-Fehlerprotokoll, wenn das Programm abstürzt und herunterfährt?
Wie viel Speicher ist im Server? Für wie viel Speicher ist SQL konfiguriert? Wie groß sind die Datenbanken? Wie viele SharePoint-Benutzer gibt es?
Antwort3
Können Sie sich mit der dedizierten Administratorverbindung (Backdoor-Methode für Verbindungen mit einem hängenden/nicht reagierenden Server – verwenden Sie SQLCMD -A) anmelden, wenn es erneut passiert, und sehen, wie viele Verbindungen bestehen?
Verwenden Sie das folgende T-SQL:
SELECT loginame, count (*) AS Connections
FROM master.dbo.sysprocesses (nolock)
GROUP BY loginame
ORDER BY loginame;
GO
Sie möchten wahrscheinlich auch den Produktsupport anrufen, der Ihnen schneller helfen kann als dieses Forum.
Danke
Antwort4
Verliert auch der IIS-Server Speicher oder nur der SQL-Server-Rechner? Ist der Ausfall des SQL-Dienstes von der SP-Nutzung abhängig?