ALTER DATABASE (Transact-SQL)

Ändern bestimmter Konfigurationsoptionen einer Datenbank

Dieser Artikel stellt die Syntax, Argumente, Anweisungen, Berechtigungen und Beispiele für das SQL-Produkt Ihrer Wahl bereit.

Weitere Informationen zu Syntaxkonventionen finden Sie unter Transact-SQL-Syntaxkonventionen.

Auswählen eines Produkts

Wählen Sie in der folgenden Zeile den Namen des Produkts aus, an dem Sie interessiert sind. Dann werden nur Informationen zu diesem Produkt angezeigt.

* SQL Server *  

 

Übersicht: SQL Server

In SQL Server ändert diese Anweisung eine Datenbank bzw. die zu dieser Datenbank gehörenden Dateien und Dateigruppen. „ALTER DATABASE“ 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. Datenbankmomentaufnahmen können nicht geändert werden. Verwenden Sie zum Ändern von Datenbankoptionen für die Replikation sp_replicationdboption.

Aufgrund ihrer Länge wird die ALTER DATABASE-Syntax in mehrere Artikel aufgeteilt.

Artikel BESCHREIBUNG
ALTER DATABASE Der aktuelle Artikel behandelt die Syntax und weitere Informationen zum Ändern des Namens und der Sortierung einer Datenbank.
ALTER DATABASE-Optionen für Dateien und Dateigruppen Stellt die Syntax und weitere Informationen zum Hinzufügen und Entfernen von Dateien und Dateigruppen in einer Datenbank sowie zum Ändern der Datei- und Dateigruppenattribute bereit.
ALTER DATABASE SET-Optionen Stellt die Syntax und weitere Informationen zum Ändern der Datenbankattribute mithilfe der SET-Optionen von ALTER DATABASE bereit.
ALTER DATABASE-Datenbankspiegelung Stellt die Syntax und weitere Informationen für die SET-Optionen von ALTER DATABASE bereit, die sich auf die Datenbankspiegelung beziehen.
ALTER DATABASE SET HADR Stellt die Syntax und weitere Informationen zu den ALTER DATABASE-Optionen für Always On-Verfügbarkeitsgruppen zum Konfigurieren einer sekundären Datenbank auf einem sekundären Replikat einer Always On-Verfügbarkeitsgruppe bereit.
ALTER DATABASE-Kompatibilitätsgrad Stellt die Syntax und weitere Informationen für die SET-Optionen von ALTER DATABASE bereit, die sich auf die Datenbank-Kompatibilitätsgrade beziehen.
ALTER DATABASE SCOPED CONFIGURATION Stellt die Syntax für datenbankweit gültige Konfigurationen bereit, die für einzelne Einstellungen auf Datenbankebene wie Abfrageoptimierung und Abfrageausführung verwendet werden.

Syntax

-- SQL Server Syntax
ALTER DATABASE { database_name | CURRENT }
{
    MODIFY NAME = new_database_name
  | COLLATE collation_name
  | <file_and_filegroup_options>
  | SET <option_spec> [ ,...n ] [ WITH <termination> ]
}
[;]

<file_and_filegroup_options>::=
  <add_or_modify_files>::=
  <filespec>::=
  <add_or_modify_filegroups>::=
  <filegroup_updatability_option>::=

<option_spec>::=
{
  | <auto_option>
  | <change_tracking_option>
  | <cursor_option>
  | <database_mirroring_option>
  | <date_correlation_optimization_option>
  | <db_encryption_option>
  | <db_state_option>
  | <db_update_option>
  | <db_user_access_option>
  | <delayed_durability_option>
  | <external_access_option>
  | <FILESTREAM_options>
  | <HADR_options>
  | <parameterization_option>
  | <query_store_options>
  | <recovery_option>
  | <service_broker_option>
  | <snapshot_option>
  | <sql_option>
  | <termination>
  | <temporal_history_retention>
  | <data_retention_policy>
  | <compatibility_level>
      { 150 | 140 | 130 | 120 | 110 | 100 | 90 }
}

Argumente

database_name

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

Hinweis

Diese Option ist in einer eigenständigen Datenbank nicht verfügbar.

CURRENT
Gilt für: SQL Server 2012 (11.x) und höher.

Legt fest, dass die zurzeit verwendete Datenbank geändert werden soll.

MODIFY NAME = new_database_name

Benennt die Datenbank in den angegebenen Namen new_database_name um.

COLLATE collation_name

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

Hinweis

Sobald die Datenbank einmal in Azure SQL-Datenbank erstellt wurde, kann sie nicht mehr geändert werden.

Beim Erstellen von Datenbanken mit einer von der Standardsortierung abweichenden Sortierung folgen die Daten in der Datenbank immer der angegebenen Sortierung. Bei der Erstellung einer eigenständigen Datenbank in SQL Server werden die internen Kataloginformationen mit der SQL Server-Standardsortierung Latin1_General_100_CI_AS_WS_KS_SC verwaltet.

Weitere Informationen zu den Namen von Windows- und SQL-Sortierungen finden Sie unter COLLATE.

<delayed_durability_option> ::=

Gilt für: SQL Server 2014 (12.x) und höher.

Weitere Informationen finden Sie unter ALTER DATABASE SET-Optionen und Steuern der Transaktionsdauerhaftigkeit.

<file_and_filegroup_options>::=

Weitere Informationen finden Sie unter ALTER DATABASE-Optionen für Dateien und Dateigruppen.

Bemerkungen

Verwenden Sie DROP DATABASE, um eine Datenbank zu entfernen.

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

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.

Der Status einer Datenbankdatei (z. B. online oder offline) wird unabhängig vom Status der Datenbank verwaltet. Weitere Informationen finden Sie im Abschnitt 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 Sichten, 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. Eine Datenbank kann den Status RESTORING aufweisen, während ein Wiederherstellungsvorgang aktiv ist oder wenn ein Wiederherstellungsvorgang einer Datenbank oder Protokolldatei aufgrund einer beschädigten Sicherungsdatei fehlschlägt.

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

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

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. Das SQL Server-Fehlerprotokoll enthält für jeden geleerten Cachespeicher im Plancache folgende informative Meldung: SQL Server has encountered %d occurrence(s) of cachestore flush for the '%s' cachestore (part of plan cache) due to some database maintenance or reconfigure operations. Diese Meldung wird alle fünf Minuten protokolliert, solange der Cache innerhalb dieses Zeitintervalls geleert wird.

Der Plancache wird auch in den folgenden Szenarien geleert:

  • Die Datenbankoption AUTO_CLOSE ist für eine Datenbank auf ON festgelegt. Wenn die Datenbank von keiner Benutzerverbindung verwendet wird bzw. keine Benutzerverbindung darauf verweist, versucht der Hintergrundtask, die Datenbank automatisch zu schließen und herunterzufahren.
  • Sie führen mehrere Abfragen für eine Datenbank aus, die über Standardoptionen verfügt. Anschließend wird die Datenbank gelöscht.
  • Eine Datenbank-Momentaufnahme für eine Quelldatenbank wird gelöscht.
  • Sie erstellen das Transaktionsprotokoll für eine Datenbank erfolgreich neu.
  • Sie stellen eine Datenbanksicherung wieder her.
  • Sie trennen eine Datenbank.

