Exécution des tâches diverses pour les instances de base de données Oracle - Amazon Relational Database Service

Exécution des tâches diverses pour les instances de base de données Oracle

Vous trouverez ci-dessous des informations sur la façon d’effectuer diverses tâches DBA sur vos instances de base de données Amazon RDS exécutant Oracle. Pour offrir une expérience de service géré, Amazon RDS ne fournit pas l'accès shell aux instances de base de données et limite l'accès à certaines tables et procédures système qui requièrent des privilèges avancés.

Création et suppression de répertoires dans l'espace de stockage de données principal

Pour créer des répertoires, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.create_directory. Vous pouvez créer jusqu'à 10 000 répertoires, tous situés dans votre espace principal de stockage des données. Pour supprimer des répertoires, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.drop_directory.

Les procédures create_directory et drop_directory ont le paramètre requis suivant.

Nom du paramètre Type de données Par défaut Obligatoire Description

p_directory_name

varchar2

Oui

Nom du répertoire.

L'exemple suivant crée un répertoire nommé PRODUCT_DESCRIPTIONS.

exec rdsadmin.rdsadmin_util.create_directory(p_directory_name => 'product_descriptions');

Le dictionnaire de données stocke le nom du répertoire en majuscules. Vous pouvez lister les répertoires en interrogeant DBA_DIRECTORIES. Le système choisit le nom du chemin réel de l'hôte automatiquement. L'exemple suivant récupère le chemin du répertoire nommé PRODUCT_DESCRIPTIONS:

SELECT DIRECTORY_PATH FROM DBA_DIRECTORIES WHERE DIRECTORY_NAME='PRODUCT_DESCRIPTIONS'; DIRECTORY_PATH ---------------------------------------- /rdsdbdata/userdirs/01

Le nom d'utilisateur maître de l'instance de base de données possède des privilèges de lecture et d'écriture dans le nouveau répertoire et peut accorder l'accès à d'autres utilisateurs. Les privilèges EXECUTE ne sont pas disponibles pour les répertoires sur une instance de base de données. Les répertoires sont créés dans votre espace principal de stockage des données et consomment de l'espace, ainsi que de la bande passante d'I/O.

L'exemple suivant supprime le répertoire nommé PRODUCT_DESCRIPTIONS.

exec rdsadmin.rdsadmin_util.drop_directory(p_directory_name => 'product_descriptions');
Note

Vous pouvez également supprimer un répertoire à l'aide de la commande SQL Oracle DROP DIRECTORY.

La suppression d'un répertoire ne supprime pas son contenu. Étant donné que la procédure rdsadmin.rdsadmin_util.create_directory peut réutiliser les noms de chemin, les fichiers figurant dans les répertoires supprimés peuvent apparaître dans un répertoire nouvellement créé. Avant de supprimer un répertoire, nous vous recommandons d'utiliser UTL_FILE.FREMOVE pour supprimer les fichiers du répertoire. Pour de plus amples informations, veuillez consulter FREMOVE Procedure dans la documentation Oracle.

Établissement de la liste des fichiers situés dans un répertoire d'instance de base de données

Pour lister les fichiers contenus dans un répertoire, utilisez la procédure Amazon RDS rdsadmin.rds_file_util.listdir. La procédure listdir possède les paramètres suivants.

Nom du paramètre Type de données Par défaut Obligatoire Description

p_directory

varchar2

Oui

Nom du répertoire à lister.

L'exemple suivant répertorie les fichiers figurant dans le répertoire nommé PRODUCT_DESCRIPTIONS.

SELECT * FROM TABLE(rdsadmin.rds_file_util.listdir(p_directory => 'PRODUCT_DESCRIPTIONS'));

Lecture de fichiers dans un répertoire d'instance de base de données

Pour lire un fichier texte, utilisez la procédure Amazon RDS rdsadmin.rds_file_util.read_text_file. La procédure read_text_file possède les paramètres suivants.

Nom du paramètre Type de données Par défaut Obligatoire Description

p_directory

