ALTER DATABASE (Transact-SQL)

Artikel
12/15/2008

Aktualisiert: 12. Dezember 2006

Ändert eine Datenbank bzw. die zu dieser Datenbank gehörenden Dateien und Dateigruppen. Fügt einer Datenbank Dateien und Dateigruppen hinzu oder entfernt diese, ändert die Attribute einer Datenbank oder ihrer Dateien und Dateigruppen, ändert die Datenbanksortierung und legt Datenbankoptionen fest. Datenbanksnapshots können nicht geändert werden. Verwenden Sie zum Ändern von Datenbankoptionen für die Replikation sp_replicationdboption.

Themenlink (Symbol) Transact-SQL-Syntaxkonventionen

Syntax

ALTER DATABASE database_name 
{
    <add_or_modify_files>
  | <add_or_modify_filegroups>
  | <set_database_options>
  | MODIFY NAME = new_database_name 
  | COLLATE collation_name
}
[;]

<add_or_modify_files>::=
{
    ADD FILE <filespec> [ ,...n ] 
        [ TO FILEGROUP { filegroup_name } ]
  | ADD LOG FILE <filespec> [ ,...n ] 
  | REMOVE FILE logical_file_name 
  | MODIFY FILE <filespec>
}

<filespec>::= 
(
    NAME = logical_file_name  
    [ , NEWNAME = new_logical_name ] 
    [ , FILENAME = 'os_file_name' ] 
    [ , SIZE = size [ KB | MB | GB | TB ] ] 
    [ , MAXSIZE = { max_size [ KB | MB | GB | TB ] | UNLIMITED } ] 
    [ , FILEGROWTH = growth_increment [ KB | MB | GB | TB| % ] ] 
    [ , OFFLINE ]
) 

<add_or_modify_filegroups>::=
{
    | ADD FILEGROUP filegroup_name 
    | REMOVE FILEGROUP filegroup_name 
    | MODIFY FILEGROUP filegroup_name
        { <filegroup_updatability_option> 
        | DEFAULT
        | NAME = new_filegroup_name 
        }
}
<filegroup_updatability_option>::=
{
    { READONLY | READWRITE } 
    | { READ_ONLY | READ_WRITE }
}

<set_database_options>::=
SET 
{
    { <optionspec> [ ,...n ] [ WITH <termination> ] }
}

<optionspec>::= 
{
    <db_state_option>
  | <db_user_access_option> 
  | <db_update_option>   | <external_access_option>
  | <cursor_option> 
  | <auto_option> 
  | <sql_option> 
  | <recovery_option> 
  | <database_mirroring_option>
  | <service_broker_option>
  | <date_correlation_optimization_option>
  | <parameterization_option>
}

<db_state_option> ::=
    { ONLINE | OFFLINE | EMERGENCY }

<db_user_access_option> ::=
    { SINGLE_USER | RESTRICTED_USER | MULTI_USER }

<db_update_option> ::=
    { READ_ONLY | READ_WRITE }

<external_access_option> ::=
{
    DB_CHAINING { ON | OFF }
  | TRUSTWORTHY { ON | OFF }
}

<cursor_option> ::= 
{
    CURSOR_CLOSE_ON_COMMIT { ON | OFF } 
  | CURSOR_DEFAULT { LOCAL | GLOBAL } 
}

<auto_option> ::= 
{
    AUTO_CLOSE { ON | OFF } 
  | AUTO_CREATE_STATISTICS { ON | OFF } 
  | AUTO_SHRINK { ON | OFF } 
  | AUTO_UPDATE_STATISTICS { ON | OFF } 
  | AUTO_UPDATE_STATISTICS_ASYNC { ON | OFF }
}

<sql_option> ::= 
{
    ANSI_NULL_DEFAULT { ON | OFF } 
  | ANSI_NULLS { ON | OFF } 
  | ANSI_PADDING { ON | OFF } 
  | ANSI_WARNINGS { ON | OFF } 
  | ARITHABORT { ON | OFF } 
  | CONCAT_NULL_YIELDS_NULL { ON | OFF } 
  | NUMERIC_ROUNDABORT { ON | OFF } 
  | QUOTED_IDENTIFIER { ON | OFF } 
  | RECURSIVE_TRIGGERS { ON | OFF } 
}

<recovery_option> ::= 
{
    RECOVERY { FULL | BULK_LOGGED | SIMPLE } 
  | TORN_PAGE_DETECTION { ON | OFF }
  | PAGE_VERIFY { CHECKSUM | TORN_PAGE_DETECTION | NONE }
}

<database_mirroring_option> ::= 
{ <partner_option> | <witness_option> }
    <partner_option> ::=
    PARTNER { = 'partner_server' 
            | FAILOVER 
            | FORCE_SERVICE_ALLOW_DATA_LOSS
            | OFF
            | RESUME 
            | SAFETY { FULL | OFF }
            | SUSPEND 
            | TIMEOUT integer
            }
    <witness_option> ::=
    WITNESS { = 'witness_server' 
            | OFF 
            }

<service_broker_option> ::=
{
    ENABLE_BROKER
  | DISABLE_BROKER
  | NEW_BROKER
  | ERROR_BROKER_CONVERSATIONS
}

<date_correlation_optimization_option> ::=
{
    DATE_CORRELATION_OPTIMIZATION { ON | OFF }
}

<parameterization_option> ::=
{
    PARAMETERIZATION { SIMPLE | FORCED }
}

<snapshot_option> ::=
{
    ALLOW_SNAPSHOT_ISOLATION {ON | OFF }
  | READ_COMMITTED_SNAPSHOT {ON | OFF }
}
<termination> ::= 
{
    ROLLBACK AFTER integer [ SECONDS ] 
  | ROLLBACK IMMEDIATE 
  | NO_WAIT
}

Argumente

database_name
Der Name der Datenbank, die geändert werden soll.

MODIFY NAME **=**new_database_name
Benennt die Datenbank in den als new_database_name angegebenen Namen um.

COLLATE collation_name
Gibt die Sortierung für die Datenbank an. collation_name kann entweder ein Windows-Sortierungsname oder ein SQL-Sortierungsname sein. Wenn keine Sortierung angegeben ist, wird der Datenbank die Sortierung der Instanz von SQL Server zugewiesen.

Weitere Informationen zu den Namen von Windows-Sortierreihenfolgen und zu SQL-Sortierungsnamen finden Sie unter COLLATE (Transact-SQL).

<add_or_modify_files>::=

Gibt die Datei an, die hinzugefügt, entfernt oder geändert werden soll.

ADD FILE
Fügt einer Datenbank eine Datei hinzu.
- TO FILEGROUP { filegroup_name }
  Gibt die Dateigruppe an, der die angegebene Datei hinzugefügt werden soll. Verwenden Sie die sys.filegroups-Katalogsicht, um die aktuellen Dateigruppen und die aktuelle Standarddateigruppe anzuzeigen.

ADD LOG FILE
Fügt eine Protokolldatei hinzu, die der angegebenen Datenbank hinzufügt werden soll.

REMOVE FILE logical_file_name
Entfernt die logische Dateibeschreibung aus einer Instanz von SQL Server und löscht die physikalische Datei. Die Datei kann nur entfernt werden, wenn sie leer ist.
- logical_file_name
  Der logische Dateiname, der in SQL Server beim Verweis auf die Datei verwendet wird.

MODIFY FILE
Gibt die Datei an, die geändert werden soll. Es kann jeweils nur eine <filespec>-Eigenschaft geändert werden. NAME muss zur Identifikation der Datei, die geändert werden soll, stets in <filespec> angegeben sein. Wenn SIZE angegeben ist, muss die neue Größe die aktuelle Dateigröße übersteigen.

Geben Sie in der NAME-Klausel den logischen Namen der Datei an, die umbenannt werden soll, und geben Sie in der NEWNAME-Klausel den neuen logischen Namen für die Datei an, um den logischen Namen einer Daten- oder Protokolldatei zu ändern. Beispiel:
```
MODIFY FILE ( NAME = logical_file_name, NEWNAME = new_logical_name ) 
```
Geben Sie den aktuellen logischen Dateinamen in der NAME-Klausel an, und geben Sie den neuen Pfad und den Betriebssystem-Dateinamen in der FILENAME-Klausel an, um eine Datendatei oder Protokolldatei an einen neuen Speicherort zu verschieben. Beispiel:
```
MODIFY FILE ( NAME = logical_file_name, FILENAME = ' new_path/os_file_name ' )
```
Wenn Sie einen Volltextkatalog verschieben, geben Sie nur den neuen Pfad in der FILENAME-Klausel an. Geben Sie nicht den Betriebssystem-Dateinamen an.

Weitere Informationen finden Sie unter Verschieben von Datenbankdateien.

<filespec>::=

Steuert die Dateieigenschaften.

NAME logical_file_name
Gibt den logischen Namen für die Datei an.
- logical_file_name
  Der logische Dateiname, der in einer Instanz von SQL Server beim Verweis auf die Datei verwendet wird.

NEWNAME new_logical_file_name
Gibt einen neuen logischen Namen für die Datei an.
- new_logical_file_name
  Der Name, der den vorhandenen logischen Dateinamen ersetzen soll. Der Name muss in der Datenbank eindeutig sein und den Regeln für Bezeichner entsprechen. Der Name kann eine Zeichen- oder Unicodekonstante, ein regulärer Bezeichner oder ein begrenzter Bezeichner sein. Weitere Informationen finden Sie unter Verwenden von Bezeichnern als Objektnamen.

FILENAME 'os_file_name'
Gibt den (physikalischen) Betriebssystem-Dateinamen an.
- ' os_file_name '
  Der Pfad und der Dateiname, die beim Erstellen der Datei vom Betriebssystem verwendet werden. Die Datei muss sich auf dem Server befinden, auf dem SQL Server installiert ist. Der angegebene Pfad muss vorhanden sein, bevor die ALTER DATABASE-Anweisung ausgeführt wird.
  
  Die Parameter SIZE, MAXSIZE und FILEGROWTH können nicht festgelegt werden, wenn für die Datei ein UNC-Pfad angegeben ist.
  
  Datendateien sollten nicht in komprimierten Dateisystemen abgelegt werden, es sei denn, es handelt es sich bei den Dateien um schreibgeschützte sekundäre Dateien, oder die Datenbank ist schreibgeschützt. Protokolldateien sollten niemals in komprimierten Dateisystemen abgelegt werden. Weitere Informationen finden Sie unter Schreibgeschützte Dateigruppen und Komprimierung.
  
  Wenn sich die Datei auf einer Rawpartition befindet, darf os_file_name nur den Laufwerkbuchstaben einer vorhandenen Rawpartition angeben. Auf jeder Rawpartition kann nur eine Datei abgelegt werden.

SIZE size
Gibt die Dateigröße an.
- size
  Die Größe der Datei.
  
  In Verbindung mit ADD FILE ist size die Anfangsgröße für die Datei. In Verbindung mit MODIFY FILE ist size die neue Größe für die Datei und muss größer als die aktuelle Dateigröße sein.
  
  Wenn in size für die primäre Datei nicht angegeben wird, verwendet SQL Server 2005-Datenbankmodul die Größe der primären Datei in der model-Datenbank. Wenn eine sekundäre oder Protokolldatei angegeben wird, size jedoch nicht für die Datei angegeben wird, legt Datenbankmodul die Größe der Datei auf 1 MB fest.
  
  Die Suffixe KB, MB, GB und TB können verwendet werden, um Kilobyte, Megabyte, Gigabyte oder Terabyte als Einheit anzugeben. Die Standardeinheit ist MB. Geben Sie eine ganze Zahl (also ohne Dezimalstellen) an. Konvertieren Sie den Wert in Kilobyte, indem Sie die Zahl mit 1024 multiplizieren, um einen Bruchteil eines Megabyte anzugeben. Geben Sie z. B. 1536 KB anstelle von 1,5 MB an (1,5 x 1024 = 1536).

MAXSIZE { max_size| UNLIMITED }
Gibt die maximale Größe an, auf die die Datei vergrößert werden kann.
- max_size
  Die maximale Dateigröße. Die Suffixe KB, MB, GB und TB können verwendet werden, um Kilobyte, Megabyte, Gigabyte oder Terabyte als Einheit anzugeben. Die Standardeinheit ist MB. Geben Sie eine ganze Zahl (also ohne Dezimalstellen) an. Wenn max_size nicht angegeben ist, kann die Datei so lange vergrößert werden, bis der Speicherplatz auf dem Datenträger erschöpft ist.
- UNLIMITED
  Gibt an, dass die Datei vergrößert wird, bis der Datenträger voll ist. In SQL Server 2005 hat eine Protokolldatei, für die eine unbegrenzte Vergrößerung angegeben ist, eine maximale Größe von 2 TB und eine Datendatei eine maximale Größe von 16 TB.

FILEGROWTH growth_increment
Gibt das Inkrement der automatischen Vergrößerung der Datei an. Die FILEGROWTH-Einstellung für eine Datei darf die MAXSIZE-Einstellung nicht überschreiten.

growth_increment
Die Menge an Speicherplatz, die jedes Mal der Datei hinzugefügt wird, sobald neuer Speicherplatz erforderlich wird.