Ä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, schlägt die Anweisung ALTER DATABASE database_name COLLATE fehl. SQL Server gibt eine Fehlermeldung für jedes Objekt zurück, das die Aktion ALTER blockiert:

  • Benutzerdefinierte Funktionen und Sichten, die mit SCHEMABINDING erstellt wurden
  • Berechnete Spalten
  • CHECK-Einschränkungen
  • Tabellenwertfunktionen, die Tabellen mit Zeichenspalten zurückgeben, deren Sortierungen von der Standardsortierung der Datenbank geerbt wurden

Abhängigkeitsinformationen für nicht schemagebundene Entitäten werden automatisch aktualisiert, wenn die Sortierung der Datenbank geändert wird.

Durch das Ändern der Sortierung der Datenbank werden keine Duplikate von Systemnamen für die Datenbankobjekte erstellt. Wenn durch die geänderte Sortierung doppelte Namen entstehen, verursachen die folgenden Namespaces möglicherweise einen Fehler bei der Änderung der Datenbanksortierung:

  • Objektnamen wie z.B. der Name einer Prozedur, Tabelle, Sicht oder eines Triggers
  • Schemanamen
  • Prinzipale wie z.B. eine Gruppe, Rolle oder ein Benutzer
  • Namen skalarer Typen wie z.B. der Name eines vom System oder Benutzer definierten 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 Datenbanken, Dateien und Dateigruppen zurückzugeben.

Berechtigungen

Erfordert die ALTER-Berechtigung für die Datenbank.

Beispiele

A. Ändern des Namens einer Datenbank

Im folgenden Beispiel wird der Name der Datenbank AdventureWorks2022 in Northwind geändert.

USE master;
GO
ALTER DATABASE AdventureWorks2022
Modify Name = Northwind ;
GO

B. Ändern der Sortierung einer Datenbank

Im folgenden Beispiel wird die Datenbank testdb mit der SQL_Latin1_General_CP1_CI_AS-Sortierung erstellt. Danach wird die Sortierung der Datenbank testdb in COLLATE French_CI_AI geändert.

Gilt für: SQL Server 2008 (10.0.x) und später

USE master;
GO

CREATE DATABASE testdb
COLLATE SQL_Latin1_General_CP1_CI_AS ;
GO

ALTER DATABASE testDB
COLLATE French_CI_AI ;
GO

Nächste Schritte

* SQL-Datenbank *  

 

Übersicht: SQL-Datenbank

Verwenden Sie diese Anweisung in Azure SQL-Datenbank, um eine Datenbank zu ändern. Verwenden Sie diese Anweisung, um den Namen einer Datenbank zu ändern, die Edition und das Dienstziel der Datenbank zu ändern, die Datenbank einem Pool für elastische Datenbanken hinzuzufügen oder daraus zu entfernen, Datenbankoptionen festzulegen, die Datenbank als sekundäre Datenbank in einer Georeplikationsbeziehung hinzuzufügen oder daraus zu entfernen oder den Datenbank-Kompatibilitätsgrad festzulegen.

Aufgrund ihrer Länge wird die ALTER DATABASE-Syntax in mehrere Artikel aufgeteilt.

ALTER DATABASE
Der aktuelle Artikel enthält die Syntax und weitere Informationen zum Ändern des Namens und anderer Einstellungen einer Datenbank.

ALTER DATABASE SET-Optionen
Stellt die Syntax und weitere Informationen zum Ändern der Datenbankattribute mithilfe der SET-Optionen von ALTER DATABASE bereit.

ALTER DATABASE-Kompatibilitätsgrad
Stellt die Syntax und weitere Informationen für die SET-Optionen von ALTER DATABASE bereit, die sich auf die Datenbank-Kompatibilitätsgrade beziehen.

Syntax

-- Azure SQL Database Syntax
ALTER DATABASE { database_name | CURRENT }
{
    MODIFY NAME = new_database_name
  | MODIFY ( <edition_options> [, ... n] )
  | MODIFY BACKUP_STORAGE_REDUNDANCY = { 'LOCAL' | 'ZONE' | 'GEO' }
  | SET { <option_spec> [ ,... n ] WITH <termination>}
  | ADD SECONDARY ON SERVER <partner_server_name>
    [WITH ( <add-secondary-option>::=[, ... n] ) ]
  | REMOVE SECONDARY ON SERVER <partner_server_name>
  | FAILOVER
  | FORCE_FAILOVER_ALLOW_DATA_LOSS
}
[;]

<edition_options> ::=
{

  MAXSIZE = { 100 MB | 250 MB | 500 MB | 1 ... 1024 ... 4096 GB }
  | EDITION = { 'Basic' | 'Standard' | 'Premium' | 'GeneralPurpose' | 'BusinessCritical' | 'Hyperscale'}
  | SERVICE_OBJECTIVE =
       { <service-objective>
       | { ELASTIC_POOL (name = <elastic_pool_name>) }
       }
}

<add-secondary-option> ::=
   {
      ALLOW_CONNECTIONS = { ALL | NO }
     | BACKUP_STORAGE_REDUNDANCY = { 'LOCAL' | 'ZONE' | 'GEO' }
     | SERVICE_OBJECTIVE =
       { <service-objective>
       | { ELASTIC_POOL ( name = <elastic_pool_name>) }
       | DATABASE_NAME = <target_database_name>
       | SECONDARY_TYPE = { GEO | NAMED }
       }
   }

<service-objective> ::={ 'Basic' |'S0' | 'S1' | 'S2' | 'S3'| 'S4'| 'S6'| 'S7'| 'S9'| 'S12'
      | 'P1' | 'P2' | 'P4'| 'P6' | 'P11' | 'P15'
      | 'BC_DC_n'
      | 'BC_Gen5_n' 
      | 'BC_M_n' 
      | 'GP_DC_n'
      | 'GP_Fsv2_n' 
      | 'GP_Gen5_n' 
      | 'GP_S_Gen5_n' 
      | 'HS_DC_n'
      | 'HS_Gen5_n'
      | 'HS_MOPRMS_n' 
      | 'HS_PRMS_n' 
      | { ELASTIC_POOL(name = <elastic_pool_name>) }
      }

<option_spec> ::=
{
    <auto_option>
  | <change_tracking_option>
  | <cursor_option>
  | <db_encryption_option>
  | <db_update_option>
  | <db_user_access_option>
  | <delayed_durability_option>
  | <parameterization_option>
  | <query_store_options>
  | <snapshot_option>
  | <sql_option>
  | <target_recovery_time_option>
  | <termination>
  | <temporal_history_retention>
  | <compatibility_level>
    { 150 | 140 | 130 | 120 | 110 | 100 | 90 }

}

Argumente

database_name

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

CURRENT
Legt fest, dass die zurzeit verwendete Datenbank geändert werden soll.

MODIFY NAME = new_database_name

Benennt die Datenbank in den angegebenen Namen new_database_name um. Im folgenden Beispiel wird der Name einer Datenbank von db1 in db2 geändert:

ALTER DATABASE db1
    MODIFY Name = db2 ;

MODIFY (EDITION = ['Basic' | 'Standard' | 'Premium' |'GeneralPurpose' | 'BusinessCritical' | 'Hyperscale'])

Ändert die Dienstebene der Datenbank.

Im folgenden Beispiel wird die Edition in Premium geändert:

ALTER DATABASE current
    MODIFY (EDITION = 'Premium');

Wichtig

Wenn die MAXSIZE-Eigenschaft für die Datenbank auf einen Wert außerhalb des gültigen, von der jeweiligen Edition unterstützten Bereichs festgelegt wird, schlägt die Änderung der EDITION-Eigenschaft fehl.