varchar2

Oui

Nom du répertoire qui contient le fichier.

p_filename

varchar2

Oui

Nom du fichier à lire.

L'exemple suivant lit le fichier rice.txt dans le répertoire PRODUCT_DESCRIPTIONS.

declare fh sys.utl_file.file_type; begin fh := utl_file.fopen(location=>'PRODUCT_DESCRIPTIONS', filename=>'rice.txt', open_mode=>'w'); utl_file.put(file=>fh, buffer=>'AnyCompany brown rice, 15 lbs'); utl_file.fclose(file=>fh); end; /

L'exemple suivant lit le fichier rice.txt figurant dans le répertoire PRODUCT_DESCRIPTIONS.

SELECT * FROM TABLE (rdsadmin.rds_file_util.read_text_file( p_directory => 'PRODUCT_DESCRIPTIONS', p_filename => 'rice.txt'));

Accès aux fichiers Opatch

Opatch est un utilitaire Oracle qui permet l'application et la restauration de correctifs sur le logiciel Oracle. Le mécanisme Oracle qui permet de déterminer les correctifs ayant été appliqués à une base de données est la commande opatch lsinventory. Pour ouvrir des demandes de service pour les clients Bring Your Own Licence (BYOL), le support Oracle demande le fichier lsinventory et parfois le fichier lsinventory_detail généré par Opatch.

Pour offrir une expérience de service géré, Amazon RDS ne fournit pas l'accès shell à Opatch. Au lieu de cela, l'instance de base de données Oracle crée automatiquement les fichiers d'inventaire toutes les heures dans le répertoire BDUMP. Vous avez accès en lecture et en écriture sur ce répertoire. Si vous ne voyez pas vos fichiers dans BDUMP, ou si les fichiers ne sont pas à jour, attendez une heure et faites une nouvelle tentative.

Note

Les exemples de cette section supposent que le répertoire BDUMP est nommé BDUMP. Sur un réplica en lecture, le nom du répertoire BDUMP est différent. Pour savoir comment obtenir le nom BDUMP en interrogeant V$DATABASE.DB_UNIQUE_NAME sur un réplica en lecture, veuillez consulter Liste de fichiers.

Les fichiers d'inventaire utilisent la convention de dénomination Amazon RDS lsinventory-dbv.txt et lsinventory_detail-dbv.txt, où dbv est le nom complet de votre version de base de données. Le fichier lsinventory-dbv.txt est disponible sur toutes les versions de base de données. Le fichier de détails correspondant est disponible sur les versions de base de données suivantes :

  • 19.0.0.0, ru-2020-01.rur-2020-01.r1 ou version ultérieure

  • 18.0.0.0, ru-2020-01.rur-2020-01.r1 ou version ultérieure

  • 12.2.0.1, ru-2020-01.rur-2020-01.r1 ou version ultérieure

  • 12.1.0.2, v19 ou ultérieure

Par exemple, si votre version de base de données est 19.0.0.0.ru-2020-04.rur-2020-04.r1, vos fichiers d'inventaire portent les noms suivants.

lsinventory-19.0.0.0.ru-2020-04.rur-2020-04.r1.txt lsinventory_detail-19.0.0.0.ru-2020-04.rur-2020-04.r1.txt

Assurez-vous de télécharger les fichiers qui correspondent à la version actuelle de votre moteur de base de données.

Pour télécharger un fichier d'inventaire à l'aide de la console

  1. Ouvrez la console Amazon RDS à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans la panneau de navigation, choisissez Databases (Bases de données).

  3. Choisissez le nom de l'instance de base de données qui contient le fichier journal que vous voulez consulter.

  4. Choisissez l'onglet Logs & events (Journaux et événements).

  5. Faites défiler jusqu'à la section Journaux.

  6. Dans la section Logs (Journaux) recherchez lsinventory.

  7. Sélectionnez le fichier auquel vous souhaitez accéder, puis choisissez Download (Télécharger).