Der Wert kann in MB, KB, GB, TB oder Prozent (%) angegeben werden. Bei Zahlen ohne Angabe von MB, KB oder % wird standardmäßig MB verwendet. Wenn der Wert in Prozent angegeben wird, ist die growth_increment-Größe der angegebene Prozentsatz der Dateigröße zum Zeitpunkt der Vergrößerung. Die angegebene Größe wird auf den nächsten durch 64 KB teilbaren Wert gerundet.

Der Wert 0 gibt an, dass die automatische Vergrößerung deaktiviert und kein zusätzlicher Speicherplatz zugelassen ist.

Ist FILEGROWTH nicht angegeben, liegt der Standardwert bei 1 MB für Datendateien und 10 % für Protokolldateien. Der Mindestwert ist 64 KB.

Hinweis:
In SQL Server 2005 wurde das Standardinkrement für die Vergrößerung von Datendateien von 10 % in 1 MB geändert. Das Standardinkrement für Protokolldateien liegt unverändert bei 10 %.

OFFLINE
Legt die Datei auf offline fest und sperrt den Zugriff auf alle Objekte in der Dateigruppe.

Vorsicht:
Diese Option sollte nur verwendet werden, wenn die Datei beschädigt ist und wiederhergestellt werden kann. Eine Datei, für die OFFLINE festgelegt ist, kann nur wieder online geschaltet werden, indem sie aus der Sicherung wiederhergestellt wird. Weitere Informationen zum Wiederherstellen einer einzelnen Datei finden Sie unter RESTORE (Transact-SQL).

<add_or_modify_filegroups>::=

Hinzufügen, Ändern oder Entfernen einer Dateigruppe aus der Datenbank.

ADD FILEGROUP filegroup_name
Fügt der Datenbank eine Dateigruppe hinzu.

REMOVE FILEGROUP filegroup_name
Entfernt eine Dateigruppe aus der Datenbank. Die Dateigruppe kann nur entfernt werden, wenn sie leer ist. Entfernen Sie zuerst alle Dateien aus der Dateigruppe. Weitere Informationen finden Sie unter "REMOVE FILE logical_file_name" weiter oben in diesem Thema.

MODIFY FILEGROUP filegroup_name { <filegroup_updatability_option> | DEFAULT | NAME **=**new_filegroup_name }
Ändert die Dateigruppe durch Festlegen des Status auf READ_ONLY oder READ_WRITE, Festlegen der Dateigruppe als Standarddateigruppe für die Datenbank oder Ändern des Dateigruppennamens.
- <filegroup_updatability_option>
  Legt die read-only- oder read/write-Eigenschaft für die Dateigruppe fest.
- DEFAULT
  Ändert die Standarddatenbank-Dateigruppe in filegroup_name. Es können nicht mehrere Dateigruppen gleichzeitig als Standarddateigruppe verwendet werden. Weitere Informationen finden Sie unter Grundlegendes zu Dateien und Dateigruppen.
- NAME = new_filegroup_name
  Ändert den Namen der Dateigruppe in new_filegroup_name.

<filegroup_updatability_option>::=

Legt die read-only- oder read/write-Eigenschaft für die Dateigruppe fest.

READ_ONLY | READONLY
Gibt an, dass die Dateigruppe schreibgeschützt ist. Aktualisierungen von Objekten in der Dateigruppe sind nicht zulässig. Die primäre Dateigruppe kann nicht schreibgeschützt werden. Sie müssen über exklusiven Zugriff auf die Datenbank verfügen, um diesen Status zu ändern. Weitere Informationen finden Sie unter der SINGLE_USER-Klausel.

Da in einer schreibgeschützten Datenbank keine Datenänderungen vorgenommen werden dürfen, gilt Folgendes:

Die automatische Wiederherstellung wird beim Systemstart ausgelassen.
Das Verkleinern der Datenbank ist nicht möglich.
In schreibgeschützten Datenbanken werden keine Daten gesperrt. Dies kann zu einer schnelleren Ausführung von Abfragen führen.

Hinweis:
Das Schlüsselwort READONLY wird in zukünftigen Versionen von Microsoft SQL Server nicht mehr bereitgestellt. Vermeiden Sie die Verwendung von READONLY bei neuen Entwicklungen, und planen Sie die Änderung von Anwendungen, in denen READONLY aktuell verwendet wird. Verwenden Sie stattdessen READ_ONLY.

READ_WRITE | READWRITE
Gibt an, dass die Gruppe den Status READ_WRITE hat. Aktualisierungen sind für die Objekte in der Dateigruppe möglich. Sie müssen über exklusiven Zugriff auf die Datenbank verfügen, um diesen Status zu ändern. Weitere Informationen finden Sie unter der SINGLE_USER-Klausel.

Hinweis:
Das Schlüsselwort READWRITE wird in zukünftigen Versionen von Microsoft SQL Server nicht mehr bereitgestellt. Vermeiden Sie die Verwendung von READWRITE bei neuen Entwicklungen, und planen Sie die Änderung von Anwendungen, in denen READWRITE aktuell verwendet wird. Verwenden Sie stattdessen READ_WRITE.

Der Status dieser Optionen kann mithilfe der Spalte is_read_only in der sys.databases-Katalogsicht oder der Updateability-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

<db_state_option>::=

Steuert den Status der Datenbank.

OFFLINE
Die Datenbank ist geschlossen, ordnungsgemäß heruntergefahren und als offline gekennzeichnet. Die Datenbank kann nicht geändert werden, während sie als offline gekennzeichnet ist.

ONLINE
Die Datenbank ist geöffnet und kann verwendet werden.

EMERGENCY
Die Datenbank ist mit READ_ONLY gekennzeichnet, die Protokollierung ist deaktiviert und der Zugriff beschränkt auf Mitglieder der festen Serverrolle sysadmin. EMERGENCY wird in erster Linie zur Problembehandlung verwendet. Beispielsweise kann für eine Datenbank, die aufgrund einer beschädigten Protokolldatei als fehlerverdächtig gekennzeichnet ist, der Status EMERGENCY festgelegt werden. Dadurch wird u. U. für den Systemadministrator der schreibgeschützte Zugriff auf die Datenbank aktiviert. Nur Mitglieder der festen Serverrolle sysadmin können für eine Datenbank den Status EMERGENCY festlegen.

Der Status dieser Option kann mithilfe der Spalten state und state_desc in der sys.databases-Katalogsicht oder der Status-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden. Weitere Informationen finden Sie unter Datenbankstatus.

Für eine Datenbank, die als RESTORING gekennzeichnet ist, kann nicht OFFLINE, ONLINE oder EMERGENCY festgelegt werden. Im Status RESTORING kann eine Datenbank sich während eines aktiven Wiederherstellungsvorgangs befinden oder wenn ein Wiederherstellungsvorgang einer Datenbank oder Protokolldatei aufgrund einer beschädigten Sicherungsdatei fehlschlägt. Weitere Informationen finden Sie unter Reagieren auf SQL Server-Wiederherstellungsfehler als Folge von beschädigten Sicherungen.

<db_user_access_option> ::=

Steuert den Benutzerzugriff auf die Datenbank.

SINGLE_USER
Gibt an, dass jeweils nur ein Benutzer auf die Datenbank zugreifen kann. Wenn SINGLE_USER angegeben ist und andere Benutzer mit der Datenbank verbunden sind, wird die ALTER DATABASE-Anweisung blockiert, bis alle Benutzer die Verbindung mit der angegebenen Datenbank trennen. Informationen zum Außerkraftsetzen dieses Verhaltens finden Sie unter der WITH <termination>-Klausel.

Die Datenbank verbleibt im SINGLE_USER-Modus, selbst wenn sich der Benutzer, der die Option festgelegt hat, abmeldet. Dadurch kann ein anderer Benutzer (aber nur einer) eine Verbindung mit der Datenbank herstellen.

Bevor Sie die Datenbank auf SINGLE_USER festlegen, müssen Sie überprüfen, ob die Option AUTO_UPDATE_STATISTICS_ASYNC auf OFF festgelegt ist. Wenn der Hintergrundthread, der zum Aktualisieren von Statistiken verwendet wird, auf ON festgelegt wird, wird eine Verbindung mit der Datenbank hergestellt, und Sie können im Einzelbenutzermodus nicht auf die Datenbank zugreifen. Fragen Sie zum Anzeigen des Status dieser Option die is_auto_update_stats_async_on-Spalte in der Katalogsicht sys.databases ab. Wenn die Option auf ON festgelegt wird, sollten Sie folgende Aufgaben ausführen:
1. Legen Sie AUTO_UPDATE_STATISTICS_ASYNC auf OFF fest.
2. Führen Sie eine Überprüfung auf aktive asynchrone Statistikaufträge aus, indem Sie die dynamische Verwaltungssicht sys.dm_exec_background_job_queue abfragen.
3. Wenn aktive Aufträge vorhanden sind, warten Sie, bis die Aufträge abgeschlossen sind, oder beenden Sie sie manuell mithilfe von KILL STATS JOB.

RESTRICTED_USER
RESTRICTED_USER ermöglicht nur Mitgliedern der festen Datenbankrolle db_owner und der festen Serverrollen dbcreator und sysadmin eine Verbindung mit der Datenbank, begrenzt jedoch nicht deren Anzahl. Alle Verbindungen zur Datenbank werden in dem durch die Beendigungsklausel der ALTER DATABASE-Anweisung angegebenen Zeitraum getrennt. Sobald die Datenbank in den Status RESTRICTED_USER gewechselt hat, werden Verbindungsversuche von nicht qualifizierten Benutzern abgelehnt.

MULTI_USER
Alle Benutzer, die über die entsprechenden Berechtigungen für die Verbindung mit der Datenbank verfügen, sind zugelassen.

Der Status dieser Option kann mithilfe der Spalte user_access in der sys.databases-Katalogsicht oder der UserAccess-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

<db_update_option>::=

Steuert, ob Aktualisierungen für die Datenbank zugelassen sind.

READ_ONLY
Benutzer können Daten aus der Datenbank lesen, aber nicht ändern.

READ_WRITE
Die Datenbank ist für Lese- und Schreibvorgänge verfügbar.

Sie müssen über exklusiven Zugriff auf die Datenbank verfügen, um diesen Status zu ändern. Weitere Informationen finden Sie unter der SINGLE_USER-Klausel.

<external_access_option>::=

Steuert, ob externe Ressourcen, z. B. Objekte aus einer anderen Datenbank, auf die Datenbank zugreifen können.

DB_CHAINING { ON | OFF }

ON
Die Datenbank kann Quelle oder Ziel einer datenbankübergreifenden Besitzverkettung sein.

OFF
Die Datenbank kann nicht an der datenbankübergreifenden Besitzverkettung teilnehmen.

Wichtig:
Die Instanz von SQL Server erkennt diese Einstellung, wenn die Serveroption cross db ownership chaining deaktiviert (0) ist. Wenn cross db ownership chaining aktiviert (1) ist, können alle Benutzerdatenbanken unabhängig vom Wert der Option an datenbankübergreifenden Besitzverkettungen teilnehmen. Diese Option wird mithilfe von sp_configure festgelegt.

Um diese Option festzulegen, ist die Mitgliedschaft in der festen Serverrolle sysadmin erforderlich. Die Option DB_CHAINING kann für folgende Systemdatenbanken nicht festgelegt werden: master, model und tempdb.

Der Status der Option kann mithilfe der Spalte is_db_chaining_on in der sys.databases-Katalogsicht ermittelt werden.

Weitere Informationen finden Sie unter Besitzketten.

TRUSTWORTHY { ON | OFF }
- ON
  Datenbankmodule (z. B. benutzerdefinierte Funktionen oder gespeicherte Prozeduren), die einen Identitätswechselkontext verwenden, können auf Ressourcen außerhalb der Datenbank zugreifen.
- OFF
  Datenbankmodule in einem Identitätswechselkontext können nicht auf Ressourcen außerhalb der Datenbank zugreifen.
TRUSTWORTHY wird auf OFF festgelegt, sobald die Datenbank angefügt wird.

Standardmäßig ist TRUSTWORTHY für alle Systemdatenbanken mit Ausnahme der msdb-Datenbank auf OFF festgelegt. Für die model-Datenbank und für die tempdb-Datenbank kann der Wert nicht geändert werden. Für die master-Datenbank sollten Sie die Option TRUSTWORTHY niemals auf ON festlegen.

Sie müssen Mitglied der festen Serverrolle sysadmin sein, um diese Option festlegen zu können.

Der Status der Option kann mithilfe der Spalte is_trustworthy_on in der sys.databases-Katalogsicht ermittelt werden.

<cursor_option>::=

Steuert Cursoroptionen.

CURSOR_CLOSE_ON_COMMIT { ON | OFF }
- ON
  Alle beim Commit oder Rollback einer Transaktion geöffneten Cursor werden geschlossen.
- OFF
  Cursor bleiben beim Commit einer Transaktion geöffnet. Beim Rollback einer Transaktion werden alle Cursor geschlossen, sofern sie nicht als INSENSITIVE oder STATIC definiert sind.
Einstellungen auf Verbindungsebene, die mithilfe der SET-Anweisung festgelegt werden, setzen die Standardeinstellung der Datenbank für CURSOR_CLOSE_ON_COMMIT außer Kraft. ODBC- und OLE DB-Clients geben standardmäßig eine SET-Anweisung aus, durch die CURSOR_CLOSE_ON_COMMIT für die Sitzung auf OFF festgelegt wird, wenn sie eine Verbindung mit einer Instanz von SQL Server herstellen. Weitere Informationen finden Sie unter SET CURSOR_CLOSE_ON_COMMIT (Transact-SQL).