MODIFY (BACKUP_STORAGE_REDUNDANCY = ['LOCAL' | 'ZONE' | 'GEO'])

Hiermit wird die Speicherredundanz für Sicherungen für die Zeitpunktwiederherstellung und die Langzeitaufbewahrung (sofern konfiguriert) der Datenbank geändert. Die Änderungen werden auf alle zukünftigen Sicherungen angewendet. Vorhandene Sicherungen verwenden weiterhin die vorherige Einstellung.

Wenn Sie Datenresidenz für das Erstellen einer Datenbank mit T-SQL erzwingen möchten, verwenden Sie LOCAL oder ZONE als Eingabe für den BACKUP_STORAGE_REDUNDANCY-Parameter.

MODIFY (MAXSIZE = [100 MB | 500 MB | 1 | 1.024...4.096] GB)

Gibt die maximale Größe der Datenbank an. Die maximale Größe muss dem gültigen Wertsatz für die EDITION-Eigenschaft der Datenbank entsprechen. Eine Änderung der maximalen Datenbankgröße kann auch dazu führen, dass die EDITION-Eigenschaft der Datenbank geändert wird.

Hinweis

Das Argument MAXSIZE gilt nicht für Einzeldatenbanken im Diensttarif „Hyperscale“. Datenbanken im Diensttarif „Hyperscale“ können bei Bedarf auf bis zu 100 TB skaliert werden. Der SQL-Datenbank-Dienst fügt automatisch Speicher hinzu. Sie müssen keine maximale Größe festlegen.

DTU-Modell

MAXSIZE Grundlegend S0-S2 S3-S12 P1-P6 P11-P15
100 MB
250 MB
500 MB
1 GB
2 GB √ (S)
5 GB
10 GB
20 GB
30 GB
40 GB
50 GB
100 GB
150 GB
200 GB
250 GB √ (S) √ (S)
300 GB
400 GB
500 GB √ (S)
750 GB
1024 GB √ (S)
Von 1024 GB bis 4096 GB in Inkrementen von 256 GB*

* P11 und P15 ermöglichen, dass die Größe von MAXSIZE bis zu 4 TB beträgt, wobei 1024 GB die Standardgröße darstellt. P11 und P15 können bis zu 4 TB des enthaltenen Speichers ohne Aufpreis verwenden. Im Premium-Tarif ist MAXSIZE mit einer Größe von mehr als 1 TB derzeit in den folgenden Regionen verfügbar: USA, Osten 2; USA, Westen; US Gov Virginia; Europa, Westen; Deutschland, Mitte; Asien, Südosten; Japan, Osten; Australien, Osten; Kanada, Mitte und Kanada, Osten. Weitere Informationen bezüglich der Ressourceneinschränkungen für das DTU-Modell finden Sie unter DTU-Ressourceneinschränkungen.

Der MAXSIZE-Wert für das DTU-Modell muss – wenn angegeben – ein gültiger Wert sein, der in der vorherigen Tabelle für die festgelegte Dienstebene angezeigt wird.

Grenzwerte wie die maximale Datengröße und tempdb-größe im vCore-Kaufmodell finden Sie in den Artikeln zu Ressourcenlimits für Einzeldatenbanken oder Ressourcenlimits für Pools für elastische Datenbanken.

Wenn kein MAXSIZE-Wert bei Verwendung des vCore-Modells festgelegt ist, beträgt die Standardgröße 32 GB. Weitere Informationen bezüglich der Ressourceneinschränkungen für das V-Kern-Modell finden Sie unter V-Kern-Ressourceneinschränkungen.

Die folgenden Regeln gelten für das MAXSIZE-Argument und das EDITION-Argument:

  • Wenn EDITION angegeben ist, MAXSIZE jedoch nicht, wird der Standardwert für die Edition verwendet. Wenn EDITION beispielsweise auf die Standard Edition festgelegt und MAXSIZE nicht angegeben ist, wird MAXSIZE automatisch auf 250 MB festgelegt.
  • Wenn weder MAXSIZE noch EDITION angegeben sind, wird EDITION auf „Universell“ (S0) und MAXSIZE auf 32 GB festgelegt.

MODIFY (SERVICE_OBJECTIVE = <service-objective>)

Gibt die Computegröße und das Dienstziel an.

SERVICE_OBJECTIVE

Gibt die Berechnungsgröße an (auch als Servicelevel-Objekt oder SLO bezeichnet).

Im folgenden Beispiel wird das Dienstziel einer Datenbank im Premium-Tarif im DTU-Kaufmodell in P6 geändert:

ALTER DATABASE <database_name>
    MODIFY (SERVICE_OBJECTIVE = 'P6');

Im folgenden Beispiel wird das Dienstziel einer bereitgestellten Computedatenbank im vCore-Kaufmodell in GP_Gen5_8 geändert:

ALTER DATABASE <database_name>
    MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');

DATABASE_NAME

Nur für Hyperscale in Azure SQL-Datenbank Dies ist der Datenbankname, der erstellt wird. Wird nur von den von Azure SQL-Datenbank benannten Hyperscale-Replikaten verwendet, wenn SECONDARY_TYPE = NAMED. Weitere Informationen finden Sie unter Sekundäre Hyperscale-Replikate.

SECONDARY_TYPE

Nur für Hyperscale in Azure SQL-Datenbank GEO spezifiziert ein Georeplikat, NAMED hingegen ein benanntes Replikat. Der Standardwert ist GEO. Weitere Informationen finden Sie unter Sekundäre Hyperscale-Replikate.

Dienstzielbeschreibungen und weitere Informationen zu Größe, Editionen und Dienstzielkombinationen finden Sie unter Dienstebenen und Leistungsstufen von Azure SQL-Datenbank, DTU-Ressourcenlimits und V-Kern-Ressourcenlimits. Die Unterstützung für PRS-Dienstziele wurde entfernt.

Wenn SERVICE_OBJECTIVE nicht angegeben ist, wird die sekundäre Datenbank auf derselben Dienstebene wie die primäre Datenbank erstellt. Wenn SERVICE_OBJECTIVE angegeben ist, wird die sekundäre Datenbank auf der angegebenen Ebene erstellt. Das angegebene SERVICE_OBJECTIVE muss sich in derselben Edition wie die Quelle befinden. So können Sie beispielsweise nicht „S0“ angeben, wenn es sich bei der Edition um eine Premium-Edition handelt.

MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL (name = <elastic_pool_name>)

Wenn Sie eine vorhandene Datenbank zu einem Pool für elastische Datenbanken hinzufügen möchten, müssen Sie das SERVICE_OBJECTIVE der Datenbank auf ELASTIC_POOL festlegen und den Namen des Pools für elastische Datenbanken angeben. Sie können mit dieser Option auch die Datenbank in einen anderen Pool für elastische Datenbanken innerhalb desselben Servers ändern. Weitere Informationen finden Sie unter Erstellen und Verwalten eines Pools für elastische Datenbanken von SQL-Database. Wenn Sie eine Datenbank aus einem Pool für elastische Datenbanken entfernen möchten, legen Sie mithilfe von ALTER DATABASE das SERVICE_OBJECTIVE-Objekt auf eine einzelne Computegröße (Dienstziel) der Datenbank fest.

Hinweis

Datenbanken im Diensttarif „Hyperscale“ können nicht zu einem Pool für elastische Datenbanken hinzugefügt werden.