Pour lire le fichier lsinventory-dbv.txt dans un client SQL, vous pouvez utiliser une instruction SELECT. Pour cette technique, utilisez l'une des fonctions rdsadmin suivantes : rdsadmin.rds_file_util.read_text_file ou rdsadmin.tracefile_listing.

Dans l'exemple de requête suivant, remplacez dbv par votre version de base de données Oracle. Par exemple, la version de votre base de données peut être 19.0.0.0.ru-2020-04.rur-2020-04.r1.

SELECT text FROM TABLE(rdsadmin.rds_file_util.read_text_file('BDUMP', 'lsinventory-dbv.txt'));

Pour lire le fichier lsinventory-dbv.txt dans un client SQL, vous pouvez écrire un programme PL/SQL. Ce programme utilise utl_file pour lire le fichier et dbms_output pour l'imprimer. Ce sont des packages fournis par Oracle.

Dans l'exemple de programme suivant, remplacez dbv par la version de votre base de données Oracle. Par exemple, la version de votre base de données peut être 19.0.0.0.ru-2020-04.rur-2020-04.r1.

SET SERVEROUTPUT ON DECLARE v_file SYS.UTL_FILE.FILE_TYPE; v_line VARCHAR2(1000); v_oracle_home_type VARCHAR2(1000); c_directory VARCHAR2(30) := 'BDUMP'; c_output_file VARCHAR2(30) := 'lsinventory-dbv.txt'; BEGIN v_file := SYS.UTL_FILE.FOPEN(c_directory, c_output_file, 'r'); LOOP BEGIN SYS.UTL_FILE.GET_LINE(v_file, v_line,1000); DBMS_OUTPUT.PUT_LINE(v_line); EXCEPTION WHEN no_data_found THEN EXIT; END; END LOOP; END; /

Ou interrogez rdsadmin.tracefile_listing et spoulez la sortie vers un fichier. L'exemple suivant spoule la sortie vers /tmp/tracefile.txt.

SPOOL /tmp/tracefile.txt SELECT * FROM rdsadmin.tracefile_listing WHERE FILENAME LIKE 'lsinventory%'; SPOOL OFF;

Gestion des tâches de conseiller

Oracle Database comprend un nombre de conseillers. Chaque conseiller prend en charge des tâches automatisées et manuelles. Vous pouvez utiliser des procédures dans le package rdsadmin.rdsadmin_util pour gérer certaines tâches de conseiller.

Les procédures de tâches de conseiller sont disponibles dans les versions suivantes du moteur :

Définition des paramètres des tâches de conseiller

Pour définir les paramètres de certaines tâches de conseiller, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.advisor_task_set_parameter. La procédure advisor_task_set_parameter possède les paramètres suivants.

Nom du paramètre Type de données Par défaut Obligatoire Description

p_task_name

varchar2

Oui

Nom de la tâche de conseiller dont vous voulez modifier les paramètres. Les valeurs suivantes sont valides :

  • AUTO_STATS_ADVISOR_TASK

  • INDIVIDUAL_STATS_ADVISOR_TASK

  • SYS_AUTO_SPM_EVOLVE_TASK

  • SYS_AUTO_SQL_TUNING_TASK

p_parameter

varchar2

Oui

Nom du paramètre de la tâche. Pour rechercher des paramètres valides d'une tâche de conseiller, exécutez la requête suivante. Remplacer p_task_name par une valeur valide de p_task_name :

COL PARAMETER_NAME FORMAT a30 COL PARAMETER_VALUE FORMAT a30 SELECT PARAMETER_NAME, PARAMETER_VALUE FROM DBA_ADVISOR_PARAMETERS WHERE TASK_NAME='p_task_name' AND PARAMETER_VALUE != 'UNUSED' ORDER BY PARAMETER_NAME;

p_value

varchar2

Oui

Valeur d'un paramètre de la tâche. Pour rechercher des valeurs valides pour des paramètres de la tâche, exécutez la requête suivante. Remplacer p_task_name par une valeur valide de p_task_name :