Der Status dieser Option kann mithilfe der Spalte is_cursor_close_on_commit_on in der sys.databases-Katalogsicht oder der IsCloseCursorsOnCommitEnabled-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

CURSOR_DEFAULT { LOCAL | GLOBAL }
Steuert, ob der Cursorbereich LOCAL oder GLOBAL verwendet.
- LOCAL
  Wenn LOCAL angegeben ist und beim Erstellen kein Cursor als GLOBAL definiert wird, ist der Gültigkeitsbereich des Cursors lokal zu dem Batch, der gespeicherten Prozedur oder dem Trigger, in dem bzw. der er erstellt wurde. Der Cursorname ist nur innerhalb dieses Bereichs gültig. Auf den Cursor kann durch lokale Cursorvariablen im Batch, in der gespeicherten Prozedur, im Trigger oder im OUTPUT-Parameter einer gespeicherten Prozedur verwiesen werden. Die Zuordnung des Cursors wird implizit aufgehoben, wenn der Batch, die gespeicherte Prozedur oder der Trigger beendet wird, es sei denn, der Cursor wird in einem OUTPUT-Parameter zurückgegeben. Wenn die Rückgabe in einem OUTPUT-Parameter erfolgt, wird die Zuordnung des Cursors aufgehoben, wenn die Zuordnung der letzten auf ihn verweisenden Variablen aufgehoben wird oder wenn der Cursor den Gültigkeitsbereich verlässt.
- GLOBAL
  Wenn GLOBAL angegeben ist und beim Erstellen kein Cursor als LOCAL definiert wird, ist der Gültigkeitsbereich des Cursors global zu der Verbindung. Auf den Cursornamen kann in jeder gespeicherten Prozedur und in jedem Batch verwiesen werden, die bzw. der von der Verbindung ausgeführt wird.
Die Zuordnung des Cursors wird implizit nur aufgehoben, wenn die Verbindung getrennt wird. Weitere Informationen finden Sie unter DECLARE CURSOR (Transact-SQL).

Der Status dieser Option kann mithilfe der Spalte is_local_cursor_default in der sys.databases-Katalogsicht oder der IsLocalCursorsDefault-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

<auto_option>::=

Steuert automatische Optionen.

AUTO_CLOSE { ON | OFF }

ON
Die Datenbank wird ordnungsgemäß heruntergefahren, und ihre Ressourcen werden freigegeben, wenn der letzte Benutzer die Arbeit beendet hat.

Die Datenbank wird automatisch wieder geöffnet, wenn ein Benutzer versucht, die Datenbank erneut zu verwenden. Beispielsweise durch Ausgeben einer USE database_name-Anweisung. Wurde die Datenbank ordnungsgemäß heruntergefahren und ist AUTO_CLOSE auf ON festgelegt, wird sie beim nächsten Start des Datenbankmodul erst dann wieder geöffnet, wenn ein Benutzer versucht, die Datenbank zu verwenden.

OFF
Die Datenbank bleibt nach dem Beenden der Verwendung durch den letzten Benutzer geöffnet.

Die Option AUTO_CLOSE ist sehr nützlich für Desktopdatenbanken, da mit ihrer Hilfe Datenbankdateien wie reguläre Dateien verwaltet werden können. Sie können verschoben, zur Sicherung kopiert oder sogar mit einer E-Mail an andere Benutzer gesendet werden.

Hinweis:
In früheren Versionen von SQL Server ist AUTO_CLOSE ein synchroner Prozess, der die Leistung beeinträchtigen kann, wenn eine Anwendung auf die Datenbank zugreift, die wiederholt Verbindungen zum Datenbankmodul herstellt und abbricht. In SQL Server 2005 ist AUTO_CLOSE ein asynchroner Prozess. Das wiederholte Öffnen und Schließen der Datenbank führt nicht mehr zu einer Beeinträchtigung der Leistung.

In früheren Versionen von SQL Server ist AUTO_CLOSE ein synchroner Prozess, der die Leistung beeinträchtigen kann, wenn eine Anwendung auf die Datenbank zugreift, die wiederholt Verbindungen zum Datenbankmodul herstellt und abbricht. In SQL Server 2005 ist AUTO_CLOSE ein asynchroner Prozess. Das wiederholte Öffnen und Schließen der Datenbank führt nicht mehr zu einer Beeinträchtigung der Leistung.

Der Status dieser Option kann mithilfe der Spalte is_auto_close_on in der sys.databases-Katalogsicht oder der IsAutoClose-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

Hinweis:
Ist AUTO_CLOSE auf ON festgelegt, geben einige Spalten in der sys.databases-Katalogsicht und DATABASEPROPERTYEX-Funktion den Wert NULL zurück, da die Datenbank nicht für den Abruf der Daten verfügbar ist. Führen Sie eine USE-Anwendung zum Öffnen der Datenbank aus, um dieses Problem zu beheben.

Hinweis:
Für die Datenbankspiegelung muss AUTO_CLOSE deaktiviert sein (OFF).

Wenn die Datenbank auf AUTOCLOSE = ON festgelegt ist, wird mit einem Vorgang, bei dem das automatische Beenden der Datenbank initiiert wird, der Plancache für die Instanz von SQL Server gelöscht. Durch das Löschen des Plancaches wird eine Neukompilierung aller nachfolgenden Ausführungspläne verursacht, und möglicherweise entsteht plötzlich eine temporäre Verringerung der Abfrageleistung. In SQL Server 2005 Service Pack 2 enthält das SQL Server-Fehlerprotokoll für jeden geleerten Cachespeicher im Plancache folgende Meldung zur Information: "SQL Server hat für den '%s'-Cachespeicher (Bestandteil des Plancache) %d Leerungen des Cachespeichers gefunden, die von Datenbankwartungs- oder Neukonfigurierungsvorgängen ausgelöst wurden". Diese Meldung wird alle fünf Minuten protokolliert, solange der Cache innerhalb dieses Zeitintervalls geleert wird.

AUTO_CREATE_STATISTICS { ON | OFF }

ON
Fehlende Statistiken, die von einer Abfrage für die Optimierung benötigt werden, werden automatisch während der Abfrageoptimierung erstellt.

Durch das Hinzufügen von Statistiken wird die Abfrageleistung verbessert, da der SQL Server-Abfrageoptimierer besser bestimmen kann, wie eine Abfrage ausgewertet werden muss. Wenn die Statistiken nicht verwendet werden, werden sie vom Datenbankmodul automatisch gelöscht. Ist diese Option auf OFF festgelegt, werden Statistiken nicht automatisch erstellt; stattdessen können sie manuell erstellt werden. Weitere Informationen finden Sie unter Indexstatistiken.

OFF
Statistiken müssen manuell erstellt werden.

Der Status dieser Option kann mithilfe der Spalte is_auto_update_stats_on in der sys.databases-Katalogsicht oder der IsAutoUpdateStatistics-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

Hinweis:
Der Abfrageoptimierer behandelt alle internen Systemtabellen so, als ob für AUTO_CREATE_STATISTICS die Einstellung ON festgelegt ist, unabhängig von der tatsächlichen Einstellung. Zu diesen Tabellen gehören Systembasistabellen, XML-Indizes, Volltextindizes, Service Broker-Warteschlangentabellen und Abfragebenachrichtigungstabellen.

AUTO_SHRINK { ON | OFF }
- ON
  Die Datenbankdateien sind Kandidaten für das automatische periodische Verkleinern.
  
  Sowohl Daten- als auch Protokolldateien können verkleinert werden. AUTO_SHRINK reduziert die Größe des Transaktionsprotokolls nur, wenn für die Datenbank das einfache Wiederherstellungsmodell festgelegt ist oder wenn das Protokoll gesichert wird. Ist diese Option auf OFF festgelegt, werden die Datenbankdateien während der periodisch ausgeführten Überprüfung auf nicht verwendeten Speicherplatz nicht automatisch verkleinert.
  
  Durch die Option AUTO_SHRINK werden Dateien dann verkleinert, wenn mehr als 25 Prozent der Datei aus nicht verwendetem Speicherplatz bestehen. Die Datei wird auf eine Größe verkleinert, bei der 25 Prozent der Datei aus nicht verwendetem Speicherplatz bestehen, oder auf die Größe, mit der die Datei erstellt wurde, je nachdem, welcher Wert größer ist.
  
  Eine schreibgeschützte Datenbank kann nicht verkleinert werden.
- OFF
  Die Datenbankdateien werden bei periodischen Prüfungen auf nicht verwendeten Speicherplatz nicht automatisch verkleinert.
Der Status dieser Option kann mithilfe der Spalte is_auto_shrink_on in der sys.databases-Katalogsicht oder der IsAutoShrink-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden. .

AUTO_UPDATE_STATISTICS { ON | OFF }

ON
Veraltete Statistiken, die von einer Abfrage für die Optimierung benötigt werden, werden automatisch während der Abfrageoptimierung aktualisiert.

OFF
Statistiken müssen manuell aktualisiert werden.

Hinweis:
Mit der UPDATE STATISTICS-Anweisung wird die automatische statistische Aktualisierung für die Zieltabelle oder -sicht wieder aktiviert, es sei denn, die NORECOMPUTE-Klausel ist aktiviert.

Hinweis:
Der Abfrageoptimierer behandelt alle internen Systemtabellen so, als ob für AUTO_UPDATE_STATISTICS die Einstellung ON festgelegt ist, unabhängig von der eigentlichen Einstellung. Zu diesen Tabellen gehören Systembasistabellen, XML-Indizes, Volltextindizes, Service Broker-Warteschlangentabellen und Abfragebenachrichtigungstabellen.

Weitere Informationen finden Sie unter Indexstatistiken.

AUTO_UPDATE_STATISTICS_ASYNC { ON | OFF }
- ON
  Abfragen, die eine automatische Aktualisierung veralteter Statistiken initiieren, warten vor dem Kompilieren nicht, bis die Statistiken aktualisiert sind. Nachfolgende Abfragen verwenden die aktualisierten Statistiken, sobald diese verfügbar sind.
- OFF
  Abfragen, die eine automatische Aktualisierung veralteter Statistiken initiieren, warten, bis die aktualisierten Statistiken im Abfrageoptimierungsplan verwendet werden können.
Das Festlegen dieser Option auf ON hat nur dann Auswirkungen, wenn AUTO_UPDATE_STATISTICS auf ON festgelegt ist.

Weitere Informationen finden Sie unter Indexstatistiken.

<sql_option>::=

Steuert die ANSI-Kompatibilitätsoptionen auf der Datenbankebene.

ANSI_NULL_DEFAULT { ON | OFF }
Bestimmt den Standardwert, NULL oder NOT NULL, einer Spalte, eines Aliasdatentyps oder eines CLR-benutzerdefinierten Typs, für den die NULL-Zulässigkeit nicht explizit in den Anweisungen CREATE TABLE oder ALTER TABLE definiert ist. Spalten, die mit Einschränkungen definiert werden, folgen den Einschränkungsregeln, und zwar ungeachtet dieser Einstellung.
- ON
  Der Standardwert ist NULL.
- OFF
  Der Standardwert ist NOT NULL.
Einstellungen auf Verbindungsebene, die mithilfe der SET-Anweisung festgelegt werden, setzen die Standardeinstellung der Datenbank für ANSI_NULL_DEFAULT außer Kraft. ODBC- und OLE DB-Clients geben standardmäßig eine SET-Anweisung aus, durch die ANSI_NULL_DEFAULT für die Sitzung auf ON festgelegt wird, wenn sie eine Verbindung mit einer Instanz von SQL Server herstellen. Weitere Informationen finden Sie unter SET ANSI_NULL_DFLT_ON (Transact-SQL).

Für die ANSI-Kompatibilität wird durch Festlegen der Datenbankoption ANSI_NULL_DEFAULT auf ON der Datenbankstandardwert auf NULL geändert.

Der Status dieser Option kann mithilfe der Spalte is_ansi_null_default_on in der sys.databases-Katalogsicht oder der IsAnsiNullDefault-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

ANSI_NULLS { ON | OFF }
- ON
  Alle Vergleiche mit einem Nullwert ergeben UNKNOWN.
- OFF
  Vergleiche von Nicht-UNICODE-Werten mit einem Nullwert ergeben TRUE, wenn beide Werte NULL sind.
Einstellungen auf Verbindungsebene, die mithilfe der SET-Anweisung festgelegt werden, setzen die Standardeinstellung der Datenbank für ANSI_NULLS außer Kraft. ODBC- und OLE DB-Clients geben standardmäßig eine SET-Anweisung aus, durch die ANSI_NULLS für die Sitzung auf ON festgelegt wird, wenn sie eine Verbindung mit einer Instanz von SQL Server herstellen. Weitere Informationen finden Sie unter SET ANSI_NULLS (Transact-SQL).

SET ANSI_NULLS muss ebenfalls auf ON festgelegt sein, wenn Sie Indizes auf berechneten Spalten oder indizierten Sichten erstellen oder ändern.

Der Status dieser Option kann mithilfe der Spalte is_ansi_null_on in der sys.databases-Katalogsicht oder der IsAnsiNullsEnabled-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

