ALTER DATABASE

Modifie les attributs d’une base de données.

Privilèges requis

Pour utiliser ALTER DATABASE, l’un des privilèges suivants est requis.

• Superuser

• Utilisateurs disposant du privilège ALTER DATABASE

• Propriétaire de la base de données

Syntaxe

ALTER DATABASE database_name
{ 
  RENAME TO new_name
  | OWNER TO new_owner
  | [ CONNECTION LIMIT { limit | UNLIMITED } ]
    [ COLLATE { CASE_SENSITIVE | CASE_INSENSITIVE } ]
    [ ISOLATION LEVEL { SERIALIZABLE | SNAPSHOT } ]
| INTEGRATION
 { 
  REFRESH { { ALL | INERROR } TABLES [ IN SCHEMA schema [, ...] ] | TABLE schema.table [, ...] }
   | SET 
     [ QUERY_ALL_STATES [=] { TRUE | FALSE } ] 
     [ ACCEPTINVCHARS [=] { TRUE | FALSE } ] 
     [ REFRESH_INTERVAL <interval> ]
     [ TRUNCATECOLUMNS [=] { TRUE | FALSE } ]
     [ HISTORY_MODE [=] {TRUE | FALSE} [ FOR { {ALL} TABLES [IN SCHEMA schema [, ...] ] | TABLE schema.table [, ...] } ] ]
 }
}

Paramètres

database_name

Nom de la base de données à modifier. Généralement, vous modifiez une base de données à laquelle vous n’êtes pas connecté ; quoi qu’il en soit, les modifications ne prennent effet que lors des séances suivantes. Vous pouvez modifier le propriétaire de la base de données, mais vous ne pouvez pas le renommer :

alter database tickit rename to newtickit;
ERROR:  current database may not be renamed

RENAME TO

Renomme la base de données spécifiée. Pour plus d’informations sur les noms valides, consultez Noms et identificateurs. Vous ne pouvez pas renommer les bases de données dev, padb_harvest, template0, template1 ou sys:internal, et vous ne pouvez pas renommer la base de données active. Seul le propriétaire de la base de données ou un superuser peut renommer une base de données ; les propriétaires qui ne sont pas des super-utilisateurs doivent aussi avoir le privilège CREATEDB.

nouveau_nom

Nouveau nom de la base de données.

OWNER TO

Modifie le propriétaire de la base de données spécifiée. Vous pouvez modifier le propriétaire de la base de données active ou d’une autre base de données. Seul un super-utilisateur peut changer le propriétaire.

nouveau_propriétaire

Nouveau propriétaire de la base de données. Le nouveau propriétaire doit être un utilisateur de base de données existant avec des privilèges en écriture. Pour plus d’informations sur les privilèges d’utilisateur, consultez GRANT.

CONNECTION LIMIT { limite | UNLIMITED }

Le nombre maximum de connexions à la base de données que les utilisateurs sont autorisés à ouvrir simultanément. La limite n’est pas appliquée pour les super-utilisateurs. Utilisez le mot-clé UNLIMITED pour autoriser le nombre maximum de connexions simultanées. Une limite sur le nombre de connexions pour chaque utilisateur peut également s’appliquer. Pour plus d'informations, consultez CREATE USER. La valeur par défaut est UNLIMITED. Pour afficher les connexions en cours, interrogez la vue système STV_SESSIONS.

Note

Si les deux limites de connexion (utilisateurs et base de données) s’appliquent, un emplacement de connexion inutilisé situé entre les deux limites doit également être disponible lorsqu’un utilisateur tente de se connecter.

COLLATE { CASE_SENSITIVE | CASE_INSENSITIVE }

Clause spécifiant si la recherche de chaînes ou la comparaison est sensible à la casse ou non.

Vous pouvez modifier la sensibilité à la casse de la base de données active qui est vide.

Vous devez disposer du privilège sur la base de données active pour modifier la sensibilité à la casse. Les super-utilisateurs ou propriétaires de base de données disposant du privilège CREATE DATABASE peuvent également modifier la sensibilité à la casse de la base de données.

ISOLATION LEVEL { SERIALIZABLE | SNAPSHOT }

Clause qui spécifie le niveau d’isolation utilisé lorsque les requêtes sont exécutées sur une base de données.

• Isolation SERIALIZABLE : offre une mise en série complète pour les transactions simultanées. Pour de plus amples informations, veuillez consulter Isolement sérialisable.

• Isolation SNAPSHOT : offre un niveau d’isolation avec protection contre les conflits de mise à jour et de suppression

Pour plus d’informations sur les niveaux d’isolation, consultez CREATE DATABASE.

Tenez compte des éléments suivants lorsque vous modifiez le niveau d’isolation d’une base de données :

• Vous devez disposer du privilège super-utilisateur ou CREATE DATABASE sur la base de données active pour modifier le niveau d’isolation de la base de données.

• Vous ne pouvez pas modifier le niveau d’isolation de la base de données dev.

• Vous ne pouvez pas modifier le niveau d’isolation au sein d’un bloc de transaction.

• La commande de modification du niveau d’isolation échoue si d’autres utilisateurs sont connectés à la base de données.

• La commande de modification du niveau d’isolation peut modifier les paramètres de niveau d’isolation de la séance en cours.

INTÉGRATION

Modifiez une base de données d'intégration zéro ETL.