COL PARAMETER_NAME FORMAT a30 COL PARAMETER_VALUE FORMAT a30 SELECT PARAMETER_NAME, PARAMETER_VALUE FROM DBA_ADVISOR_PARAMETERS WHERE TASK_NAME='p_task_name' AND PARAMETER_VALUE != 'UNUSED' ORDER BY PARAMETER_NAME;

Le programme PL/SQL suivant définit ACCEPT_PLANS à FALSE pour SYS_AUTO_SPM_EVOLVE_TASK. La tâche automatisée SQL Plan Management vérifie les plans et génère un rapport de résultats, mais ne fait pas évoluer les plans automatiquement. Vous pouvez utiliser un rapport pour identifier de nouvelles lignes de base de SQL Plan et les accepter manuellement.

BEGIN rdsadmin.rdsadmin_util.advisor_task_set_parameter( p_task_name => 'SYS_AUTO_SPM_EVOLVE_TASK', p_parameter => 'ACCEPT_PLANS', p_value => 'FALSE'); END;

Le programme PL/SQL suivant définit EXECUTION_DAYS_TO_EXPIRE à 10 pour AUTO_STATS_ADVISOR_TASK. La tâche prédéfinie AUTO_STATS_ADVISOR_TASK s'exécute dans la fenêtre de maintenance une fois par jour automatiquement. Dans l'exemple, la période de rétention pour l'exécution de la tâche est définie à 10 jours.

BEGIN rdsadmin.rdsadmin_util.advisor_task_set_parameter( p_task_name => 'AUTO_STATS_ADVISOR_TASK', p_parameter => 'EXECUTION_DAYS_TO_EXPIRE', p_value => '10'); END;

Désactivation de AUTO_STATS_ADVISOR_TASK

Pour désactiver AUTO_STATS_ADVISOR_TASK, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.advisor_task_drop. La procédure advisor_task_drop accepte les paramètres suivants.

Note

Cette procédure est disponible dans Oracle Database 12c version 2 (12.2.0.1) et ultérieures.

Nom du paramètre Type de données Par défaut Obligatoire Description

p_task_name

varchar2

Oui

Nom de la tâche de conseiller qui doit être désactivée. La seule valeur valide est AUTO_STATS_ADVISOR_TASK.

La commande suivante désactive AUTO_STATS_ADVISOR_TASK.

EXEC rdsadmin.rdsadmin_util.advisor_task_drop('AUTO_STATS_ADVISOR_TASK')

Vous pouvez réactiver AUTO_STATS_ADVISOR_TASK en utilisant rdsadmin.rdsadmin_util.dbms_stats_init.

Réactivation de AUTO_STATS_ADVISOR_TASK

Pour réactiver AUTO_STATS_ADVISOR_TASK, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.dbms_stats_init. La procédure dbms_stats_init n'accepte aucun paramètre.

La commande suivante réactive AUTO_STATS_ADVISOR_TASK.

EXEC rdsadmin.rdsadmin_util.dbms_stats_init()

Activation de HugePages pour une instance de base de données Oracle

Amazon RDS pour Oracle prend en charge la fonctionnalité HugePages du noyau Linux pour obtenir une base de données plus évolutive. HugePages réduit la taille des tables de page et le temps UC de gestion de la mémoire, ce qui augmente les performances des instances de bases de données volumineuses. Pour plus d'informations, consultez Overview of HugePages (Présentation des grandes pages) dans la documentation Oracle.

Vous pouvez utiliser HugePages avec les versions et éditions suivantes d'Oracle Database :

  • 19.0.0.0, toutes les éditions

  • 18.0.0.0, toutes les éditions

  • 12.2.0.1, toutes les éditions

  • 12.1.0.2, toutes les éditions

Le paramètre use_large_pages contrôle si HugePages est activé pour une instance de base de données. Les valeurs possibles pour ce paramètre sont ONLY, FALSE et {DBInstanceClassHugePagesDefault}. Le paramètre use_large_pages est défini sur {DBInstanceClassHugePagesDefault} dans le groupe de paramètres DB par défaut pour Oracle.

