Événements
31 mars, 23 h - 2 avr., 23 h
Le plus grand événement d’apprentissage SQL, Fabric et Power BI. 31 mars au 2 avril. Utilisez le code FABINSIDER pour économiser 400 $.
Inscrivez-vous aujourd’huiCe navigateur n’est plus pris en charge.
Effectuez une mise à niveau vers Microsoft Edge pour tirer parti des dernières fonctionnalités, des mises à jour de sécurité et du support technique.
Modifie certaines options de configuration d’une base de données.
Cet article fournit la syntaxe, les arguments, les notes, les autorisations et des exemples associés au produit SQL que vous choisissez.
Pour plus d’informations sur les conventions de la syntaxe, consultez Conventions de la syntaxe Transact-SQL.
Sur la ligne suivante, sélectionnez le nom du produit qui vous intéresse afin d’afficher uniquement les informations qui le concernent.
* SQL Server *
Dans SQL Server, cette instruction modifie une base de données ou les fichiers et groupes de fichiers associés à la base de données. ALTER DATABASE ajoute ou supprime des fichiers et des groupes de fichiers d'une base de données, modifie ses attributs ou ses fichiers et groupes de fichiers, modifie le classement de la base de données et définit les options de celle-ci. Les instantanés de base de données ne peuvent pas être modifiés. Pour modifier les options de base de données associées à la réplication, utilisez sp_replicationdboption.
En raison de sa longueur, la syntaxe d’ALTER DATABASE
est divisée en plusieurs articles.
Article | Description |
---|---|
ALTER DATABASE |
Le présent article indique la syntaxe à utiliser et les informations associées pour modifier le nom et le classement d’une base de données. |
Options de fichiers et de groupes de fichiers ALTER DATABASE | Indique la syntaxe à utiliser et les informations associées pour ajouter et supprimer des fichiers et groupes de fichiers d’une base de données, et pour modifier les attributs des fichiers et groupes de fichiers. |
Options ALTER DATABASE SET | Indique la syntaxe à utiliser et les informations associées pour modifier les attributs d’une base de données à l’aide des options SET d’ALTER DATABASE. |
Mise en miroir de bases de données ALTER DATABASE | Indique la syntaxe et les informations associées des options SET d’ALTER DATABASE relatives à la mise en miroir de bases de données. |
ALTER DATABASE SET HADR | Indique la syntaxe et les informations associées des options Groupes de disponibilité Always On d’ALTER DATABASE pour configurer une base de données secondaire sur un réplica secondaire d’un groupe de disponibilité Always On. |
Niveau de compatibilité ALTER DATABASE | Indique la syntaxe et les informations associées des options SET d’ALTER DATABASE relatives aux niveaux de compatibilité des bases de données. |
MODIFIER LA CONFIGURATION DÉLIMITÉE À LA BASE DE DONNÉES | Indique la syntaxe associée aux configurations étendues à la base de données utilisées pour les paramètres individuels au niveau de la base de données, tels que l’optimisation des requêtes et les comportements associés à l’exécution des requêtes. |
-- 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 }
}
Nom de la base de données à modifier.
Notes
Cette option n’est pas disponible dans une base de données autonome.
CURRENT
S’applique à : SQL Server 2012 (11.x) et versions ultérieures.
Indique que la base de données actuelle en cours d'utilisation doit être modifiée.
Renomme la base de données avec le nom spécifié nouveau_nom_base_de_données.
Spécifie le classement par défaut de la base de données. collation_name peut être un nom de classement Windows ou SQL. S'il n'est pas spécifié, le classement par défaut de l'instance de SQL Server sera appliqué à la base de données.
Notes
Le classement ne peut pas être modifié une fois la base de données créée sur Azure SQL Database.
Lors de la création de bases de données autrement qu'avec le classement par défaut, les données dans la base de données respectent toujours le classement spécifié. Pour SQL Server, quand vous créez une base de données autonome, les informations de catalogue interne sont conservées à l'aide du classement par défaut SQL Server, Latin1_General_100_CI_AS_WS_KS_SC.
Pour plus d’informations sur les noms de classements Windows et SQL, voir COLLATE.
S’applique à : SQL Server 2014 (12.x) et versions ultérieures.
Pour plus d’informations, consultez les options ALTER DATABASE SET et la durabilité des transactions de contrôle.
Pour plus d’informations, voir Options de fichiers et de groupes de fichiers d’ALTER DATABASE.
Pour supprimer une base de données, utilisez DROP DATABASE.
Pour diminuer la taille d'une base de données, utilisez DBCC SHRINKDATABASE.
L’instruction ALTER DATABASE
doit s’exécuter en mode de validation automatique (mode de gestion des transactions par défaut) et n’est pas autorisée dans une transaction explicite ou implicite.
L'état d'un fichier de base de données (par exemple, en ligne ou hors connexion) est préservé indépendamment de l'état de la base de données. Pour plus d’informations, consultez États des fichiers. L'état des fichiers dans un groupe de fichiers détermine la disponibilité de tout le groupe de fichiers. Pour qu'un groupe de fichiers soit disponible, tous ses fichiers doivent être en ligne. Si un groupe de fichiers est hors connexion, toute tentative d’accès au groupe de fichiers par une instruction SQL échoue avec une erreur. Lorsque vous créez des plans de requête pour les instructions SELECT, l'optimiseur de requête évite les index non cluster et les vues indexées qui résident dans les groupes de fichiers hors connexion. Cela permet aux instructions de s'exécuter correctement. Cependant, si le groupe de fichiers hors connexion contient le segment ou l'index cluster d'une table cible, les instructions SELECT échouent. En outre, toute INSERT
instruction ou toute UPDATE
DELETE
instruction qui modifie une table avec n’importe quel index dans un groupe de fichiers hors connexion échoue.
Lorsqu’une base de données est dans l’état RESTOREING, la plupart des ALTER DATABASE
instructions échouent. La définition des options de mise en miroir de bases de données fait exception. Une base de données peut être dans l’état RESTOREING pendant une opération de restauration active ou lorsqu’une opération de restauration d’une base de données ou d’un fichier journal échoue en raison d’un fichier de sauvegarde endommagé.
Le cache du plan pour l'instance de SQL Server est effacé par la définition de l'une des options suivantes :
Cette opération entraîne la recompilation de tous les plans d'exécution ultérieurs et peut entraîner une baisse temporaire et brutale des performances des requêtes. Pour chaque mémoire cache effacée du cache du plan, le journal des erreurs de SQL Server contient le message d'information suivant : 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
. Ce message est enregistré toutes les cinq minutes si le cache est vidé au cours de cet intervalle de temps.
Le cache de plan est également vidé dans les scénarios suivants :
AUTO_CLOSE
est activée (ON). Lorsqu'aucune connexion utilisateur ne fait référence ou n'utilise la base de données, la tâche en arrière-plan essaie de fermer et d'arrêter la base de données automatiquement.Avant d'appliquer un autre classement à une base de données, veillez à ce que les conditions suivantes soient remplies :
Si les objets suivants, qui dépendent du classement de base de données, existent dans la base de données, l’instruction ALTER DATABASE database_name COLLATE
échoue. SQL Server retourne un message d’erreur pour chaque objet bloquant l’action ALTER
:
Les informations de dépendance des entités non liées au schéma sont mises à jour automatiquement lorsque le classement de la base de données est modifié.
La modification du classement de la base de données ne crée pas de doublons parmi les noms système des objets de la base de données. Si les noms en double résultent du classement modifié, les espaces de noms suivants peuvent entraîner l’échec d’un changement de classement de base de données :
Les noms en double résultant du nouveau classement provoquent l’échec de l’action de modification et SQL Server retourne un message d’erreur spécifiant l’espace de noms où le doublon a été trouvé.
Vous pouvez utiliser les affichages catalogue, les fonctions système et les procédures stockées du système pour retourner des informations sur les bases de données, les fichiers et les groupes de fichiers.
Requiert l'autorisation ALTER
sur la base de données.
L'exemple suivant modifie le nom de la base de données AdventureWorks2022
en Northwind
.
USE master;
GO
ALTER DATABASE AdventureWorks2022
Modify Name = Northwind ;
GO
L’exemple suivant crée une base de données nommée testdb
qui utilise le classement SQL_Latin1_General_CP1_CI_AS
, puis modifie le classement de la base de données testdb
en COLLATE French_CI_AI
.
S’applique à : SQL Server 2008 (10.0.x) et versions ultérieures.
USE master;
GO
CREATE DATABASE testdb
COLLATE SQL_Latin1_General_CP1_CI_AS ;
GO
ALTER DATABASE testDB
COLLATE French_CI_AI ;
GO
* SQL Database *
Dans Azure SQL Database, utilisez cette instruction pour modifier une base de données. modifier son nom, son édition et son objectif de service, la joindre à un pool élastique ou l’en supprimer, définir ses options, l’ajouter ou la supprimer comme base de données secondaire dans une relation de géoréplication et définir son niveau de compatibilité.
En raison de sa longueur, la syntaxe d’ALTER DATABASE
est divisée en plusieurs articles.
ALTER DATABASE
Le présent article indique la syntaxe à utiliser et les informations associées pour modifier le nom et les autres paramètres d’une base de données.
Options ALTER DATABASE SET
Indique la syntaxe à utiliser et les informations associées pour modifier les attributs d’une base de données à l’aide des options SET d’ALTER DATABASE.
Niveau de compatibilité ALTER DATABASE
Indique la syntaxe et les informations associées des options SET d’ALTER DATABASE relatives aux niveaux de compatibilité des bases de données.
-- 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
}
[WITH ( [MANUAL_CUTOVER] | [PERFORM_CUTOVER] )]
[;]
<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_S_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 }
}
Nom de la base de données à modifier.
CURRENT
Indique que la base de données actuelle en cours d'utilisation doit être modifiée.
Renomme la base de données avec le nom spécifié nouveau_nom_base_de_données. L’exemple suivant remplace le nom de la base de données db1
par db2
:
ALTER DATABASE db1
MODIFY Name = db2 ;
Modifie le niveau de service de la base de données.
L’exemple suivant remplace l’édition par Premium
:
ALTER DATABASE current
MODIFY (EDITION = 'Premium');
Important
La modification d’EDITION échoue si la propriété MAXSIZE de la base de données a une valeur située en dehors de la plage valide prise en charge par cette édition.
Change la redondance du stockage des sauvegardes de restauration à un point dans le temps et les sauvegardes de conservation à long terme (si elles sont configurées) de la base de données. Les modifications sont appliquées à toutes les sauvegardes futures. Les sauvegardes existantes continuent à utiliser le paramètre précédent.
Pour appliquer la résidence des données lors de la création d’une base de données à l’aide de T-SQL, utilisez LOCAL
ou ZONE
comme entrée pour le paramètre BACKUP_STORAGE_REDUNDANCY.
Spécifie la taille maximale de la base de données. La taille maximale doit être conforme au jeu de valeurs valide pour la propriété EDITION de la base de données. La modification de la taille maximale de la base de données peut entraîner la modification de l’édition de base de données.
Notes
L’argument MAXSIZE ne s’applique pas aux bases de données uniques dans le niveau de service Hyperscale. Les bases de données de niveau de service Hyperscale s’agrandissent selon les besoins, jusqu’à 128 To. Le service SQL Database ajoute automatiquement du stockage : vous n’avez pas besoin de définir une taille maximale.
Modèle DTU
MAXSIZE | De base | S0-S2 | S3-S12 | P1-P6 | P11-P15 |
---|---|---|---|---|---|
100 Mo | Oui | Oui | Oui | Oui | Oui |
250 Mo | Oui | Oui | Oui | Oui | Oui |
500 Mo | Oui | Oui | Oui | Oui | Oui |
1 Go | Oui | Oui | Oui | Oui | Oui |
2 Go | Oui (D) | Oui | Oui | Oui | Oui |
5 Go | N/A | Oui | Oui | Oui | Oui |
10 Go | N/A | Oui | Oui | Oui | Oui |
20 Go | N/A | Oui | Oui | Oui | Oui |
30 Go | N/A | Oui | Oui | Oui | Oui |
40 Go | N/A | Oui | Oui | Oui | Oui |
50 Go | N/A | Oui | Oui | Oui | Oui |
100 Go | N/A | Oui | Oui | Oui | Oui |
150 Go | N/A | Oui | Oui | Oui | Oui |
200 Go | N/A | Oui | Oui | Oui | Oui |
250 Go | N/A | Oui (D) | Oui (D) | Oui | Oui |
300 Go | N/A | Oui | Oui | Oui | Oui |
400 Go | N/A | Oui | Oui | Oui | Oui |
500 Go | N/A | Oui | Oui | Oui (D) | Oui |
750 Go | N/A | Oui | Oui | Oui | Oui |
1 024 Go | N/A | Oui | Oui | Oui | Oui (D) |
De 1 024 Go à 4 096 Go par incréments de 256 Go 1 | N/A | N/A | N/A | N/A | Oui |
1 P11 et P15 autorisent MAXSIZE jusqu’à 4 To avec 1 024 Go étant la taille par défaut. P11 et P15 peuvent utiliser jusqu’à 4 To de stockage inclus sans frais supplémentaires. Au niveau Premium, une valeur MAXSIZE supérieure à 1 To est actuellement disponible dans les régions suivantes : USA Est 2, USA Ouest, US Gov Virginie, Europe Ouest, Allemagne Centre, Asie Sud-Est, Japon Est, Australie Est, Canada Centre et Canada Est. Pour plus d’informations sur les limitations des ressources du modèle DTU, consultez Limites des ressources DTU.
La valeur MAXSIZE pour le modèle DTU, si elle est spécifiée, doit être une valeur valide indiquée dans le tableau ci-dessus pour le niveau de service spécifié.
Pour connaître les limites telles que la taille maximale des données et la taille tempdb
dans le modèle d’achat vCore, reportez-vous aux articles pour connaître les limites de ressources pour les bases de données uniques ou les limites de ressources pour les pools élastiques.
Si aucune valeur MAXSIZE
n’est définie lors de l’utilisation du modèle vCore, la valeur par défaut est de 32 Go. Pour plus d’informations sur les limitations des ressources du modèle vCore, consultez Limites des ressources vCore.
Les règles suivantes s'appliquent aux arguments MAXSIZE et EDITION.
Spécifie la taille de calcul et l’objectif de service.
Spécifie la taille de calcul (également appelée objectif de niveau de service ou SLO).
S0
, S1
, S2
, S3
, S4
, S6
, S7
, S9
, S12
, P1
, P2
, P4
, P6
, P11
, P15
. Reportez-vous aux limites de ressources pour les bases de données uniques DTU ou aux limites de ressources pour les pools élastiques DTU pour connaître le nombre de DTU affectées à chaque taille de calcul.n
. Reportez-vous aux limites de ressources pour les bases de données uniques vCore ou les limites de ressources pour les pools élastiques vCore.
GP_Gen5_8
à usage général, calcul approvisionné, série Standard (Gen5), 8 vCores.GP_S_Gen5_8
à usage général, calcul serverless, série Standard (Gen5), 8 vCores.HS_Gen5_8
pour Hyperscale, calcul approvisionné, série Standard (Gen5), 8 vCores.HS_S_Gen5_8
pour Hyperscale, calcul serverless, série Standard (Gen5), 8 vCores.Par exemple, l’exemple suivant modifie l’objectif de service d’une base de données de niveau Premium dans le modèle d’achat DTU en P6
:
ALTER DATABASE <database_name>
MODIFY (SERVICE_OBJECTIVE = 'P6');
Par exemple, l’exemple suivant modifie l’objectif de service d’une base de données de calcul approvisionné dans le modèle d’achat vCore en GP_Gen5_8
:
ALTER DATABASE <database_name>
MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
Uniquement pour l’hyperscale Azure SQL Database. Le nom de la base de données à créer. Utilisé uniquement par les réplicas nommés Azure SQL Database Hyperscale, quand SECONDARY_TYPE
= NAMED
. Pour plus d’informations, consultez réplicas secondaires Hyperscale.
Uniquement pour l’hyperscale Azure SQL Database.
GEO
spécifie un géo-réplica, NAMED
spécifie un réplica nommé. La valeur par défaut est GEO
. Pour plus d’informations, consultez réplicas secondaires Hyperscale.
Pour obtenir des descriptions d’objectifs de service et plus d’informations sur la taille, les éditions et les combinaisons d’objectifs de service, consultez Comparer les modèles d’achat vCore et DTU d’Azure SQL Database, les limites des ressources DTU et les limites de ressources vCore. La prise en charge des objectifs de service PRS a été supprimée.
Quand SERVICE_OBJECTIVE n’est pas spécifié, la base de données secondaire est créée au même niveau de service que la base de données primaire. Quand SERVICE_OBJECTIVE est spécifié, la base de données secondaire est créée au niveau spécifié. Le SERVICE_OBJECTIVE spécifié doit appartenir à la même édition que la source. Par exemple, vous ne pouvez pas spécifier S0 si l’édition est Premium.
Pour ajouter une base de données existante à un pool élastique, définissez le SERVICE_OBJECTIVE de la base de données sur ELASTIC_POOL et fournissez le nom du pool élastique. Vous pouvez également utiliser cette option pour ajouter la base de données à un autre pool élastique du même serveur. Pour plus d’informations, consultez Les pools élastiques vous aident à gérer et à mettre à l'échelle plusieurs bases de données Azure SQL Database. Pour supprimer une base de données d’un pool élastique, utilisez ALTER DATABASE pour définir le SERVICE_OBJECTIVE à une taille de calcul de base de données unique (objectif de service).
Notes
Les bases de données du niveau de service Hyperscale ne peuvent pas être ajoutées à un pool élastique.
Crée une base de données secondaire de géoréplication de même nom sur un serveur partenaire, faisant ainsi de la base de données locale la base de données de géoréplication primaire, puis commence à répliquer des données de manière asynchrone entre la base de données primaire et la nouvelle base de données secondaire. Si une base de données portant le même nom existe déjà dans la base de données secondaire, la commande échoue. La commande est exécutée sur la base de données master
sur le serveur qui héberge la base de données locale qui devient la base de données primaire.
Important
Par défaut, la base de données secondaire est créée avec la même redondance du stockage des sauvegardes que celle de la base de données primaire ou de la base de données source. La modification de la redondance du stockage de sauvegarde lors de la création de la base de données secondaire n’est pas prise en charge via T-SQL.
Quand ALLOW_CONNECTIONS n’est pas spécifié, il est défini sur ALL par défaut. S’il est défini sur ALL, il s’agit d’une base de données en lecture seule qui autorise toutes les connexions disposant des autorisations nécessaires.
Quand ELASTIC_POOL n’est pas spécifié, la base de données secondaire n’est pas créée dans un pool élastique. Quand ELASTIC_POOL est spécifié, la base de données secondaire est créée dans le pool spécifié.
Important
L’utilisateur qui exécute la commande ADD SECONDARY doit avoir le rôle de DBManager pour le serveur principal, appartenir au groupe db_owner de la base de données locale et avoir le rôle de DBManager pour le serveur secondaire. L’adresse IP du client doit être ajoutée à la liste autorisée sous les règles du pare-feu pour les serveurs principal et secondaire. En cas d’adresses IP du client différentes, la même adresse IP du client qui a été ajoutée sur le serveur principal doit également être ajoutée au serveur secondaire. Il s’agit d’une étape obligatoire à effectuer avant d’exécuter la commande ADD SECONDARY pour lancer la géo-réplication.
Supprime la base de données secondaire géorépliquée spécifiée du serveur spécifié. La commande est exécutée sur la base de données master
sur le serveur qui héberge la base de données primaire.
Important
L’utilisateur qui exécute la commande REMOVE SECONDARY
doit avoir le rôle de DBManager pour le serveur principal.
Promeut la base de données secondaire du partenariat de géoréplication sur laquelle est exécutée la commande, pour qu’elle devienne la base de données primaire et que la base de données primaire actuelle devienne secondaire. Dans le cadre de ce processus, le mode de géoréplication passe temporairement du mode asynchrone au mode synchrone. Pendant le processus de basculement :
Cette séquence garantit qu’aucune perte de données ne se produit. Lorsque les rôles sont permutés, la période pendant laquelle les deux bases de données sont indisponibles est d’environ 0 à 25 secondes. Au total, l’opération prend environ une minute. Si la base de données primaire n’est pas disponible lorsque cette commande est émise, la commande échoue avec un message d’erreur indiquant que la base de données primaire n’est pas disponible. Si le processus de basculement ne se termine pas et semble bloqué, vous pouvez utiliser la commande de basculement forcé et accepter la perte de données. Ensuite, si vous avez besoin de récupérer les données perdues, adressez-vous à l’équipe DevOps (CSS).
Important
L’utilisateur qui exécute la commande FAILOVER doit avoir le rôle de DBManager pour le serveur principal et le serveur secondaire.
Promeut la base de données secondaire du partenariat de géoréplication sur laquelle est exécutée la commande, pour qu’elle devienne la base de données primaire et que la base de données primaire actuelle devienne secondaire. Utilisez cette commande uniquement lorsque la base de données primaire actuelle n’est plus disponible. Elle ne doit être utilisée qu’en cas de récupération d’urgence, lorsque la restauration de la disponibilité est critique, et qu’une petite perte de données est acceptable.
Pendant un basculement forcé :
Important
L’utilisateur exécutant la commande FORCE_FAILOVER_ALLOW_DATA_LOSS
doit être membre du rôle dbmanager
sur le serveur principal et le serveur secondaire.
Démarrez la conversion de la base de données vers le niveau de service Hyperscale avec l’option permettant de lancer manuellement le basculement lorsque vous êtes prêt. Applicable uniquement lorsque le niveau de service est converti en Hyperscale. Pour lancer le basculement, utilisez PERFORM_CUTOVER. Pour plus d’informations, consultez Convertir une base de données existante enHyperscale .
Surveillez la progression de la conversion en Hyperscale avec sys.dm_operation_status.
Lance le basculement lorsque la conversion de base de données vers le niveau Hyperscale est en état WaitingForCutover. Applicable uniquement lorsque le niveau de service est converti en Hyperscale démarré avec l’argument MANUAL_CUTOVER.
Surveillez la progression de la conversion en Hyperscale avec sys.dm_operation_status. Pour plus d’informations, consultez Convertir une base de données existante enHyperscale .
Pour supprimer une base de données, utilisez DROP DATABASE. Pour diminuer la taille d'une base de données, utilisez DBCC SHRINKDATABASE.
L’instruction ALTER DATABASE
doit s’exécuter en mode de validation automatique (mode de gestion des transactions par défaut) et n’est pas autorisée dans une transaction explicite ou implicite.
Cette opération entraîne la recompilation de tous les plans d'exécution ultérieurs et peut entraîner une baisse temporaire et brutale des performances des requêtes. Pour chaque mémoire cache effacée du cache du plan, le journal des erreurs de SQL Server contient le message d'information suivant : 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
. Ce message est enregistré toutes les cinq minutes si le cache est vidé au cours de cet intervalle de temps.
Le cache de procédures est également vidé dans le scénario suivant : Vous exécutez plusieurs requêtes sur une base de données dont les options par défaut sont activées. Puis, la base de données est supprimée.
Vous pouvez utiliser les affichages catalogue, les fonctions système et les procédures stockées du système pour retourner des informations sur les bases de données, les fichiers et les groupes de fichiers.
Pour modifier une base de données, une connexion doit être soit la connexion d’administrateur du serveur (créée lorsque le serveur logique Azure SQL Database a été approvisionné), l’administrateur Microsoft Entra du serveur, un membre du rôle de base de données dbmanager dans master
, un membre du rôle de base de données db_owner dans la base de données active ou dbo
de la base de données. L’ID Microsoft Entra est (anciennement Azure Active Directory).
Pour mettre à l’échelle des bases de données via T-SQL, des autorisations ALTER DATABASE sont nécessaires. Pour mettre à l’échelle des bases de données via le portail Azure, PowerShell, Azure CLI ou l’API REST, des autorisations Azure RBAC sont nécessaires, en particulier les rôles Azure RBAC Contributeur, Contributeur SQL DB ou Contributeur SQL Server. Pour plus d’informations, consultez les rôles intégrés Azure.
Définit une taille d’édition et maximale pour la base de données db1
:
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');
Déplace une base de données existante dans un pool nommé pool1
:
ALTER DATABASE db1
MODIFY ( SERVICE_OBJECTIVE = ELASTIC_POOL ( name = pool1 ) ) ;
Crée une base de données secondaire accessible en lecture db1
sur le serveur secondaryserver
de db1
sur le serveur local.
ALTER DATABASE db1
ADD SECONDARY ON SERVER secondaryserver
WITH ( ALLOW_CONNECTIONS = ALL );
Supprime la base de données secondaire db1
du serveur secondaryserver
.
ALTER DATABASE db1
REMOVE SECONDARY ON SERVER testsecondaryserver;
Promeut la base de données secondaire db1
sur le serveur secondaryserver
pour qu’elle devienne la nouvelle base de données primaire lorsqu’elle est exécutée sur le serveur secondaryserver
.
ALTER DATABASE db1 FAILOVER;
Notes
Pour plus d’informations, consultez les instructions de récupération d’urgence - Azure SQL Database et la liste de contrôle de haute disponibilité et de récupération d’urgence d’Azure SQL Database.
Force une base de données secondaire db1
sur le serveur secondaryserver
à devenir la nouvelle base de données primaire quand elle est exécutée sur le serveur secondaryserver
, dans le cas où le serveur principal ne soit plus disponible. Cette option peut entraîner une perte de données.
ALTER DATABASE db1 FORCE_FAILOVER_ALLOW_DATA_LOSS;
Met à jour une base de données unique vers l’édition Standard (niveau de service) avec une taille de calcul (objectif de service) de S0 et une taille maximale de 250 Go.
ALTER DATABASE [db1] MODIFY (EDITION = 'Standard', MAXSIZE = 250 GB, SERVICE_OBJECTIVE = 'S0');
Met à jour la redondance du stockage des sauvegardes d’une base de données en « redondant interzone ». Toutes les sauvegardes futures de cette base de données utilisent le nouveau paramètre. Ceci comprend les sauvegardes pour restauration à un point dans le temps et les sauvegardes pour conservation à long terme (si elles sont configurées).
ALTER DATABASE db1 MODIFY BACKUP_STORAGE_REDUNDANCY = 'ZONE';
Pour convertir une base de données existante dans Azure SQL Database en Hyperscale avec Transact-SQL, connectez-vous à la base de données master
sur votre serveur SQL logique.
Vous devez spécifier l’édition et l’objectif du service dans l’instruction ALTER DATABASE
.
Par défaut, la base de données effectue un basculement vers la base de données Hyperscale pour terminer la conversion dès que la base de données Hyperscale est disponible. L’argument MANUAL_CUTOVER
démarre plutôt la conversion qui se terminera par un basculement initié manuellement, à la fois de votre choix. Cette option est la plus utile pour planifier la transition afin de minimiser l'interruption des activités.
Cet exemple d’instruction convertit une base de données nommée mySampleDatabase
en niveau de service Hyperscale avec l’objectif de service HS_Gen5_2
. Remplacez le nom de la base de données par la valeur appropriée avant d’exécuter l’instruction.
ALTER DATABASE [mySampleDatabase]
MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_2')
WITH MANUAL_CUTOVER;
Pour surveiller les opérations d’une base de données Hyperscale, connectez-vous à la base de données master
et interrogez sys.dm_operation_status?view=azuresqldb-current&preserve-view=true) pour passer en revue les opérations sur votre serveur logique.
SELECT *
FROM sys.dm_operation_status
WHERE major_resource_id = 'mySampleDatabase'
ORDER BY start_time DESC;
GO
Lorsque vous êtes prêt, le phase_code
sera WaitingForCutover
. Utilisez l’argument PERFORM_CUTOVER
pour lancer le basculement :
ALTER DATABASE [mySampleDatabase] PERFORM_CUTOVER;
* SQL Managed Instance *
Dans Azure SQL Managed Instance, utilisez cette instruction pour définir les options de base de données.
En raison de sa longueur, la syntaxe d’ALTER DATABASE
est divisée en plusieurs articles.
Article | Description |
---|---|
ALTER DATABASE |
|
Le présent article indique la syntaxe à utiliser et les informations associées pour définir des options de fichiers et de groupes de fichiers, des options de base de données et le niveau de compatibilité de la base de données. | |
Options de fichiers et de groupes de fichiers ALTER DATABASE | |
Indique la syntaxe à utiliser et les informations associées pour ajouter et supprimer des fichiers et groupes de fichiers d’une base de données, et pour modifier les attributs des fichiers et groupes de fichiers. | |
Options ALTER DATABASE SET | |
Indique la syntaxe à utiliser et les informations associées pour modifier les attributs d’une base de données à l’aide des options SET d’ALTER DATABASE. | |
Niveau de compatibilité ALTER DATABASE | |
Indique la syntaxe et les informations associées des options SET d’ALTER DATABASE relatives aux niveaux de compatibilité des bases de données. |
-- 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 }
}
Nom de la base de données à modifier.
CURRENT
Indique que la base de données actuelle en cours d'utilisation doit être modifiée.
Pour supprimer une base de données, utilisez DROP DATABASE.
Pour diminuer la taille d'une base de données, utilisez DBCC SHRINKDATABASE.
L’instruction ALTER DATABASE
doit s’exécuter en mode de validation automatique (mode de gestion des transactions par défaut) et n’est pas autorisée dans une transaction explicite ou implicite.
Le cache du plan pour l’Azure SQL Managed Instance est effacé par la définition de l’une des options suivantes.
COLLATE
MODIFY FILEGROUP DEFAULT
MODIFY FILEGROUP READ_ONLY
MODIFY FILEGROUP READ_WRITE
MODIFY NAME
Cette opération entraîne la recompilation de tous les plans d'exécution ultérieurs et peut entraîner une baisse temporaire et brutale des performances des requêtes. Pour chaque mémoire cache effacée du cache du plan, le journal des erreurs de SQL Server contient le message d'information suivant : 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
. Ce message est enregistré toutes les cinq minutes si le cache est vidé au cours de cet intervalle de temps.
Le cache du plan est également vidé quand plusieurs requêtes sont exécutées sur une base de données qui a des options par défaut. Puis, la base de données est supprimée.
Certaines instructions ALTER DATABASE
nécessitent un verrou exclusif sur une base de données pour être exécutées. C’est pourquoi elles peuvent échouer quand un autre processus actif maintient un verrou sur la base de données. L’erreur signalée dans un cas comme celui-ci est Msg 5061, Level 16, State 1, Line 38
avec le message ALTER DATABASE failed because a lock could not be placed on database '<database name>'. Try again later
. Il s’agit généralement d’une défaillance temporaire. Pour la résoudre, réessayez l’instruction ALTER DATABASE
ayant échoué une fois tous les verrous de la base de données libérés. La vue système sys.dm_tran_locks
contient des informations sur les verrous actifs. Pour vérifier s’il existe des verrous partagés ou exclusifs sur une base de données, utilisez la requête suivante.
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');
Vous pouvez utiliser les affichages catalogue, les fonctions système et les procédures stockées du système pour retourner des informations sur les bases de données, les fichiers et les groupes de fichiers.
Seule la connexion principale au niveau du serveur (créée par le processus de configuration) ou les membres du rôle de base de données dbcreator
peuvent modifier une base de données.
Important
Le propriétaire de la base de données ne peut pas modifier la base de données, sauf s’ils sont membres du dbcreator
rôle.
Les exemples suivants vous montrent comment définir le paramétrage automatique et comment ajouter un fichier à une base de données dans Azure SQL Managed Instance.
ALTER DATABASE WideWorldImporters
SET AUTOMATIC_TUNING ( FORCE_LAST_GOOD_PLAN = ON);
ALTER DATABASE WideWorldImporters
ADD FILE (NAME = 'data_17');
* Azure Synapse
Analytics *
Dans Azure Synapse, ALTER DATABASE
modifie certaines options de configuration d’un pool SQL dédié.
En raison de sa longueur, la syntaxe d’ALTER DATABASE
est divisée en plusieurs articles.
Les options ALTER DATABASE SET fournissent la syntaxe et les informations associées pour modifier les attributs d’une base de données à l’aide des options SET de ALTER DATABASE
.
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'
}
Spécifie le nom de la base de données à modifier.
Renomme la base de données avec le nom spécifié nouveau_nom_base_de_données.
L’option 'MODIFY NAME' a des limites de prise en charge dans Azure Synapse :
La valeur par défaut est 245 760 Go (240 To).
S’applique à : Optimisé pour le calcul Gen1
Taille maximale autorisée pour la base de données. La base de données ne peut pas dépasser MAXSIZE.
S’applique à : Optimisé pour le calcul Gen2
Taille maximale autorisée pour les données rowstore dans la base de données. Les données stockées dans des tables rowstore, le deltastore d’un index columnstore ou un index non cluster sur un index columnstore cluster ne peuvent pas dépasser MAXSIZE. Les données compressées au format columnstore n’ont pas de limite de taille et ne sont pas limitées par MAXSIZE.
Spécifie la taille de calcul (objectif de service). Pour plus d’informations sur les objectifs de service d’Azure Synapse, voir Data Warehouse Units (DWU).
Nécessite ces autorisations :
dbmanager
.Le propriétaire de la base de données ne peut pas modifier la base de données, sauf si le propriétaire est membre du dbmanager
rôle.
La base de données actuelle doit être différente de celle que vous modifiez. Par conséquent, ALTER doit être exécuté tout en étant connecté à la base de données master
.
COMPATIBILITY_LEVEL dans SQL Analytics est défini sur 130 par défaut et ne peut pas être modifié. Pour plus d’informations, consultez Niveau de compatibilité ALTER DATABASE.
Notes
COMPATIBILITY_LEVEL s’applique uniquement aux ressources provisionnées (pools).
Pour exécuter ALTER DATABASE
, la base de données doit être en ligne et ne peut pas être dans un état suspendu.
L’instruction ALTER DATABASE
doit s’exécuter en mode de validation automatique, qui est le mode de gestion de transaction par défaut. Ce mode est défini dans les paramètres de connexion.
L’instruction ALTER DATABASE
ne peut pas faire partie d’une transaction définie par l’utilisateur.
Vous ne pouvez pas modifier le classement de base de données.
Avant d’exécuter ces exemples, vérifiez que la base de données que vous modifiez n’est pas la base de données active. La base de données actuelle doit être différente de celle que vous modifiez. Par conséquent, ALTER doit être exécuté tout en étant connecté à la base de données master
.
ALTER DATABASE AdventureWorks2022
MODIFY NAME = Northwind;
ALTER DATABASE dw1 MODIFY ( MAXSIZE=10240 GB );
ALTER DATABASE dw1 MODIFY ( SERVICE_OBJECTIVE= 'DW1200' );
ALTER DATABASE dw1 MODIFY ( MAXSIZE=10240 GB, SERVICE_OBJECTIVE= 'DW1200' );
* Analytics
Platform System (PDW) *
Dans Analytics Platform System (PDW), ALTER DATABASE modifie les options de taille de base de données maximale pour les tables répliquées, les tables distribuées et le journal des transactions. Cette instruction permet de gérer les allocations de l’espace disque à mesure que la taille d’une base de données augmente ou diminue. Cet article décrit également la syntaxe liée à la définition des options de base de données dans Analytics Platform System (PDW).
-- 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 }
Nom de la base de données à modifier. Pour afficher une liste des bases de données sur l’appliance, utilisez sys.databases.
Met à jour l’option AUTOGROW. Quand AUTOGROW est défini sur ON, Analytics Platform System (PDW) augmente automatiquement l’espace alloué pour les tables répliquées, les tables distribuées et le journal des transactions en fonction des besoins pour s’adapter à la croissance des besoins de stockage. Quand AUTOGROW est défini sur OFF, Analytics Platform System (PDW) retourne une erreur si des tables, répliquées, des tables distribuées ou le journal des transactions dépasse le paramètre de taille maximale.
Spécifie le nouveau nombre maximal de gigaoctets par nœud de calcul pour le stockage de toutes les tables répliquées dans la base de données en cours de modification. Si vous planifiez l’espace de stockage de l’appliance, vous devez multiplier les REPLICATED_SIZE par le nombre de nœuds de calcul dans l’appliance.
Spécifie le nouveau nombre maximal de gigaoctets par base de données pour le stockage de toutes les tables distribuées dans la base de données en cours de modification. La taille est répartie entre tous les nœuds de calcul dans l’appliance.
Spécifie le nouveau nombre maximal de gigaoctets par base de données pour le stockage de tous les journaux des transactions dans la base de données en cours de modification. La taille est répartie entre tous les nœuds de calcul dans l’appliance.
Spécifie si la base de données doit être chiffrée (ON) ou non chiffrée (OFF). Le chiffrement peut être configuré uniquement pour Analytics Platform System (PDW) quand sp_pdw_database_encryption a été défini sur 1. Une clé de chiffrement de base de données doit être créée avant de pouvoir configurer le chiffrement transparent des données. Pour plus d’informations sur le chiffrement de base de données, consultez Transparent Data Encryption (TDE).
Quand l’option de création automatique de statistiques AUTO_CREATE_STATISTICS est activée, l’optimiseur de requête crée les statistiques nécessaires sur les colonnes individuelles du prédicat de requête pour améliorer les estimations de cardinalité pour le plan de requête. Ces statistiques de colonne unique sont créées sur les colonnes où ne figure pas déjà un histogramme au niveau d'un objet de statistiques existant.
La valeur par défaut est ON pour les nouvelles bases de données créées après la mise à niveau vers AU7. La valeur par défaut est OFF pour les bases de données créées avant la mise à niveau.
Pour plus d’informations sur les statistiques, consultez Statistiques.
Quand l’option de mise à jour automatique des statistiques AUTO_UPDATE_STATISTICS est activée, l’optimiseur de requête détermine si les statistiques sont obsolètes, puis les met à jour le cas échéant quand elles sont utilisées par une requête. Les statistiques deviennent obsolètes si des opérations d’insertion, de mise à jour, de suppression ou de fusion changent la distribution des données dans la table ou la vue indexée. L'optimiseur de requête détermine si les statistiques sont obsolètes en comptant le nombre de modifications de données depuis la dernière mise à jour des statistiques et en comparant le nombre de modifications à un seuil. Ce seuil est basé sur le nombre de lignes contenues dans la table ou la vue indexée.
La valeur par défaut est ON pour les nouvelles bases de données créées après la mise à niveau vers AU7. La valeur par défaut est OFF pour les bases de données créées avant la mise à niveau.
Pour plus d’informations sur les statistiques, consultez Statistiques.
L'option de mise à jour asynchrone des statistiques AUTO_UPDATE_STATISTICS_ASYNC détermine si l'optimiseur de requête utilise des mises à jour de statistiques synchrones ou asynchrones. L’option AUTO_UPDATE_STATISTICS_ASYNC s’applique aux objets de statistiques créés pour les index, aux colonnes uniques contenues dans les prédicats de requête et aux statistiques créées à l’aide de l’instruction CREATE STATISTICS
.
La valeur par défaut est ON pour les nouvelles bases de données créées après la mise à niveau vers AU7. La valeur par défaut est OFF pour les bases de données créées avant la mise à niveau.
Pour plus d’informations sur les statistiques, consultez Statistiques.
Requiert l’autorisation ALTER
sur la base de données.
Si les statistiques automatiques sont désactivées et que vous essayez de modifier les paramètres des statistiques, PDW génère l’erreur This option isn't supported in PDW
. L’administrateur système peut activer les statistiques automatiques en activant le commutateur de fonctionnalité AutoStatsEnabled.
Les valeurs de REPLICATED_SIZE
, DISTRIBUTED_SIZE
et LOG_SIZE
peuvent être supérieures, égales ou inférieures aux valeurs actuelles de la base de données.
Les opérations d’augmentation et de réduction sont approximatives. Les tailles réelles obtenues peuvent varier en fonction des paramètres de taille.
Analytics Platform System (PDW) n’exécute pas l’instruction ALTER DATABASE
comme une opération atomique. Si l’instruction est interrompue pendant l’exécution, les modifications qui ont déjà eu lieu sont conservées.
Les paramètres de statistiques fonctionnent uniquement si l’administrateur a activé les statistiques automatiques. Si vous êtes un administrateur, utilisez le commutateur de fonctionnalité AutoStatsEnabled pour activer ou désactiver les statistiques automatiques.
Prend un verrou partagé sur l’objet DATABASE. Vous ne pouvez pas modifier une base de données utilisée par un autre utilisateur pour la lecture ou l’écriture. Cela inclut les sessions qui ont émis une instruction USE sur la base de données.
La réduction de la taille d’une base de données peut prendre beaucoup de temps et consommer beaucoup de ressources système, en fonction de la taille des données réelles contenues dans la base de données et du volume de fragmentation sur le disque. Par exemple, la réduction de la taille d’une base de données peut prendre plusieurs heures ou plus.
Pour déterminer la progression du chiffrement transparent des données de base de données sous la forme d’un pourcentage, utilisez la requête suivante :
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';
Pour obtenir un exemple complet illustrant toutes les étapes d’implémentation de TDE, consultez Transparent Data Encryption (TDE).
Définissez AUTOGROW sur ON pour la base de données CustomerSales
.
ALTER DATABASE CustomerSales
SET ( AUTOGROW = ON );
L’exemple suivant définit la limite de stockage des tables répliquées sur 1 Go pour la base de données CustomerSales
. Il s’agit de la limite de stockage par nœud de calcul.
ALTER DATABASE CustomerSales
SET ( REPLICATED_SIZE = 1 GB );
L’exemple suivant définit la limite de stockage de table distribuée à 1 000 Go (1 téraoctet) pour la base de données CustomerSales
. Il s’agit de la limite de stockage combiné sur l’ensemble de l’appliance pour tous les nœuds de calcul, et non pas la limite de stockage par nœud de calcul.
ALTER DATABASE CustomerSales
SET ( DISTRIBUTED_SIZE = 1000 GB );
L’exemple suivant met à jour la base de données CustomerSales
pour avoir une taille maximale du journal de transactions SQL Server de 10 Go pour l’appliance.
ALTER DATABASE CustomerSales
SET ( LOG_SIZE = 10 GB );
La requête suivante retourne les valeurs des statistiques actuelles pour toutes les bases de données. La valeur 1
signifie que la fonctionnalité est activée, et un 0
qu’elle est désactivée.
SELECT NAME,
is_auto_create_stats_on,
is_auto_update_stats_on,
is_auto_update_stats_async_on
FROM sys.databases;
Utilisez l’instruction suivante pour activer les statistiques de création et de mise à jour, de façon automatique et asynchrone, pour la base de données CustomerSales. Cette opération crée et met à jour, selon les besoins, des statistiques dans une seule colonne pour créer des plans de requête de haute qualité.
ALTER DATABASE CustomerSales
SET AUTO_CREATE_STATISTICS ON;
ALTER DATABASE CustomerSales
SET AUTO_UPDATE_STATISTICS ON;
ALTER DATABASE
SET AUTO_UPDATE_STATISTICS_ASYNC ON;
Microsoft Fabric
Dans Microsoft Fabric Warehouse, cette instruction modifie un entrepôt.
En raison de sa longueur, la syntaxe d’ALTER DATABASE
est divisée en plusieurs articles.
Article | Description |
---|---|
ALTER DATABASE |
Le présent article indique la syntaxe à utiliser et les informations associées pour modifier le nom et le classement d’une base de données. |
Options ALTER DATABASE SET | Indique la syntaxe à utiliser et les informations associées pour modifier les attributs d’une base de données à l’aide des options SET d’ALTER DATABASE. |
Actuellement, la suspension de la publication des journaux Delta Lake et la désactivation du comportement de commande V-Order dans un entrepôt sont les seules utilisations pour ALTER DATABASE ... SET
Microsoft Fabric. Consultez Options ALTER DATABASE SET.
Événements
31 mars, 23 h - 2 avr., 23 h
Le plus grand événement d’apprentissage SQL, Fabric et Power BI. 31 mars au 2 avril. Utilisez le code FABINSIDER pour économiser 400 $.
Inscrivez-vous aujourd’hui