none
1. Hilfe - SQL-Server mit speicheroptimierten Tabellen startet ewig nicht

    Frage

  • Für einen gemeinnützigen Jugendverband / NGO mit nachgeordneten Landesverbänden administriere ich ehrenamtlich einen Windows Server 2012 R2, auf dem ein SQL Server 2017 Express läuft. Die Datenbanken beinhalten speicheroptimierte Tabellen und auch nativ kompilierte Stored Procedures, sowie "normale" SPs.

    Gestern Abend / Nacht hat nun Windows ein automatisches Update auf dem Server eingespielt und anschließend einen Neustart des Systems erzwungen. Ich weiß nicht genau was dabei nicht geklappt hat - auf jeden Fall gibt es jetzt ein Problem beim Start des SQL-Servers.

    Zwar wird im Server-Manager der Dienst korrekt als gestartet angezeigt - die Systemleistung (CPU) wird aber zu knapp 70 % für den SQL-Server-Dienst verbraucht. Das System hat 64 GB RAM und ist damit eigentlich gut speichermäßig ausgestattet. Mir ist auch klar, dass der Start der speicheroptimierten Datenbanken (es sind ca. 8 Stück mit jeweils vielleicht 15 Tabellen) auch seine Zeit benötigt. Aber man merkt vom Speicherverbrauch auch keine Änderung bzw. kein laden der speicheroptimierten Datenbanken.

    Normalerweise brauchte der SQL-Server so 1 GB RAM. Seit Umstellung auf die speicheroptimierten Tabellen zog er ca. 5 GB RAM (was ja auch so gewollt war, weil ausreichend Speicher vorhanden ist und die Tabellen dort reingeladen wurden). Jetzt zeigt der Taskmanager nur einen Speicherverbrauch von ca. 1.3 GB an und irgendwie weiß ich jetzt auch nicht weiter, wo genau das Problem jetzt steckt.

    Weiß jemand, ob man als NGO von Microsoft vergünstigt Supportleistungen einkaufen kann? Ich glaube, dass sich das ein echter Profi mal angucken sollte.

    Freitag, 11. Mai 2018 06:33