Pour contrôler si HugePages est activé automatiquement pour une instance de base de données, vous pouvez utiliser la variable de formule DBInstanceClassHugePagesDefault dans les groupes de paramètres. La valeur est déterminée comme suit :

  • Pour les classes d'instance de base de données indiquées dans le tableau suivant, DBInstanceClassHugePagesDefault a toujours la valeur FALSE par défaut, et use_large_pages a la valeur FALSE. Vous pouvez activer HugePages manuellement pour ces instances de base de données si la classe d'instance de bases de données dispose d'au moins 14 Gio de mémoire.

  • Pour les classes d'instance de base de données non mentionnées dans le tableau suivant, si la classe d'instance de base de données possède au moins 14 Gio de mémoire, DBInstanceClassHugePagesDefault a toujours la valeur FALSE. En outre, use_large_pages a la valeur FALSE.

  • Pour les classes d'instance de base de données non mentionnées dans le tableau suivant, si la classe d'instance possède au moins 14 Gio de mémoire et moins de 100 Gio de mémoire, DBInstanceClassHugePagesDefault a la valeur TRUE par défaut. En outre, use_large_pages a la valeur ONLY. Vous pouvez désactiver HugePages manuellement en définissant use_large_pages sur FALSE.

  • Pour les classes d'instance de base de données non mentionnées dans le tableau suivant, si la classe d'instance possède au moins 100 Gio de mémoire, DBInstanceClassHugePagesDefault a toujours la valeur TRUE. En outre, use_large_pages a la valeur ONLY et HugePages ne peut pas être désactivé.

HugePages n'est pas activé par défaut pour les classes d'instance de base de données suivantes.

Famille de classes d'instance de base de données Classes d'instance de base de données avec HugePages non activé par défaut

db.m5

db.m5.large

db.m4

db.m4.large, db.m4.xlarge, db.m4.2xlarge, db.m4.4xlarge, db.m4.10xlarge

db.t3

db.t3.micro, db.t3.small, db.t3.medium, db.t3.large

Pour plus d'informations sur les classes d'instance DB, consultez Spécifications matérielles pour les classes d'instance de base de données .

Pour activer manuellement HugePages pour des instances de bases de données nouvelles ou existantes, définissez le paramètre use_large_pages sur ONLY. Vous ne pouvez pas utiliser HugePages avec Oracle Automatic Memory Management (AMM). Si vous définissez le paramètre use_large_pages sur ONLY, vous devez aussi définir memory_target et memory_max_target sur 0. Pour plus d'informations sur la définition des paramètres de votre instance de base de données, consultez Utilisation de groupes de paramètres de base de données.

Vous pouvez aussi définir les paramètres sga_target, sga_max_size et pga_aggregate_target. Lorsque vous définissez les paramètres de mémoire des zones SGA (System Global Area) et PGA (Program Global Area), ajoutez les valeurs ensemble. Soustrayez ce total de votre mémoire d'instance disponible (DBInstanceClassMemory) pour déterminer l'espace mémoire libre restant au-delà de l'attribution par HugePages. Vous devez conserver une mémoire libre d'au moins 2 Gio ou égale à 10 pourcent de la mémoire totale disponible de l'instance, la plus petite des deux valeurs étant retenue.

Après avoir configuré vos paramètres, vous devez redémarrer votre instance de base de données pour que les modifications soient effectives. Pour plus d'informations, consultez Redémarrage d'une instance de base de données.

Note

L'instance de base de données Oracle diffère les modifications apportées aux paramètres d'initialisation liés à la SGA jusqu'à ce que vous redémarriez l'instance sans basculement. Dans la console Amazon RDS, choisissez Redémarrer, mais ne choisissez pas Redémarrer avec basculement. Dans l’AWS CLI, appelez la commande reboot-db-instance avec le paramètre --no-force-failover. L'instance de base de données ne traite pas les paramètres liés à la SGA pendant le basculement ou lors d'autres opérations de maintenance qui provoquent le redémarrage de l'instance.

