Archive:MS SQL Server 2000/2005/2008

From SEPsesam

Copyright © SEP AG 1999-2024. Alle Rechte vorbehalten.

Jede Form der Reproduktion der Inhalte dieses Benutzerhandbuches, ganz oder in Teilen, ist nur mit der ausdrücklichen schriftlichen Erlaubnis der SEP AG gestattet. Bei der Erstellung dieses Benutzerhandbuches wurde mit größtmöglicher Sorgfalt gearbeitet, um korrekte und fehlerfreie Informationen bereit stellen zu können. Trotzdem kann die SEP AG keine Gewähr für die Richtigkeit der Inhalte dieses Benutzerhandbuches übernehmen.

Icon archived docs.png DER INHALT DIESER SEITE IST VERALTET
Die SEP AG hat die Unterstützung für veraltete SEP sesam Versionen eingestellt. Anleitungen stehen nach wie vor für diese SEP sesam Produkte zur Verfügung, jedoch übernimmt SEP AG keine Verantwortung oder Haftung für Fehler oder Ungenauigkeiten in den Anleitungen oder für die falsche Bedienung veralteter SEP sesam Software. Es wird dringend empfohlen Ihre SEP sesam Software auf die neueste Version zu aktualisieren. Die neueste Dokumentation für SEP sesam finden Sie unter Dokumentation.


Einführung

MS SQL Server 2000/2005/2008/2012 bestehen aus mehreren Windows Diensten, der Hauptdienst ist jedoch MSSQLServer. Zwei weitere Dienste sind MSDTC und SQLServerAgent. Die Datenbank Dateien liegen bei der Standardinstallation unter C:\<MSSQL_HOME> jeweils als Daten-Datei (.mdf) und Log-Datei (.ldf).

Als Quelle einer MS SQL Server Sicherung ist die Bezeichnung der SQL Server Datenbank anzugeben. Ist die Angabe einer Instanz notwendig, so sind als Quelle der Servername und die Instanz voranzustellen: <servername>/<instance>/<database>.

Die Namen für die Backup Quelle (z.B. Northwind) können mittels "SQL Server Management Studio" bestimmt werden.

Ab SEP sesam Version 3.4 besteht die Möglichkeit die Quellen im Browser für Auftragsquellen anzuzeigen und auszuwählen.

Systemvoraussetzungen

  • Unterstütze Versionen
  • SEP sesam Klient ab Version 3.2.1.17
  • Das MSSQL Datenbankmodul ist in der Standard Installation eines SEP sesam Klienten/Servers enthalten.


Hinweis

"MS SQL Server 7.0" wird ab SEP sesam Version 3.4 nicht mehr unterstützt.

Sicherungsquelle einer MS SQL Server Datenbank

Die Sicherungsquelle hat folgenden Aufbau:

<HOSTNAME>/<Instance>/<DB Name> 

Sicherung einer Datenbank in der 1. Instanz

In diesem Beispiel wird die Datenbank master in der ersten Instanz des MS SQL Servers COSINUS gesichert. Dazu muss in der SEP sesam GUI ein neuer Sicherungsauftrag mit dem Sicherungstyp MS-SQL Server und folgender Sicherungsquelle erstellt werden:

 COSINUS/Master

verwendet werden.

Dabei ist es wichtig den richtigen Sicherungstyp auszuwählen und als Quelle den NETBIOS Hostnamen des Systems anzugeben und mit „/“ oder „:“ getrennt den Namen der Datenbank. Damit ist der Auftrag vollständig eingerichtet und kann nun sofort oder über einen Zeitplan gestartet werden.


Mssql task example.JPG

Sicherung einer Datenbank in der 2. bzw. einer weiteren Instanz

Im zweiten Beispiel wird eine Datenbank aus der 2-ten Instanz eines MS SQL Servers gesichert.

Mssql enterpr man2.JPG