ADD SECONDARY ON SERVER <partner_server_name>

Erstellt eine georeplizierte sekundäre Datenbank mit dem gleichen Namen auf einem Partnerserver. Dabei wird die lokale Datenbank in eine georeplizierte primäre Datenbank umgewandelt und mit dem asynchronen Replizieren von Daten von der primären in die neue sekundäre Datenbank begonnen. Der Befehl schlägt fehl, wenn auf dem sekundären Server bereits eine Datenbank mit dem gleichen Namen vorhanden ist. Der Befehl wird in der master-Datenbank auf dem Server ausgeführt, der Host der lokalen Datenbank ist, die zur primären Datenbank wird.

Wichtig

Standardmäßig wird die sekundäre Datenbank mit der gleichen Sicherungsspeicherredundanz wie die primäre Datenbank oder Quelldatenbank erstellt. Das Ändern der Sicherungsspeicherredundanz während des Erstellens einer sekundären Datenbank wird von T-SQL nicht unterstützt.

WITH ALLOW_CONNECTIONS { ALL | NO }

Wenn ALLOW_CONNECTIONS nicht angegeben ist, wird es standardmäßig auf ALL festgelegt. Wenn ALL festgelegt ist, handelt es sich um eine schreibgeschützte Datenbank, zu der alle Anmeldenamen mit den entsprechenden Berechtigungen eine Verbindung herstellen dürfen.

ELASTIC_POOL (name = <elastic_pool_name>)

Wenn ELASTIC_POOL nicht angegeben ist, wird die sekundäre Datenbank nicht in einem Pool für elastische Datenbanken erstellt. Wenn ELASTIC_POOL angegeben ist, wird die sekundäre Datenbank im angegebenen Pool erstellt.

Wichtig

Der Benutzer, der den Befehl ADD SECONDARY ausführt, muss DBManager auf dem primären Server, db_owner-Mitglied in der lokalen Datenbank und DBManager auf dem sekundären Server sein. Die IP-Clientadresse muss sowohl für den primären als auch für den sekundären Server der Zulassungsliste in den Firewallregeln hinzugefügt werden. Sollten unterschiedliche IP-Clientadressen vorliegen, muss exakt dieselbe IP-Clientadresse, die auf dem primären Server hinzugefügt wurde, auch auf dem sekundären Server hinzugefügt werden. Dieser Schritt ist erforderlich, bevor Sie den Befehl ADD SECONDARY ausführen, um die Georeplikation zu initiieren.

REMOVE SECONDARY ON SERVER <partner_server_name>

Entfernt die angegebene georeplizierte sekundäre Datenbank vom angegebenen Server. Der Befehl wird in der master-Datenbank auf dem Server ausgeführt, der Host der primären Datenbank ist.

Wichtig

Der Benutzer, der den Befehl REMOVE SECONDARY ausführt, muss DBManager auf dem primären Server sein.

FAILOVER

Stuft die sekundäre Datenbank in einer Partnerschaft für die Georeplikation hoch, für die der Befehl ausgeführt wird, damit sie zur primären Datenbank wird, und stuft die aktuelle primäre Datenbank tiefer, sodass diese zur neuen sekundären Datenbank wird. Im Rahmen dieses Prozesses wird der Georeplikationsmodus vorübergehend vom asynchronen in den synchronen Modus umgeschaltet. Während des Failoverprozesses:

  1. Die primäre Datenbank übernimmt keine neuen Transaktionen mehr.
  2. Alle ausstehenden Transaktionen werden in der sekundären Datenbank geleert.
  3. Die sekundäre Datenbank wird zur primären Datenbank und beginnt mit der asynchronen Replikation mit der alten primären/der neuen sekundären Datenbank.

Durch diese Sequenz wird sichergestellt, dass keine Daten verloren gehen. Der Zeitraum, in dem keine der beiden Datenbanken verfügbar ist, umfasst 0 bis 25 Sekunden. In dieser Zeit werden die Rollen gewechselt. Der gesamte Vorgang sollte nicht mehr als einer Minute in Anspruch nehmen. Wenn die primäre Datenbank bei der Ausgabe dieses Befehls nicht verfügbar ist, schlägt der Befehl fehl, und es wird eine Fehlermeldung angezeigt, dass die primäre Datenbank nicht verfügbar ist. Wenn der Failoverprozess nicht abgeschlossen wird und ins Stocken geraten zu sein scheint, können Sie den Befehl zur Erzwingung des Failovers verwenden und einen Datenverlust in Kauf nehmen. Anschließend, wenn eine Wiederherstellung der verloren gegangenen Daten erforderlich sein sollte, können Sie DevOps (CSS) zur Wiederherstellung der verloren gegangenen Daten aufrufen.

Wichtig

Der Benutzer, der den Befehl FAILOVER ausführt, muss DBManager auf dem primären und dem sekundären Server sein.

FORCE_FAILOVER_ALLOW_DATA_LOSS

Stuft die sekundäre Datenbank in einer Partnerschaft für die Georeplikation hoch, für die der Befehl ausgeführt wird, damit sie zur primären Datenbank wird, und stuft die aktuelle primäre Datenbank tiefer, sodass diese zur neuen sekundären Datenbank wird. Verwenden Sie diesen Befehl nur dann, wenn die aktuelle primäre Datenbank nicht mehr verfügbar ist. Er wurde nur für die Notfallwiederherstellung erstellt, wenn die Wiederherstellung der Verfügbarkeit wesentlich und ein Datenverlust akzeptabel ist.

Während eines erzwungenen Failovers:

  1. Die angegebene sekundäre Datenbank wird sofort zur primären Datenbank und beginnt, neue Transaktionen zu akzeptieren.
  2. Wenn die ursprüngliche primäre Datenbank eine Verbindung zur neuen primären Datenbank wiederherstellen kann, wird eine inkrementelle Sicherung von der ursprünglichen primären Datenbank erstellt. Die ursprüngliche primäre Datenbank wird dann zu einer neuen sekundären Datenbank.
  3. Zur Wiederherstellung der Daten aus dieser inkrementellen Sicherung der ursprünglichen primären Datenbank bindet der Benutzer DevOps/CSS ein.
  4. Wenn es weitere sekundäre Datenbanken gibt, werden diese automatisch so neu konfiguriert, dass sie zu den sekundären Datenbanken der neuen primären Datenbank werden. Dieser Vorgang ist asynchron. Bis zum Abschluss des Vorgangs kann es zu einer Verzögerung kommen. Bis zum Abschluss der Neukonfiguration sind die sekundären Datenbanken weiterhin die sekundären Datenbanken der ursprünglichen primären Datenbank.

Wichtig

Der Benutzer, der den Befehl FORCE_FAILOVER_ALLOW_DATA_LOSS ausführt, muss auf dem primären und sekundären Server die Rolle dbmanager inne haben.

Bemerkungen

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

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.

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. Das SQL Server-Fehlerprotokoll enthält für jeden geleerten Cachespeicher im Plancache folgende informative Meldung: SQL Server has encountered %d occurrence(s) of cachestore flush for the '%s' cachestore (part of plan cache) due to some database maintenance or reconfigure operations. Diese Meldung wird alle fünf Minuten protokolliert, solange der Cache innerhalb dieses Zeitintervalls geleert wird.

Der Prozedurcache wird auch im folgenden Szenario geleert: Sie führen mehrere Abfragen für eine Datenbank aus, die über Standardoptionen verfügt. Anschließend wird die Datenbank gelöscht.

