Zugriff verweigert Fehler in CREATE DATABASE… FOR ATTACH

Ich versuche, eine Kopie von msdban meine Workstation SQL Server 2012 Developer Edition unter Windows 8.1 anzuhängen , um das in dieser Frage beschriebene Problem nachzuahmen , bei dem das OP versucht, fehlende Jobs aus einer fremden MSDB wiederherzustellen.

Ich habe folgende Aktionen ausgeführt:

use master;

backup database msdb to disk='C:\sqlserver\test.bak';
go
restore database msdbtest from disk='c:\sqlserver\test.bak' 
    with move 'MSDBData' to 'C:\SQLServer\Data\msdbtest_data.mdf'
    , move 'MSDBLog' TO 'C:\SQLServer\Logs\msdbtest_log.ldf';
go

Ich habe dann den SQL Server-Dienst gestoppt, eine Kopie von C:\SQLServer\Data\msdbtest_data.mdfund erstellt C:\SQLServer\Logs\msdbtest_log.mdfund SQL Server neu gestartet.

Ich habe dann folgendes durchgeführt:

drop database msdbtest;
go
create database msdbtest on (
    name='msdbtest_data'
    ,filename='c:\sqlserver\data\msdbtest_data.mdf'
) log on (
    name='msdbtest_log'
    , filename='c:\sqlserver\log\msdbtest_log.ldf'
) for attach;

Das führt zu:

Msg 5120, Level 16, State 101, Line 1
Unable to open the physical file "c:\sqlserver\data\msdbtest_data.mdf". 
Operating system error 5: "5(Access is denied.)".

SQL Server wird mit den Standardeinstellungen für das Dienstkonto konfiguriert:

Der effektive Sicherheitszugriff für das SQL Server-Dienstkonto c:\sqlserver\data\msdbtest_data.mdfist:

Ich bin total ratlos; Ich denke, der zurückgegebene Fehler führt mich in die Irre. Vielleicht verstehe ich den Zweck von falsch CREATE DATABASE ... FOR ATTACH?

Soweit ich das beurteilen kann, sollte SQL Server auf jeden Fall Zugriff auf die Datei haben. Der Ordner C:\SQLServer\Datawird von allen anderen Benutzerdatenbanken verwendet, die derzeit an die Instanz angehängt sind.

SELECT @@VERSION kehrt zurück:

Microsoft SQL Server 2012 (SP1) - 11.0.3128.0 (X64) 
Dec 28 2012 20:23:12 
Copyright (c) Microsoft Corporation
Developer Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: )

Wenn Sie diese Nachricht erhalten, kann es ein paar Dinge sein. Einige Beispiele:

1.) Schreibgeschützte markierte Dateien

2.) Unzureichende Berechtigungen für die Dateien für das SQL Server-Dienstkonto

3.) Unzureichende Berechtigungen für die Ordner, in denen sich die Dateien befinden.

Sie haben in unserem Chat angegeben, dass dies nicht schreibgeschützt ist. Sie haben auch überprüft, ob Berechtigungen wie Vollzugriff aussehen. Das schloss diese drei Punkte aus.

Die Tatsache, dass bei unserer Chat-Konversation dieses Problem nicht aufgetreten ist, als Sie eine Datenbank mit sp_detach_db ordnungsgemäß getrennt haben - wodurch sich die Berechtigungen für die Dateien tatsächlich ein wenig ändern -, habe ich vorgeschlagen, SSMS als Administrator auszuführen.

Warum? Nun, dieser Artikel befasst sich viel eingehender mit einigen der Identitätswechselprobleme hier - aber ich verstehe:

1.) Wenn Sie nur den SQL Server-Dienst beenden und die Datei verschieben. Der Eigentümer der Datei ist das Dienstkonto, das sie erstellt hat.

2.) Wenn Sie die Datenbank trennen, werden Sie möglicherweise eine Änderung der Berechtigungen bemerken. Der Eigentümer hat sich grundlegend geändert und die Datei ist nicht auf die gleiche Weise mit diesem SQL Server-Dienstkonto verknüpft.

3.) Es funktioniert also, wenn Sie versuchen, eine Verbindung herzustellen, da die Berechtigungen zugewiesen werden können, weil die Sicherheit der Datei dies zulässt.

Wenn Sie den Dienst jedoch nur beenden, hat sich die Sicherheit nicht geändert, und Sie können dies nicht anhängen, wenn Sie die Benutzerkontensteuerung aktiviert haben, es sei denn, Sie geben sich als Administratorzugriff aus.

Ich habe den Dateibesitz und den Zugriff hier wahrscheinlich verwirrender gemacht, aber der Artikel, den ich geteilt habe, macht wahrscheinlich einen besseren Job :-)

Aber eine kleine Moral ist - machen Sie das nächste Mal eine Trennung ;-) Oder seien Sie einfach darauf vorbereitet, SSMS von Zeit zu Zeit als Administrator auszuführen, wenn Sie auf verschiedene Weise mit dem Betriebssystem interagieren.

Laut dem SQL CrossJoin-Blog kann das Ablaufverfolgungsflag 1802 verwendet werden, um den Berechtigungsänderungscode zu deaktivieren.

Aus diesem Blog:

[Ablaufverfolgungsflag 1802] Umgeht ein Problem, bei dem „Sie nach dem Trennen einer Microsoft SQL Server 2005-Datenbank, die sich im Netzwerkspeicher befindet, die SQL Server-Datenbank nicht erneut verbinden können. Dieses Problem tritt auf, weil SQL Server 2005 die Dateiberechtigungen zurücksetzt, wenn die Datenbank getrennt wird. Wenn Sie versuchen, die Datenbank erneut anzuhängen, kann sie aufgrund eingeschränkter Freigabeberechtigungen nicht angehängt werden. “ ( KB922804 )

Aus der Beschreibung geht hervor, dass dieses Flag die Funktionalität von SQL Server beim Ändern von Berechtigungen für Datenbankdateien nach dem Trennen der Datenbank deaktiviert. Dies bedeutet, dass das Flag Auswirkungen auf die Sicherheit hat.

Beenden Sie die SQL Server-Dienste und ändern Sie "Anmelden als" in " Lokales System"

Starten Sie die SQL-Dienste neu und überprüfen Sie. In meinem Fall hat es gut funktioniert.