ACTUALISER {{ALL | INERROR} TABLES [DANS LE SCHÉMA DU SCHÉMA [,...]] | TABLEAU schema.table [,...]}

Clause spécifiant si Amazon Redshift actualisera toutes les tables ou les tables présentant des erreurs dans le schéma ou la table spécifiés. L’actualisation déclenchera la réplication complète des tables du schéma ou de la table spécifiés à partir de la base de données source.

Pour plus d'informations, consultez la section Intégrations Zero-ETL dans le guide de gestion Amazon Redshift. Pour plus d’informations sur les statuts d’intégration, consultez SVV_INTEGRATION_TABLE_STATE et SVV_INTEGRATION.

QUERY_ALL_STATES [=] {VRAI | FAUX}

La clause QUERY_ALL_STATES indique si les tables d'intégration zéro ETL peuvent être interrogées dans tous les états (,, et). Synced Failed ResyncRequired ResyncInitiated Par défaut, une table d'intégration zéro ETL ne peut être interrogée que dans son état. Synced

ACCEPTINVCHARS [=] {VRAI | FAUX}

La clause ACCEPTINVCHARS indique si les tables d'intégration zéro ETL continuent à être ingérées lorsque des caractères non valides sont détectés pour le type de données VARCHAR. Lorsque des caractères non valides sont détectés, ils sont remplacés par un ? caractère par défaut.

INTERVALLE DE RAFRAÎCHISSEMENT <interval>

La clause REFRESH_INTERVAL définit l'intervalle de temps approximatif, en secondes, pour actualiser les données de la source zéro ETL vers la base de données cible. La valeur interval peut être définie entre 0 et 432 000 secondes (5 jours) pour les intégrations sans ETL dont le type de source est Aurora MySQL, Aurora PostgreSQL ou RDS for MySQL. Pour les intégrations Amazon DynamoDB Zero-ETL, les valeurs peuvent être définies entre 900 et interval 432 000 secondes (15 minutes et 5 jours).

Pour plus d'informations sur la création de bases de données avec des intégrations sans ETL, consultez la section Création de bases de données de destination dans Amazon Redshift dans le guide de gestion Amazon Redshift.

TRONCATCOLUMNS [=] {VRAI | FAUX}

La clause TRUNCATECOLUMNS indique si les tables d'intégration Zero-ETL continuent à être ingérées lorsque les valeurs de la colonne VARCHAR dépassent la limite. LorsqueTRUE, les valeurs sont tronquées pour tenir dans la colonne.

HISTORY_MODE [=] {TRUE | FALSE} [POUR {{TOUTES} TABLES [DANS LE SCHÉMA [,...]] | TABLE schema.table [,...]}]

Clause qui indique si Amazon Redshift définira le mode historique pour toutes les tables ou les tables du schéma spécifié qui participent à l'intégration zéro ETL. Cette option s'applique uniquement aux bases de données créées pour une intégration zéro ETL.

La clause HISTORY_MODE peut être définie sur ou. TRUE FALSE L’argument par défaut est FALSE. L'activation ou la désactivation du mode historique ne s'applique qu'aux tables qui sont dans Synced cet état. Pour plus d'informations sur HISTORY_MODE, consultez la section Mode historique dans le guide de gestion Amazon Redshift.

Notes d’utilisation

Les commandes ALTER DATABASE s’appliquent aux séances ultérieures, pas aux séances en cours. Vous devez vous reconnecter à la base de données modifiée pour voir l’effet de la modification.

Exemples

L’exemple suivant renomme une base de données nommée TICKIT_SANDBOX en TICKIT_TEST :

alter database tickit_sandbox rename to tickit_test;

L’exemple suivant modifie le propriétaire de la base de données TICKIT (la base de données active) en DWUSER :

alter database tickit owner to dwuser;

L’exemple suivant modifie la sensibilité à la casse de la base de données sampledb :

ALTER DATABASE sampledb COLLATE CASE_INSENSITIVE;

L’exemple suivant montre comment modifier une base de données nommée sampledb avec un niveau d’isolation SNAPSHOT.

ALTER DATABASE sampledb ISOLATION LEVEL SNAPSHOT;

L’exemple suivant actualise les tables schema1.sample_table1 et schema2.sample_table2 dans la base de données sample_integration_db dans le cadre de votre intégration zéro ETL.

ALTER DATABASE sample_integration_db INTEGRATION REFRESH TABLE schema1.sample_table1, schema2.sample_table2;

L’exemple suivant actualise toutes les tables synchronisées et défaillantes au sein de votre intégration zéro ETL.

ALTER DATABASE sample_integration_db INTEGRATION REFRESH ALL tables;

L'exemple suivant définit l'intervalle d'actualisation pour les intégrations sans ETL à 600 secondes.

ALTER DATABASE sample_integration_db INTEGRATION SET REFRESH_INTERVAL 600;

L'exemple suivant actualise toutes les tables figurant ErrorState dans le schémasample_schema.

ALTER DATABASE sample_integration_db INTEGRATION REFRESH INERROR TABLES in SCHEMA sample_schema;

L'exemple suivant active le mode historique pour le tableaumyschema.table1.

ALTER DATABASE sample_integration_db INTEGRATION SET HISTORY_MODE = true FOR TABLE myschema.table1

L'exemple suivant active le mode historique pour toutes les tables demyschema.

ALTER DATABASE sample_integration_db INTEGRATION SET HISTORY_MODE = true for ALL TABLES IN SCHEMA myschema