Voici un exemple de configuration de paramètres pour HugePages activant manuellement HugePages. Vous devez définir les valeurs qui répondent à vos besoins.

memory_target = 0 memory_max_target = 0 pga_aggregate_target = {DBInstanceClassMemory*1/8} sga_target = {DBInstanceClassMemory*3/4} sga_max_size = {DBInstanceClassMemory*3/4} use_large_pages = ONLY

Supposons que les valeurs des paramètres suivantes sont définies dans un groupe de paramètres.

memory_target = IF({DBInstanceClassHugePagesDefault}, 0, {DBInstanceClassMemory*3/4}) memory_max_target = IF({DBInstanceClassHugePagesDefault}, 0, {DBInstanceClassMemory*3/4}) pga_aggregate_target = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*1/8}, 0) sga_target = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*3/4}, 0) sga_max_size = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*3/4}, 0) use_large_pages = {DBInstanceClassHugePagesDefault}

Le groupe de paramètres est utilisé par une classe d'instance de base de données db.r4 dotée de moins de 100 Gio de mémoire. Avec ces paramètres et use_large_pages défini sur {DBInstanceClassHugePagesDefault}, HugePages est activé sur l'instance db.r4.

Supposons que les valeurs des paramètres suivantes sont définies dans un groupe de paramètres.

memory_target = IF({DBInstanceClassHugePagesDefault}, 0, {DBInstanceClassMemory*3/4}) memory_max_target = IF({DBInstanceClassHugePagesDefault}, 0, {DBInstanceClassMemory*3/4}) pga_aggregate_target = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*1/8}, 0) sga_target = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*3/4}, 0) sga_max_size = IF({DBInstanceClassHugePagesDefault}, {DBInstanceClassMemory*3/4}, 0) use_large_pages = FALSE

Le groupe de paramètres est utilisé par une classe d'instance de base de données db.r4 et une classe d’instance de base de données db.r5, toutes deux avec plus de 100 Gio de mémoire. Avec ces paramètres, HugePages est désactivé sur les instances db.r4 et db.r5.

Note

Si ce groupe de paramètres est utilisé par une classe d'instance de base de données db.r4 ou db.r5 avec au moins 100 Gio de mémoire, la valeur de FALSE pour use_large_pages est remplacée et définie sur ONLY. Dans ce cas, une notification concernant le remplacement est envoyée au client.

Lorsque HugePages est activé sur votre instance de base de données, vous pouvez afficher les informations sur HugePages en activant la surveillance améliorée. Pour plus d'informations, consultez Suivi des métriques du système d'exploitation à l'aide de la Surveillance améliorée.

Activation des types de données étendus

Amazon RDS Oracle Database 12c prend en charge les types de données étendus. Avec les types de données étendus, la taille maximum est de 32 767 octets pour les types de données VARCHAR2, NVARCHAR2 et RAW. Pour utiliser les types de données étendus, définissez le paramètre MAX_STRING_SIZE sur EXTENDED. Pour plus d'informations, consultez Extended Data Types dans la documentation Oracle.

Si vous ne souhaitez pas utiliser les types de données étendus, gardez le paramètre MAX_STRING_SIZE défini sur STANDARD (par défaut). Lorsque ce paramètre est défini sur STANDARD, les limites de taille sont 4 000 octets pour les types de données VARCHAR2 et NVARCHAR2, et 2 000 octets pour le type de données RAW.

Vous pouvez activer les types de données étendus sur une nouvelle instance de base de données ou sur une instance de base de données existante. Pour les nouvelles instances de base de données, la durée nécessaire pour créer une instance de base de données est généralement plus longue lorsque vous activez les types de données étendus. Pour les instances de base de données existantes, l'instance de base de données n'est pas disponible pendant le processus de conversion.