Das Ziel soll sein die Datenbank master unter der zweiten DB-Instanz zu sichern. Dazu muss in der SEP sesam GUI ein Auftrag mit folgender Quellangabe erstellt werden:

 COSINUS/ZWEITE_DB/master

Mssql db instanz2.JPG

Dabei ist es wichtig den richtigen Sicherungstyp auszuwählen und als Quelle den NETBIOS-Hostnamen des Systems (ohne Domäne), den Namen der Instanz und den Namen der Datenbank mit „/“ getrennt anzugeben. Als letztes Trennzeichen wir auch „:“ akzeptiert.

Log Truncation

Achtung!
  • SEP empfiehlt dringend das Wiederherstellungsmodell 'Vollständig'/'Full') zu verwenden, siehe auch SQL Server-Onlinedokumentation 'Übersicht über Wiederherstellungsmodelle'.
  • Im Falle des Wiederherstellungsmodells 'Vollständig'/'Full' müssen zusätzlich zu den FULL Sicherungen auch regelmäßig inkrementelle (INC) Sicherungen durchgeführt werden, um die Log-Sicherungen durchzuführen.
  • Nur mit INC Sicherungen werden MSSQL Log Dateien abgeschnitten (truncated)!

Nur mit dem Wiederherstellungsmodell 'Vollständig' gehen keine Daten aufgrund einer verlorenen oder beschädigten Datendatei verloren und die Wiederherstellung bis zu einem beliebigen Zeitpunkt ist möglich (z. B. vor Anwendungs- oder Benutzerfehlern). Das Wiederherstellungsmodell 'Vollständig' erfordert Protokollsicherungen (FULL+INC Backups).

SQL Server Test auf der Kommandline

Browsen der Datenquellen

Der Schalter '-D' (directory) steht zum Browsen der MS SQL Server Datenquellen zur Verfügung.

Als Wurzel kann angegeben werden

  • "sbcmsql:/Net:" Ausgabe der über Netz erreichbaren MS SQL Server
  • "sbcmsql:/NetInstances:" Ausgabe der über Netz erreichbaren MS SQL Server inkl. Instanzen
  • "sbcmsql:/MS SQL Server:[/<server>[/<instance>]]" Ausgabe des auf dem lokalen System erreichbaren MS SQL Server und weiterer Ebenen wie Instanzen und Datenbanken

Ab der sbcmsql.dll Version 3.2.0.8 können auch die logischen File Namen gebrowsed werden:

  • "sbcmsql:/MS SQL Server:/<server>/<instance>/<database>" Ausgabe der logischen und physikalischen Dateinamen, Trennzeichen ':'

Beispiele:

sbc_uc -D "sbcmsql:/Net:"
"/MS SQL Server:/BUCHFIX2" d_ 2007.10.17 18:02:01 2007.10.17 18:02:01
"/MS SQL Server:/COSINUS" d_ 2007.10.17 18:02:01 2007.10.17 18:02:01
"/MS SQL Server:/SEHNIX" d_ 2007.10.17 18:02:01 2007.10.17 18:02:01
sbc_uc -D "sbcmsql:/NetInstances:"
"/MS SQL Server:/BUCHFIX2" d_ 2007.10.17 18:02:26 2007.10.17 18:02:26
"/MS SQL Server:/COSINUS" d_ 2007.10.17 18:02:26 2007.10.17 18:02:26
"/MS SQL Server:/COSINUS\ZWEITE_DB" d_ 2007.10.17 18:02:26 2007.10.17 18:02:26
"/MS SQL Server:/SEHNIX" d_ 2007.10.17 18:02:26 2007.10.17 18:02:26
sbc_uc -D "sbcmsql:/MS SQL Server:"
"/MS SQL Server:/MIRACULIX" d_ 2007.10.17 18:02:52 2007.10.17 18:02:52
sbc_uc -D "sbcmsql:/MS SQL Server:/MIRACULIX"
"/MS SQL Server:/MIRACULIX/(local)" d_ 2007.10.17 18:03:11 2007.10.17 18:03:11
"/MS SQL Server:/MIRACULIX/SECOND" d_ 2007.10.17 18:03:11 2007.10.17 18:03:11
"/MS SQL Server:/MIRACULIX/SQLSERVER2005" d_ 2007.10.17 18:03:11 2007.10.17 18:03:11
"/MS SQL Server:/MIRACULIX/SQLSERVER2005B" d_ 2007.10.17 18:03:11 2007.10.17 18:03:11
sbc_uc -D "sbcmsql:/MS SQL Server:/MIRACULIX/(local)"
/MS SQL Server:/MIRACULIX/(local)/master fb 2003-04-08 09:13:36.390 07.10.17 18:06:33. 4096 -,
/MS SQL Server:/MIRACULIX/(local)/model fb 2003-04-08 09:13:36.390 07.10.17 18:06:33. 4096 -,
/MS SQL Server:/MIRACULIX/(local)/msdb fb 2005-10-14 01:54:05.240 07.10.17 18:06:33. 4096 -,
/MS SQL Server:/MIRACULIX/(local)/msdb2 fb 2007-10-10 12:55:46.030 07.10.17 18:06:33. 4096 -,
/MS SQL Server:/MIRACULIX/(local)/sesam_db fb 2007-09-20 14:17:04.730 07.10.17 18:06:33. 4096 -,
/MS SQL Server:/MIRACULIX/(local)/sesam_db2 fb 2007-09-20 16:21:01.030 07.10.17 18:06:33. 4096 -,
/MS SQL Server:/MIRACULIX/(local)/tempdb fb 2007-10-17 18:06:27.747 07.10.17 18:06:33. 4096 -,  
not_saveable only for temporary operations
/MS SQL Server:/MIRACULIX/(local)/testdb fb 2007-09-24 16:19:36.123 07.10.17 18:06:33. 4096 -,
sbc_uc -D "sbcmsql:/MS SQL Server:/MIRACULIX/SECOND"
/MS SQL Server:/MIRACULIX/SECOND/AdventureWorks fb 2007-08-16 16:17:06.717 07.10.17 18:05:54. 4096 -,
/MS SQL Server:/MIRACULIX/SECOND/AdventureWorksDW fb 2007-08-16 16:16:45.640 07.10.17 18:05:54. 4096 -,
/MS SQL Server:/MIRACULIX/SECOND/master fb 2003-04-08 09:13:36.390 07.10.17 18:05:54. 4096 -,
/MS SQL Server:/MIRACULIX/SECOND/model fb 2003-04-08 09:13:36.390 07.10.17 18:05:54. 4096 -,
/MS SQL Server:/MIRACULIX/SECOND/msdb fb 2005-10-14 01:54:05.240 07.10.17 18:05:54. 4096 -,
/MS SQL Server:/MIRACULIX/SECOND/sesam_db fb 2007-10-10 13:26:53.310 07.10.17 18:05:54. 4096 -,
/MS SQL Server:/MIRACULIX/SECOND/sesam_db2 fb 2007-10-10 15:09:26.200 07.10.17 18:05:54. 4096 -,
/MS SQL Server:/MIRACULIX/SECOND/sesam2 fb 2007-10-10 15:13:49.607 07.10.17 18:05:54. 4096 -,
/MS SQL Server:/MIRACULIX/SECOND/tempdb fb 2007-10-17 18:05:41.967 07.10.17 18:05:54. 4096 -,  
not_saveable only for temporary operations
sbc_uc -D "SBCMSQL:MS SQL Server:/miraculix/(local)/sesam_db" 2>nul
/MS SQL Server:/miraculix/(local)/sesam_db/sesam_db:"D:\Programme\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\sesam_db.mdf" f_ 07.11.28 13:07:36. 07.11.28 13:07:36. 4096 -,
/MS SQL Server:/miraculix/(local)/sesam_db/sesam_db_log:"D:\Programme\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\sesam_db_log.ldf" f_ 07.11.28 13:07:36. 07.11.28 13:07:36. 4096 -,

