Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Transactions DDL et distribuées dans Aurora DSQL
<a name="working-with-ddl"></a>

Le langage de définition des données (DDL) se comporte différemment dans Aurora DSQL et dans PostgreSQL. Aurora DSQL propose une couche de base de données distribuée et sans partage Multi-AZ, construite sur des flottes de calcul et de stockage à plusieurs locataires. Comme il n’existe pas de nœud de base de données primaire ni de leader unique, le catalogue de base de données est distribué. Ainsi, Aurora DSQL gère les modifications du schéma DDL sous forme de transactions distribuées.

Plus précisément, DDL se comporte différemment dans Aurora DSQL comme suit :

**Réponses de contrôle de la simultanéité**  
Le catalogue de base de données étant distribué, Aurora DSQL gère les modifications du schéma DDL sous forme de transactions distribuées qui mettent à jour la version du catalogue. Les sessions qui disposent d'une copie en cache du catalogue dans une version antérieure peuvent recevoir une réponse de contrôle de simultanéité avec le code SQLSTATE `40001` et le code OCC `OC001` lors de leur prochaine interaction avec le stockage.  
Par exemple, considérez la séquence d’actions suivante :  

1. Au cours de la session 1, un utilisateur ajoute une colonne à la table `mytable`. Cela met à jour la version du catalogue.

1. Au cours de la session 2, un utilisateur tente d’insérer une ligne dans `mytable`. La version précédente du catalogue est toujours en cache pour cette session.

   Aurora DSQL revient`SQL Error [40001]: ERROR: schema has been updated by another transaction (OC001)`.
Une OC001 réponse peut également se produire lorsque le changement de schéma est déjà terminé avant le début de la transaction concernée. Les processeurs de requêtes Aurora DSQL détectent les modifications du catalogue de manière réactive lors de l'exécution des requêtes, de sorte qu'une session inactive peut toujours fonctionner avec une version de catalogue obsolète. Lors d'une nouvelle tentative, la session actualise son cache de catalogue et la transaction aboutit généralement.

**DDL et DML dans la même transaction**  
Les transactions dans Aurora DSQL ne peuvent contenir qu’une seule instruction DDL et ne peuvent pas contenir à la fois des instructions DDL et DML. Cette restriction signifie que vous ne pouvez pas créer de table et insérer des données dans la même table au cours de la même transaction. Par exemple, Aurora DSQL prend en charge les transactions séquentielles suivantes.  

```
BEGIN;
  CREATE TABLE mytable (ID_col integer);
COMMIT;

BEGIN;
  INSERT into FOO VALUES (1);
COMMIT;
```
Aurora DSQL ne prend pas en charge la transaction suivante, qui inclut à la fois les instructions `CREATE` et `INSERT`.  

```
BEGIN;
  CREATE TABLE FOO (ID_col integer);
  INSERT into FOO VALUES (1);
COMMIT;
```

**DDL asynchrone**  
Dans PostgreSQL standard, les opérations DDL telles que `CREATE INDEX` verrouille la table concernée, la rendant indisponible pour les lectures et les écritures provenant d’autres sessions. Dans Aurora DSQL, ces instructions DDL s’exécutent de manière asynchrone à l’aide d’un gestionnaire d’arrière-plan. L’accès à la table concernée n’est pas bloqué. Ainsi, DDL sur de grandes tables peut fonctionner sans durée d’indisponibilité ni impact sur les performances. Pour plus d’informations sur l’utilisation du gestionnaire de tâches asynchrones dans Aurora DSQL, consultez [Index asynchrones dans Aurora DSQL](working-with-create-index-async.md).