ANSI_PADDING { ON | OFF }

ON
Zeichenfolgen werden vor der Konvertierung oder dem Einfügen in einen varchar- oder nvarchar-Datentyp durch Einfügen von Leerstellen auf dieselbe Länge gebracht.

Nachfolgende Leerzeichen in Zeichenwerten, die in varchar- oder nvarchar-Spalten eingefügt werden, und nachfolgende Nullen in Binärwerten, die in varbinary-Spalten eingefügt werden, werden nicht abgeschnitten. Werte werden nicht bis zur Spaltenlänge aufgefüllt.

OFF
Nachfolgende Leerzeichen für varchar oder nvarchar und Nullen für varbinary werden abgeschnitten.

Ist OFF festgelegt, wirkt sich diese Einstellung nur auf die Definition neuer Spalten aus.

char(n)- und binary(n)-Spalten, die Nullen zulassen, werden durch Einfügen von Leerzeichen auf die Länge der Spalte gebracht, wenn ANSI_PADDING auf ON festgelegt ist, aber nachfolgende Leerzeichen und Nullen werden abgeschnitten, wenn ANSI_PADDING auf OFF festgelegt ist. char(n)- und binary(n)-Spalten, die keine Nullen zulassen, werden stets durch Einfügen von Leerzeichen auf die Länge der Spalte gebracht.

Einstellungen auf Verbindungsebene, die mithilfe der SET-Anweisung festgelegt werden, setzen die Standardeinstellung der Datenbank für ANSI_PADDING außer Kraft. ODBC- und OLE DB-Clients geben standardmäßig eine SET-Anweisung aus, durch die ANSI_PADDING für die Sitzung auf ON festgelegt wird, wenn sie eine Verbindung mit einer Instanz von SQL Server herstellen. Weitere Informationen finden Sie unter SET ANSI_PADDING (Transact-SQL).

Wichtig:
Es wird empfohlen, ANSI_PADDING stets auf ON festzulegen. ANSI_PADDING muss beim Erstellen oder Bearbeiten von Indizes auf berechneten Spalten oder indizierten Sichten auf ON festgelegt sein.

Der Status dieser Option kann mithilfe der Spalte is_ansi_padding_on in der sys.databases-Katalogsicht oder der IsAnsiPaddingEnabled-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

ANSI_WARNINGS { ON | OFF }
- ON
  Fehler oder Warnungen werden ausgegeben, wenn Bedingungen wie eine Division durch Null oder Nullwerte in Aggregatfunktionen auftreten.
- OFF
  Bei Bedingungen wie einer Division durch Null werden keine Warnungen ausgegeben, und Nullwerte werden zurückgegeben.
SET ANSI_WARNINGS muss auf ON festgelegt sein, wenn Sie Indizes auf berechneten Spalten oder indizierten Sichten erstellen oder ändern.

Einstellungen auf Verbindungsebene, die mithilfe der SET-Anweisung festgelegt werden, setzen die Standardeinstellung der Datenbank für ANSI_WARNINGS außer Kraft. ODBC- und OLE DB-Clients geben standardmäßig eine SET-Anweisung aus, durch die ANSI_WARNINGS für die Sitzung auf ON festgelegt wird, wenn sie eine Verbindung mit einer Instanz von SQL Server herstellen. Weitere Informationen finden Sie unter SET ANSI_WARNINGS (Transact-SQL).

Der Status dieser Option kann mithilfe der Spalte is_ansi_warnings_on in der sys.databases-Katalogsicht oder der IsAnsiWarningsEnabled-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

ARITHABORT { ON | OFF }
- ON
  Eine Abfrage wird beendet, wenn während der Abfrage ein Überlauffehler oder ein Fehler aufgrund einer Division durch Null auftritt.
- OFF
  Es wird eine Warnmeldung angezeigt, wenn einer dieser Fehler auftritt. Die Abfrage, der Batch oder die Transaktion wird jedoch so fortgeführt, als sei kein Fehler aufgetreten.
SET ARITHABORT muss auf ON festgelegt sein, wenn Sie Indizes auf berechneten Spalten oder indizierten Sichten erstellen oder ändern.

Der Status dieser Option kann mithilfe der Spalte is_arithabort_on in der sys.databases-Katalogsicht oder der IsArithmeticAbortEnabled-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

CONCAT_NULL_YIELDS_NULL { ON | OFF }
- ON
  Das Ergebnis einer Verkettungsoperation ist NULL, wenn einer der Operanden NULL ist. Wenn z. B. die Zeichenfolge "This is" und NULL verkettet wird, ist das Ergebnis NULL statt "This is".
- OFF
  Der Nullwert wird als leere Zeichenfolge behandelt.
CONCAT_NULL_YIELDS_NULL muss auf ON festgelegt sein, wenn Sie Indizes auf berechneten Spalten oder indizierten Sichten erstellen oder ändern.

Einstellungen auf Verbindungsebene, die mithilfe der SET-Anweisung festgelegt werden, setzen die Standardeinstellung der Datenbank für CONCAT_NULL_YIELDS_NULL außer Kraft. ODBC- und OLE DB-Clients geben standardmäßig eine SET-Anweisung aus, durch die CONCAT_NULL_YIELDS_NULL für die Sitzung auf ON festgelegt wird, wenn sie eine Verbindung mit einer Instanz von SQL Server herstellen. Weitere Informationen finden Sie unter SET CONCAT_NULL_YIELDS_NULL (Transact-SQL).

Der Status dieser Option kann mithilfe der Spalte is_concat_null_yields_null_on in der sys.databases-Katalogsicht oder der IsNullConcat-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

QUOTED_IDENTIFIER { ON | OFF }
- ON
  Doppelte Anführungszeichen können nur zum Einschließen begrenzter Bezeichner verwendet werden.
  
  Alle Zeichenfolgen, die durch doppelte Anführungszeichen begrenzt werden, werden als Objektbezeichner interpretiert. Bezeichner in Anführungszeichen müssen nicht den Transact-SQL-Regeln für Bezeichner entsprechen. Sie können Schlüsselwörter darstellen und Zeichen einschließen, die in Transact-SQL-Bezeichnern sonst nicht zulässig sind. Ein einfaches Anführungszeichen (’), das zur Literalzeichenfolge selbst gehört, kann durch doppelte Anführungszeichen (’’) dargestellt werden.
- OFF
  Bezeichner dürfen nicht in Anführungszeichen eingeschlossen werden und müssen allen Transact-SQL-Regeln für Bezeichner entsprechen. Literale können in einfache oder doppelte Anführungszeichen gesetzt werden.
In SQL Server ist es zudem möglich, Bezeichner durch eckige Klammern ([ ]) zu begrenzen. Eckige Klammern als Begrenzungszeichen können jederzeit verwendet werden. Die Einstellung für QUOTED_IDENTIFIER spielt keine Rolle. Weitere Informationen finden Sie unter Begrenzte Bezeichner (Datenbankmodul).

Beim Erstellen einer Tabelle wird die Option QUOTED IDENTIFIER immer als ON in den Metadaten der Tabelle gespeichert, selbst wenn die Option beim Erstellen der Tabelle auf OFF festgelegt war.

Einstellungen auf Verbindungsebene, die mithilfe der SET-Anweisung festgelegt werden, setzen die Standardeinstellung der Datenbank für QUOTED_IDENTIFIER außer Kraft. ODBC- und OLE DB-Clients geben standardmäßig eine SET-Anweisung aus, durch die QUOTED_IDENTIFIER auf ON festgelegt wird, wenn sie eine Verbindung mit SQL Server herstellen. Weitere Informationen finden Sie unter SET QUOTED_IDENTIFIER (Transact-SQL).

Der Status dieser Option kann mithilfe der Spalte is_quoted_identifier_on in der sys.databases-Katalogsicht oder der IsQuotedIdentifiersEnabled-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

NUMERIC_ROUNDABORT { ON | OFF }
- ON
  Es wird ein Fehler generiert, wenn ein Genauigkeitsverlust in einem Ausdruck auftritt.
- OFF
  Bei Genauigkeitsverlusten werden keine Fehlermeldungen generiert, und das Ergebnis wird auf die Genauigkeit der Spalte oder Variablen gerundet, die das Ergebnis speichert.
NUMERIC_ROUNDABORT muss auf OFF festgelegt sein, wenn Sie Indizes auf berechneten Spalten oder indizierten Sichten erstellen oder ändern.

Der Status dieser Option kann mithilfe der Spalte is_numeric_roundabort_on in der sys.databases-Katalogsicht oder der IsNumericRoundAbortEnabled-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

RECURSIVE_TRIGGERS { ON | OFF }

ON
Das rekursive Auslösen von AFTER-Triggern ist zugelassen.

OFF
Nur das direkte rekursive Auslösen von AFTER-Triggern ist nicht zugelassen. Legen Sie die Serveroption für verschachtelte Trigger mithilfe von sp_configure auf 0 fest, um auch die indirekte Rekursion von AFTER-Triggern zu deaktivieren.

Hinweis:
Nur die direkte Rekursion wird verhindert, wenn RECURSIVE_TRIGGERS auf OFF festgelegt ist. Sie müssen auch die nested triggers-Serveroption auf 0 festlegen, um die indirekte Rekursion zu deaktivieren.

Der Status dieser Option kann mithilfe der Spalte is_recursive_triggers_on in der sys.databases-Katalogsicht oder der IsRecursiveTriggersEnabled-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

<recovery_option> ::=

Steuert Datenbankwiederherstellungsoptionen und Datenträger-E/A-Fehlerprüfung.

FULL
Stellt nach einem Medienausfall mithilfe von Transaktionsprotokollsicherungen eine vollständige Wiederherstellung bereit. Falls eine Datendatei beschädigt ist, kann die Medienwiederherstellung alle Transaktionen wiederherstellen, für die ein Commit ausgeführt wurde. Weitere Informationen finden Sie unter Sichern beim vollständigen Wiederherstellungsmodell.

BULK_LOGGED
Stellt nach einem Medienausfall eine Wiederherstellung durch die Kombination der besten Leistung und der geringsten Verwendung von Protokollspeicher für bestimmte umfangreiche Vorgänge oder Massenvorgänge bereit. Informationen dazu, welche Vorgänge als Massenprotokoll protokolliert werden, finden Sie unter Minimal protokollierte Vorgänge. Bei dem BULK_LOGGED-Wiederherstellungsmodell ist die Protokollierung für diese Vorgänge minimal. Weitere Informationen finden Sie unter Sichern beim massenprotokollierten Wiederherstellungsmodell.

SIMPLE
Es wird eine einfache Sicherungsstrategie bereitgestellt, die minimalen Protokollspeicherplatz verwendet. Protokollspeicherplatz kann automatisch erneut verwendet werden, wenn er für die Wiederherstellung nach einem Serverfehler nicht mehr benötigt wird. Weitere Informationen finden Sie unter Sicherungen mit dem einfachen Wiederherstellungsmodell.

Wichtig:
Das Modell der einfachen Wiederherstellung ist einfacher zu verwalten als die anderen beiden Modelle, jedoch auf Kosten eines höheren Datenverlustes, falls eine Datendatei beschädigt ist. Alle Änderungen, die nach der neuesten Datenbank- oder differenziellen Datenbanksicherung durchgeführt wurden, gehen verloren und müssen manuell erneut eingegeben werden.

Das standardmäßige Wiederherstellungsmodell wird durch das Wiederherstellungsmodell der model-Datenbank bestimmt. Weitere Informationen zum Auswählen des geeigneten Wiederherstellungsmodells finden Sie unter Auswählen des Wiederherstellungsmodells für eine Datenbank.

Der Status dieser Option kann mithilfe der Spalten recovery_model und recovery_model_desc in der sys.databases-Katalogsicht oder der Recovery-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

TORN_PAGE_DETECTION { ON | OFF }

ON
Unvollständige Seiten können vom Datenbankmodul erkannt werden.

OFF
Unvollständige Seiten können vom Datenbankmodul nicht erkannt werden.

Wichtig:
Die Syntaxstruktur TORN_PAGE_DETECTION ON \| OFF wird in zukünftigen Versionen von Microsoft SQL Server entfernt. Vermeiden Sie das Verwenden dieser Syntaxstruktur bei neuen Entwicklungsarbeiten, und planen Sie die Änderung von Anwendungen, die diese Syntaxstruktur zurzeit verwenden. Verwenden Sie stattdessen die Option PAGE_VERIFY.

PAGE_VERIFY { CHECKSUM | TORN_PAGE_DETECTION | NONE }
Entdeckt Datenbankseiten, die durch Datenträger-E/A-Pfadfehler beschädigt wurden. Datenträger-E/A-Pfadfehler können die Ursache von Datenbankbeschädigungen sein und werden im Allgemeinen durch Stromausfälle oder Datenträger-Hardwarefehler verursacht, die beim Schreiben der Seite auf den Datenträger auftreten.
- CHECKSUM
  Berechnet eine Prüfsumme für den Inhalt der gesamten Seite und speichert den Wert im Seitenkopf, wenn eine Seite auf den Datenträger geschrieben wird. Wird die Seite vom Datenträger gelesen, wird die Prüfsumme neu berechnet und mit dem im Seitenkopf gespeicherten Prüfsummenwert verglichen. Stimmen die Werte nicht überein, wird Fehlermeldung 824 (Hinweis auf einen Prüfsummenfehler) an das SQL Server-Fehlerprotokoll und an das Windows-Ereignisprotokoll gemeldet. Ein Prüfsummenfehler weist auf ein Problem mit dem E/A-Pfad hin. Um die eigentliche Ursache zu ermitteln, müssen die Hardware, die Firmwaretreiber, das BIOS, die Filtertreiber (z. B. Antivirussoftware) und andere Komponenten des E/A-Pfades untersucht werden.