Alle Antworten

  • Hallo,

    Der SQL Express hat eine technische Beschränkung von 1 GB RAM. Mehr darf der SQL Server nicht nutzen. Wenn er eine speicheroptimierte Tabelle laden will die größer ist als 1 GB wird der Start der Datenbank scheitern.

    https://docs.microsoft.com/de-de/sql/sql-server/editions-and-components-of-sql-server-2017?view=sql-server-2017

    Die Größe der In-Memory OLTP-Daten und des Columnstore-Segmentcaches sind auf die Größe des Arbeitsspeichers beschränkt, die von der Edition im Bereich Kapazitätsgrenzen festgelegt wird. Den maximale Grad an Parallelität ist beschränkt. Der Grad an Prozessparallelität (Degree of Parallelism, DOP) für eine Indexerstellung ist auf 2 DOP für die Standard Edition und auf 1 DOP für die Web und die Express Edition beschränkt. Dies gilt für Columnstore-Indizes, die über datenträgerbasierte Tabellen und speicheroptimierte Tabellen erstellt wurden.


    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012 


    Freitag, 11. Mai 2018 06:45
  • Also alle Datenbanken sind weit unter der Grenze von 1 GB RAM. Vor dem Windows-Update liefen die Datenbanken daher auch problemlos.

    Zwischenzeitlich konnte ich mich auch erfolgreich im Server Management Studio anmelden. Dort steht bei allen Datenbanken "Wird wiederhergestellt". Mein Eindruck ist, dass er gerade alle 12 Datenbanken auf einmal wiederherstellen will. Jede Datenbank an sich ist zwar eher klein (die Sicherung der Datenbank verbraucht ca. 100 MB) - aber in der Summe scheint es extrem langsam oder gar nicht vorwärtszugehen.

    Ich würde gerne eine Datenbank nach der anderen schrittweise wiederherstellen lassen. Allerdings kann ich die Datenbanken auch nicht mehr offline schalten. Hier kommt der Hinweis, dass die Datenbank gerade wiederhergestellt wird.

    Die Frage ist jetzt, ob man irgendwie den SQL-Server zwingen kann, den Wiederherstellungsprozess zu beenden. Wenn ich das schrittweise für jede Datenbank durchführe, dann sollte es funktionieren - aber alle DB gleichzeitig blockiert scheinbar nur das System.

    Freitag, 11. Mai 2018 07:31
  • Wie Groß die einzelnen Datenbanken sind ist unerheblich wenn die Summe der speicheroptimierten Tabellen in den Datenbanken über 1 GB ist. 

    Wenn die Datenbanken laufen kann es passieren, dass die Tabellen über die 1. GB Grenze wachsen, dies wird dann beim nächsten Neustart der Instanz den Start der Datenbanken verhindern. 

    Es spielt keine Rolle ob du die Datenbanken nach einander startest oder gleichzeitig. Du wirst in jedem Fall an diese Grenze scheitern.

    Entweder musst du die speicheroptimierten Tabellen entfernen oder jede Datenbank in eine eigenen Instanz legen.

    Du kannst versuchen den SQL Server im Einzelbenutzermodus zu starten und die Datenbanken offline zu nehmen. Ich weis aber nicht ob beim normalen Neustart die Datenbanken noch Offline bleiben. https://docs.microsoft.com/de-de/sql/database-engine/configure-windows/start-stop-pause-resume-restart-sql-server-services?view=sql-server-2017


    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Freitag, 11. Mai 2018 07:46
  • Mmm - ich meine ich hatte die Frage irgendwo anders schon gestellt, ob die 352 MB-Grenze pro speicheroptimierte Datenbank "on top" auf die 1-GB-RAM-Beschränkung dazukommt und hier war die Auskunft (ich meine sogar von einem Mitarbeiter von MS), dass dem so wäre:

    https://www.microsoft.com/de-de/sql-server/sql-server-2017-editions

    Für mich spielt es gerade aber eine untergeordnete Rolle. Denn eine Fehlermeldung wird mir nicht angezeigt, wonach diese Speichergrenze ein Problem wäre. Ich muss jetzt irgendwie mit dem aktuellen Problem klarkommen und sei es, dass ich erst mal die Verbände wieder an den Start bekomme, die am dringendsten mit der Datenbank arbeiten müssen. Die anderen kann ich bis auf Weiteres deaktivieren.

    Das Problem ist aber, dass der SQL-Server mir weder das Offline-Stellen von Datenbanken noch das Entfernen von Datenbanken erlaubt. Jeweils mit dem Hinweis, dass die Datenbank erst wiederhergestellt wird und dann entfernt werden kann. Das ist natürlich widersinnig für mich - denn wenn die Wiederherstellung abgeschlossen wäre, dann bräuchte ich ja kein Offlinestellen mehr.

    Ich schau mir aber einmal den Einzelbenutzermodus an.

    Freitag, 11. Mai 2018 08:38
  • Also so ganz versteh ich den verlinkten Text zum Einzelbenutzermodus nicht. Wie kann ich das mit dem Server Management Studio in diesem Modus starten? Es steht zwar dran, dass man es wohl über diesen Weg machen kann - aber wie?

    Ich hab versucht als Startparameter im Fenster mit der Verbindung noch "-m" anzuhängen. Geht aber nicht.

    Freitag, 11. Mai 2018 08:51
  • Du musst den Dienst des SQL Server zuerst beenden. Danach kannst du den Dienst über eine CMD oder Powershell mit Adminrechten starten 

    net start "Instanzname" /f /m

    Oder du gehst über den SQL Server Konfiguration Manager und fügst bei dem Dienst unter Startparameter den -m hinzu und startest dann den Dienst neu. Du kannst dich nicht wie üblich mit dem SSMS auf den SQL Server verbinden, da dabei zu viele Verbindungen hergestellt werden. Starte das SSMS ohne dich mit der Instanz zu verbinden und öffne dann eine neue Abfrage und verbinde diese mit der Instanz.

    Dort drin kannst du die DBs versuchen Offline zu schalten oder sie aus der Instanz zu entfernen (trennen ohne zu löschen).

    USE [master]
    GO
    ALTER DATABASE [test] SET  SINGLE_USER WITH ROLLBACK IMMEDIATE
    GO
    USE [master]
    GO
    EXEC master.dbo.sp_detach_db @dbname = N'test', @skipchecks = 'false'
    GO

    Hier ein Beispiel für die Datenbank Test


    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Freitag, 11. Mai 2018 09:08
  • Gehen wir mal davon aus, dass Du eine aktuelle Sicherung aller Datenbanken hast.

    Dann könnte man den SQL Server Dienst beenden und die mdfs und ldfs der Datenbanken mal temporär in ein anderes Verzeichnis schieben.

    Danach neu starten und schauen, ob der Server alleine mit den Systemdatenbanken startet. Die Benutzerdatenbanken stehen dann alle nicht zur Verfügung.

    Dann könnte man probieren eine Datenbank wieder an den richtigen Ort zu kopieren (Hier würde ich dann nicht verschieben) und die Datenbank anzuhängen (attach). Oder Alternativ aus dem aktuellen Backup wiederherstellen.

    Dann sollte man mehr sehen können.


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Freitag, 11. Mai 2018 09:55
  • Eine aktuelle Sicherung von gestern Vormittag ist vorhanden. Ich werde es mal wie von Dir beschrieben versuchen und falls nichts mehr hilft, dann muss ich tatsächlich nochmal alle Sicherungen einspielen.

    Funktioniert es denn alleine mit den mdfs und ldfs, wenn es sich um speicheroptimierte Tabellen handelt? Ich dachte, dass die Daten irgendwie anders gespeichert werden...

    Grundsätzlich ist für mich auch die Frage, ob es einen MS-Partner gibt, der speziell für das Thema "speicheroptimierte Tabellen" im Fall eines Problems einen (kostenpflichtigen) Support bieten kann?

    Einen Kontakt zu einer Firma, die sich speziell mit MS SQL-Server auskennt habe ich bereits - allerdings hat man dort abgewunken, als ich mit meinen speicheroptimierten Tabellen gekommen bin. Das haben die noch nie gemacht bzw. mal kurz reingeschaut und dann sein lassen (zu wenig Vorteil für die Kunden). Irgendwo in Deutschland muss es aber ja vermutlich ein Unternehmen geben, dass sich damit speziell auskennt. Vielleicht ist das für so jemanden eine kurze Sache und dann zahlt man halt einen Betrag für die Supportleistung.

    Freitag, 11. Mai 2018 12:27
  • Ganz spontan fallen mir da

    Uwe Ricken http://www.db-berater.de/

    oder 

    Andreas Wolter http://www.sarpedonqualitylab.com/

    ein.


    Benjamin Hoch
    MCSE: Data Platform & Data Management and Analytics
    MCSA: SQL Server 2012/2014 & 2016 DB Administration
    MCSA: Windows Server 2012

    Freitag, 11. Mai 2018 12:36
  • Vielen Dank für die Links. Werde mich dort gleich mal melden.
    Freitag, 11. Mai 2018 13:01
  • Hallo,

    ich würed auch mal einen Blick ins SQL Server ErrorLog werfen, ob dort irgendwelche Hinweise stehen: Anzeigen des SQL Server-Fehlerprotokolls (SQL Server Management Studio)


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Montag, 14. Mai 2018 05:52
  • Also so richtig weitergeholfen hat leider keiner der Tipps. Der SQL-Server war vollständig durch den Modus der "Wiederherstellung" der In-Memory-Tabellen der Datenbanken blockiert. Man konnte keine Datenbank mehr trennen, löschen oder sonstwie diesen Prozess unterbrechen. Es wurde jeweils der Hinweis angezeigt, dass erst die Wiederherstellung abgewartet werden muss. Das war natürlich widersinnig, weil eine Datenbank, die ich lösche, natürlich nicht mehr wiederhergestellt werden bräuchte.

    Nach mehreren Stops des SQL-Servers Neustarts und anderen vergeblichen Versuchen dann plötzlich das unerwartete Ende: ohne ersichtlichen Grund klappte die Wiederherstellung plötzlich und alle Datenbanken wurden erfolgreich geladen. Der Speicherverbrauch stieg wieder auf die vorherigen 4 GB RAM an - ein Zeichen, dass alle In-Memory-Tabellen geladen wurden.

    Danke trotzdem für die vielen Tipps und das Mitdenken in der Sache. Ich hoffe einfach, dass der Zustand nicht noch einmal eintritt - denn ich wüsste dann wieder nicht, wie ich es lösen kann.


    • Bearbeitet Stefaktiv Montag, 14. Mai 2018 14:52
    Montag, 14. Mai 2018 14:50
  • Trifft zwar nicht ganz auf Deinen Fall zu, aber vielleicht hilft das neue CU trotzdem: FIX: In-Memory OLTP database takes a long time to recover in SQL Server 2017

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Freitag, 18. Mai 2018 13:43
  • Ich werde es auf jeden Fall im Hinterkopf behalten. Der Windows Server 2012 R2 meldet mir nämlich wieder ein Update: "Vorschau des monatlichen Qualitätsrollups für Windows Server (KB4103724)". Bin aufgrund der Erfahrung mit dem letzten Update sehr vorsichtig.

    Ggf. ist es eine sinnvolle Idee, dass ich vor dem Update alle Datenbanken offline stelle? Dann kann ich nach dem Neustart des Servers die Datenbanken einzeln selber wieder online stellen.

    Montag, 21. Mai 2018 06:50
  • Da leider nicht sicher ist, was genau geschehen ist, kann man nicht ausschließen, dass das noch einmal passiert. Auch ein Online schalten könnte dann ähnlich lange dauern. Ohne Analyse kann man halt vieles vermuten.

    Auf dem aktuellsten Stand zu sein ist aber sicher eine gute Idee-

    Leider ist die In-Memory Engine durchaus noch etwas buggy. Und wenn dort etwas passiert, dann hat das oft schnell große Auswirkungen. Das ist in der Architektur begründet. Ein Fast oder Partial Recovery wünsche ich mir da schon lange..

    viel Erfolg

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform MCSE Data Platform
    MCSM Charter Member, MCITP Charter Member etc.
    www.SarpedonQualityLab.com
    (Founder)

    Donnerstag, 24. Mai 2018 21:42
  • Schon seit einigen Tagen wurde mir im Server ein empfohlenes Update ("Vorschau auf Qualitätsrollup" oder so) angezeigt. Aufgrund meiner schlechten Erfahrungen mit dem Neustart war ich sehr vorsichtig und hab mich nicht richtig rangetraut.

    Jetzt hab ich es durchgezogen und dabei folgende Schritte berücksichtigt:

    1. Backup erstellen (wird automatisch gemacht - der Vollständigkeit halber sei es erwähnt)
    2. Alle In-Memory-Datenbanken einzeln auf "Offline" geschalten
    3. SQL Server angehalten dann gestoppt. Startoption auf "manuell"
    4. Update durchgeführt - Server neu gestartet
    5. Erst alle Dienste gestartet und gewartet, bis der Server im neutralen Status war
    6. SQL Server-Dienst gestartet
    7. Alle In-Memory-Datenbanken einzeln auf "Online" geschalten. Dabei jeweils auf die CPU-Auslastung geachtet (war nie mehr als sehr kurzzeitig 20 %)
    8. Datenbanktests - alles läuft wie gewünscht

    Der Unterschied war wirklich das Offline-schalten aller Datenbanken. Das Problem beim letzten Mal lag wohl wirklich daran, dass der SQL-Server gleichzeitig zu viele Datenbanken wiederherstellen wollte. Das ging nicht. nacheinander hat es tadellos geklappt - der Server hat auch nicht sonderlich lange gebraucht, bis er eine einzelne Datenbank wieder online genommen hat.

    Ist das ggf. einfach noch ein "Bug" im Server enthalten? Wenn mehrere In-Memory-Datenbanken automatisch wiederherstellt werden müssen, dann sollte die Kiste einfach nacheinander schrittweise arbeiten. In der Summe war die Sache in 5 Minuten Zeitdauer erledigt.

    Interessant war bei der Gelegenheit auch die RAM-Nutzung zu beobachten. Der SQL-Server Express hatte vor dem Update 9 GB RAM verwendet - danach waren es noch 3 GB.

    Sonntag, 3. Juni 2018 07:02
  • Das kann man alles gut vermuten.

    Nicht umsonst gab es gerade einen Hotfix zu dem Thema Recovery bei vielen Objekten.

    Wirklich zu einem Ergebnis wird man ohne eine echte Analyse aber nicht kommen.

    Man müsste mindestens mal die Errorlogs von dem Problemfall sehen, und idealerweise die Wait-Stats aus dem Zeitraum. Dann kann man es eingrenzen.

    Und wenn es reproduzierbar ist, kann man auch einen Case eröffnen.


    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform MCSE Data Platform
    MCSM Charter Member, MCITP Charter Member etc.
    www.SarpedonQualityLab.com
    (Founder)

    Montag, 4. Juni 2018 09:46
  • Kurze Rückmeldung, nachdem zwischenzeitlich mehrfach ein Neustart notwendig war: über den Weg mit dem Offline-schalten der Datenbanken ging es jedes Mal. Interessanterweise war es aber manchmal nicht möglich, dass eine der mehreren Datenbanken offline geschalten wurde (jeweils unterschiedliche Datenbanken - kein Muster erkennbar). Die anderen konnte man ganz normal offline schalten und wenn dann nur noch eine im Status "versuche offline zu schalten" war, dann konnte ich den SQL-Server dennoch pausieren, stoppen und den Server neu starten. Die eine problematische Datenbank wurde dann in annehmbarer Zeit wiederherstellt und alle anderen offline geschaltenen Datenbanken konnten wieder normal aktiviert werden.

    Das ist zwar keine tolle Lösung - aber einmal in 1 oder 2 Monaten geht es schon so.

    Montag, 16. Juli 2018 08:10
  • Jetzt hat es uns doch wieder erwischt... ganz unverhofft hat Avira ein Update für den Virenscanner eingeschoben, dass (warum auch immer) den SQL Server Dienst geschlossen hat. Ggf. hängt es mit den Problemen zusammen, die das Neuste Update von MS mit Avira (und anderen Virenscannern) hat: https://support.microsoft.com/de-de/help/4493446/windows-8-1-update-kb4493446

    Ich kann nur mutmaßen, dass das Avira-Update Ausfluss der Aussage "Wir untersuchen dieses Problem aktuell gemeinsam mit Avira und werden so bald wie möglich ein Update bereitstellen. " sein kann.

    Fakt ist, dass der "Datenbanken offline nehmen"-Trick hier nicht mehr funktioniert hat - schließlich passierte alles ohne Vorwarnung. Jetzt sitz ich wieder hier und komm nicht weiter.

    Eine kleine Hilfe war das starten des SQL Servers im abgesicherten Modus über die Kommandozeile:
    NET START MSSQL$Instanz /f /T3608

    Danach konnte ich mich mit dem SQL Server verbinden:
    SQLCMD –S Instanz

    Zuletzt war ich schon euphorisch, weil mit

    ALTER DATABASE [Datenbankname] SET OFFLINE WITH ROLLBACK IMMEDIATE

    tatsächlich ein paar Datenbanken offline gingen. Allerdings ging es nur so lange, bis ich zur ersten Datenbank kam, die sich nicht offline schalten ließ. Da ging es dann mit der Kommandozeile nicht mehr weiter und aufgrund des auf einen Admin beschränkten Zugriffs konnte ich auch nicht über das Management Studio nachlegen.

    Gerade das Problem mit den nicht offline nehmbaren Datenbanken bestand schon seit längerer Zeit (siehe oben). Welche Teile welcher Logfiles könnte ich Euch zur Verfügung stellen, damit das Problem näher analysiert werden kann?

    Montag, 22. April 2019 12:14