Anzeigen von Datenbankinformationen

Sie können Katalogsichten, Systemfunktionen und gespeicherte Systemprozeduren verwenden, um Informationen zu Datenbanken, Dateien und Dateigruppen zurückzugeben.

Berechtigungen

Um eine Datenbank zu ändern, muss eine Anmeldung entweder die Serveradministratoranmeldung sein (erstellt, wenn der Azure SQL-Datenbank logischer Server bereitgestellt wurde), der Microsoft Entra-Administrator des Servers, ein Mitglied der Datenbankrolle "dbmanager" in master, ein Mitglied der db_owner Datenbankrolle in der aktuellen Datenbank oder dbo der Datenbank. Microsoft Entra-ID ist (früher Azure Active Directory).

Zum Skalieren von Datenbanken über T-SQL sind ALTER DATABASE-Berechtigungen erforderlich. Für die Skalierung von Datenbanken über das Azure-Portal, PowerShell, die Azure CLI oder REST-API sind Azure RBAC-Berechtigungen erforderlich, insbesondere die Azure RBAC-Rollen „Mitwirkender“, „SQL-DB-Mitwirkender“ oder „SQL Server-Mitwirkender“. Weitere Informationen finden Sie unter Azure RBAC: integrierte Rollen.

Beispiele

A. Überprüfen Sie die Bearbeitungsoptionen, und ändern Sie diese

Legt eine Edition und maximale Größe für die Datenbank db1 fest:

SELECT Edition = DATABASEPROPERTYEX('db1', 'EDITION'),
        ServiceObjective = DATABASEPROPERTYEX('db1', 'ServiceObjective'),
        MaxSizeInBytes =  DATABASEPROPERTYEX('db1', 'MaxSizeInBytes');

ALTER DATABASE [db1] MODIFY (EDITION = 'Premium', MAXSIZE = 1024 GB, SERVICE_OBJECTIVE = 'P15');

B. Verschieben einer Datenbank in einen anderen Pool für elastische Datenbanken

Verschiebt eine vorhandene Datenbank in einen Pool mit dem Namen pool1:

ALTER DATABASE db1
MODIFY ( SERVICE_OBJECTIVE = ELASTIC_POOL ( name = pool1 ) ) ;

C. Hinzufügen einer sekundären Datenbank für eine Georeplikation

Erstellt die lesbare sekundäre Datenbank db1 auf dem Server secondaryserver der Datenbank db1 auf dem lokalen Server.

ALTER DATABASE db1
ADD SECONDARY ON SERVER secondaryserver
WITH ( ALLOW_CONNECTIONS = ALL )

D: Entfernen einer sekundären Datenbank für eine Georeplikation

Entfernt die sekundäre Datenbank db1 auf dem Server secondaryserver.

ALTER DATABASE db1
REMOVE SECONDARY ON SERVER testsecondaryserver

E. Failover für eine sekundäre Datenbank für eine Georeplikation

Stuft die sekundäre Datenbank db1 auf dem Server secondaryserver höher, damit sie bei Ausführung auf dem Server secondaryserver zur neuen primären Datenbank wird.

ALTER DATABASE db1 FAILOVER

F. Erzwingen eines Failovers für eine sekundäre Datenbank für eine Georeplikation mit Datenverlust

Erzwingt die sekundäre Datenbank db1 auf dem Server secondaryserver, damit diese bei Ausführung die primäre Datenbank auf dem Server secondaryserver wird, wenn der primäre Server nicht mehr verfügbar ist. Diese Option kann zu Datenverlust führen.

ALTER DATABASE db1 FORCE_FAILOVER_ALLOW_DATA_LOSS

G. Aktualisieren einer einzelnen Datenbank auf Diensttarif S0 (Standard Edition, Leistungsstufe 0)

Der folgende Befehl führt ein Update für eine einzelne Datenbank auf die Standard Edition (Diensttarif) mit einer Computegröße (Dienstziel) von S0 und einer maximalen Größe von 250 GB durch.

ALTER DATABASE [db1] MODIFY (EDITION = 'Standard', MAXSIZE = 250 GB, SERVICE_OBJECTIVE = 'S0');

H. Aktualisieren der Sicherungsspeicherredundanz einer Datenbank

In diesem Beispiel wird die Sicherungsspeicherredundanz einer Datenbank in Zonenredundanz aktualisiert. Die neue Einstellung wird bei allen zukünftigen Sicherungen dieser Datenbank verwendet. Dies gilt auch für Zeitpunktwiederherstellungs- und Langzeitaufbewahrungssicherungen (sofern konfiguriert).

ALTER DATABASE db1 MODIFY BACKUP_STORAGE_REDUNDANCY = 'ZONE'

Nächste Schritte

* SQL Managed Instance *  

 

Übersicht: Verwaltete Azure SQL-Instanz

Verwenden Sie diese Anweisung in Verwaltete Azure SQL-Instanz, um Datenbankoptionen festzulegen.

Aufgrund ihrer Länge wird die ALTER DATABASE-Syntax in mehrere Artikel aufgeteilt.

Artikel BESCHREIBUNG
ALTER DATABASE
Der aktuelle Artikel umfasst die Syntax und weitere Informationen zum Festlegen von Datei- und Dateigruppenoptionen, von Datenbankoptionen und des Datenbank-Kompatibilitätsgrads.
ALTER DATABASE-Optionen für Dateien und Dateigruppen
Stellt die Syntax und weitere Informationen zum Hinzufügen und Entfernen von Dateien und Dateigruppen in einer Datenbank sowie zum Ändern der Datei- und Dateigruppenattribute bereit.
ALTER DATABASE SET-Optionen
Stellt die Syntax und weitere Informationen zum Ändern der Datenbankattribute mithilfe der SET-Optionen von ALTER DATABASE bereit.
ALTER DATABASE-Kompatibilitätsgrad
Stellt die Syntax und weitere Informationen für die SET-Optionen von ALTER DATABASE bereit, die sich auf die Datenbank-Kompatibilitätsgrade beziehen.

Syntax

-- Azure SQL Managed Instance syntax  
ALTER DATABASE { database_name | CURRENT }  
{
    MODIFY NAME = new_database_name
  | COLLATE collation_name
  | <file_and_filegroup_options>  
  | SET <option_spec> [ ,...n ]  
}  
[;]

<file_and_filegroup_options>::=  
  <add_or_modify_files>::=  
  <filespec>::=
  <add_or_modify_filegroups>::=  
  <filegroup_updatability_option>::=  

<option_spec> ::=
{
    <auto_option>
  | <change_tracking_option>
  | <cursor_option>
  | <db_encryption_option>  
  | <db_update_option>
  | <db_user_access_option>
  | <delayed_durability_option>
  | <parameterization_option>
  | <query_store_options>
  | <snapshot_option>
  | <sql_option>
  | <target_recovery_time_option>
  | <temporal_history_retention>
  | <compatibility_level>
      { 150 | 140 | 130 | 120 | 110 | 100 | 90 }

}  

Argumente

database_name

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

CURRENT
Legt fest, dass die zurzeit verwendete Datenbank geändert werden soll.