- TORN_PAGE_DETECTION
  Speichert ein bestimmtes Bit für jeden 512-Byte-Sektor in der 8-KB-Datenbankseite und wird im Seitenkopf der Datenbank gespeichert, wenn die Seite auf den Datenträger geschrieben wird. Wird die Seite vom Datenträger gelesen, werden die zerrissenen Bits im Seitenkopf mit den Sektorinformationen der eigentlichen Seite verglichen. Nicht übereinstimmende Werte weisen darauf hin, dass nur ein Teil der Seite auf den Datenträger geschrieben wurde. In dieser Situation wird Fehlermeldung 824 (Hinweis auf einen Fehler durch eine zerrissene Seite) an das SQL Server-Fehlerprotokoll und an das Windows-Ereignisprotokoll gemeldet. Zerrissene Seiten werden im Allgemeinen bei der Datenbankwiederherstellung entdeckt, wenn es sich tatsächlich um einen unvollständigen Schreibvorgang für eine Seite handelt. Allerdings können auch andere E/A-Pfadfehler jederzeit eine zerrissene Seite verursachen.
- NONE
  Schreibvorgänge für Datenbankseiten generieren keinen CHECKSUM- oder TORN_PAGE_DETECTION-Wert. SQL Server überprüft während eines Lesevorgangs selbst dann keine Prüfsummen oder zerrissenen Seiten, wenn ein CHECKSUM- oder TORN_PAGE_DETECTION-Wert im Seitenkopf vorhanden ist.
Beachten Sie beim Verwenden der Option PAGE_VERIFY die folgenden wichtigen Punkte:
- In SQL Server 2005 lautet der Standardwert CHECKSUM. In SQL Server 2000 ist der Standard TORN_PAGE_DETECTION.
- Wenn eine Benutzer- oder Systemdatenbank auf SQL Server 2005 aktualisiert wird, bleibt der PAGE_VERIFY-Wert (NONE oder TORN_PAGE_DETECTION) erhalten. Sie sollten CHECKSUM verwenden.
- TORN_PAGE_DETECTION verwendet zwar weniger Ressourcen, bietet jedoch einen minimalen Teil des Schutzes von CHECKSUM.
- PAGE_VERIFY kann festgelegt werden, ohne die Datenbank offline zu schalten, zu sperren oder die Parallelität der Datenbank anderweitig zu beeinträchtigen.
- CHECKSUM und TORN_PAGE_DETECTION schließen sich gegenseitig aus. Beide Optionen können nicht gleichzeitig aktiviert werden.
Bei Entdecken einer zerrissenen Seite oder eines Prüfsummenfehlers können Sie eine Wiederherstellung ausführen, indem Sie die Daten wiederherstellen oder den Index u. U. neu erstellen, wenn der Fehler auf Indexseiten beschränkt ist. Führen Sie DBCC CHECKDB aus, um bei einem Prüfsummenfehler den Typ der betroffenen Datenbankseite(n) zu bestimmen. Weitere Informationen zu Wiederherstellungsoptionen finden Sie unter RESTORE-Argumente (Transact-SQL). Auch wenn das Datenbeschädigungsproblem durch das Wiederherstellen der Daten behoben wird, sollte die eigentliche Ursache, wie z. B. ein Datenträger-Hardwarefehler, diagnostiziert und baldmöglichst behoben werden, um wiederholte Fehler zu vermeiden.

SQL Server wiederholt Lesevorgänge, die wegen eines Prüfsummenfehlers, einer zerrissenen Seite oder eines anderen E/A-Fehlers fehlschlagen, vier Mal. Ist der Lesevorgang bei einem dieser Wiederholungsversuche erfolgreich, wird eine Meldung in das Fehlerprotokoll geschrieben, und der Befehl, der den Lesevorgang ausgelöst hat, wird fortgesetzt. Schlagen alle Wiederholungsversuche fehl, schlägt der Befehl mit Fehlermeldung 824 fehl.

Weitere Informationen zu Prüfsummen, zerrissenen Seiten, Lesewiederholungen, den Fehlermeldungen 823 und 824 und anderen E/A-Überwachungsfunktionen von SQL Server finden Sie auf dieser Microsoft-Website.

Die aktuelle Einstellung dieser Option kann mithilfe der Spalte page_verify_option in der sys.databases-Katalogsicht oder der IsTornPageDetectionEnabled-Eigenschaft der DATABASEPROPERTYEX-Funktion ermittelt werden.

<database_mirroring_option>::=

Steuert die Datenbankspiegelung für eine Datenbank. Mit den Datenbankspiegelungsoptionen angegebene Werte gelten für Kopien der Datenbank sowie auch für die gesamte Datenbankspiegelungssitzung. Pro ALTER DATABASE-Anweisung ist nur eine <database_mirroring_option> zugelassen { SET PARTNER <partner_option> | SET WITNESS <witness_option>}.

Wichtig:
Ein SET PARTNER- oder SET WITNESS-Befehl kann nach der Eingabe erfolgreich abgeschlossen werden und dennoch später einen Fehler generieren.

Hinweis:
Es empfiehlt sich, die Konfiguration der Datenbankspiegelung außerhalb der Spitzenbetriebszeiten durchzuführen, da sich die Konfiguration auf die Leistung auswirken kann.

Weitere Informationen zur Datenbankspiegelung finden Sie unter Datenbankspiegelung.

PARTNER <partner_option>
Steuert die Datenbankeigenschaften, die die Failoverpartner einer Datenbank-Spiegelungssitzung und deren Verhalten definieren. Einige Optionen von SET PARTNER können auf einem beliebigen der Partner festgelegt werden, andere sind auf den Prinzipal- oder den Spiegelserver beschränkt. Weitere Informationen finden Sie unter den jeweiligen Optionen von PARTNER weiter unten. Eine SET PARTNER-Klausel wirkt sich auf beide Kopien der Datenbank aus, unabhängig davon, für welchen Partner sie angegeben ist.

Für die Endpunkte beider Partner muss STATE auf STARTED festgelegt werden, um eine SET PARTNER-Anweisung auszuführen. Außerdem muss ROLE für den Datenbankspiegelungs-Endpunkt jeder Partnerserverinstanz auf PARTNER oder ALL festgelegt sein. Weitere Informationen zum Angeben eines Endpunktes finden Sie unter Vorgehensweise: Erstellen eines Endpunktes der Datenbankspiegelung für Windows-Authentifizierung (Transact-SQL). Verwenden Sie folgende Transact-SQL-Anweisung, um die Rolle und den Status des Datenbankspiegelungs-Endpunktes einer Serverinstanz zu erfahren:

SELECT role_desc, state_desc FROM sys.database_mirroring_endpoints

<partner_option> ::=

Hinweis:
Pro SET PARTNER-Klausel ist nur eine <partner_option> zugelassen.

'partner_server'
Gibt die Servernetzwerkadresse einer Instanz von SQL Server an, die als Failoverpartner in einer neuen Datenbank-Spiegelungssitzung agiert. Jede Sitzung erfordert zwei Partner, von denen einer als Prinzipalserver, der andere als Spiegelserver beginnt. Die beiden Partner sollten sich auf unterschiedlichen Computern befinden.

Diese Option wird einmal pro Sitzung für jeden Partner angegeben. Für das Starten einer Datenbank-Spiegelungssitzung sind zwei ALTER DATABASE database SET PARTNER ='partner_server'-Anweisungen erforderlich. Ihre Reihenfolge ist wichtig. Stellen Sie zuerst eine Verbindung mit dem Spiegelserver her, und geben Sie die Prinzipalserverinstanz als partner_server (SET PARTNER ='principal_server') an. Stellen Sie dann eine Verbindung mit dem Prinzipalserver her, und geben Sie die Spiegelserverinstanz als partner_server (SET PARTNER ='mirror_server') an; auf diese Weise wird eine Datenbank-Spiegelungssitzung zwischen diesen beiden Partnern gestartet. Weitere Informationen finden Sie unter Einrichten der Datenbankspiegelung.

Der Wert von partner_server ist eine Server-Netzwerkadresse. Diese hat folgende Syntax:

TCP**://<system-address>:**<port>

Dabei gilt:

<system-address> ist eine Zeichenfolge, z. B. ein Systemname, ein vollqualifizierter Domänenname oder eine IP-Adresse, die das Zielcomputersystem eindeutig identifiziert.
<port> ist eine Portnummer, die dem Spiegelungsendpunkt der Partnerserverinstanz zugeordnet ist.

Weitere Informationen finden Sie unter Angeben einer Server-Netzwerkadresse (Datenbankspiegelung).

Das folgende Beispiel veranschaulicht die SET PARTNER ='partner_server'-Klausel:

SET PARTNER = 'TCP://MYSERVER.mydomain.Adventure-Works.com:7777'

Wichtig:
Wird eine Sitzung mithilfe der ALTER DATABASE-Anweisung statt mit SQL Server Management Studio eingerichtet, wird die Sitzung standardmäßig auf vollständige Transaktionssicherheit festgelegt (SAFETY wird auf FULL festgelegt) und im Modus für hohe Sicherheit ohne automatisches Failover ausgeführt. Konfigurieren Sie einen Zeugen, um automatisches Failover zuzulassen. Für die Ausführung im Modus für hohe Leistung deaktivieren Sie die Transaktionssicherheit (SAFETY OFF).

Wird eine Sitzung mithilfe der ALTER DATABASE-Anweisung statt mit SQL Server Management Studio eingerichtet, wird die Sitzung standardmäßig auf vollständige Transaktionssicherheit festgelegt (SAFETY wird auf FULL festgelegt) und im Modus für hohe Sicherheit ohne automatisches Failover ausgeführt. Konfigurieren Sie einen Zeugen, um automatisches Failover zuzulassen. Für die Ausführung im Modus für hohe Leistung deaktivieren Sie die Transaktionssicherheit (SAFETY OFF).

FAILOVER
Führt ein manuelles Failover vom Prinzipalserver zum Spiegelserver aus. Sie können FAILOVER nur auf dem Prinzipalserver angeben. Diese Option ist nur dann gültig, wenn die Einstellung SAFETY auf FULL (Standard) festgelegt ist.

Die Option FAILOVER erfordert master als Datenbankkontext.

Weitere Informationen finden Sie unter Manuelles Failover.

FORCE_SERVICE_ALLOW_DATA_LOSS
Erzwingt ein Failover des Datenbankdienstes auf die Spiegeldatenbank, wenn auf dem Prinzipalserver ein Fehler auftritt, wobei sich die Datenbank im nicht synchronisierten Zustand oder im synchronisierten Zustand ohne automatisches Failover befindet.

Es wird dringend empfohlen, den Dienst nur dann zu erzwingen, wenn der Prinzipalserver nicht mehr ausgeführt wird. Ansonsten können einige Clients weiter versuchen, auf die ursprüngliche Prinzipaldatenbank zuzugreifen statt auf die neue Prinzipaldatenbank.

FORCE_SERVICE_ALLOW_DATA_LOSS ist nur auf dem Spiegelserver verfügbar und nur unter allen folgenden Bedingungen:
- Der Prinzipalserver ist ausgefallen.
- WITNESS ist auf OFF festgelegt, oder der Zeuge ist mit dem Spiegelserver verbunden.
Sie sollten den Dienst nur erzwingen, wenn Sie bereit sind, Datenverluste in Kauf zu nehmen, um den Dienst für die Datenbank unverzüglich wiederherzustellen. Informationen zu Alternativen für das Erzwingen des Dienstes finden Sie unter Asynchrone Datenbankspiegelung (Modus für hohe Leistung).

Durch das Erzwingen des Dienstes wird die Sitzung ausgesetzt, und alle Daten werden vorübergehend in der ursprünglichen Prinzipaldatenbank beibehalten. Sobald der ursprüngliche Prinzipalserver in Betrieb und zur Kommunikation mit dem neuen Prinzipalserver in der Lage ist, kann der Datenbankadministrator den Dienst fortsetzen. Wenn die Sitzung fortgesetzt wird, gehen alle nicht gesendeten Protokolldatensätze sowie die entsprechenden Aktualisierungen verloren.

Weitere Informationen zu den Risiken beim Erzwingen des Dienstes finden Sie unter Erzwungener Dienst (mit möglichem Datenverlust).

OFF
Entfernt eine Datenbank-Spiegelungssitzung und entfernt die Spiegelung von der Datenbank. Sie können OFF auf beiden Partnern festlegen. Informationen zu den Auswirkungen des Entfernens der Spiegelung finden Sie unter Entfernen der Datenbankspiegelung.

RESUME
Setzt eine ausgesetzte Datenbank-Spiegelungssitzung fort. Sie können RESUME nur auf dem Hauptserver angeben.

SAFETY { FULL | OFF }
Legt die Sicherheitsstufe für Transaktionen fest. Sie können SAFETY nur auf dem Hauptserver angeben.

