Configurer des fonctions Oracle Database pour Exadata Cloud Infrastructure
Cette rubrique décrit comment configurer Oracle Multitenant, le chiffrement d'espace-table et les larges pages pour les utiliser avec votre instance Exadata Cloud Infrastructure.
- Utilisation d'Oracle Multitenant dans une instance Exadata Cloud Infrastructure
- Gestion du chiffrement d'espace-table
- Gestion des larges pages
Rubrique parent : Guides pratiques
Utilisation d'Oracle Multitenant dans une instance Exadata Cloud Infrastructure
Lorsque vous créez une instance Exadata Cloud Infrastructure qui utilise Oracle Database 12c ou une version ultérieure, un environnement Oracle Multitenant est créé.
L'architecture multilocataire permet à une base de données Oracle de fonctionner comme une base de données conteneur (CDB) multilocataire incluant zéro, une ou plusieurs bases de données enfichables. Une base de données enfichable est une collection portable de schémas, d'objets de schéma et d'objets sans schéma qui apparaît à un client Oracle Net Services comme base de données non conteneur. Toutes les bases de données Oracle utilisant des versions antérieures à Oracle Database 12c sont des bases de données non conteneur.
Pour utiliser le chiffrement TDE (Oracle Transparent Data Encryption) dans une base de données enfichable, vous devez créer et activer une clé de chiffrement principale pour cette dernière.
Dans un environnement multilocataire, chaque base de données enfichable dispose de sa propre clé principale de chiffrement qui est stockée dans un seul magasin de clés utilisé par tous les conteneurs.
Vous devez exporter et importer la clé de chiffrement principale pour toutes les bases de données enfichables chiffrées que vous connectez à la base de données conteneur de votre instance Exadata Cloud Infrastructure.
Si votre base de données enfichable source est chiffrée, vous devez exporter la clé de chiffrement principale, puis l'importer.
Vous pouvez exporter et importer toutes les clés de chiffrement principales TDE appartenant à la base de données enfichable en effectuant ces opérations depuis une base de données enfichable. L'exportation et l'importation des clés de chiffrement principales TDE prennent en charge les opérations de déconnexion et de connexion de la base de données enfichable. Pendant la déconnexion et la connexion d'une base de données enfichable, toutes les clés de chiffrement principales TDE lui appartenant, ainsi que les métadonnées, sont impliquées.
Voir "Exportation et importation des clés de chiffrement principales TDE pour une base de données enfichable" dans le guide sur la sécurité avancée d'Oracle Database pour la version 19, 18, 12.2 ou 12.1.
Voir la section relative à l'administration de la gestion des clés dans le document Informations de référence sur le langage SQL pour Oracle Database version 19, 18, 12.2 ou 12.1,
Pour déterminer si vous devez créer et activer une clé de chiffrement pour la base de données enfichable
- Appelez SQL*Plus et connectez-vous à la base de données en tant qu'utilisateur
SYS
avec les privilègesSYSDBA
. -
Réglez le conteneur à la base de données enfichable :
SQL> ALTER SESSION SET CONTAINER = pdb;
-
Interrogez
V$ENCRYPTION_WALLET
comme suit :SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;
Si la colonne
STATUS
contient la valeurOPEN_NO_MASTER_KEY
, vous devez créer et activer la clé de chiffrement principale.
Pour créer et activer la clé de chiffrement principale dans une base de données enfichable
-
Réglez le conteneur à la base de données enfichable :
SQL> ALTER SESSION SET CONTAINER = pdb;
-
Créez et activez une clé de chiffrement principale dans la base de données enfichable en exécutant la commande suivante :
SQL> ADMINISTER KEY MANAGEMENT SET KEY USING TAG 'tag' FORCE KEYSTORE IDENTIFIED BY keystore-password WITH BACKUP USING 'backup_identifier';
Dans la commande précédente :
keystore-password
est le mot de passe du magasin de clés. Par défaut, le mot de passe du magasin de clés est réglé à la valeur du mot de passe d'administration spécifié à la création de la base de données.- La clause
USING TAG 'tag'
facultative permet d'associer un marqueur à la nouvelle clé de chiffrement principale. - La clause
WITH BACKUP
et la clause facultativeUSING 'backup_identifier'
peuvent être utilisées pour créer une sauvegarde du magasin de clés avant la création de la nouvelle clé de chiffrement principale.
Voir également la section relative à l'administration de la gestion des clés dans le document
Note
Pour activer les opérations de gestion des clés pendant que le magasin de clés est utilisé, Oracle Database 12c version 2, et les versions supérieures, incluent l'option
FORCE KEYSTORE
pour la commandeADMINISTER KEY MANAGEMENT
. Cette option est également disponible pour Oracle Database 12c version 1 avec le correctif d'ensemble d'octobre 2017, ou ultérieur.Si votre base de données Oracle 12c version 1 n'a pas encore reçu ce correctif d'ensemble, vous pouvez effectuer les étapes de remplacement suivantes :
- Fermez le magasin de clés.
- Ouvrez le magasin de clés protégé par mot de passe.
- Créez et activez une clé de chiffrement principale dans la base de données enfichable à l'aide de la commande
ADMINISTER KEY MANAGEMENT
sans l'optionFORCE KEYSTORE
. - Mettez à jour le magasin de clés à connexion automatique en utilisant la commande
ADMINISTER KEY MANAGEMENT
avec l'optionCREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE
.
-
Interrogez à nouveau
V$ENCRYPTION_WALLET
pour vérifier que la colonneSTATUS
est réglée àOPEN
:SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;
-
Interrogez
V$INSTANCE
et prenez note de la valeur dans la colonneHOST_NAME
qui identifie le serveur de base de données qui contient les fichiers de magasin de clés mis à jour :SQL> SELECT host_name FROM v$instance;
-
Copiez les fichiers de magasin de clés mis à jour vers tous les autres serveurs de base de données.
Pour distribuer le magasin de clés mis à jour, vous devez effectuer les actions suivantes sur chaque serveur de base de données qui ne contient pas les fichiers de magasin de clés mis à jour :
-
Connectez-vous au conteneur racine et interrogez
V$ENCRYPTION_WALLET
. Prenez note de l'emplacement du magasin de clés contenu dans la colonneWRL_PARAMETER
:SQL> SELECT wrl_parameter, status FROM v$encryption_wallet;
-
Copiez les fichiers de magasin de clés mis à jour.
Vous devez copier tous les fichiers de magasin de clés mis à jour à partir d'un serveur de base de données déjà actualisé. Utilisez l'emplacement du magasin de clés observé dans la colonne
WRL_PARAMETER
deV$ENCRYPTION_WALLET
.
Ouvrez le magasin de clés mis à jour :SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE open FORCE KEYSTORE IDENTIFIED BY keystore-password CONTAINER=all;
Note
Pour activer les opérations de gestion des clés pendant que le magasin de clés est utilisé, Oracle Database 12c version 2, et les versions supérieures, incluent l'option
FORCE KEYSTORE
pour la commandeADMINISTER KEY MANAGEMENT
. Cette option est également disponible pour Oracle Database 12c version 1 avec le correctif d'ensemble d'octobre 2017, ou ultérieur.Si votre base de données Oracle 12c version 1 n'a pas encore reçu ce correctif d'ensemble, vous pouvez effectuer les étapes de remplacement suivantes :
- Fermez le magasin de clés avant de copier les fichiers de magasin de clés mis à jour.
- Copiez les fichiers de magasin de clés mis à jour.
- Ouvrez le magasin de clés mis à jour en utilisant la commande
ADMINISTER KEY MANAGEMENT
sans l'optionFORCE KEYSTORE
.
-
-
Interrogez
GV$ENCRYPTION_WALLET
pour vérifier que la colonneSTATUS
est réglée àOPEN
pour toutes les instances de la base de données :SQL> SELECT wrl_parameter, status, wallet_type FROM gv$encryption_wallet;
Pour exporter et importer une clé de chiffrement principale
- Exportez la clé de chiffrement principale.
- Appelez SQL*Plus et connectez-vous à la base de données enfichable.
-
Exécutez la commande suivante :
SQL> ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "secret" TO 'filename' IDENTIFIED BY keystore-password;
- Importez la clé de chiffrement principale.
- Appelez SQL*Plus et connectez-vous à la base de données enfichable.
-
Exécutez la commande suivante :
SQL> ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS WITH SECRET "secret" FROM 'filename' IDENTIFIED BY keystore-password;
Gestion du chiffrement d'espace-table
Par défaut, tous les nouveaux espaces-tables créés dans une base de données Exadata sont chiffrés.
Toutefois, les espaces-tables qui sont initialement créés en même temps que la base de données ne sont peut-être pas chiffrés par défaut.
- Pour les bases de données qui utilisent Oracle Database 12c version 2 ou ultérieure, seuls les espaces-tables
USERS
créés en même temps que la base de données sont chiffrés. Aucun autre espace-table n'est chiffré, pas même les espaces-tables non-USERS
dans :- Le conteneur racine (
CDB$ROOT
). - La base de données enfichable prédéfinie (
PDB$SEED
). - La première base de données enfichable, créée en même temps que la base de données.
- Le conteneur racine (
- Pour les bases de données qui utilisent Oracle Database 12c version 1 ou Oracle Database 11g, aucun des espaces-tables créés initialement lorsque la base de données a été créée n'est chiffré.
Pour obtenir plus d'informations sur la mise en oeuvre du chiffrement de l'espace-table dans Exadata, ainsi que son incidence sur différents scénarios de déploiement, voir Comportement de chiffrement d'espace-table Oracle Database dans Oracle Cloud.
Création d'espaces-tables chiffrés
Les espaces-tables créés par l'utilisateur sont chiffrés par défaut.
Par défaut, tous les nouveaux espaces-tables créés à l'aide de la commande SQL CREATE TABLESPACE
sont chiffrés à l'aide de l'algorithme de chiffrement AES128. Vous n'avez pas besoin d'inclure la clause USING 'encrypt_algorithm'
pour utiliser le chiffrement par défaut.
Vous pouvez spécifier un autre algorithme pris en charge en incluant la clause USING 'encrypt_algorithm' dans la commande CREATE TABLESPACE. Les algorithmes pris en charge sont AES256, AES192, AES128 et 3DES168.
Gestion du chiffrement d'espace-table
Vous pouvez gérer le magasin de clés de logiciel (appelé portefeuille Oracle dans Oracle Database 11g), la clé de chiffrement principale, et contrôler si le chiffrement est activé par défaut.
Gestion de la clé principale de chiffrement
Le chiffrement d'espace-table utilise une architecture basée sur une clé à deux niveaux pour chiffrer de manière transparente des espaces-tables. La clé de chiffrement principale est stockée dans un module de sécurité externe (magasin de clés de logiciel). Cette clé de chiffrement principale est utilisée pour chiffrer la clé de chiffrement de l'espace-table, qui elle-même est utilisée pour chiffrer et déchiffrer les données de l'espace-table.
Lorsqu'une base de données est créée sur une instance du service Exadata Cloud, un magasin de clés logicielles local est créé. Le magasin de clés est local aux noeuds de calcul et il est protégé par le mot de passe d'administration spécifié lors de la création de la base de données. Le magasin de clés du logiciel de connexion automatique est ouvert automatiquement au démarrage de la base de données.
Vous pouvez modifier (effectuer la rotation de) la clé de chiffrement principale au moyen de l'énoncé ADMINISTER KEY MANAGEMENT SQL
. Par exemple :
SQL> ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY USING TAG 'tag'
IDENTIFIED BY password WITH BACKUP USING 'backup';
keystore altered.
Voir "Gestion de la clé principale de chiffrement TDE" dans le guide sur la sécurité avancée d'Oracle Database pour la version 19, 18, 12.2 ou 12.1 ou "Définition et réinitialisation de la clé principale de chiffrement" dans le guide de l'administrateur de la sécurité avancée d'Oracle Database pour la version 11.2.
Gestion du chiffrement d'espace-table par défaut
Le paramètre d'initialisation ENCRYPT_NEW_TABLESPACES
contrôle le chiffrement par défaut des nouveaux espaces-tables. Dans les bases de données Exadata, ce paramètre est réglé à CLOUD_ONLY
(valeur par défaut).
Les valeurs de ce paramètre sont les suivantes.
Valeur | Description |
---|---|
ALWAYS
|
Pendant leur création, les espaces-tables sont chiffrés de façon transparente avec l'algorithme AES128 à moins qu'un autre algorithme ne soit spécifié dans la clause ENCRYPTION .
|
CLOUD_ONLY
|
Les espaces-tables créés dans une base de données Exadata sont chiffrés de façon transparente avec l'algorithme AES128 à moins qu'un autre algorithme ne soit spécifié dans la clause ENCRYPTION . Pour les bases de données qui ne sont pas en nuage, les espaces-tables ne sont chiffrés que si la clause ENCRYPTION est spécifiée. ENCRYPTION est la valeur par défaut.
|
DDL
|
Pendant leur création, les espaces-tables ne sont pas chiffrés de manière transparente par défaut et le sont uniquement si la clause ENCRYPTION est spécifiée.
|
Avec Oracle Database 12c version 2 (12.2) ou ultérieure, vous ne pouvez plus créer d'espace-table non chiffré dans une base de données Exadata. Un message d'erreur est retourné si vous réglez
ENCRYPT_NEW_TABLESPACES
à DDL
et soumettez une commande CREATE TABLESPACE
sans spécifier de clause ENCRYPTION
.
Gestion des larges pages
Les larges pages offrent des avantages importants pour la performance d'Oracle Database sur les systèmes comportant de grandes quantités de mémoire. Oracle Database sur une instance Exadata Cloud Infrastructure fournit des paramètres de configuration qui utilisent par défaut les larges pages. Toutefois, vous pouvez effectuer des ajustements manuels pour optimiser leur configuration.
Les larges pages sont une fonctionnalité intégrée au noyau Linux 2.6. L'activation des larges pages permet au système d'exploitation de prendre en charge des pages de mémoire d'une taille supérieure. L'utilisation des larges pages peut améliorer la performance du système en réduisant la quantité de ressources d'UC et de mémoire requise pour gérer les tables de pages Linux, qui stockent le mappage entre les adresses de mémoire virtuelle et physique. Dans le cas des bases de données Oracle, l'utilisation des larges pages peut considérablement réduire le nombre d'entrées de table de pages associées à la mémoire SGA.
Sur les instances Exadata Cloud Infrastructure, une page standard est de 4 Ko, tandis qu'une large page est de 2 Mo par défaut. Par conséquent, une base de données Oracle Database sur une grappe de machines virtuelles Exadata avec une mémoire SGA de 50 Go nécessite 13 107 200 pages standard pour héberger la mémoire SGA, contre seulement 25 600 larges pages. Les tableaux de page sont donc plus petits, la mémoire requise pour le stockage est réduite et les ressources d'UC à gérer sont moins nombreuses.
Ajustement de la configuration des larges pages
La configuration des larges pages pour Oracle Database est un processus en deux étapes :
-
Au niveau du système d'exploitation, la mémoire globale affectée aux larges pages est contrôlée par l'entrée
vm.nr_hugepages
dans le fichier/etc/sysctl.conf
. Ce paramètre est défini sur chaque noeud de calcul de l'environnement et il est vivement recommandé d'en assurer la cohérence sur tous les noeuds. Pour modifier l'affectation des larges pages, vous pouvez exécuter la commande suivante sur chaque noeud de calcul en tant qu'utilisateur racine :# sysctl -w vm.nr_hugepages=value
où
value
représente le nombre de larges pages.Dans les instances Exadata Cloud Infrastructure, chaque large page est de 2 Mo par défaut. Par conséquent, pour allouer 50 Go de mémoire à des larges pages, vous pouvez exécuter la commande suivante :
# sysctl -w vm.nr_hugepages=25600
- Au niveau d'Oracle Database, l'utilisation des larges pages est contrôlée par le paramètre d'instance
USE_LARGE_PAGES
. Ce paramètre s'applique à chaque instance de base de données dans une base de données en grappe. Oracle recommande vivement un paramètre cohérent dans toutes les instances de base de données associées à une base de données. Les options suivantes sont disponibles :TRUE
- Indique que l'instance de base de données peut utiliser des larges pages si elles sont disponibles. Pour toutes les versions d'Oracle Database après 11.2.0.3, Oracle alloue autant de mémoire SGA que possible, à l'aide des larges pages. Lorsque l'affectation de larges pages est épuisée, des pages de mémoire standard sont utilisées.FALSE
- Indique que l'instance de base de données n'utilise pas les larges pages. Ce paramètre n'est généralement pas recommandé si des larges pages sont disponibles.ONLY
- Indique que l'instance de base de données doit utiliser les larges pages. Avec ce paramètre, l'instance de base de données ne peut pas démarrer si la totalité de la mémoire SGA est trop importante pour les larges pages.
Si vous apportez des ajustements au niveau du système d'exploitation ou de l'application Oracle Database, assurez-vous que la configuration globale fonctionne.
Pour plus d'informations, voir Référence de l'administrateur Oracle Database pour les systèmes d'exploitation Linux et UNIX pour la version 19, 18, 12.1 ou 11.2 pour un aperçu général des larges pages et en savoir plus sur leur configuration. Also, see USE_LARGE_PAGES
in the Oracle Database Reference for Release 12.2, 12.1, or 11.2.