Bemerkungen

  • Verwenden Sie DROP DATABASE, um eine Datenbank zu entfernen.

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

  • 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.

  • Sie können den Plancache für die Azure SQL Managed Instance bereinigen, indem Sie eine der folgenden Optionen festlegen.

    • COLLATE
    • MODIFY FILEGROUP DEFAULT
    • MODIFY FILEGROUP READ_ONLY
    • MODIFY FILEGROUP READ_WRITE
    • MODIFY NAME

    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. Für jeden geleerten Cachespeicher im Plancache enthält das SQL Server-Fehlerprotokoll folgende Meldung zur Information: „SQL Server hat für den "%2!s!"-Cachespeicher (Bestandteil des Plancache) %1!s! 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. Der Plancache wird auch dann geleert, wenn mehrere Abfragen auf eine Datenbank angewendet werden, die Standardoptionen aufweist. Anschließend wird die Datenbank gelöscht.

  • Einige ALTER DATABASE-Anweisungen erfordern eine exklusive Sperre der Datenbank. Aus diesem Grund können sie fehlschlagen, wenn ein anderer aktiver Prozess die Datenbank sperrt. In diesem Fall wird der Fehler Msg 5061, Level 16, State 1, Line 38 mit der Meldung ALTER DATABASE failed because a lock could not be placed on database '<database name>'. Try again later ausgelöst. Hierbei handelt es sich in der Regel um einen vorübergehenden Fehler. Versuchen Sie noch mal, die ALTER DATABASE-Anweisung auszuführen, wenn alle Sperren der Datenbank aufgehoben wurden. Die Systemsicht sys.dm_tran_locks enthält Informationen zu aktiven Sperren. Verwenden Sie die folgende Abfrage, um zu überprüfen, ob gemeinsame oder exklusive Sperren für eine Datenbank vorliegen.

    SELECT
        resource_type, resource_database_id, request_mode, request_type, request_status, request_session_id 
    FROM 
        sys.dm_tran_locks
    WHERE
        resource_database_id = DB_ID('testdb');
    

Anzeigen von Datenbankinformationen

Sie können Katalogsichten, Systemfunktionen und gespeicherte Systemprozeduren verwenden, um Informationen zu Datenbanken, Dateien und Dateigruppen zurückzugeben.

Berechtigungen

Datenbanken können nur durch den Prinzipalanmeldenamen auf Serverebene (vom Bereitstellungsprozess erstellt) oder Mitglieder der Datenbankrolle dbcreator geändert werden.

Wichtig

Der Datenbankbesitzer kann die Datenbank nur ändern, wenn er Mitglied der Rolle dbcreator ist.

Beispiele

In den folgenden Beispielen wird gezeigt, wie Sie die automatische Optimierung festlegen und einer Datenbank in Azure SQL Managed Instance eine Datei hinzufügen.

ALTER DATABASE WideWorldImporters
  SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON);

ALTER DATABASE WideWorldImporters
  ADD FILE (NAME = 'data_17');

Nächste Schritte

* Azure Synapse
Analytics *
 

 

Übersicht: Azure Synapse Analytics

In Azure Synapse ändert ALTER DATABASE bestimmte Konfigurationsoptionen eines dedizierten SQL-Pools.

Aufgrund ihrer Länge wird die ALTER DATABASE-Syntax in mehrere Artikel aufgeteilt.

ALTER DATABASE SET-Optionen stellt die Syntax und weitere Informationen zum Ändern der Datenbankattribute mithilfe der SET-Optionen von ALTER DATABASE bereit.

Syntax

ALTER DATABASE { database_name | CURRENT }
{
  MODIFY NAME = new_database_name
| MODIFY ( <edition_option> [, ... n] )
| SET <option_spec> [ ,...n ] [ WITH <termination> ]
}
[;]

<edition_option> ::=
      MAXSIZE = {
            250 | 500 | 750 | 1024 | 5120 | 10240 | 20480
          | 30720 | 40960 | 51200 | 61440 | 71680 | 81920
          | 92160 | 102400 | 153600 | 204800 | 245760
      } GB
      | SERVICE_OBJECTIVE = {
            'DW100' | 'DW200' | 'DW300' | 'DW400' | 'DW500'
          | 'DW600' | 'DW1000' | 'DW1200' | 'DW1500' | 'DW2000'
          | 'DW3000' | 'DW6000' | 'DW500c' | 'DW1000c' | 'DW1500c'
          | 'DW2000c' | 'DW2500c' | 'DW3000c' | 'DW5000c' | 'DW6000c'
          | 'DW7500c' | 'DW10000c' | 'DW15000c' | 'DW30000c'
      }

Argumente

database_name

Gibt den Namen der zu ändernden Datenbank an.

MODIFY NAME = new_database_name

Benennt die Datenbank in den angegebenen Namen new_database_name um.

Für die Option „MODIFY NAME“ gelten einige Einschränkungen bei der Unterstützung in Azure Synapse:

  • Keine Unterstützung für serverlose Azure Synapse-Pools
  • Keine Unterstützung für dedizierte SQL-Pools, die im Azure Synapse-Arbeitsbereich erstellt wurden
  • Unterstützt mit dedizierten SQL-Pools (vormals SQL DW), die über das Azure-Portal erstellen wurden, einschließlich derer mit verbundenem Arbeitsbereich

MAXSIZE

Der Standardwert ist 245.760 GB (240 TB).

Anwendungsbereich: Optimiert für Compute Gen1

Der Wert für die maximal zulässige Größe der Datenbank Die Datenbank kann nicht größer sein als MAXSIZE.

Anwendungsbereich: Optimiert für Compute Gen2

Die maximal zulässige Größe für Rowstore-Daten in der Datenbank Daten, die in Rowstore-Tabellen, dem Deltastore eines Columnstore-Index oder einem nicht gruppierten Index für einen gruppierten Columnstore-Index gespeichert sind, können MAXSIZE nicht übersteigen. Daten, die im Columnstore-Format komprimiert sind, haben kein Größenlimit und werden nicht durch MAXSIZE beschränkt.

SERVICE_OBJECTIVE

Gibt die Computegröße (Dienstziel) an. Weitere Informationen zu Dienstzielen für Azure Synapse finden Sie unter Data Warehouse-Einheiten (DWUs).

Berechtigungen

Folgende Berechtigungen sind erforderlich:

  • Der Prinzipalanmeldename auf Serverebene (der während des Bereitstellungsprozesses erstellt wurde) oder
  • Mitgliedschaft in der dbmanager-Datenbankrolle

Der Datenbankbesitzer kann die Datenbank nur ändern, wenn er Mitglied der Rolle dbmanager ist.

Hinweise

Bei der aktuellen Datenbank muss es sich um eine andere Datenbank als die handeln, die Sie ändern. Deshalb muss ALTER ausgeführt werden, während eine Verbindung zur master-Datenbank besteht.

Der Wert für COMPATIBILITY_LEVEL ist in SQL Analytics standardmäßig auf 130 festgelegt und kann nicht geändert werden. Weitere Informationen finden Sie unter Verbesserte Abfrageleistung mit Kompatibilitätsgrad 130 in Azure SQL-Datenbank.

Hinweis

COMPATIBILITY_LEVEL gilt nur für bereitgestellte Ressourcen (bzw. Ressourcenpools).

Einschränkungen

Für die Ausführung von ALTER DATABASE muss die Datenbank online sein und darf sich nicht im angehaltenen Zustand befinden.

Die Anweisung ALTER DATABASE muss im Autocommitmodus ausgeführt werden. Dabei handelt es sich um den Standardmodus für die Transaktionsverwaltung. Dies wird in den Verbindungseinstellungen festgelegt.