Die Standardeinstellung ist FULL. Bei vollständiger Sicherheit (FULL) wird die Datenbank-Spiegelungssitzung synchron (im Modus für hohe Sicherheit) ausgeführt. Ist SAFETY auf OFF festgelegt, wird die Datenbank-Spiegelungssitzung asynchron (im Modus für hohe Leistung) ausgeführt.

Das Verhalten des Modus für hohe Sicherheit hängt teilweise folgendermaßen vom Zeugen ab:

Wenn die Sicherheit auf FULL und ein Zeuge für die Sitzung festgelegt wurde, wird die Sitzung im Modus für hohe Sicherheit mit automatischem Failover ausgeführt. Wenn der Prinzipalserver ausfällt, findet automatisch ein Failover der Sitzung statt, sofern die Datenbank synchronisiert ist und die Spiegelserverinstanz und der Zeuge noch miteinander verbunden sind (das heißt, sie verfügen über ein Quorum). Weitere Informationen finden Sie unter Quorum: Auswirkungen eines Zeugen auf die Datenbankverfügbarkeit.
Wenn ein Zeuge für die Sitzung festgelegt wurde, der zurzeit nicht verbunden ist, bewirkt der Verlust des Spiegelservers, dass der Prinzipalserver ausfällt
Wenn die Sicherheit auf FULL und der Zeuge auf OFF festgelegt wurde, wird die Sitzung im Modus für hohe Sicherheit ohne automatisches Failover ausgeführt. Wenn die Spiegelserverinstanz ausfällt, besitzt dies keine Auswirkungen auf die Prinzipalserverinstanz. Wenn der Prinzipalserver ausfällt, können Sie den Dienst (mit möglichem Datenverlust) auf dem Spiegelserver erzwingen.

Ist SAFETY auf OFF festgelegt, wird die Sitzung im Modus für hohe Leistung ausgeführt, und weder automatisches noch manuelles Failover werden unterstützt. Probleme auf dem Spiegelserver wirken sich jedoch nicht auf den Prinzipalserver aus. Wenn die Prinzipalserverinstanz ausfällt, können Sie ggf. das Failover des Dienstes (mit möglichem Datenverlust) auf die Spiegelserverinstanz erzwingen – wenn WITNESS auf OFF festgelegt wurde oder der Zeuge aktuell mit dem Spiegelserver verbunden ist. Weitere Informationen zum Erzwingen des Dienstes finden Sie im Abschnitt zu FORCE_SERVICE_ALLOW_DATA_LOSS weiter oben in diesem Abschnitt.

Wichtig:
Der Modus für hohe Leistung ist nicht für die Verwendung eines Zeugen konzipiert. Beim Festlegen von SAFETY auf OFF sollte unbedingt sichergestellt werden, dass WITNESS ebenfalls auf OFF festgelegt ist.

Weitere Informationen finden Sie unter Transact-SQL-Einstellungen und Datenbankspiegelungs-Betriebsmodi.

SUSPEND
Setzt eine Datenbank-Spiegelungssitzung aus.

Sie können SUSPEND auf beiden Partnern angeben.

TIMEOUT integer
Gibt den Timeoutzeitraum in Sekunden an. Der Timeoutzeitraum ist die Zeit, die eine Serverinstanz maximal auf den Empfang einer PING-Nachricht von einer anderen Instanz in der Spiegelungssitzung wartet, bevor davon ausgegangen wird, dass die Verbindung der anderen Instanz getrennt wurde.

Sie können die Option TIMEOUT nur auf dem Prinzipalserver angeben. Wenn Sie die Option nicht angeben, beträgt der Timeoutzeitraum standardmäßig 10 Sekunden. Wenn Sie 5 oder höher angeben, wird der Timeoutzeitraum auf die angegebene Anzahl von Sekunden festgelegt. Wenn Sie einen Timeoutzeitwert von 0 bis 4 Sekunden angeben, wird der Timeoutzeitraum automatisch auf 5 Sekunden festgelegt.

Wichtig:
Es wird empfohlen, einen Timeoutzeitraum von 10 Sekunden oder mehr zu wählen. Wenn Sie diesen Wert auf weniger als 10 Sekunden festlegen, verpasst ein stark ausgelastetes System möglicherweise PINGs und meldet einen falschen Fehler.

Weitere Informationen finden Sie unter Mögliche Fehler während der Datenbankspiegelung.

WITNESS <witness_option>
Steuert die Datenbankeigenschaften, die einen Datenbank-Spiegelungszeugen definieren. Eine SET WITNESS-Klausel wirkt sich auf beide Kopien der Datenbank aus, Sie können SET WITNESS jedoch nur auf dem Prinzipalserver angeben. Wenn ein Zeuge für eine Sitzung festgelegt wird, ist unabhängig von der SAFETY-Einstellung ein Quorum zum Anbieten der Datenbank erforderlich; weitere Informationen finden Sie unter Quorum: Auswirkungen eines Zeugen auf die Datenbankverfügbarkeit.

Zeuge und Failoverpartner sollten sich auf separaten Computern befinden. Weitere Informationen zum Zeugen finden Sie unter Datenbank-Spiegelungszeuge. Weitere Informationen zum automatischen Failover finden Sie unter Automatisches Failover.

Für die Endpunkte von Prinzipal- und Zeugenserverinstanz muss STATE auf STARTED festgelegt werden, um eine SET WITNESS-Anweisung auszuführen. Außerdem muss ROLE für den Datenbankspiegelungs-Endpunkt einer Zeugenserverinstanz auf WITNESS oder ALL festgelegt sein. (Informationen zum Angeben eines Endpunktes finden Sie unter Datenbank-Spiegelungsendpunkt.)

Verwenden Sie folgende Transact-SQL-Anweisung, um die Rolle und den Status des Datenbankspiegelungs-Endpunktes einer Serverinstanz zu erfahren:
```
SELECT role_desc, state_desc FROM sys.database_mirroring_endpoints
```
Hinweis:

Auf dem Zeugen können keine Datenbankeigenschaften festgelegt werden.

<witness_option> ::=

Hinweis:

Pro SET WITNESS-Klausel ist nur eine <witness_option> zugelassen.
- 'witness_server'
  Gibt eine Instanz vom Datenbankmodul an, die als Zeugenserver für die Datenbank-Spiegelungssitzung agiert. Sie können SET WITNESS-Anweisungen nur auf dem Prinzipalserver angeben.
  
  In einer SET WITNESS ='witness_server'-Anweisung ist die Syntax von witness_server mit der Syntax von partner_server identisch.
- OFF
  Entfernt den Zeugen aus einer Datenbank-Spiegelungssitzung. Durch das Festlegen des Zeugen auf OFF wird das automatische Failover deaktiviert. Ist die Datenbank auf FULL SAFETY festgelegt und der Zeuge auf OFF, führt ein Fehler auf dem Spiegelserver dazu, dass der Prinzipalserver die Datenbank nicht verfügbar macht.

Hinweis:
Auf dem Zeugen können keine Datenbankeigenschaften festgelegt werden.

Hinweis:
Pro SET WITNESS-Klausel ist nur eine <witness_option> zugelassen.

<service_broker_option>::=

Steuert die Service Broker-Optionen.

ENABLE_BROKER
Gibt an, dass Service Broker für die angegebene Datenbank aktiviert ist. Das is_broker_enabled-Flag ist in der sys.databases-Katalogsicht auf TRUE festgelegt, und die Nachrichtenübermittlung ist gestartet.

Hinweis:
Das Aktivieren von SQL Server Service Broker in einer Datenbank erfordert eine Datenbanksperre. Um Service Broker in der msdb-Datenbank zu aktivieren, beenden Sie zunächst den SQL Server-Agent, sodass Service Broker die erforderliche Sperre erhalten kann.

DISABLE_BROKER
Gibt an, dass Service Broker für die angegebene Datenbank deaktiviert ist. Das is_broker_enabled-Flag ist in der sys.databases-Katalogsicht auf FALSE festgelegt, und die Nachrichtenübermittlung ist angehalten.

NEW_BROKER
Gibt an, dass die Datenbank einen neuen Broker-Bezeichner erhalten sollte. Da die Datenbank als neuer Service Broker betrachtet wird, werden alle bestehenden Konversationen in der Datenbank sofort entfernt, ohne Nachrichten über das Beenden des Dialogs zu erstellen.

ERROR_BROKER_CONVERSATIONS
Gibt an, dass Konversationen in der Datenbank eine Fehlermeldung erhalten sollten, wenn die Datenbank angefügt wird. Auf diese Weise können Anwendungen reguläre Cleanups für bestehende Konversationen ausführen.

<date_correlation_optimization_option> ::=

Steuert die Option DATE_CORRELATION_OPTIMIZATION.

DATE_CORRELATION_OPTIMIZATION { ON | OFF }
- ON
  SQL Server verwaltet Korrelationsstatistiken zwischen zwei beliebigen Tabellen in der Datenbank, die durch eine FOREIGN KEY-Einschränkung verknüpft sind und über datetime-Spalten verfügen. Weitere Informationen finden Sie unter Optimieren von Abfragen, die auf korrelierte datetime-Spalten zugreifen.
- OFF
  Es werden keine Korrelationsstatistiken verwaltet.
Wenn DATE_CORRELATION_OPTIMIZATION auf ON festgelegt werden soll, darf keine aktive Verbindung mit der Datenbank bestehen außer der Verbindung, über die die ALTER DATABASE-Anweisung ausgeführt wird. Anschließend werden mehrere Verbindungen unterstützt.

Die aktuelle Einstellung der Option kann mithilfe der Spalte is_date_correlation_on in der sys.databases-Katalogsicht ermittelt werden.

<parameterization_option> ::=

Steuert die Parametrisierungsoption.

PARAMETERIZATION { SIMPLE | FORCED }
- SIMPLE
  Abfragen werden basierend auf dem Standardverhalten der Datenbank parametrisiert. Weitere Informationen finden Sie unter Einfache Parametrisierung.
- FORCED
  SQL Server parametrisiert alle Abfragen in der Datenbank. Weitere Informationen finden Sie unter Erzwungene Parametrisierung.
Die aktuelle Einstellung der Option kann mithilfe der Spalte is_parameterization_forced in der sys.databases-Katalogsicht ermittelt werden.

<snapshot_option>::=

Bestimmt die Isolationsstufe für Transaktionen.

ALLOW_SNAPSHOT_ISOLATION { ON| OFF }
- ON
  Transaktionen können die Isolationsstufe SNAPSHOT für Transaktionen angeben. Wird eine Transaktion auf der SNAPSHOT-Isolationsstufe ausgeführt, werden Snapshots von Daten für Anweisungen so angezeigt wie beim Start der Transaktion. Greift eine Transaktion, die auf der SNAPSHOT-Isolationsstufe ausgeführt wird, auf Daten in mehreren Datenbanken zu, muss entweder in allen Datenbanken ALLOW_SNAPSHOT_ISOLATION auf ON festgelegt sein oder jede Anweisung in der Transaktion muss Sperrhinweise für alle Verweise in einer FROM-Klausel verwenden, die auf eine Tabelle in einer Datenbank verweisen, bei der ALLOW_SNAPSHOT_ISOLATION auf OFF festgelegt ist.
- OFF
  Transaktionen können die Isolationsstufe SNAPSHOT für Transaktionen nicht angeben.
Wenn Sie ALLOW_SNAPSHOT_ISOLATION auf einen neuen Status festlegen (von ON zu OFF oder von OFF zu ON), gibt ALTER DATABASE die Kontrolle erst dann an den Aufrufer zurück, wenn ein Commit aller bestehenden Transaktionen in der Datenbank ausgeführt wurde. Hat die Datenbank bereits den in der ALTER DATABASE-Anweisung angegebenen Status, wird die Kontrolle direkt an den Aufrufer zurückgegeben. Erfolgt keine schnelle Rückgabe durch die ALTER DATABASE-Anweisung, verwenden Sie sys.dm_tran_active_snapshot_database_transactions, um zu bestimmen, ob lang andauernde Transaktionen vorhanden sind. Wird die ALTER DATABASE-Anweisung abgebrochen, bleibt die Datenbank in dem Status, in dem sie sich vor dem Start von ALTER DATABASE befand. In der sys.databases-Katalogsicht wird der Status von Snapshot-Isolationstransaktionen in der Datenbank angegeben. Ist snapshot_isolation_state_desc = IN_TRANSITION_TO_ON, wird ALTER DATABASE ALLOW_SNAPSHOT_ISOLATION OFF für 6 Sekunden angehalten und der Vorgang dann wiederholt.

Sie können den Status von ALLOW_SNAPSHOT_ISOLATION nicht ändern, wenn die Datenbank OFFLINE ist.

Wenn Sie ALLOW_SNAPSHOT_ISOLATION in einer READ_ONLY-Datenbank festlegen, wird die Einstellung gespeichert, wenn die Datenbank später auf READ_WRITE festgelegt wird.

Sie können die ALLOW_SNAPSHOT_ISOLATION-Einstellungen für die Datenbanken master, model, msdb und tempdb ändern. Wenn Sie die Einstellung für tempdb ändern, wird die Einstellung jedes Mal beibehalten, wenn die Instanz vom Datenbankmodul angehalten und neu gestartet wird. Wenn Sie die Einstellung für model ändern, wird die Einstellung zur Standardeinstellung für alle neu erstellten Datenbanken, mit Ausnahme von tempdb.