Sicherung

Da sowohl eine voll qualifizierte Angabe des Servers plus Instanz als auch nur der Datenbank-Bezeichner akzeptiert werden, sind folgende Angaben in ihrer Bedeutung identisch, im Beispiel Server 'MIRACULIX' ohne spezifischen Instanznamen, wobei in diesem Fall als Instanz "(local)" angegeben wird:

sbc_uc -b -s @sesam_db.save -v 3 sbcmsql:/MIRACULIX/(local)/sesam_db
sbc_uc -b -s @sesam_db.save -v 3 sbcmsql:MIRACULIX/(local)/sesam_db
sbc_uc -b -s @sesam_db.save -v 3 sbcmsql:MIRACULIX/sesam_db
sbc_uc -b -s @sesam_db.save -v 3 sbcmsql:sesam_db

Falsch ist die Angabe von "/MS SQL Server:", die nicht in der Quellangabe akzeptiert wird: "/MS SQL Server:/MIRACULIX/(local)/sesam_db" ist falsch!


Hinweis

Eine weitere Instanz muss immer voll qualifiziert angegeben werden.

Beispiele:

sbc_uc -b -s @sesam_db.save -v 3 sbcmsql:/MIRACULIX/SECOND/sesam_db
sbc_uc -b -s @sesam_db.save -v 3 sbcmsql:MIRACULIX/SECOND/sesam_db

Rücksicherungen

Rücksicherungen sollten mit 'Überschreiben' und 'Recover' gestartet werden. Wurde eine Datenbank komplett ohne recover restauriert, so kann ein recover auch per Kommandline nachgestartet werden:

sbc_uc -r -a recover -v 3 sbcmsql:MIRACULIX/SECOND/sesam_db

Rücksicherung auf Original

Eine Rücksicherung auf Original mit 'Überschreiben' und 'Recover' würde für obiges Beispiel folgendermaßen aufgebaut:

sbc_uc -r -s @sesam_db.save -o over -a recover -v 3 sbcmsql:MIRACULIX/SECOND/sesam_db

Rücksicherung nach Löschung der Datenbank oder auf andere Instanz

Wurde die Datenbank auf der Original Instanz gelöscht oder soll diese auf eine andere Instanz zurückgesichert werden, so ist dies möglich, sofern der Pfad für die Datenbankdateien existiert.

Existiert der Pfad nicht, so wird eine Meldung mit dem nicht vorhandenen Pfad im Protokoll der Rücksicherung ausgegeben.

Beispiel:

Directory lookup for the file "C:\Programme\Microsoft SQL Server\MSSQL$ZWEITE_DB\data\sesamdb_Data.MDF" 
failed with the operating system error 3(The system cannot find the path specified.).
File 'sesamdb_Data' cannot be restored to 'C:\Programme\Microsoft SQL Server\MSSQL$ZWEITE_DB\data\sesamdb_Data.MDF'. 
Use WITH MOVE to identify a valid location for the file.

Nach Anlegen des Pfades kann die Rücksicherung ausgeführt werden. Sollen die Datenbankdateien unter einem anderen Pfad angelegt werden, so können die Dateinamen mit Hilfe der Move-Option, wie unter Move-Option beschrieben, angegeben werden.

Rücksicherung auf eine identisch aufgebaute Datenbank

Wurde die Datenbank mit gleichen logischen File Namen aufgebaut, so kann eine Rücksicherung direkt erfolgen:

sbc_uc -r -s @sesam_db.save -o over -a recover -v 3 sbcmsql:"/MIRACULIX/SECOND/sesam_db"

Der Aufbau kann im Microsoft SQL Server Management Studio oder mit folgendem osql Kommando überprüft werden: (name == logischer File Name)