Die Anweisung ALTER DATABASE darf nicht Teil einer benutzerdefinierten Transaktion sein.

Sie können die Datenbanksortierung nicht ändern.

Beispiele

Stellen Sie vor dem Ausführen dieser Beispiele sicher, dass es sich bei der Datenbank, die Sie ändern, nicht um die aktuelle Datenbank handelt. Bei der aktuellen Datenbank muss es sich um eine andere Datenbank als die handeln, die Sie ändern. Deshalb muss ALTER ausgeführt werden, während eine Verbindung zur master-Datenbank besteht.

A. Ändern des Datenbanknamens

ALTER DATABASE AdventureWorks2022
MODIFY NAME = Northwind;

B. Ändern der maximalen Datenbankgröße

ALTER DATABASE dw1 MODIFY ( MAXSIZE=10240 GB );

C. Ändern der Computegröße (Dienstziel)

ALTER DATABASE dw1 MODIFY ( SERVICE_OBJECTIVE= 'DW1200' );

D: Ändern der maximalen Größe und der Computegröße (Dienstziel)

ALTER DATABASE dw1 MODIFY ( MAXSIZE=10240 GB, SERVICE_OBJECTIVE= 'DW1200' );

Nächste Schritte

* Analytics
Platform System (PDW) *
 

 

Übersicht: Analyseplattformsystem

In Analytics Platform System (PDW) ändert „ALTER DATABASE“ die Optionen für die maximale Datenbankgröße für replizierte Tabellen, verteilte Tabellen und das Transaktionsprotokoll. Verwenden Sie diese Anweisung, um die Speicherplatzzuordnungen für eine Datenbank zu verwalten, wenn sich diese vergrößert oder verkleinert. In diesem Artikel wird auch die Syntax im Zusammenhang mit dem Festlegen von Datenbankoptionen in Analytics Platform System (PDW) beschrieben.

Syntax

-- Analytics Platform System
ALTER DATABASE database_name
    SET ( <set_database_options> | <db_encryption_option> )
[;]

<set_database_options> ::=
{
    AUTOGROW = { ON | OFF }
    | REPLICATED_SIZE = size [GB]
    | DISTRIBUTED_SIZE = size [GB]
    | LOG_SIZE = size [GB]
    | SET AUTO_CREATE_STATISTICS { ON | OFF }
    | SET AUTO_UPDATE_STATISTICS { ON | OFF }
    | SET AUTO_UPDATE_STATISTICS_ASYNC { ON | OFF }
}

<db_encryption_option> ::=
    ENCRYPTION { ON | OFF }

Argumente

database_name

Der Name der Datenbank, die geändert werden soll. Um eine Liste von Datenbanken auf dem Gerät anzuzeigen, verwenden Sie sys.databases.

AUTOGROW = { ON | OFF }

Aktualisiert die Option AUTOGROW. Wenn AUTOGROW ON ist, erhöht Analytics-Plattformsystem (PDW) automatisch den zugeordneten Speicherplatz für replizierte Tabellen und verteilte Tabellen sowie das Transaktionsprotokoll nach Bedarf, um den gesteigerten Speicheranforderungen gerecht zu werden. Wenn AUTOGROW OFF ist, gibt Analytics-Plattformsystem (PDW) einen Fehler zurück, wenn replizierte Tabellen, verteilte Tabellen oder das Transaktionsprotokoll die Einstellung für die maximale Größe überschreiten.

REPLICATED_SIZE = size [GB]

Gibt die neue maximale Anzahl von Gigabyte pro Computeknoten für die Speicherung aller replizierten Tabellen in der Datenbank an, die geändert werden. Wenn Sie Appliancespeicherplatz planen, müssen Sie REPLICATED_SIZE mit der Anzahl der Computeknoten in der Appliance multiplizieren.

DISTRIBUTED_SIZE = size [GB]

Gibt die neue maximale Anzahl von Gigabyte pro Datenbank für die Speicherung aller verteilten Tabellen in der Datenbank an, die geändert werden. Die Größe wird auf alle Computeknoten der Appliance verteilt.

LOG_SIZE = size [GB]

Gibt die neue maximale Anzahl von Gigabyte pro Datenbank für die Speicherung aller Transaktionsprotokolle in der Datenbank an, die geändert werden. Die Größe wird auf alle Computeknoten der Appliance verteilt.

ENCRYPTION { ON | OFF }

Legt fest, ob die Datenbank verschlüsselt (ON) oder nicht verschlüsselt (OFF) werden soll. Die Verschlüsselung kann nur für Analytics-Plattformsystem (PDW) konfiguriert werden, wenn sp_pdw_database_encryption auf 1 festgelegt wurde. Ein Datenbank-Verschlüsselungsschlüssel muss erstellt werden, bevor Transparent Data Encryption konfiguriert werden kann. Weitere Informationen zur Datenbankverschlüsselung finden Sie unter Transparent Data Encryption (TDE).

SET AUTO_CREATE_STATISTICS { ON | OFF }

Ist die Option AUTO_CREATE_STATISTICS zum automatischen Erstellen von Statistiken aktiviert, erstellt der Abfrageoptimierer nach Bedarf Statistiken für einzelne Spalten im Abfrageprädikat, um Kardinalitätsschätzungen für den Abfrageplan zu verbessern. Diese Statistiken für einzelne Spalten werden für Spalten erstellt, die noch nicht über ein Histogramm in einem vorhandenen Statistikobjekt verfügen.

Bei neuen Datenbanken, die nach dem Upgrade auf AU7 erstellt wurden, ist die Option standardmäßig auf ON festgelegt. Bei Datenbanken, die vor dem Upgrade erstellt wurden, ist die Option standardmäßig auf OFF festgelegt.

Weitere Informationen zu Statistiken finden Sie unter Statistik

SET AUTO_UPDATE_STATISTICS { ON | OFF }

Wenn die Option AUTO_UPDATE_STATISTICS zum automatischen Update von Statistiken aktiviert ist, stellt der Abfrageoptimierer fest, wann Statistiken veraltet sein könnten, und aktualisiert diese Statistiken, sobald sie von einer Abfrage verwendet werden. Statistiken sind veraltet, wenn die Datenverteilung in der Tabelle oder indizierten Sicht durch die Vorgänge INSERT, UPDATE, DELETE oder MERGE geändert wurde. Der Abfrageoptimierer stellt fest, wann Statistiken veraltet sein könnten, indem er die Anzahl der Datenänderungen seit des letzten Statistikupdates ermittelt und sie mit einem Schwellenwert vergleicht. Der Schwellenwert basiert auf der Anzahl von Zeilen in der Tabelle oder indizierten Sicht.

Bei neuen Datenbanken, die nach dem Upgrade auf AU7 erstellt wurden, ist die Option standardmäßig auf ON festgelegt. Bei Datenbanken, die vor dem Upgrade erstellt wurden, ist die Option standardmäßig auf OFF festgelegt.

Weitere Informationen zu Statistiken finden Sie unter Statistik.

SET AUTO_UPDATE_STATISTICS_ASYNC { ON | OFF }

Mit der AUTO_UPDATE_STATISTICS_ASYNC-Option für die asynchrone Statistikaktualisierung wird festgelegt, ob der Abfrageoptimierer die synchrone oder asynchrone Statistikaktualisierung verwendet. Die AUTO_UPDATE_STATISTICS_ASYNC-Option gilt für Statistikobjekte, die für Indizes, einzelne Spalten in Abfrageprädikaten und mit der CREATE STATISTICS -Anweisung generierte Statistiken erstellt wurden.