Die Option hat für die Datenbanken master und msdb die Standardeinstellung ON.

Die aktuelle Einstellung der Option kann mithilfe der Spalte snapshot_isolation_state in der sys.databases-Katalogsicht ermittelt werden.

READ_COMMITTED_SNAPSHOT { ON | OFF }
- ON
  Transaktionen, die die Isolationsstufe READ COMMITTED angeben, verwenden die Zeilenversionsverwaltung anstelle von Sperren. Wenn eine Transaktion auf der Isolationsstufe READ COMMITTED ausgeführt wird, werden Snapshots von Daten für Anweisungen so angezeigt, wie beim Start der Anweisung vorlagen.
- OFF
  Transaktionen, die die Isolationsstufe READ_COMMITTED angeben, verwenden Sperren.
Außer der Verbindung, die den ALTER DATABASE-Befehl ausführt, dürfen keine aktiven Verbindungen zur Datenbank bestehen, um READ_COMMITTED_SNAPSHOT auf ON oder OFF festzulegen. Die Datenbank muss sich jedoch nicht im Einzelbenutzermodus befinden. Sie können den Status dieser Option nicht ändern, wenn die Datenbank OFFLINE ist.

Wenn Sie READ_COMMITTED_SNAPSHOT in einer READ_ONLY-Datenbank festlegen, wird die Einstellung beibehalten, wenn die Datenbank später auf READ_WRITE festgelegt wird.

READ_COMMITTED_SNAPSHOT kann für die Systemdatenbanken master, tempdb oder msdb nicht auf ON festgelegt werden. Wenn Sie die Einstellung für model ändern, wird die Einstellung zur Standardeinstellung für alle neu erstellten Datenbanken, mit Ausnahme von tempdb.

Die aktuelle Einstellung der Option kann mithilfe der Spalte is_read_committed_snapshot_on in der sys.databases-Katalogsicht ermittelt werden.

WITH <termination>::=

Gibt an, wann beim Übergang der Datenbank von einem Status in einen anderen für unvollständige Transaktionen ein Rollback ausgeführt werden soll. Wird die Beendigungsklausel ausgelassen, wartet die ALTER DATABASE-Anweisung auf unbestimmte Zeit, wenn keine Sperre für die Datenbank besteht. Es kann nur eine Beendigungsklausel angegeben werden, und diese steht hinter den SET-Klauseln.

Hinweis:
Nicht alle Datenbankoptionen verwenden die WITH <termination>-Klausel. Weitere Informationen finden Sie in der Tabelle unter "Festlegen von Optionen" im Abschnitt mit den Hinweisen.

ROLLBACK AFTER integer [SECONDS] | ROLLBACK IMMEDIATE
Gibt an, ob ein Rollback sofort oder nach Ablauf der angegebenen Sekundenzahl ausgeführt werden soll.

NO_WAIT
Gibt an, dass die Anforderung fehlschlägt, wenn diese Änderung des Datenbankstatus oder der Datenbankoption nicht sofort vollständig vorgenommen werden kann, ohne dass darauf gewartet werden muss, dass Transaktionen selbst einen Commit oder Rollback ausführen.

Hinweise

Verwenden Sie DROP DATABASE, um eine Datenbank zu entfernen.

Um eine Datenbank umzubenennen, verwenden Sie die MODIFY NAME = new_database_name-Option mit ALTER DATABASE.

Verwenden Sie DBCC SHRINKDATABASE, um die Größe einer Datenbank zu reduzieren.

Sie können keine Dateien hinzufügen oder entfernen, während eine BACKUP-Anweisung ausgeführt wird.

Für jede Datenbank können maximal 32.767 Dateien und 32.767 Dateigruppen angegeben werden.

Die ALTER DATABASE-Anweisung muss im Autocommitmodus (dem Standardmodus für die Transaktionsverwaltung) ausgeführt werden und ist in einer expliziten oder impliziten Transaktion nicht zugelassen. Weitere Informationen finden Sie unter Autocommit-Transaktionen.

In SQL Server 2005 wird der Status einer Datenbankdatei (z. B. online oder offline) unabhängig vom Status der Datenbank verwaltet. Weitere Informationen finden Sie unter Dateistatus. Der Status der Dateien in einer Dateigruppe bestimmt die Verfügbarkeit der gesamten Dateigruppe. Damit eine Dateigruppe verfügbar ist, müssen alle Dateien in der Dateigruppe online sein. Ist eine Dateigruppe offline, verursacht jeder Versuch, über eine SQL-Anweisung auf die Dateigruppe zuzugreifen, einen Fehler. Wenn Sie Abfragepläne für SELECT-Anweisungen erstellen, vermeidet der Abfrageoptimierer nicht gruppierte Indizes und indizierte Ansichten, die sich in Offlinedateigruppen befinden. Dadurch wird ein erfolgreiches Ausführen der Anweisungen ermöglicht. Enthält die Offlinedateigruppe jedoch den Heap oder gruppierten Index der Zieltabelle, schlagen die SELECT-Anweisungen fehl. Auch alle INSERT-, UPDATE- oder DELETE-Anweisungen, die eine Tabelle mit einem Index in einer Offlinedateigruppe ändern, schlagen fehl.

Wenn eine Datenbank sich im Status RESTORING befindet, erzeugen die meisten ALTER DATABASE-Anweisungen einen Fehler. Eine Ausnahme bildet das Festlegen von Datenbank-Spiegelungsoptionen. Im Status RESTORING kann eine Datenbank sich während eines aktiven Wiederherstellungsvorgangs befinden oder wenn ein Wiederherstellungsvorgang einer Datenbank oder Protokolldatei aufgrund einer beschädigten Sicherungsdatei fehlschlägt. Weitere Informationen finden Sie unter Reagieren auf SQL Server-Wiederherstellungsfehler als Folge von beschädigten Sicherungen.

Festlegen von Optionen

Verwenden Sie die sys.databases-Katalogsicht oder DATABASEPROPERTYEX, um die aktuellen Einstellungen für Datenbankoptionen abzurufen. Eine Liste der Standardwerte, die einer Datenbank bei ihrem Erstellen zugewiesen werden, finden Sie unter Festlegen von Datenbankoptionen.

Wenn Sie eine Datenbankoption festlegen, tritt die Änderung sofort in Kraft.

Wenn Sie die Standardwerte einer Datenbankoption für alle neu erstellten Datenbanken ändern möchten, ändern Sie die entsprechende Datenbankoption in der model-Datenbank.

Nicht alle Datenbankoptionen verwenden die WITH <termination>-Klausel oder können zusammen mit anderen Optionen festgelegt werden. In der folgenden Tabelle sind die Optionen und ihr Options- und Beendigungsstatus aufgeführt.

Optionskategorie	Kann mit anderen Optionen angegeben werden	Kann die WITH <termination>-Klausel verwenden
<db_state_option>	Ja	Ja
<db_user_access_option>	Ja	Ja
db_update_option>	Ja	Ja
<external_access_option>	Ja	Nein
<cursor_option>	Ja	Nein
<auto_option>	Ja	Nein
<sql_option>	Ja	Nein
<recovery_option>	Ja	Nein
<database_mirroring_option>	Nein	Nein
ALLOW_SNAPSHOT_ISOLATION	Nein	Nein
READ_COMMITTED_SNAPSHOT	Nein	Ja
<service_broker_option>	Ja	Nein
DATE_CORRELATION_OPTIMIZATION	Ja	Ja
<parameterization_option>	Ja	Ja

Der Plancache für die Instanz von SQL Server wird gelöscht, indem eine der folgenden Optionen festgelegt wird:

OFFLINE	READ_WRITE
ONLINE	MODIFY FILEGROUP DEFAULT
MODIFY_NAME	MODIFY FILEGROUP READ_WRITE
COLLATE	MODIFY FILEGROUP READ_ONLY
READ_ONLY

Durch das Löschen des Plancaches wird eine Neukompilierung aller nachfolgenden Ausführungspläne verursacht, und möglicherweise entsteht plötzlich eine temporäre Verringerung der Abfrageleistung. In SQL Server 2005 Service Pack 2 enthält das SQL Server-Fehlerprotokoll für jeden geleerten Cachespeicher im Plancache folgende Meldung zur Information: "SQL Server hat für den '%s'-Cachespeicher (Bestandteil des Plancache) %d Leerungen des Cachespeichers gefunden, die von Datenbankwartungs- oder Neukonfigurierungsvorgängen ausgelöst wurden". Diese Meldung wird alle fünf Minuten protokolliert, solange der Cache innerhalb dieses Zeitintervalls geleert wird.

Verschieben von Dateien

In SQL Server 2005 können Sie System- oder benutzerdefinierte Daten und Protokolldateien verschieben, indem Sie den neuen Speicherort in FILENAME angeben. Dies kann in den folgenden Szenarien nützlich sein:

Wiederherstellung nach einem Fehler. Beispiel: Die Datenbank befindet sich im verdächtigen Modus oder wurde wegen eines Hardwarefehlers heruntergefahren.
Eine geplante Verschiebung.
Verschiebung wegen einer geplanten Datenträgerwartung.

Weitere Informationen finden Sie unter Verschieben von Datenbankdateien.

Initialisieren von Dateien

Standardmäßig werden Daten- und Protokolldateien durch Ausfüllen der Dateien mit Nullen initialisiert, wenn Sie eine der folgenden Operationen ausführen:

Erstellen einer Datenbank.
Hinzufügen von Dateien zu einer bestehenden Datenbank.
Erhöhen der Größe einer vorhandenen Datei.
Wiederherstellen einer Datenbank oder Dateigruppe.

In SQL Server 2005 können Datendateien sofort initialisiert werden. Dies ermöglicht ein schnelles Ausführen der entsprechenden Dateioperationen. Weitere Informationen finden Sie unter Datenbankdatei-Initialisierung.

Ändern der Datenbanksortierung

Bevor Sie auf eine Datenbank eine andere Sortierung anwenden, stellen Sie sicher, dass die folgenden Bedingungen erfüllt sind:

Die Datenbank wird derzeit nur von Ihnen verwendet.
Von der Sortierung der Datenbank hängt kein schemagebundenes Objekt ab.
Wenn die folgenden Objekte, die von der Datenbanksortierung abhängen, in der Datenbank vorhanden sind, tritt bei der ALTER DATABASEdatabase_name COLLATE-Anweisung ein Fehler auf. In SQL Server wird eine Fehlermeldung für jedes Objekt zurückgegeben, das die ALTER-Aktion blockiert:
- Benutzerdefinierte Funktionen und Sichten, die mit SCHEMABINDING erstellt wurden.
- Berechnete Spalten.
- CHECK-Einschränkungen.
- Funktionen mit Tabellenrückgabe, deren Rückgabetabellen Zeichenspalten mit Sortierungen enthalten, die von der Sortierung der Standarddatenbank geerbt wurden.
Durch das Ändern der Sortierung der Datenbank werden keine Duplikate von Systemnamen für die Datenbankobjekte erstellt.
Die folgenden Namespaces verursachen möglicherweise einen Fehler bei der Änderung der Datenbanksortierung, wenn durch die geänderte Sortierung doppelte Namen entstehen:
- Objektnamen wie z. B. der Name einer Prozedur, einer Tabelle, eines Triggers oder einer Sicht.
- Schemanamen
- Prinzipale wie z. B. eine Gruppe, eine Rolle oder ein Benutzer.
- Namen skalarer Typen wie z. B. der Name eines system- oder benutzerdefinierten Typs.
- Namen von Volltextkatalogen
- Spalten- oder Parameternamen in einem Objekt
- Indexnamen in einer Tabelle
  Durch doppelte Namen, die durch die neue Sortierung entstanden sind, schlägt die ALTER-Aktion fehl. SQL Server gibt eine Fehlermeldung zurück, in der der Namespace angegeben wird, in dem das Duplikat gefunden wurde.

Anzeigen von Datenbankinformationen

Sie können Katalogsichten, Systemfunktionen und gespeicherte Systemprozeduren verwenden, um Informationen zu Datenbank, Dateien und Dateigruppen zurückzugeben. Weitere Informationen finden Sie unter Anzeigen von Datenbankmetadaten.

Berechtigungen

Erfordert die ALTER-Berechtigung für die Datenbank.

Beispiele

A. Hinzufügen einer Datei zu einer Datenbank

Im folgenden Beispiel wird der AdventureWorks-Datenbank eine 5-MB-Datendatei hinzugefügt.

USE master;
GO
-- Get the SQL Server data path
DECLARE @data_path nvarchar(256);
SET @data_path = (SELECT SUBSTRING(physical_name, 1, CHARINDEX(N'master.mdf', LOWER(physical_name)) - 1)
                  FROM master.sys.master_files
                  WHERE database_id = 1 AND file_id = 1);