osql -E -S MIRACULIX\SECOND -Q "select name,physical_name,state_desc from sys.database_files" -d sesam_db 
name        physical_name           state_desc
-----------------------------------------------------------------------------------------------------------------------
sesam_db       D:\Programme\Microsoft SQL Server\MSSQL.3\MSSQL\DATA2\sesam_db.mdf       ONLINE
sesam_db_log   D:\Programme\Microsoft SQL Server\MSSQL.3\MSSQL\DATA2\sesam_db_log.ldf   ONLINE

Demnach muss die Ziel Datenbank ebenfalls sesam_db und sesam_db_log enthalten!


Hinweis

Für MS SQL Server 2000 heißt die entsprechende Abfrage (Beispiel):

osql -E -S COSINUS\ZWEITE_DB -Q "select * from sysfiles" -d sesamdb

Alle Datenbanken können mit folgendem Kommando ausgegeben werden:

osql -E -S w2003enterprise -Q "select name, filename from sysdatabases" -d master

Rücksicherung auf Datenbank in einer anderen Lokation OHNE Move Option

Falls die Datenbank mit anderen logischen File Namen aufgebaut wurde, ist eine Rücksicherung nur mit Hilfe der 'MOVE TO'-Clause oder durch eine Umbenennung der logischen File Namen im 'SQL Server Management Studio' möglich. Hier der Weg mittels Umbenennen der Dateinamen.

Der Name der Original-Datenbank ist OriginalDB und der Name der Restore-Datenbank ist RestoreDB.

  1. Nach dem erfolgreichen Backup der Datenbank OriginalDB ist über das MS-SQL Management Studio die Restore-Datenbank RestoreDB anzulegen.
  2. In der Restore-Datenbank sind die logischen Datenbanknamen (RestoreDB und RestoreDB_log) auf die Namen der Originaldatendank zu ändern (hier OriginalDB and OriginalDB_log).
  3. Umbenennen der Dateinamen der Restore-Datenbank (RestoreDB.mdf und RestoreDB_log.ldf) auf die Dateinamen der Originaldatendank zu ändern (hier OriginalDB.mdf and OriginalDB_log.ldf).
  4. Die Restore-Datenbank ist Offline zu setzen.
  5. Start des Sesam Restore Wizard und Auswahl der Datenbank OriginalDB zum Rücksichern.
  6. Auf der Restore Wizard Seite Sichern und Starten in das Feld neues Rücksicherungsziel den Wert auf W2K8R2SQL/MSSQLSERVER/RestoreDB setzen. Dann sind die Ausführungs-Optionen Existierende Dateien überschrieben und Auto Recover nach Restore zu wählen.
  7. Start des Restore-Prozesses
  8. Nach dem erfolgreichen Restore ist die Restore-Datenbank Online zu setzen.


Rücksicherung auf Datenbank in einer anderen Lokation MIT Move Option

Falls die Datenbank mit anderen logischen File Namen aufgebaut wurde, ist eine Rücksicherung nur mit Hilfe der 'MOVE TO'-Clause oder durch eine Umbenennung der logischen File Namen im 'SQL Server Management Studio' möglich. Hier der Weg mittels 'Move' Option.

Format der 'Move' Option:

-a move={logical_name_mdf}:"{file_name_mdf}" -a move={logical_name_ldf}:"{file_name_ldf}"

Für {logical_name_mdf} bzw. {logical_name_ldf} sind die logischen Namen der Original Datenbank Datei(en) bzw. LogDatei(en) zu verwenden, wohingegen für {file_name_mdf} bzw. {file_name_ldf} die vollständigen Dateipfade der Ziel Datenbank Dateien anzugeben sind.


Beispiel: Zieldatenbank sesam2 soll mit Sicherung der Originaldatenbank sesam überschrieben werden

osql -E -S MIRACULIX\SECOND -Q "select name,physical_name,state_desc from sys.database_files" -d sesam2 
name        physical_name           state_desc
-----------------------------------------------------------------------------------------------------------------------
sesam_db2       D:\Programme\Microsoft SQL Server\MSSQL.3\MSSQL\DATA2\sesam_db2.mdf       ONLINE
sesam_db2_log   D:\Programme\Microsoft SQL Server\MSSQL.3\MSSQL\DATA2\sesam_db2_log.ldf   ONLINE

