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ätsstufe | 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>
{ 160 | 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 enthaltenen 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
Die Sortierung kann nicht geändert werden, nachdem die Datenbank auf Azure SQL-Datenbank erstellt wurde.
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 options and Control Transaction Durability.
<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 Automatischen Commit-Modus (standardtransaktionsverwaltungsmodus) ausgeführt werden und ist in einer expliziten oder impliziten Transaktion nicht zulässig.
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. Wenn eine Dateigruppe offline ist, tritt bei jedem Versuch, über eine SQL-Anweisung auf die Dateigruppe zuzugreifen, ein Fehler auf. 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. Darüber hinaus schlägt jede INSERT
, UPDATE
oder Anweisung, DELETE
die eine Tabelle mit einem beliebigen Index in einer Offlinedateigruppe ändert, fehl.
Wenn sich eine Datenbank im RESTOREING-Zustand befindet, schlagen die meisten ALTER DATABASE
Anweisungen fehl. Eine Ausnahme bildet das Festlegen von Datenbank-Spiegelungsoptionen. Eine Datenbank befindet sich möglicherweise während eines aktiven Wiederherstellungsvorgangs im WIEDERHERSTELLEN-Zustand 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 ALTER DATABASE database_name COLLATE
Anweisung fehl. SQL Server gibt eine Fehlermeldung für jedes Objekt zurück, das die ALTER
Aktion 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 doppelte Namen aus der geänderten Sortierung resultieren, können die folgenden Namespaces den Fehler einer Datenbanksortierungsänderung verursachen:
- 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
Doppelte Namen, die sich aus der neuen Sortierung ergeben, führen dazu, dass die Änderungsaktion fehlschlägt, und SQL Server gibt eine Fehlermeldung zurück, die den Namespace angibt, 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 höher.
USE master;
GO
CREATE DATABASE testdb
COLLATE SQL_Latin1_General_CP1_CI_AS ;
GO
ALTER DATABASE testDB
COLLATE French_CI_AI ;
GO
Zugehöriger Inhalt
* 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>
{ 160 | 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. Das Ändern der maximalen Größe der Datenbank kann dazu führen, dass die Datenbank EDITION 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 | Ja | Ja | Ja | Ja | Ja |
250 MB | Ja | Ja | Ja | Ja | Ja |
500 MB | Ja | Ja | Ja | Ja | Ja |
1 GB | Ja | Ja | Ja | Ja | Ja |
2 GB | Ja (D) | Ja | Ja | Ja | Ja |
5 GB | N/V | Ja | Ja | Ja | Ja |
10 GB | N/V | Ja | Ja | Ja | Ja |
20 GB | N/V | Ja | Ja | Ja | Ja |
30 GB | N/V | Ja | Ja | Ja | Ja |
40 GB | N/V | Ja | Ja | Ja | Ja |
50 GB | N/V | Ja | Ja | Ja | Ja |
100 GB | N/V | Ja | Ja | Ja | Ja |
150 GB | N/V | Ja | Ja | Ja | Ja |
200 GB | N/V | Ja | Ja | Ja | Ja |
250 GB | N/V | Ja (D) | Ja (D) | Ja | Ja |
300 GB | N/V | Ja | Ja | Ja | Ja |
400 GB | N/V | Ja | Ja | Ja | Ja |
500 GB | N/V | Ja | Ja | Ja (D) | Ja |
750 GB | N/V | Ja | Ja | Ja | Ja |
1024 GB | N/V | Ja | Ja | Ja | Ja (D) |
Von 1024 GB bis zu 4096 GB in Schritten von 256 GB 1 | – | – | – | – | Ja |
1 P11 und P15 ermöglichen MAXSIZE bis zu 4 TB, wobei 1024 GB die Standardgröße aufweisen. 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, aber MAXSIZE nicht angegeben ist, wird der Standardwert für die Edition verwendet. Ist z. B. die EDITION auf "Standard" festgelegt, und die MAXSIZE-Eigenschaft ist nicht angegeben, dann wird die MAXSIZE-Größe 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).
- Für das DTU-Kaufmodell:
S0
,S1
,S2
,S3
,S4
,S6
,S7
,S9
,S12
,P1
,P2
,P4
,P6
,P11
,P15
. Verweisen Sie auf die Ressourcenbeschränkungen für einzelne DTU-Datenbanken oder Ressourcengrenzwerte für DTU-elastische Pools, um die Anzahl der DTU zu ermitteln, die jeder Computegröße zugewiesen ist. - Wählen Sie die Dienstebene für das vCore-Kaufmodell aus, und geben Sie die Anzahl der virtuellen Kerne aus einer voreingestellten Liste von Werten an, wobei
n
für die Anzahl der virtuellen Kerne steht. Weitere Informationen finden Sie unter Ressourcenlimits für Einzeldatenbanken mit virtuellem Kern oder Ressourcenlimits für Pools für elastische Datenbanken mit virtuellem Kern.- Zum Beispiel:
GP_Gen5_8
für Universell – Standard-Serie (Gen5) – Compute, 8 virtuelle Kerne.GP_S_Gen5_8
für Universell serverlos – Standard-Serie (Gen5) – Computing, 8 virtuelle Kerne.HS_Gen5_8
für Hyperscale – bereitgestelltes Computing – Standard-Serie (Gen5), 8 virtuelle Kerne.
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ären Hyperscale-Replikaten.
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ären Hyperscale-Replikaten.
Informationen zu Größe, Editionen und den Kombinationen von Servicezielen finden Sie unter Vergleichen von vCore- und DTU-basierten Einkaufsmodellen von Azure SQL-Datenbank, DTU-Ressourcenlimits und vCore-Ressourcengrenzwerten. Die Unterstützung für PRS-Dienstziele wurde entfernt.
Wenn SERVICE_OBJECTIVE nicht angegeben wird, 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. Beispielsweise können Sie S0 nicht angeben, wenn die Edition Premium ist.
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 Elastische Pools helfen Ihnen, mehrere Datenbanken in Azure SQL Database zu verwalten und zu skalieren. 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 auf der Hyperscale-Dienstebene können keinem elastischen Pool 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 beim Erstellen der sekundären Daten wird nicht über T-SQL unterstützt.
WITH ALLOW_CONNECTIONS { ALL | NO }
Wenn ALLOW_CONNECTIONS nicht angegeben ist, ist sie standardmäßig auf ALLE 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 wird, wird die sekundäre Datenbank nicht in einem elastischen Pool 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:
- Die primäre Datenbank übernimmt keine neuen Transaktionen mehr.
- Alle ausstehenden Transaktionen werden in der sekundären Datenbank geleert.
- 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 nicht verfügbar ist, wenn dieser Befehl ausgegeben wird, schlägt der Befehl mit einer Fehlermeldung fehl, die angibt, 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:
- Die angegebene sekundäre Datenbank wird sofort zur primären Datenbank und beginnt, neue Transaktionen zu akzeptieren.
- 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.
- Zur Wiederherstellung der Daten aus dieser inkrementellen Sicherung der ursprünglichen primären Datenbank bindet der Benutzer DevOps/CSS ein.
- 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 Prozess ist asynchron, und es kann zu einer Verzögerung kommen, bis dieser Vorgang abgeschlossen ist. 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 Automatischen Commit-Modus (standardtransaktionsverwaltungsmodus) ausgeführt werden und ist in einer expliziten oder impliziten Transaktion nicht zulässig.
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 in den integrierten Azure-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;
Hinweis
Weitere Informationen finden Sie in den Richtlinien zur Notfallwiederherstellung – Azure SQL-Datenbank und der Prüfliste für hohe Verfügbarkeit und Notfallwiederherstellung Azure SQL-Datenbank.
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 datenverlusten.
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. Alle zukünftigen Sicherungen dieser Datenbank verwenden die neue Einstellung. Dies gilt auch für Zeitpunktwiederherstellungs- und Langzeitaufbewahrungssicherungen (sofern konfiguriert).
ALTER DATABASE db1 MODIFY BACKUP_STORAGE_REDUNDANCY = 'ZONE';
Zugehöriger Inhalt
- CREATE DATABASE (Azure SQL-Datenbank)
- DATABASEPROPERTYEX
- DROP DATABASE
- SET TRANSACTION ISOLATION LEVEL
- EVENTDATA
- sp_spaceused
- sys.databases
- sys.database_files
- sys.filegroups
- sys.master_files
- Systemdatenbanken
- Leitfaden zur Notfallwiederherstellung – Azure SQL-Datenbank
- Prüfliste für Hochverfügbarkeit und Notfallwiederherstellung in Azure SQL-Datenbank
- DTU-Ressourcenlimits
- vCore-Ressourcenlimits für Einzeldatenbanken
- vCore-Ressourcenlimits für Pools für elastische Datenbanken
* 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>
{ 160 | 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 Automatischen Commit-Modus (standardtransaktionsverwaltungsmodus) ausgeführt werden und ist in einer expliziten oder impliziten Transaktion nicht zulässig.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. 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 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 FehlerMsg 5061, Level 16, State 1, Line 38
mit der MeldungALTER 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, dieALTER DATABASE
-Anweisung auszuführen, wenn alle Sperren der Datenbank aufgehoben wurden. Die Systemsichtsys.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 Besitzer der Datenbank kann die Datenbank nur ändern, wenn sie Mitglied der dbcreator
Rolle sind.
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');
Zugehöriger Inhalt
* 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 stellen die Syntax und die zugehörigen Informationen zum Ändern der Attribute einer Datenbank mithilfe der SET-Optionen bereit ALTER DATABASE
.
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 über MAXSIZE hinaus wachsen.
Anwendungsbereich: Optimiert für Compute Gen2
Die maximal zulässige Größe für Rowstore-Daten in der Datenbank Daten, die in Zeilenspeichertabellen, dem Deltastore eines Columnstore-Index oder einem nicht gruppierten Index in einem gruppierten Columnstore-Index gespeichert sind, können nicht über MAXSIZE hinaus wachsen. In das Spaltenspeicherformat komprimierte Daten weisen keine Größenbeschränkung auf und sind nicht durch MAXSIZE eingeschrä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 Besitzer der Datenbank kann die Datenbank nur ändern, wenn der Besitzer Mitglied der dbmanager
Rolle 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.
COMPATIBILITY_LEVEL in SQL Analytics ist standardmäßig auf 130 festgelegt und kann nicht geändert werden. Weitere Informationen finden Sie unter ALTER DATABASE-Kompatibilitätsgrad.
Hinweis
COMPATIBILITY_LEVEL gilt nur für bereitgestellte Ressourcen (bzw. Ressourcenpools).
Begrenzungen
Zur Ausführung ALTER DATABASE
muss die Datenbank online sein und kann nicht in einem angehaltenen Zustand sein.
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 ALTER DATABASE
Anweisung kann nicht Teil einer benutzerdefinierten Transaktion sein.
Sie können die Datenbanksortierung nicht ändern.
Beispiele
Bevor Sie diese Beispiele ausführen, stellen Sie sicher, dass die Datenbank, die Sie ändern, nicht die aktuelle Datenbank ist. 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' );
Zugehöriger Inhalt
* 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 für den Appliance-Speicherplatz 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).For more information about database encryption, see 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 isn't 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.
Begrenzungen
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 keine Datenbank ändern, die von einem anderen Benutzer zum Lesen oder Schreiben verwendet wird. 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 umfassendes Beispiel zur Veranschaulichung aller Schritte bei der Implementierung von TDE finden Sie unter Transparent data encryption (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;
Zugehöriger Inhalt
Übersicht: Microsoft Fabric
Microsoft Fabric
In Microsoft Fabric Warehouse ändert diese Anweisung ein Lager.
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 SET-Optionen | Stellt die Syntax und weitere Informationen zum Ändern der Datenbankattribute mithilfe der SET-Optionen von ALTER DATABASE bereit. |
Hinweise
Derzeit werden das Anhalten der Veröffentlichung von Delta Lake-Protokollen und das Deaktivieren des V-Order-Verhaltens in einem Lager die einzige Verwendung in ALTER DATABASE ... SET
Microsoft Fabric. Siehe ALTER DATABASE SET-Optionen.