EXECUTE (
'ALTER DATABASE AdventureWorks 
ADD FILE 
(
    NAME = Test1dat2,
    FILENAME = '''+ @data_path + 't1dat2.ndf'',
    SIZE = 5MB,
    MAXSIZE = 100MB,
    FILEGROWTH = 5MB
)'
);
GO

B. Hinzufügen einer Dateigruppe mit zwei Dateien zu einer Datenbank

Im folgenden Beispiel wird die Dateigruppe Test1FG1 in der AdventureWorks-Datenbank erstellt, und der Dateigruppe werden zwei 5-MB-Dateien hinzugefügt.

USE master
GO
ALTER DATABASE AdventureWorks
ADD FILEGROUP Test1FG1;
GO
-- Get the SQL Server data path
DECLARE @data_path nvarchar(256);
SET @data_path = (SELECT SUBSTRING(physical_name, 1, CHARINDEX(N'master.mdf', LOWER(physical_name)) - 1)
                  FROM master.sys.master_files
                  WHERE database_id = 1 AND file_id = 1);
EXECUTE (
'ALTER DATABASE AdventureWorks 
ADD FILE 
(
    NAME = test1dat3,
    FILENAME = '''+ @data_path + 't1dat3.ndf'',
    SIZE = 5MB,
    MAXSIZE = 100MB,
    FILEGROWTH = 5MB
),
(
    NAME = test1dat4,
    FILENAME = '''+ @data_path + 't1dat4.ndf'',
    SIZE = 5MB,
    MAXSIZE = 100MB,
    FILEGROWTH = 5MB
)
TO FILEGROUP Test1FG1'
);
GO

C. Hinzufügen von zwei Protokolldateien zu einer Datenbank

Im folgenden Beispiel werden der AdventureWorks-Datenbank zwei 5-MB-Protokolldateien hinzugefügt.

USE master;
GO
-- Get the SQL Server data path
DECLARE @data_path nvarchar(256);
SET @data_path = (SELECT SUBSTRING(physical_name, 1, CHARINDEX(N'master.mdf', LOWER(physical_name)) - 1)
                  FROM master.sys.master_files
                  WHERE database_id = 1 AND file_id = 1);
EXECUTE (
'ALTER DATABASE AdventureWorks 
ADD LOG FILE 
(
    NAME = test1log2,
    FILENAME = '''+ @data_path + 'test2log.ldf'',
    SIZE = 5MB,
    MAXSIZE = 100MB,
    FILEGROWTH = 5MB
),
(
    NAME = test1log3,
    FILENAME = '''+ @data_path + 'test3log.ldf'',
    SIZE = 5MB,
    MAXSIZE = 100MB,
    FILEGROWTH = 5MB
)'
);
GO

D. Entfernen einer Datei aus einer Datenbank

Im folgenden Beispiel wird eine der in Beispiel B hinzugefügten Dateien entfernt.

USE master;
GO
ALTER DATABASE AdventureWorks
REMOVE FILE test1dat4;
GO

E. Ändern einer Datei

Im folgenden Beispiel wird die Größe einer der in Beispiel B hinzugefügten Dateien reduziert.

USE master;
GO
ALTER DATABASE AdventureWorks 
MODIFY FILE
    (NAME = test1dat3,
    SIZE = 20MB);
GO

F. Verschieben einer Datei an einen neuen Speicherort

Im folgenden Beispiel wird die in Beispiel A erstellte Datei Test1dat2 in ein neues Verzeichnis verschoben.

Hinweis:
Sie müssen die Datei physikalisch in das neue Verzeichnis verschieben, bevor Sie dieses Beispiel ausführen. Halten Sie anschließend die Instanz von SQL Server an, und starten Sie diese neu, oder schalten Sie die AdventureWorks-Datenbank OFFLINE und wieder ONLINE, um die Änderung zu implementieren.

USE master;
GO
ALTER DATABASE AdventureWorks
MODIFY FILE
(
    NAME = Test1dat2,
    FILENAME = N'c:\t1dat2.ndf'
);
GO

G. Verschieben von tempdb an einen neuen Speicherort

Im folgenden Beispiel wird tempdb vom aktuellen Speicherort auf dem Datenträger an einen anderen Speicherort verschoben. Da tempdb jedes Mal beim Starten des MSSQLSERVER-Dienstes neu erstellt wird, müssen Sie die Daten- und Protokolldateien nicht physikalisch verschieben. Die Dateien werden erstellt, wenn der Dienst in Schritt 3 neu gestartet wird. Bis zum Neustart des Dienstes setzt tempdb den Betrieb am bisherigen Speicherort fort.

Ermitteln Sie die logischen Dateinamen der tempdb-Datenbank und ihren aktuellen Speicherort auf dem Datenträger.
```
SELECT name, physical_name
FROM sys.master_files
WHERE database_id = DB_ID('tempdb');
GO
```

Ändern Sie den Speicherort der einzelnen Dateien mithilfe von ALTER DATABASE.

USE master;
GO
ALTER DATABASE tempdb 
MODIFY FILE (NAME = tempdev, FILENAME = 'E:\SQLData\tempdb.mdf');
GO
ALTER DATABASE  tempdb 
MODIFY FILE (NAME = templog, FILENAME = 'E:\SQLData\templog.ldf');
GO

Halten Sie die Instanz von SQL Server an, und starten Sie sie erneut.

Überprüfen Sie die Dateiänderung.

SELECT name, physical_name
FROM sys.master_files
WHERE database_id = DB_ID('tempdb');

Löschen Sie die Dateien tempdb.mdf und templog.ldf von deren ursprünglichen Speicherorten.

H. Festlegen einer Dateigruppe als Standarddateigruppe

Im folgenden Beispiel wird die in Beispiel B erstellte Test1FG1 -Dateigruppe als Standarddateigruppe festgelegt. Die Standarddateigruppe wird dann auf die PRIMARY-Dateigruppe zurückgesetzt. PRIMARY muss durch eckige Klammern oder Anführungszeichen begrenzt werden.

USE master;
GO
ALTER DATABASE AdventureWorks 
MODIFY FILEGROUP Test1FG1 DEFAULT;
GO
ALTER DATABASE AdventureWorks 
MODIFY FILEGROUP [PRIMARY] DEFAULT;
GO

I. Festlegen von Optionen für eine Datenbank

Im folgenden Beispiel werden die Optionen für das Wiederherstellungsmodell und die Datenseitenüberprüfung für die AdventureWorks -Beispieldatenbank festgelegt.

USE master;
GO
ALTER DATABASE AdventureWorks 
SET RECOVERY FULL, PAGE_VERIFY CHECKSUM;
GO

J. Festlegen der Datenbank auf READ_ONLY

Das Ändern des Status einer Datenbank oder Dateigruppe auf READ_ONLY oder READ_WRITE erfordert den exklusiven Zugriff auf die Datenbank. Im folgenden Beispiel wird die Datenbank auf den SINGLE_USER-Modus festgelegt, um exklusiven Zugriff zu erhalten. Anschließend wird in dem Beispiel der Status der AdventureWorks-Datenbank auf READ_ONLY festgelegt und der Zugriff auf die Datenbank an alle Benutzer zurückgegeben.

Hinweis:
In diesem Beispiel wird die Beendigungsoption `WITH ROLLBACK IMMEDIATE` in der ersten `ALTER DATABASE`-Anweisung verwendet. Für alle unvollständigen Transaktionen wird ein Rollback ausgeführt, und alle anderen Verbindungen zur `AdventureWorks`-Beispieldatenbank werden sofort getrennt.

USE master;
GO
ALTER DATABASE AdventureWorks
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO
ALTER DATABASE AdventureWorks
SET READ_ONLY;
GO
ALTER DATABASE AdventureWorks
SET MULTI_USER;
GO

K. Aktivieren der Snapshotisolation für eine Datenbank

Im folgenden Beispiel wird die Option für das Snapshotisolations-Framework für die AdventureWorks-Datenbank aktiviert.

USE AdventureWorks;
GO
-- Check the state of the snapshot_isolation_framework
-- in the database.
SELECT name, snapshot_isolation_state,
     snapshot_isolation_state_desc AS description
FROM sys.databases
WHERE name = N'AdventureWorks';
GO
USE master;
GO
ALTER DATABASE AdventureWorks
    SET ALLOW_SNAPSHOT_ISOLATION ON;
GO
-- Check again.
SELECT name, snapshot_isolation_state,
     snapshot_isolation_state_desc AS description
FROM sys.databases
WHERE name = N'AdventureWorks';
GO

Das Resultset zeigt, dass das Framework für die Snapshotisolation aktiviert ist.

name            snapshot_isolation_state  description
--------------- ------------------------  -----------
AdventureWorks  1                         ON

L. Erstellen einer Datenbank-Spiegelungssitzung mit einem Zeugen

Das Einrichten einer Datenbankspiegelung mit einem Zeugen erfordert das Konfigurieren von Sicherheit und Vorbereiten der Spiegeldatenbank sowie das Verwenden von ALTER DATABASE zum Festlegen der Partner. Ein Beispiel des vollständigen Setupprozesses finden Sie unter Einrichten der Datenbankspiegelung.

M. Manuelles Ausführen eines Failovers für eine Datenbank-Spiegelungssitzung

Ein manuelles Failover kann von beiden Partnern der Datenbankspiegelung initiiert werden. Vor dem Failover sollten Sie sicherstellen, dass es sich bei dem aktuellen Prinzipalserver auch tatsächlich um den Prinzipalserver handelt. Führen Sie z. B. für die AdventureWorks-Datenbank auf der Serverinstanz, die Sie für den aktuellen Prinzipalserver halten, die folgende Abfrage aus:

SELECT db.name, m.mirroring_role_desc 
FROM sys.database_mirroring m 
JOIN sys.databases db
ON db.database_id = m.database_id
WHERE db.name = N'AdventureWorks' 
GO

Handelt es sich bei der Serverinstanz tatsächlich um den Prinzipalserver, hat mirroring_role_desc den Wert Principal. Handelt es sich bei der Serverinstanz aber um den Spiegelserver, gibt die SELECT-Anweisung Mirror zurück.

Im folgenden Beispiel wird vorausgesetzt, dass es sich bei dem Server um den aktuellen Prinzipalserver handelt.

Manuelles Failover an den Datenbank-Spiegelungsserver:

ALTER DATABASE AdventureWorks SET PARTNER FAILOVER;
GO

Führen Sie die folgende Abfrage aus, um die Ergebnisse des Failovers auf dem neuen Spiegelserver zu überprüfen:
```
SELECT name, mirroring_role_desc 
FROM sys.databases WHERE name = N'AdventureWorks';
GO
```
Der aktuelle Wert von mirroring_role_desc ist jetzt Mirror.

Siehe auch

Änderungsverlauf

Version	Verlauf
12. Dezember 2006	Neuer Inhalt: Dem Abschnitt "Festlegen von Optionen" in den Hinweisen und der Definition von AUTO_CLOSE wurden Informationen zu Optionen hinzugefügt, mit denen Sie den Plancache löschen können. In der Definition von SINGLE_USER wurden Informationen zum Verwenden der Option AUTO_UPDATE_STATISTICS_ASYNC im Einzelbenutzermodus hinzugefügt.
14. April 2006	Geänderter Inhalt: Die Beschreibung der Option FAILOVER wurde aktualisiert, um anzugeben, dass sie master als Datenbankkontext erfordert. Der Einführung zum Abschnitt über <database_mirroring_option> wurde ein wichtiger Hinweis hinzugefügt. Unter dem Argument ALLOW_SNAPSHOT_ISOLATION wurden die Informationen zum Bestimmen des Status von Snapshotisolationstransaktionen in der Datenbank und zu den Auswirkungen des Status auf das Verhalten von SQL Server bei einer Änderung dieser Option aktualisiert. Die Definition von DATE_CORRELATION_OPTIMIZATION wurde korrigiert.
05. Dezember 2005	Neuer Inhalt: Hinweis zur Definition von ENABLE_BROKER hinzugefügt. Empfehlung zum Ändern der Option PAGE_VERIFY bei aktualisierten Datenbanken hinzugefügt. Geänderter Inhalt: Option SUPPLEMENTAL_LOGGING entfernt. Beispiel G korrigiert. Informationen über die Option TRUSTWORTHY in Systemdatenbanken korrigiert. Definition von READ_COMMITTED_SNAPSHOT aktualisiert, um anzugeben, dass Einzelbenutzermodus nicht notwendig ist. Definition von <db_state_option> aktualisiert, um anzugeben, dass die Optionen OFFLINE, ONLINE und EMERGENCY nicht festgelegt werden können, wenn sich die Datenbank im Status RESTORING befindet.

12. Dezember 2006

Neuer Inhalt:

Dem Abschnitt "Festlegen von Optionen" in den Hinweisen und der Definition von AUTO_CLOSE wurden Informationen zu Optionen hinzugefügt, mit denen Sie den Plancache löschen können.
In der Definition von SINGLE_USER wurden Informationen zum Verwenden der Option AUTO_UPDATE_STATISTICS_ASYNC im Einzelbenutzermodus hinzugefügt.

14. April 2006

Geänderter Inhalt:

Die Beschreibung der Option FAILOVER wurde aktualisiert, um anzugeben, dass sie master als Datenbankkontext erfordert.
Der Einführung zum Abschnitt über <database_mirroring_option> wurde ein wichtiger Hinweis hinzugefügt.
Unter dem Argument ALLOW_SNAPSHOT_ISOLATION wurden die Informationen zum Bestimmen des Status von Snapshotisolationstransaktionen in der Datenbank und zu den Auswirkungen des Status auf das Verhalten von SQL Server bei einer Änderung dieser Option aktualisiert.
Die Definition von DATE_CORRELATION_OPTIMIZATION wurde korrigiert.

05. Dezember 2005