Mögliches Rücksicherungskommando:

sbc_uc -r -s @sesam_db.save -o over -a recover 
-a move=sesam_db:"D:\Programme\Microsoft SQL Server\MSSQL.3\MSSQL\DATA2\sesam2.mdf" 
-a move=sesam_db_log:"D:\Programme\Microsoft SQL Server\MSSQL.3\MSSQL\DATA2\sesam2_log.ldf" 
sbcmsql:"/MIRACULIX/SECOND/sesam2"
Achtung

Bei Verwendung der 'Move' Option ist sicherzustellen, dass die angegebenen Verzeichnisse bereits existieren. Existieren die angegebenen Dateien, so werden diese, sofern die 'Überschreiben' Option gewählt wurde, überschrieben. D.h. hier sollte darauf geachtet werden, dass nicht unbeabsichtigt Datenbank-Dateien überschrieben werden.

Hinweise
  • Die 'Move' Option -a move=.:. kann (ohne Zeilenwechsel) im Rücksicherungswizard unter Experten Optionen - Optionen als Text eingetragen werden.
  • Ist die Ziel-Datenbank in Benutzung, z.B. durch öffnen einer Tabelle mit 'Open Table' im 'SQL Server Management Studio', so misslingt die Rücksicherung. D.h. vor einer Rücksicherung ist sicherzustellen, dass die Datenbank unbenutzt ist.
  • SEP sesam erkennt nicht immer ob eine Rücksicherung wirklich erfolgreich war, deshalb soll auf jeden Fall nach einer Rücksicherung das Rücksicherungsprotokoll auf Fehlermeldungen überprüft werden.
  • Falls der SEP sesam Server mit einer Postgres Datenbank arbeitet, z.B. auf Linux x64, dann müssen die \-Zeichen doppelt eingegeben werden, ansonsten verschwinden diese in den Pfaden!
  • Durch den Restore mit 'Move' Option werden die logischen File Namen der Ziel Datenbank angepasst.


Beispiel: Nach einer Rücksicherung angepasste logische File Namen

osql -E -S MIRACULIX\SECOND -Q "select name,physical_name,state_desc from sys.database_files" -d sesam2 
name        physical_name           state_desc
-----------------------------------------------------------------------------------------------------------------------
sesam_db       D:\Programme\Microsoft SQL Server\MSSQL.3\MSSQL\DATA2\sesam_db2.mdf       ONLINE
sesam_db_log   D:\Programme\Microsoft SQL Server\MSSQL.3\MSSQL\DATA2\sesam_db2_log.ldf   ONLINE

Rücksicherung einer MS SQL Server 2000 Datenbank auf MS SQL Server 2005

Eine Datenbank einer MS SQL Server 2000 Instanz kann auf einem MS SQL Server 2005 zurückgesichert werden. Nach der Rücksicherung wird die Datenbank automatisch upgegraded.

Achtung: MS SQL Server 2005 Datenbanken können nicht auf MS SQL Server 2000 Instanzen zurückgesichert werden.

Disaster Recovery

Im Falle einer Disaster Recovery Situation, typischerweise die Notwendigkeit einen SQL Server neu aufzusetzen oder die master Datenbank auf einem existierenden SQL Server wiederherzustellen, müssen zunächst die System Datenbanken wiederhergestellt werden.


Hinweis

Zum Wiederherstellen der master Datenbank kann das Rebuildm.exe Utility unter \..\mssql7\binn\ oder \..\Microsoft SQL server\80\Tools\Binn\ für SQL 2000/2005 benutzt werden. Allerdings sollte dieselbe 'Sort Order' und 'Code Page' wie bei dem zu recoverenden SQL Server verwendet werden.

