Benutzer mit den meisten Antworten
sporadisch Fehler 18456 Schweregrad: 14 Status: 38 bei verschiedenen Benutzern und verschiedenen Datenbanken

Frage
-
Guten Tag,
bevor ich hier schreibe, habe ich ca. 4 Wochen alle erdenklichen "Lösungen" die Google liefern kann, versucht. Erfolglos. Auch die hier im Forum angebotenen Schritte haben wir, soweit möglich, abgearbeitet.
Das Problem:
Wie oben schon geschrieben, haben wir den Fehler Protokoll), leider aber bei verschiedenen Beutzern und verschiedenen Datenbanken. Anbei ein etwas abgeändertes Log (Datenschutz):
05/12/2014 14:03:27,spid73,Unbekannt,Starting up database 'db_1'.
05/12/2014 14:02:26,spid58,Unbekannt,Starting up database 'db_1'.
05/12/2014 14:01:23,spid54,Unbekannt,Starting up database 'db_1'.
05/12/2014 14:01:22,,Unbekannt,Login failed for user 'user_1'. Ursache: Fehler beim Öffnen der explizit angegebenen Datenbank. [CLIENT: 192.168.99.101]
05/12/2014 14:01:22,,Unbekannt,Fehler: 18456<c/> Schweregrad: 14<c/> Status: 38.
05/12/2014 13:51:19,spid71,Unbekannt,Starting up database 'db_1'.
05/12/2014 13:51:13,spid69,Unbekannt,Starting up database 'db_1'.und noch viel häufiger:
05/12/2014 16:48:36,spid53,Unbekannt,Starting up database 'db_2'.
05/12/2014 16:48:19,,Unbekannt,Login failed for user 'sa'. Ursache: Fehler beim Öffnen der explizit angegebenen Datenbank. [CLIENT: 192.168.99.100]
05/12/2014 16:48:19,,Unbekannt,Fehler: 18456<c/> Schweregrad: 14<c/> Status: 38.
05/12/2014 16:45:24,spid53,Unbekannt,Starting up database 'db_2'.
05/12/2014 16:41:54,spid53,Unbekannt,Starting up database 'db_2'.Zunächst haben wir uns lange an der Fehlermeldung mit db_2 aufgehalten. Der Fehler tritt- wie gesagt - sporadisch auf!
Zum Server: es handelt sich um einen SBS 2011 SP1, der SQL-Server ist Version 10.50.1600. Der Server hat 8 Kerne und 16 GB Ram, wovon ca.. 13 GB in Nutzung sind. Die Last hält sich bei 2-20 % - eher im unteren Bereich.
Der Zugriff bei db_2 erfolgt über den User 'sa'. Da das Programm dahinter das meistgenutzte Programm ist, haben wir lange (auch mit Hilfe des Herstellers) versucht, den Fehler beim User 'sa' oder beim Programm zu finden. Gestern dann der Schock: der Fehler tritt auch bei einer anderen Software auf, welche mit dem "user_1" eine Verbindung aufbaut. Beide Programme nutzen die Benutzerauthentifizierung, der Server akzeptiert jedoch beide Varianten.
Logge ich mich mit Benutzer 'sa' im Managementstudio ein, habe ich vollen Zugriff auf die Datenbank "db_2".
Für die Anwender äußert sich der Fehler so, dass das Programm hängen bleibt, und nach 5-10 sek. normal weiter läuft, als wenn nichts gewesen wäre.
Für mich macht es den Eindruck, als ob die Datenbanken zeitweise nicht erreichbar wären. Wie kann man so etwas tracken?
Ich bin dankbar für jede Hilfe.
Antworten
-
Ich würde erst mal das Auto_Close bei den Datenbanken abschalten:
USE [master] GO ALTER DATABASE [dbname] SET AUTO_CLOSE OFF WITH NO_WAIT; GO
Dann mal schauen, ob der Fehler noch auftritt.
Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu- Als Antwort vorgeschlagen Elmar Boye Dienstag, 13. Mai 2014 14:34
- Als Antwort markiert Christoph MuthmannEditor Freitag, 23. Mai 2014 08:28
Alle Antworten
-
Ich würde erst mal das Auto_Close bei den Datenbanken abschalten:
USE [master] GO ALTER DATABASE [dbname] SET AUTO_CLOSE OFF WITH NO_WAIT; GO
Dann mal schauen, ob der Fehler noch auftritt.
Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu- Als Antwort vorgeschlagen Elmar Boye Dienstag, 13. Mai 2014 14:34
- Als Antwort markiert Christoph MuthmannEditor Freitag, 23. Mai 2014 08:28
-
Anderes Thema:
Der User sa hat hier überhaupt nichts zu suchen und sollte dringend durch irgendeinen anderen Account mit weniger Rechten abgelöst werden.Einen schönen Tag noch,
Christoph
--
Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu -
Hallo,
ist die Thematik abgeklärt?
Gruss,
RaulRaul Talmaciu, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können. -
Hallo,
hier die versprochene Rückmeldung, wenn auch etwas spät.
Wir haben also die db_2 über den Punkt Optionen auf Auto_Close = False gesetzt. Ab diesem Augenblick kam innerhalb der letzten Woche keine einzige Fehlermeldung (siehe oben) mehr. Insofern vielen Dank für diesen Tipp. Auch bei der db_1 haben wir die hier weit seltener auftretende Fehlermeldung nicht mehr im Log. Ich habe mich nun belesen, was und wofür diese Einstellung gut ist.
Bleibt für mich die Frage, ob diese Einstellung Auswirkungen auf den Betrieb hat:z.B. für das Backup oder aber auch die Datensicherheit im Falle eine Systemcrashs (ob nun Stromausfall - USV ist vorhanden, keine Angst- oder ein klassischer Softwareabsturz). Bei Acces-Datenbanken haben wir da schon sehr schlechte Erfahungen gemacht, wenn Datenbanken permanent geöffnet sind. Kann man es eventuell so einstellen, dass nach einer bestimmten Zeit die DB geschlossen wird, sagen wir 1 Stunde?
Auf jeden Fall möchte ich mich wirklich bedanken für die Hilfe hier.
Mit freundlichem Gruß
KSYH
-
Hallo,
Das Schließen einer Datenbank hat keinerlei Sicherheitshintergrund (und kann sie nicht verbessern).
Eine Datenbanksicherung (über BACKUP) kann im laufenden Betrieb gemacht werden (und dabei ist die Datenbank geöffnet). Die Sicherung vor Abstürzen erfolgt durch das Transaktionsprotokoll. Und dieses sollte ebenso periodisch (in kurzen Abständen) gesichert werden.
Die Option Automatisch schließen sollte bei genutzten Datenbanken generell auf aus stehen. Sie zu aktivieren kann bestenfalls für sehr selten genutzte Datenbanken sinnvoll (wenn der Server sehr unterdimensioniert ist), um Ressourcen zu sparen.
Offizielle Empfehlung siehe auch:
Recommendations and guidelines for setting the AUTO_CLOSE database option in SQL Server
Best Practice recommendations for SQL Server Database Backups
Gruß Elmar