Voici les considérations relatives à une instance de base de données pour laquelle les types de données étendus sont activés :

  • Lorsque vous activez les types de données étendus pour une instance de base de données, vous ne pouvez pas à nouveau modifier l'instance de base de données afin qu'elle utilise la taille standard pour les types de données. Après la conversion d'une instance afin qu'elle utilise les types de données étendus, si vous redéfinissez le paramètre MAX_STRING_SIZE sur STANDARD le statut devient incompatible-parameters.

  • Lorsque vous restaurez une instance de base de données qui utilise des types de données étendus, vous devez spécifier un groupe de paramètres avec le paramètre MAX_STRING_SIZE défini sur EXTENDED. Pendant la restauration, si vous spécifiez le groupe de paramètres par défaut ou tout autre groupe de paramètres avec le paramètre MAX_STRING_SIZE défini sur STANDARD le statut devient incompatible-parameters.

  • Nous vous conseillons de ne pas activer les types de données étendus pour les instances de base de données Oracle qui s'exécutent sur la classe d'instance de base de données t2.micro.

Lorsque l'état de l'instance de base de données est incompatible-parameters à cause du paramètre MAX_STRING_SIZE, l'instance de base de données reste indisponible jusqu'à ce que le paramètre MAX_STRING_SIZE soit défini sur EXTENDED et que l'instance de base de données soit redémarrée.

Activation des types de données étendus pour une nouvelle instance de base de données

Pour activer les types de données étendus pour une nouvelle instance de base de données

  1. Définissez le paramètre MAX_STRING_SIZE sur EXTENDED dans un groupe de paramètres.

    Pour définir le paramètre, vous pouvez créer un groupe de paramètres de base de données ou modifier un groupe de paramètres existant.

    Pour plus d'informations, consultez Utilisation de groupes de paramètres de base de données.

  2. Créez une nouvelle instance de base de données Amazon RDS Oracle et associez le groupe de paramètres avec le paramètre MAX_STRING_SIZE défini sur EXTENDED avec l'instance de base de données.

    Pour plus d'informations, consultez Création d'une instance de base de données Amazon RDS.

Activation des types de données étendus pour une instance de base de données existante

Lorsque vous modifiez une instance de base de données afin d'activer les types de données étendus, les données de la base de données sont converties afin d'utiliser les tailles étendues. L'instance de base de données n'est pas disponible pendant la conversion. La durée nécessaire pour convertir les données dépend de la classe d'instance de base de données utilisée par l'instance de base de données et de la taille de la base de données.

Note

Une fois que vous avez activé les types de données étendus, vous pouvez effectuer une opération de restauration à un moment donné pendant la conversion. Vous pouvez restaurer au moment précédant immédiatement la conversion ou au moment suivant immédiatement la conversion.

Pour activer les types de données étendus pour une instance de base de données existante

  1. Créez un instantané de la base de données.

    S'il existe des objets no valides dans la base de données, Amazon RDS tente de les recompiler. La conversion en vue d'activer les types de données étendus peut échouer si Amazon RDS ne peut pas recompiler un objet non valide. L'instantané vous permet de restaurer la base de données en cas de problème avec la conversion. Vérifiez toujours la présence d'objets non valides avant la conversion afin d'y apporter une solution ou de les supprimer. Pour les bases de données de production, nous vous conseillons d'abord de tester le processus de conversion sur une copie de votre instance de base de données.

    Pour plus d'informations, consultez Création d'un instantané de base de données.

  2. Définissez le paramètre MAX_STRING_SIZE sur EXTENDED dans un groupe de paramètres.

    Pour définir le paramètre, vous pouvez créer un groupe de paramètres de base de données ou modifier un groupe de paramètres existant.

    Pour plus d'informations, consultez Utilisation de groupes de paramètres de base de données.

  3. Modifiez l'instance de base de données afin de l'associer au groupe de paramètres avec le paramètre MAX_STRING_SIZE défini sur EXTENDED.

    Pour plus d'informations, consultez Modification d'une instance de base de données Amazon RDS.

  4. Redémarrez l'instance de base de données pour que la modification des paramètres prenne effet.

    Pour plus d'informations, consultez Redémarrage d'une instance de base de données.