Falls ein neuer SQL Server installiert wird, sollten auch die aktuellen Service Packs eingespielt werden.

Zunächst muss der SQL Server mit dem Switch '-m' im Single User Mode gestartet werden, handelt es sich um eine Instanz so wird der Instanzname mit '-s <instancename>' angegeben:

sqlservr.exe -m [-s <instancename>]

Danach kann mittels SEP sesam GUI der Restore für die master Datenbank angestoßen werden. Unabhängig vom ursprünglichen Verzeichnis werden die Dateien der master Datenbank dort restauriert, wo diese vom neu installierten MS SQL Server erwartet werden.

Danach wird der SQL Server im normalen Modus, d.h. als Service gestartet.

Nun wird die msdb Datenbank restauriert. Danach die model Datenbank.

Hinweis

Zu beachten ist, dass die Pfade - auch bei Verwendung der MOVE Option - vorhanden sein müssen und ggf. die 'Überschreiben' Option verwendet werden muss.

Nachdem die System Datenbanken wieder verfügbar sind, werden die anderen Datenbanken restauriert.

Hinweis

Falls die Dateipfade in der restaurierten master Datenbank anders als die aktuellen Dateipfade der model Datenbank sind, wird der SQL Server Start misslingen. Dies kann umgangen werden, indem die model Datenbank Dateien model.mdf und modellog.ldf in das Verzeichnis verschoben werden, das von der master Datenbank vorgegeben wird.

Troubleshooting

Login incorrect - Anmeldung falsch

Problem: Wird eine Sicherung oder eine Rücksicherung fehlerhaft beendet und finden sich im Protokoll Zeilen wie die folgenden:

DB Module: [DB-Library: Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.]
DB Module: [DB-Library message: Login incorrect.]

so wurde versucht auf einem Klienten eine SQL Server Instanz anzusprechen, die nicht lokal auf diesem System vorhanden ist. Die verwendete "Trusteed Connection" erlaubt eine Anmeldung nur an dem SQL Server an dem die Instanz lokal aktiv ist.

Lösung: In dem Fall muss der Backup Klient oder der Zielknoten auf den aktiven SQL Server geändert werden.


Sicherung schlägt fehl mit 'The server principal "NT AUTHORITY\SYSTEM" is not able to access the database "<database>" under the current security context.'

Problem: Der Benutzer "SYSTEM" darf sich nicht am MS-SQL server anmelden, weil der SEP sesam Dienst standardmäßig als Benutzer "SYSTEM" läuft.


Lösung: In diesem Fall muss man einfach den SEP sesam Dienst auf einen Benutzer ändern, der auf die MS-SQL Datenbank(en) zugreifen darf. Dazu die Windows Diensteverwaltung öffnen, die Eigenschaften des SEP sesam Dienstes bearbeiten und im Reiter "Anmeldung" autorisierte Benutzerdaten eingeben und anschließend den Dienst neu starten.


Rücksicherung misslingt mit "Directory lookup for the file '...' failed"

Problem: Falls Meldungen der Art

DB Module: [DB-Library: Directory lookup for the file "e:\Database\SQL Server 2000 SE\MSSQL\Data\sesam.mdf" 
  failed with the operating system error 21(The device is not ready.).]
DB Module: [DB-Library: File 'sesam_db' cannot be restored to 'e:\Database\SQL Server 2000 SE\MSSQL\Data\sesam.mdf'. 
  Use WITH MOVE to identify a valid location for the file.]

auftreten, dann existiert der Pfad in dem sich die Datenbankdateien ursprünglich befanden nicht auf dem Zielsystem oder mit der MOVE-Option wurde ein nicht existierender Pfad angegeben.

Lösung: Es muss der Pfad angelegt oder ein korrekter Pfad mit der Move-Option angegeben werden. Das Anlegen des Pfades ist i.allg. die einfachere Lösungsmöglichkeit. Außerdem kann es bei langen Pfaden zu Problemen mit der Move-Option kommen, die Eingabe wird dann verkürzt.

