none
SQL SRV 2008R2 - Bedeutung der Datenbank "BBSn_5518_model" RRS feed

  • Allgemeine Diskussion

  • Die "BBSn_5518_model" war von einem auf den anderen Tag offline gesetzt und Sicherungsaufträge schlugen fehl. Die einfache Sicherung über den Objektexplorer - Tasks - Sichern funktionierte problemlos, der monatelang funktionierende Wartungsplan dagegen nicht. Ich bin auch im www auf keinerlei Hinweise gestoßen - leider.

    Mittwoch, 11. Dezember 2013 12:57

Alle Antworten

  • Also wenn nicht zufällig hier im Forum jemand anderes die selbe Applikation mit der selben Datenbank hat - zum SQL Server selber gehört sie nicht - wird es eine Ratestunde.

    Versuch mal anhand

    • der Extended Properties,
    • der Tabellennamen,
    • der Prozedurennamen
    • und Code-Kommentaren

    Ihre Bedeutung festzustellen.

    Ansonsten scheint sie ja von diesen Wartungsaufträgen/Jobs benötigt zu werden. Auch diese muss ja jemand angelegt haben.


    Andreas Wolter | Microsoft Certified Master SQL Server

    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com | www.SarpedonQualityLab.com

    Mittwoch, 11. Dezember 2013 13:18
  • Also: Die Bedeutung der BBSn_5518_model ist mir nach wie vor nicht klar. Wie lange sie schon vorhanden ist oder ob sie plötzlich da war, da möchte ich auch keine Zeit mehr reinstecken.

    Seltsam ist, dass sie auf einmal offline war und die Sicherung über ARCserve und aus dem Management Studio (Wartungsplan) heraus Fehler meldete. Die Sicherung unserer Datenbank für sich allein bereitete keine Probleme.

    Ursache für die plötzlichen Probleme waren im Wartungsplan vorhandene Einstellungen für ALLE Datenbanken (Integritätsprüfung und Sicherung), die über Monate und Jahre schon existierten. Die explizite Beschränkung auf "Bestimmte Datenbanken" und Auswahl aller dort angebotenen DBn brachte die Lösung.

    Auf die BBSn_5518_model wird mit der Einstellung "Alle Datenbanken" versucht zuzugreifen, obwohl sie unter "Bestimmte Datenbanken" nicht aufgeführt wird - anderenfalls könnte sie ja auch dort ausgewählt werden.

    Da muss man erst mal drauf kommen ...


    R. Wittek

    Donnerstag, 12. Dezember 2013 07:23
  • Verstehe.

    Ja, das Problem hat schon einige getroffen. Dafür müsste es in den eingebauten Wartungsplänen so eine Option "ignoriere Datenbanken, die nicht online sind" geben. So ähnlich muss das heissen (hab keine deutschen Server und nutze Wartungspläne nicht :-) )


    Andreas Wolter | Microsoft Certified Master SQL Server

    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com | www.SarpedonQualityLab.com

    Donnerstag, 12. Dezember 2013 10:02
  • Wie lange sie schon vorhanden ist oder ob sie plötzlich da war ...

    Da sie ja bis zur Offline Schaltung immer mit gesichert wurde, kannst Du das ganz einfach aus dem Sicherungsverlauf des SQL Server ermitteln und das mit dieser Abfrage:

    SELECT MIN([backup_start_date]) AS DatumErsteSicherung      
      FROM [msdb].[dbo].[backupset]
      WHERE [database_name] = N'BBSn_5518_model'


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 12. Dezember 2013 10:09
  • Danke für die Abfrage!
    Ergebnis:
    DatumErsteSicherung: NULL

    LMT auf das + vor der DB:
    Der Zugriff auf die BBSn_5518_model-Datenbank ist nicht möglich. (Object Explorer)

    Solange nur der Zugriff auf diese DB geblockt wird, die Sicherungen sauber laufen und das optische Vorhandensein nur Fragen aufwirft, soll mir das egal sein.

    Ein Vergleich mit anderen SQL Servern 2008R2 ergab: Dort gibt es keine derartige DB, nur auf diesem speziellen Verfahrensserver. Zusammenhänge mit dem betreffenden Verfahren wurden aber auch verneint.

    Komisch ist nur, dass BBSn_5518_model scheinbar weltweit einmalig vorkommt - das ist aber auch ein tolles Ergebnis!

    ;-)

    


    R. Wittek

    Donnerstag, 12. Dezember 2013 10:45
  • Danke für die Abfrage!
    Ergebnis:
    DatumErsteSicherung: NULL

    Da würde ich mal vermuten, die Datenbank wurde genau an dem Tag angelegt, bevor der Sicherungsjob fehlschlug und dann gleich wieder Offline genommen; sonst wäre sie ja mitgesichert worden.

    Mach mal in SSMS im "Object Explorer" einen Rechte-Maus-Klick auf den Server Eintrag => "Reports" => "Standard Reports" => "Schema Changes History" (Schemaänderungsverlauf), dort wirst Du vielleicht sehen können, wer wann die DB angelegt hat.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 12. Dezember 2013 11:23
  • Die letzten DDL-Vorgänge CREATE, ALTER und DROP wurden für die produktive DB und die Entwickler-DB vom 19.-21.11.2013 protokolliert. Das steht also auch in keinem direkten Zusammenhang zu den Ausfällen nach dem 06.12.2013.
    Das Ganze wird wohl ominös bleiben ...


    R. Wittek


    • Bearbeitet Wurzelpeter Donnerstag, 12. Dezember 2013 12:13
    Donnerstag, 12. Dezember 2013 11:53
  • Wenn ich mich  nicht sehr irre, dann restored ArcServe die Systemdatenbanken nach einem Backup, um zu testen, ob es erfolgreich war.

    Das solltest Du auch im Server-Protokoll sehen können.

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu

    Donnerstag, 12. Dezember 2013 12:44
    Beantworter
  • Guten Morgen!

    Weitergekommen insofern, dass die BBSn_5518_model (mit Gänsehaut und gesträubtem Nackenhaar) online gesetzt wurde und die beiden im Verfahren arbeitenden Server neu gestartet wurden. Die BBSn-DB blieb online, aber sowohl der Wartungsauftrag des SQL-Servers (Integritätsprüfung, Sicherung, Löschungen) als auch die Sicherung über ARCserve funktionierten nicht mehr.

    Der Fehler wurde ja schließlich auf die BBSn-DB eingegrenzt, die im Wartungsplan mit der Einstellung "Alle DBn" wohl mit erfasst wird (sie wurde also schon immer mit erfasst und blockte erst, als sie offline war), aber keinerlei Zugriff erlaubt. Schon bei der Integritätsprüfung (erster Schritt) brach der Wartungsplan ab - auch nach dem Online-setzen und den Neustarts.

    Mit der Einstellung "Bestimmte DBn" und Auswahl aller hier aufgelisteten DBn wird die BBSn-DB offensichtlich nicht mit erfasst. Erst mit diesem neu erzeugten Wartungsplan liefen Integritätsprüfung und Sicherung wieder.

    Die BBSn_5518_model ist nicht vergleichbar mit der Systemdatenbank model. Die Systemdatenbanken werden problemlos gesichert. Der Ausgangspunkt war die Frage, was diese BBSn-DB überhaupt bedeutet. Darauf wurde bisher keine brauchbare Antwort gefunden.

    Dieser Beitrag wird sicherlich auch in den kommenden Wochen von einem meiner Kollegen verfolgt.
    Ich selbst muss mich erst einmal anderen Dingen widmen.

    Vielen Dank an alle, die versucht haben, zur Lösung beizutragen!

    Ich wünsche schon mal "Frohe Weihnachten!" und "Guten Rutsch!".

    Reinhard


    R. Wittek

    Nun kommt doch noch alles in's Reine!

    Der SQL Server ist (wie unbeirrt vermutet!) unschuldig, Verursacher eines Deadlocks war tatsächlich ARCserve auf Grund zeitgleich ablaufender Prozesse.
    Die BBSn-Datenbank(en) werden von ARCserve im Sicherungsverlauf erzeugt. Die BBSn_5518_model blieb wegen einer Kollision offline - und dann ging gar nichts mehr.

    Das alles jetzt hier zu verklickern würde zu unübersichtlich werden. Die Logfiles sind jedenfalls eindeutig - die Fehlermeldungen waren leider nur verwirrend.

    Den Lorbeerkranz setze ich einem immer gern gesehenen Helfer und Spezialisten auf, der das auch kann, wovon er redet. Meine Lorbeeren sind das nicht!

    Nochmals vielen Dank, Frohe Weihnachten und Guten Rutsch!

    Reinhard

     
    • Bearbeitet Wurzelpeter Dienstag, 17. Dezember 2013 09:44
    Montag, 16. Dezember 2013 08:19