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.
# Utilisation des bases de données Oracle avec l'extension oracle\$1fdw
Pour accéder à une base de données Oracle depuis votre instance de base de données RDS pour PostgreSQL, vous pouvez installer et utiliser l’extension `oracle_fdw`. Cette extension est un encapsuleur de données externes pour les bases de données Oracle. Pour en savoir plus sur cette extension, consultez la documentation [oracle\$1fdw](https://github.com/laurenz/oracle_fdw).
L'extension `oracle_fdw` est prise en charge sur RDS pour PostgreSQL 12.7, 13.3 et les versions ultérieures.
**Topics**
+ [Activation de l'extension oracle\$1fdw](#postgresql-oracle-fdw.enabling)
+ [Exemple : utilisation d'un serveur externe lié à une base de données Amazon RDS for Oracle Database](#postgresql-oracle-fdw.example)
+ [Utilisation du chiffrement en transit](#postgresql-oracle-fdw.encryption)
+ [Comprendre la vue et les autorisations pg\$1user\$1mappings](#postgresql-oracle-fdw.permissions)
## Activation de l'extension oracle\$1fdw
Pour utiliser l'extension oracle\$1fdw, suivez la procédure suivante.
**Pour activer l'extension oracle\$1fdw**
+ Exécutez la commande suivante en utilisant un compte disposant d'autorisations `rds_superuser`.
```
CREATE EXTENSION oracle_fdw;
```
## Exemple : utilisation d'un serveur externe lié à une base de données Amazon RDS for Oracle Database
Les exemples suivants démontrent l'utilisation d'un serveur externe lié à une base de données Amazon RDS for Oracle.
**Pour créer un serveur externe lié à une base de données RDS for Oracle**
1. Notez ce qui suit sur l'instance de base de données RDS for Oracle :
+ Point de terminaison
+ Port
+ Nom de base de données
1. Créez un serveur externe.
```
test=> CREATE SERVER oradb FOREIGN DATA WRAPPER oracle_fdw OPTIONS (dbserver '//endpoint:port/DB_name');
CREATE SERVER
```
1. Accordez l'utilisation à un utilisateur dépourvu d'autorisations `rds_superuser`, par exemple `user1`.
```
test=> GRANT USAGE ON FOREIGN SERVER oradb TO user1;
GRANT
```
1. Connectez-vous en tant que `user1` et créez un mappage à un utilisateur Oracle.
```
test=> CREATE USER MAPPING FOR user1 SERVER oradb OPTIONS (user 'oracleuser', password 'mypassword');
CREATE USER MAPPING
```
1. Créez une table externe liée à une table Oracle.
```
test=> CREATE FOREIGN TABLE mytab (a int) SERVER oradb OPTIONS (table 'MYTABLE');
CREATE FOREIGN TABLE
```
1. Interrogez la table externe.
```
test=> SELECT * FROM mytab;
a
---
1
(1 row)
```
Si la requête signale l'erreur suivante, vérifiez votre groupe de sécurité et votre liste de contrôle d'accès (ACL) pour vous assurer que les deux instances peuvent communiquer.
```
ERROR: connection for foreign table "mytab" cannot be established
DETAIL: ORA-12170: TNS:Connect timeout occurred
```
## Utilisation du chiffrement en transit
Le chiffrement PostgreSQL vers Oracle en transit est basé sur une combinaison de paramètres de configuration client et serveur. Pour un exemple d'utilisation d'Oracle 21c, consultez [A propos de la négociation du chiffrement et de l'intégrité](https://docs.oracle.com/en/database/oracle/oracle-database/21/dbseg/configuring-network-data-encryption-and-integrity.html#GUID-3A2AF4AA-AE3E-446B-8F64-31C48F27A2B5) dans la documentation Oracle. Le client utilisé pour oracle\$1fdw sur Amazon RDS est configuré avec `ACCEPTED`, ce qui signifie que le chiffrement dépend de la configuration du serveur de base de données Oracle et qu’il utilise Oracle Security Library (libnnz) pour le chiffrement.
Si votre base de données se trouve sur RDS for Oracle, consultez la section [Oracle native network encryption](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.NetworkEncryption.html) (Chiffrement réseau natif Oracle) pour configurer le chiffrement.
## Comprendre la vue et les autorisations pg\$1user\$1mappings
Le catalogue PostgreSQL `pg_user_mapping` stocke le mappage d’un utilisateur RDS pour PostgreSQL vers l’utilisateur d’un serveur de données externe (distant). L'accès au catalogue est restreint, mais vous utilisez la vue `pg_user_mappings` pour visualiser les mappages. Dans ce qui suit, vous trouverez un exemple qui présente comment les autorisations s'appliquent avec un exemple de base de données Oracle, mais ces informations s'appliquent plus généralement à tout encapsuleur de données externes.
Dans la sortie suivante, vous pouvez trouver des rôles et des autorisations mappés à trois exemples d'utilisateurs différents. Les utilisateurs `rdssu1` et `rdssu2` sont membres du rôle `rds_superuser`, et `user1` ne l'est pas. L'exemple utilise la métacommande `psql` `\du` pour lister les rôles existants.
```
test=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+-------------------------------------------------------------
rdssu1 | | {rds_superuser}
rdssu2 | | {rds_superuser}
user1 | | {}
```
Tous les utilisateurs, y compris ceux qui disposent de privilèges `rds_superuser`, sont autorisés à voir leurs propres mappages d'utilisateurs (`umoptions`) dans la table `pg_user_mappings`. Comme le montre l'exemple suivant, lorsque `rdssu1` tente d'obtenir tous les mappages d'utilisateurs, une erreur s'affiche en dépit des privilèges `rds_superuser` de `rdssu1` :
```
test=> SELECT * FROM pg_user_mapping;
ERROR: permission denied for table pg_user_mapping
```
Voici quelques exemples.
```
test=> SET SESSION AUTHORIZATION rdssu1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 | {user=oracleuser,password=mypwd}
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
test=> SET SESSION AUTHORIZATION rdssu2;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+----------------------------------
16414 | 16411 | oradb | 16412 | user1 |
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 | {user=oracleuser,password=mypwd}
(3 rows)
test=> SET SESSION AUTHORIZATION user1;
SET
test=> SELECT * FROM pg_user_mappings;
umid | srvid | srvname | umuser | usename | umoptions
-------+-------+---------+--------+------------+--------------------------------
16414 | 16411 | oradb | 16412 | user1 | {user=oracleuser,password=mypwd}
16423 | 16411 | oradb | 16421 | rdssu1 |
16424 | 16411 | oradb | 16422 | rdssu2 |
(3 rows)
```
En raison des différences dans l'implémentation de `information_schema._pg_user_mappings` et de `pg_catalog.pg_user_mappings`, un `rds_superuser` créé manuellement nécessite des autorisations supplémentaires pour afficher les mots de passe dans `pg_catalog.pg_user_mappings`.
Un `rds_superuser` n'a besoin d'aucune autorisation supplémentaire pour afficher les mots de passe dans `information_schema._pg_user_mappings`.
Les utilisateurs qui n'ont pas le rôle `rds_superuser` peuvent afficher les mots de passe dans `pg_user_mappings` uniquement dans les conditions suivantes :
+ L'utilisateur actif est celui faisant l'objet du mappage. Il possède le serveur ou détient le privilège `USAGE` sur celui-ci.
+ L'utilisateur actuel est le propriétaire du serveur et le mappage est pour `PUBLIC`.