Bei neuen Datenbanken, die nach dem Upgrade auf AU7 erstellt wurden, ist die Option standardmäßig auf ON festgelegt. Bei Datenbanken, die vor dem Upgrade erstellt wurden, ist die Option standardmäßig auf OFF festgelegt.

Weitere Informationen zu Statistiken finden Sie unter Statistik.

Berechtigungen

Erfordert die Berechtigung ALTER für die Datenbank.

Fehlermeldungen

Wenn „auto-stats“ deaktiviert ist und Sie versuchen, die Statistikeinstellungen zu ändern, gibt PDW die Fehlermeldung This option is not supported in PDW aus. Der Systemadministrator kann „auto-stats“ aktivieren, indem er den Featureschalter AutoStatsEnabled aktiviert.

Hinweise

Die Werte für REPLICATED_SIZE, DISTRIBUTED_SIZE und LOG_SIZE können größer, gleich oder kleiner als die aktuellen Werte für die Datenbank sein.

Einschränkungen

Vergrößerungs- und Verkleinerungsvorgänge sind ungenau. Die resultierenden tatsächlichen Größen können von den Größenparametern abweichen.

Analytics-Plattformsystem (PDW) führt die ALTER DATABASE-Anweisung nicht als unteilbaren Vorgang aus. Wenn die Anweisung während der Ausführung abgebrochen wird, bleiben Änderungen, die bereits durchgeführt wurden, erhalten.

Die Statistikeinstellungen funktionieren nur, wenn der Administrator „auto-stats“ aktiviert hat. Wenn Sie Administrator sind, aktivieren oder deaktivieren Sie „auto-stats“ mithilfe des Featureschalters AutoStatsEnabled.

Sperrverhalten

Führt eine gemeinsame Sperre für das DATABASE-Objekt durch. Sie können eine Datenbank, die von einem anderen Benutzer im Lese- oder Schreibmodus verwendet wird, nicht ändern. Dies schließt auch Sitzungen ein, die eine USE-Anweisung für die Datenbank ausgeführt haben.

Leistung

Das Verkleinern einer Datenbank kann, abhängig von der Größe der tatsächlichen Daten innerhalb der Datenbank und der Menge der Fragmentierung auf dem Datenträger, viel Zeit und viele Systemressourcen in Anspruch nehmen. Das Verkleinern einer Datenbank könnte beispielsweise mehrere Stunden oder noch länger dauern.

Bestimmen des Verschlüsselungsfortschritts

Verwenden Sie die folgende Abfrage, um den Fortschritt der transparenten Datenverschlüsselung für die Datenbank als Prozentsatz zu bestimmen:

WITH
database_dek AS (
    SELECT ISNULL(db_map.database_id, dek.database_id) AS database_id,
        dek.encryption_state, dek.percent_complete,
        dek.key_algorithm, dek.key_length, dek.encryptor_thumbprint,
        type
    FROM sys.dm_pdw_nodes_database_encryption_keys AS dek
    INNER JOIN sys.pdw_nodes_pdw_physical_databases AS node_db_map
        ON dek.database_id = node_db_map.database_id
        AND dek.pdw_node_id = node_db_map.pdw_node_id
    LEFT JOIN sys.pdw_database_mappings AS db_map
        ON node_db_map .physical_name = db_map.physical_name
    INNER JOIN sys.dm_pdw_nodes nodes
        ON nodes.pdw_node_id = dek.pdw_node_id
    WHERE dek.encryptor_thumbprint <> 0x
),
dek_percent_complete AS (
    SELECT database_dek.database_id, AVG(database_dek.percent_complete) AS percent_complete
    FROM database_dek
    WHERE type = 'COMPUTE'
    GROUP BY database_dek.database_id
)
SELECT DB_NAME( database_dek.database_id ) AS name,
    database_dek.database_id,
    ISNULL(
       (SELECT TOP 1 dek_encryption_state.encryption_state
        FROM database_dek AS dek_encryption_state
        WHERE dek_encryption_state.database_id = database_dek.database_id
        ORDER BY (CASE encryption_state
            WHEN 3 THEN -1
            ELSE encryption_state
            END) DESC), 0)
        AS encryption_state,
dek_percent_complete.percent_complete,
database_dek.key_algorithm, database_dek.key_length, database_dek.encryptor_thumbprint
FROM database_dek
INNER JOIN dek_percent_complete
    ON dek_percent_complete.database_id = database_dek.database_id
WHERE type = 'CONTROL';

Ein umfangreiches Beispiel mit allen Schritten zur Implementierung von TDE finden Sie unter Transparente Datenverschlüsselung (TDE).

Beispiele: Analytics-Plattformsystem (PDW)

A. Ändern der AUTOGROW-Einstellung

Legen Sie AUTOGROW für die Datenbank CustomerSales auf ON fest.

ALTER DATABASE CustomerSales
    SET ( AUTOGROW = ON );

B. Ändern des maximalen Speicherplatzes für replizierte Tabellen

Im folgenden Beispiel wird die Speicherbegrenzung für replizierte Tabellen für die Datenbank CustomerSales auf 1 GB festgelegt. Dabei handelt es sich um die Speicherbegrenzung pro Computeknoten.

ALTER DATABASE CustomerSales
    SET ( REPLICATED_SIZE = 1 GB );

C. Ändern des maximalen Speicherplatzes für verteilte Tabellen

Im folgenden Beispiel wird die Speicherbegrenzung für verteilte Tabellen für die Datenbank CustomerSales auf 1000 GB (ein Terabyte) festgelegt. Dabei handelt es sich um die gemeinsame Speicherbegrenzung für alle Computeknoten der Appliance und nicht um die Speicherbegrenzung pro Computeknoten.

ALTER DATABASE CustomerSales
    SET ( DISTRIBUTED_SIZE = 1000 GB );

D: Ändern des maximalen Speicherplatzes für das Transaktionsprotokoll

Im folgenden Beispiel wird die Datenbank CustomerSales so aktualisiert, dass die maximale Größe des SQL Server-Transaktionsprotokolls für die Appliance 10 GB beträgt.

ALTER DATABASE CustomerSales
    SET ( LOG_SIZE = 10 GB );

E. Überprüfung auf aktuelle Statistikwerte

Die folgende Abfrage gibt die aktuellen Statistikwerte für sämtliche Datenbanken zurück. Der Wert 1 bedeutet, dass das Feature aktiviert ist, und eine 0 bedeutet, dass das Feature deaktiviert ist.

SELECT NAME,
    is_auto_create_stats_on,
    is_auto_update_stats_on,
    is_auto_update_stats_async_on
FROM sys.databases;

F. Aktivieren der automatischen Erstellung und des automatischen Updates von Statistiken für eine Datenbank

Mit der folgenden Anweisung können Sie Statistiken zur automatischen und asynchronen Erstellung und Aktualisierung für die Datenbank „CustomerSales“ aktivieren. Dadurch werden zur Erstellung hochwertiger Abfragepläne nach Bedarf einspaltige Statistiken erstellt und aktualisiert.

ALTER DATABASE CustomerSales
    SET AUTO_CREATE_STATISTICS ON;
ALTER DATABASE CustomerSales
    SET AUTO_UPDATE_STATISTICS ON;
ALTER DATABASE
    SET AUTO_UPDATE_STATISTICS_ASYNC ON;

Nächste Schritte