Rücksicherung misslingt mit "Unable to connect: SQL Server does not exist or network access denied."

Problem: Falls Meldungen der Art

DB Module: [DB-Library message: Unable to connect: SQL Server is unavailable or does not exist.  
  Unable to connect: SQL Server does not exist or network access denied.; Net-Library message: ConnectionOpen (Connect()).; ]

auftreten, dann existiert der Server nicht. Möglicherweise wurde fälschlicherweise eine Instanz ohne Server angegeben.

Lösung: Servernamen überprüfen, ggf. Rücksicherungs-Ziel voll qualifiziert mit

<HOSTNAME>/<Instance>/<DB Name> 

angeben.

Rücksicherung mit MOVE Option misslingt mit "The physical file name '...' may be incorrect"

Problem: Falls Meldungen der Art

DB Module: [DB-Library: A file activation error occurred. The physical file name 'c:/temp/sesam_log.ldf' may be incorrect. 
  Diagnose and correct additional errors, and retry the operation.]
DB Module: [DB-Library: File 'sesam_db_log' cannot be restored to 'c:/temp/sesam_log.ldf'. 
  Use WITH MOVE to identify a valid location for the file.]

auftreten, dann wurde eine falsche Syntax, im Beispiel / statt \, im Dateinamen verwendet.

Lösung: Pfad mit richtiger Syntax angeben.

Achtung

Falls der SEP sesam Server mit einer Postgres Datenbank arbeitet, z.B. auf Linux x64, dann müssen die \-Zeichen doppelt eingegeben werden, ansonsten verschwinden diese in den Pfaden!

Beispiel:

-a move=Mgmt_data:"e:\\SQL Server 2000 SE\\MSSQL\\Data\\Mgmt.mdf" -a move=Mgmt_log:"e:\\SQL Server 2000 SE\\MSSQL\\Data\\Mgmt_log.ldf"

Rücksicherung mit MOVE Option misslingt mit "Logical file '...' is not part of database"

Problem: Falls Meldungen der Art

DB Module: [DB-Library: Logical file 'Mgmt_data' is not part of database 'sesam_db2'. 
  Use RESTORE FILELISTONLY to list the logical file names.]

auftreten, dann wurde in der MOVE-Option ein falscher logischer Name angegeben.

Lösung: Logischen File Namen richtig angeben, er kann aus dem Sicherungsprotokoll (NOT-File) entnommen werden.

Beispiel: Im Sicherungsprotokoll stehen die Zeilen:

DB Module: [DB-Library: Processed 256 pages for database 'sesam_db', file 'sesam_db' on file 1.]
DB Module: [DB-Library: Processed 1 pages for database 'sesam_db', file 'sesam_db_log' on file 1.]

Die logischen File Namen lauten hier sesam_db und sesam_db_log.

Zurückgesicherte Datenbank bleibt im Zustand 'Restoring'

Problem: Nach der Rücksicherung einer MS SQLServer Datenbank verbleibt diese im Zustand '(Restoring...)'. Dieser Zustand tritt auf, wenn die Option 'Auto Recover' im Rücksicherungswizard nicht ausgewählt wurde.

Lösung: Rücksicherung mit Option 'Auto Recover' ausführen. Oder nachträglich durch manuellen Aufruf von sbc mit Option -a recover für die entsprechende Datenbank.

Beispiel:

MSSQL restoring.jpeg

Durch den folgenden sbc Aufruf auf dem Klienten kann die Datenbank recovered werden:

sbc -r -a recover sbcmsql:"/MIRACULIX/SECOND/msdb"


Hinweis

Auch bei der Rücksicherung einer Datenbank und zusätzlicher Transaktionslogdateien (Generationsrestore) verbleiben die Datenbanken solange im Zustand 'Restoring...' bis die letzte Rücksicherung (mit '-a recover') abgeschlossen wird.

Weitere Links/Literatur