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

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.

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

Vous trouverez ci-dessous des informations sur la façon d'effectuer certaines tâches DBA courantes liées aux bases de données 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. Amazon RDS restreint également l'accès à certaines procédures système et tables qui requièrent des privilèges avancés.

Modification du nom global d'une base de données

Pour modifier le nom global d'une base de données, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.rename_global_name. La procédure rename_global_name possède les paramètres suivants.

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

p_new_global_name

varchar2

Oui

Nouveau nom global de la base de données.

La base de données doit être ouverte pour que la modification du nom puisse se produire. Pour plus d'informations sur la modification du nom global d'une base de données, consultez ALTER DATABASE dans la documentation Oracle.

L'exemple suivant remplace le nom global de la base de données par new_global_name.

EXEC rdsadmin.rdsadmin_util.rename_global_name(p_new_global_name => 'new_global_name');

Création et dimensionnement des espaces de table

Amazon RDS ne prend en charge qu'Oracle Managed Files (OMF) pour les fichiers de données, les fichiers journaux et les fichiers de contrôle. Lorsque vous créez des fichiers de données et des fichiers journaux, vous ne pouvez pas spécifier les noms de fichiers physiques.

Par défaut, si vous ne spécifiez pas de taille de fichier de données, les espaces de table sont créés avec AUTOEXTEND ON par défaut et sans taille maximum. Dans l'exemple suivant, l'espace de table users1 est auto-extensible.

CREATE TABLESPACE users1;

A cause de ces paramètres par défaut, les espaces de table peuvent se développer pour utiliser l'ensemble du stockage alloué. Nous vous recommandons de spécifier une taille maximum appropriée sur les espaces de table permanents et temporaires, et de surveiller attentivement l'utilisation de l'espace.

L'exemple suivant crée un espace de table nommé users2 avec une taille de départ de 1 gigaoctet. Puisque la taille du fichier de données est spécifiée, mais pas AUTOEXTEND ON, l'espace de tables n'est pas auto-extensible.

CREATE TABLESPACE users2 DATAFILE SIZE 1G;

L'exemple suivant crée un espace de table nommé users3 avec une taille de départ de 1 gigaoctet, l'auto-extension activée et une taille maximum de 10 gigaoctets.

CREATE TABLESPACE users3 DATAFILE SIZE 1G AUTOEXTEND ON MAXSIZE 10G;

L'exemple suivant crée un espace de table temporaire nommé temp01.

CREATE TEMPORARY TABLESPACE temp01;

Vous pouvez redimensionner un espace de table bigfile en utilisant ALTER TABLESPACE. Vous pouvez spécifier la taille en kilo-octets (Ko), mégaoctets (Mo), gigaoctets (Go) ou téraoctets (To). L'exemple suivant redimensionne un espace de table bigfile nommé users_bf pour qu'il fasse 200 Mo.

ALTER TABLESPACE users_bf RESIZE 200M;

L'exemple suivant ajoute un fichier de données à un espace de table smallfile nommé users_sf.

ALTER TABLESPACE users_sf ADD DATAFILE SIZE 100000M AUTOEXTEND ON NEXT 250m MAXSIZE UNLIMITED;

Définition de l'espace de table par défaut

Pour définir l'espace de table par défaut, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.alter_default_tablespace. La procédure alter_default_tablespace possède les paramètres suivants.

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

tablespace_name

varchar

Oui

Nom de l'espace de table par défaut.

L'exemple suivant définit le tablespace par défaut sur users2 :

EXEC rdsadmin.rdsadmin_util.alter_default_tablespace(tablespace_name => 'users2');

Définition de l'espace de table temporaire par défaut

Pour définir l'espace de table temporaire par défaut, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.alter_default_temp_tablespace. La procédure alter_default_temp_tablespace possède les paramètres suivants.

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

tablespace_name

varchar

Oui

Nom de l'espace de table temporaire par défaut.

L'exemple suivant définit l'espace de table temporaire par défaut sur temp01.

EXEC rdsadmin.rdsadmin_util.alter_default_temp_tablespace(tablespace_name => 'temp01');

Création d'un espace de table temporaire sur le stockage d'instances

Pour créer un espace de table temporaire sur le stockage d'instances, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.create_inst_store_tmp_tblspace. La procédure create_inst_store_tmp_tblspace possède les paramètres suivants.

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

p_tablespace_name

varchar

Oui

Nom de l'espace de table temporaire.

L'exemple suivant crée l'espace de table temporaire temp01 dans le stockage d'instances.

EXEC rdsadmin.rdsadmin_util.create_inst_store_tmp_tblspace(p_tablespace_name => 'temp01');
Important

Lorsque vous exécutez rdsadmin_util.create_inst_store_tmp_tblspace, l'espace de table temporaire nouvellement créé n'est pas automatiquement défini comme l'espace de table temporaire par défaut. Pour le définir comme valeur par défaut, consultez Définition de l'espace de table temporaire par défaut.

Pour plus d’informations, consultez Stockage de données temporaires dans un stockage d'instances RDS for Oracle.

Ajout d'un fichier temporaire au stockage d'instances sur un réplica en lecture

Lorsque vous créez un espace de table temporaire sur une instance de base de données principale, le réplica en lecture ne crée pas de fichiers temporaires. Supposons qu'un espace de table temporaire vide existe sur votre réplica en lecture pour l'une des raisons suivantes :

  • Vous avez déposé un fichier temporaire de l'espace de table sur votre réplica en lecture. Pour plus d’informations, consultez Dépôt de fichiers temporaires sur un réplica en lecture.

  • Vous avez créé un nouvel espace de table temporaire sur l'instance de base de données principale. Dans ce cas, RDS for Oracle synchronise les métadonnées avec le réplica en lecture.

Vous pouvez ajouter un fichier temporaire à l'espace de table temporaire vide et stocker le fichier temporaire dans le stockage d'instances. Pour créer un fichier temporaire dans le stockage d'instances, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.add_inst_store_tempfile. Vous pouvez utiliser cette procédure uniquement sur un réplica en lecture. La procédure possède les paramètres suivants.

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

p_tablespace_name

varchar

Oui

Nom de l'espace de table temporaire sur votre réplica en lecture.

Dans l'exemple suivant, l'espace de table temporaire vide temp01 existe sur votre réplica en lecture. Exécutez la commande suivante pour créer un fichier temporaire pour cet espace de table et le stocker dans le stockage d'instances.

EXEC rdsadmin.rdsadmin_util.add_inst_store_tempfile(p_tablespace_name => 'temp01');

Pour plus d’informations, consultez Stockage de données temporaires dans un stockage d'instances RDS for Oracle.

Dépôt de fichiers temporaires sur un réplica en lecture

Vous ne pouvez pas créer un espace de table temporaire existant sur un réplica en lecture. Vous pouvez modifier le stockage du fichier temporaire sur un réplica en lecture depuis Amazon EBS vers le stockage d'instances, ou depuis le stockage d'instances vers Amazon EBS. Pour atteindre ces objectifs, procédez comme suit :

  1. Déposez les fichiers temporaires actuels dans l'espace de table temporaire du réplica en lecture.

  2. Créez de nouveaux fichiers temporaires sur différents stockages.

Pour supprimer les fichiers temporaires, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util. drop_replica_tempfiles. Vous pouvez utiliser cette procédure uniquement sur des réplicas en lecture. La procédure drop_replica_tempfiles possède les paramètres suivants.

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

p_tablespace_name

varchar

Oui

Nom de l'espace de table temporaire sur votre réplica en lecture.

Supposons qu'un espace de table temporaire nommé temp01 réside dans le stockage d'instances de votre réplica en lecture. Déposez tous les fichiers temporaires dans cet espace de table en exécutant la commande suivante.

EXEC rdsadmin.rdsadmin_util.drop_replica_tempfiles(p_tablespace_name => 'temp01');

Pour plus d’informations, consultez Stockage de données temporaires dans un stockage d'instances RDS for Oracle.

Création d'un point de contrôle de base de données

Pour créer un point de contrôle sur la base de données, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.checkpoint. La procédure checkpoint ne comporte aucun paramètre.

L'exemple suivant crée un point de contrôle sur la base de données.

EXEC rdsadmin.rdsadmin_util.checkpoint;

Définition d'une récupération distribuée

Pour définir une récupération distribuée, utilisez les procédures Amazon RDS rdsadmin.rdsadmin_util.enable_distr_recovery et disable_distr_recovery. Ces procédures ne comportent aucun paramètre.

L'exemple suivant active la récupération distribuée.

EXEC rdsadmin.rdsadmin_util.enable_distr_recovery;

L'exemple suivant désactive la récupération distribuée.

EXEC rdsadmin.rdsadmin_util.disable_distr_recovery;

Définition du fuseau horaire de la base de données

Vous pouvez définir le fuseau horaire de votre base de données Oracle Amazon RDS des manières suivantes :

  • L'option Timezone

    L'option Timezone modifie le fuseau horaire au niveau de l'hôte et impacte toutes les valeurs et colonnes date, telles que SYSDATE. Pour plus d'informations, consultez Fuseau horaire Oracle.

  • La procédure Amazon RDS rdsadmin.rdsadmin_util.alter_db_time_zone

    La procédure alter_db_time_zone modifie le fuseau horaire uniquement pour certains types de données, et ne change pas SYSDATE. Il existe des restrictions supplémentaires sur la définition du fuseau horaire, répertoriées dans la documentation Oracle.

Note

Vous pouvez également définir le fuseau horaire par défaut pour Oracle Scheduler. Pour plus d'informations, consultez Définition du fuseau horaire pour les tâches d'Oracle Scheduler.

La procédure alter_db_time_zone possède les paramètres suivants.

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

p_new_tz

varchar2

Oui

Nouveau fuseau horaire correspondant à une région nommée ou à un décalage absolu par rapport à l'heure UTC (Coordinated Universal Time). Les décalages valides s'étendent de -12h00 à +14h00.

L'exemple suivant remplace le fuseau horaire par l'heure UTC plus trois heures.

EXEC rdsadmin.rdsadmin_util.alter_db_time_zone(p_new_tz => '+3:00');

L'exemple suivant définit le fuseau horaire de la région Africa/Algiers.

EXEC rdsadmin.rdsadmin_util.alter_db_time_zone(p_new_tz => 'Africa/Algiers');

Après avoir modifié le fuseau horaire grâce à la procédure alter_db_time_zone, redémarrez l'instance de base de données pour que la modification prenne effet. Pour plus d'informations, consultez Redémarrage d'une instance de base de données. Pour de plus amples informations sur la mise à niveau des fuseaux horaires, veuillez consulter Considérations relatives au fuseau horaire

Utilisation de tables externes Oracle

Les tables externes Oracle sont des tables contenant des données ne figurant pas dans la base de données. À la place, les données se trouvent dans des fichiers externes auxquels la base de données peut accéder. L'utilisation de tables externes vous permet d'accéder aux données sans les charger dans la base de données. Pour de plus amples informations sur les tables externes, veuillez consulter Managing External Tables dans la documentation Oracle.

Avec Amazon RDS, vous pouvez stocker des fichiers de table externe dans des objets de répertoire. Vous pouvez créer un objet de répertoire ou vous pouvez en utiliser un qui est prédéfini dans la base de données Oracle, comme le répertoire DATA_PUMP_DIR. Pour plus d'informations sur la création d'objets de répertoire, consultez Création et suppression de répertoires dans l'espace de stockage de données principal. Vous pouvez interroger la vue ALL_DIRECTORIES pour répertorier tous les objets de répertoire de votre instance de base de données Amazon RDS Oracle.

Note

Les objets de répertoire pointent vers le même espace de stockage de données (volume Amazon EBS) utilisé par votre instance. L'espace utilisé—ainsi que les fichiers de données, journaux redo, d'audit, de suivi et autres—sont déduits du stockage alloué.

Vous pouvez déplacer un fichier de données externes d'une base de données Oracle à une autre à l'aide du package DBMS_FILE_TRANSFER ou du package UTL_FILE. Le fichier de données externes est déplacé d'un répertoire de la base de données source vers le répertoire spécifié sur la base de données de destination. Pour plus d'informations sur l'utilisation de DBMS_FILE_TRANSFER, consultez Importation à l'aide d'Oracle Data Pump.

Après avoir déplacé le fichier de données externe, celui-ci peut vous permettre de créer une table externe. L'exemple suivant crée une table externe qui utilise le fichier emp_xt_file1.txt dans le répertoire USER_DIR1.

CREATE TABLE emp_xt ( emp_id NUMBER, first_name VARCHAR2(50), last_name VARCHAR2(50), user_name VARCHAR2(20) ) ORGANIZATION EXTERNAL ( TYPE ORACLE_LOADER DEFAULT DIRECTORY USER_DIR1 ACCESS PARAMETERS ( RECORDS DELIMITED BY NEWLINE FIELDS TERMINATED BY ',' MISSING FIELD VALUES ARE NULL (emp_id,first_name,last_name,user_name) ) LOCATION ('emp_xt_file1.txt') ) PARALLEL REJECT LIMIT UNLIMITED;

Supposons que vous souhaitiez déplacer des données se trouvant dans une instance de base de données Amazon RDS Oracle vers un fichier de données externe. Dans ce as, vous pouvez remplir le fichier de données externe en créant une table externe et en sélectionnant les données de la table de la base de données. Par exemple, l'instruction SQL suivante crée la table externe orders_xt en interrogeant la table orders de la base de données.

CREATE TABLE orders_xt ORGANIZATION EXTERNAL ( TYPE ORACLE_DATAPUMP DEFAULT DIRECTORY DATA_PUMP_DIR LOCATION ('orders_xt.dmp') ) AS SELECT * FROM orders;

Dans cet exemple, les données sont renseignées dans le fichier orders_xt.dmp du répertoire DATA_PUMP_DIR.

Génération de rapports de performance avec AWR (Automatic Workload Repository)

Pour collecter des données de performance et générer des rapports, Oracle recommande AWR (Automatic Workload Repository). AWR nécessite Oracle Database Enterprise Edition et une licence pour les packs Diagnostics et Tuning. Pour activer AWR, définissez le paramètre d'initialisation CONTROL_MANAGEMENT_PACK_ACCESS sur DIAGNOSTIC ou DIAGNOSTIC+TUNING.

Utilisation des rapports AWR dans RDS

Pour générer des rapports AWR, vous pouvez exécuter des scripts tels que awrrpt.sql. Ces scripts sont installés sur le serveur hôte de base de données. Dans Amazon RDS, vous n'avez pas d'accès direct à l'hôte. Toutefois, vous pouvez obtenir des copies de scripts SQL à partir d'une autre installation d'Oracle Database.

Vous pouvez également utiliser AWR en exécutant des procédures dans le package PL/SQL SYS.DBMS_WORKLOAD_REPOSITORY. Vous pouvez utiliser ce package pour gérer les références et les instantanés, mais aussi pour afficher les rapports ASH et AWR. Par exemple, pour générer un rapport AWR au format texte, exécutez la procédure DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_TEXT. Toutefois, vous ne pouvez pas accéder à ces rapports AWR à partir de la AWS Management Console.

Lorsque vous travaillez avec AWR, nous vous recommandons d'utiliser les procédures rdsadmin.rdsadmin_diagnostic_util. Vous pouvez utiliser ces procédures pour générer les éléments suivants :

  • Rapports AWR

  • Rapports ASH (Active Session History)

  • Rapports ADDM (Automatic Database Diagnostic Monitor)

  • Fichiers de vidage Oracle Data Pump Export des données AWR

Les procédures rdsadmin_diagnostic_util enregistrent les rapports dans le système de fichiers de l'instance de base de données. Vous pouvez accéder à ces rapports à partir de la console. Vous pouvez également accéder aux rapports à l'aide des procédures rdsadmin.rds_file_util. Vous pouvez accéder aux rapports copiés dans Amazon S3 à l'aide de l'option S3 Integration. Pour plus d’informations, consultez Lecture de fichiers dans un répertoire d'instance de base de données et Intégration Amazon S3.

Vous pouvez utiliser les procédures rdsadmin_diagnostic_util pour les versions suivantes du moteur de base de données Amazon RDS for Oracle :

  • Toutes les versions de Oracle Database 21c

  • 19.0.0.0.ru-2020-04.rur-2020-04.r1 et versions ultérieures de Oracle Database 19c

  • 12.2.0.1.ru-2020-04.rur-2020-04.r1 et versions ultérieures de Oracle Database 12c version 2 (12.2)

  • 12.1.0.2.v20 et versions ultérieures de Oracle Database 12c version 1 (12.1)

Pour consulter un blog expliquant comment utiliser les rapports de diagnostic dans un scénario de réplication, consultez Générer des rapports AWR pour les réplicas en lecture Amazon RDS for Oracle (langue française non garantie).

Paramètres communs pour le package d'utilitaires de diagnostic

Vous utilisez généralement les paramètres suivants lors de la gestion d'AWR et d'ADDM avec le package rdsadmin_diagnostic_util.

Paramètre Type de données Par défaut Obligatoire Description

begin_snap_id

NUMBER

Oui

ID de l'instantané de début.

end_snap_id

NUMBER

Oui

ID de l'instantané de fin.

dump_directory

VARCHAR2

BDUMP

Non

Répertoire dans lequel le rapport ou le fichier d'exportation sera écrit. Si vous spécifiez un répertoire autre que le répertoire par défaut, l'utilisateur qui exécute les procédures rdsadmin_diagnostic_util doit disposer des autorisations en écriture pour le répertoire.

p_tag

VARCHAR2

Non

Chaîne pouvant être utilisée pour distinguer les sauvegardes afin d'indiquer leur but ou leur utilisation, telles que incremental ou daily.

Vous pouvez spécifier jusqu'à 30 caractères. Les caractères valides sont a-z, A-Z, 0-9, un trait de soulignement (_), un tiret (-), et un point (.). L'identification n'est pas sensible à la casse. RMAN stocke toujours les identifications en majuscules, quel que soit la casse utilisée lors de leur saisie.

Les identifications n'ont pas besoin d'être uniques, de sorte que plusieurs sauvegardes peuvent avoir la même. Si vous ne spécifiez pas de balise, RMAN attribue automatiquement une balise par défaut au format TAGYYYYMMDDTHHMMSS, où YYYY est l'année, MM le mois, DD le jour, HH l'heure (au format 24 heures), MM les minutes et SS les secondes. La date et l'heure indiquent quand RMAN a démarré la sauvegarde. Par exemple, une sauvegarde avec l'identification par défaut TAG20190927T214517 indique une sauvegarde qui a commencé le 27 septembre 2019 à 21:45:17.

Le paramètre p_tag est pris en charge pour les versions suivantes du moteur de base de données RDS for Oracle :

  • Oracle Database 21c (21.0.0)

  • Oracle Database 19c (19.0.0), avec 19.0.0.0.ru-2021-10.rur-2021-10.r1 et versions ultérieures

  • Oracle Database 12c version 2 (12.2) avec 12.2.0.1.ru-2021-10.rur-2021-10.r1 et ultérieures

  • Oracle Database 12c version 1 (12.1) avec 12.1.0.2.v26 et ultérieures

report_type

VARCHAR2

HTML

Non

Format du rapport. Les valeurs valides sont TEXT et HTML.

dbid

NUMBER

Non

Identifiant de base de données valide (DBID) affiché dans la vue DBA_HIST_DATABASE_INSTANCE pour Oracle. Si ce paramètre n'est pas spécifié, RDS utilise le DBID actuel affiché dans la vue V$DATABASE.DBID.

Vous utilisez généralement les paramètres suivants lors de la gestion d'ASH avec le package rdsadmin_diagnostic_util.

Paramètre Type de données Par défaut Obligatoire Description

begin_time

DATE

Oui

Heure de début de l'analyse ASH.

end_time

DATE

Oui

Heure de fin de l'analyse ASH.

slot_width

NUMBER

0

Non

Durée des emplacements (en secondes) utilisés dans la section « Top Activity (Activité principale) » du rapport ASH. Si ce paramètre n'est pas spécifié, l'intervalle de temps entre begin_time et end_time n'utilise pas plus de 10 emplacements.

sid

NUMBER

Null

Non

ID de session.

sql_id

VARCHAR2

Null

Non

ID SQL.

wait_class

VARCHAR2

Null

Non

Nom de la classe d'attente.

service_hash

NUMBER

Null

Non

Hachage du nom de service.

module_name

VARCHAR2

Null

Non

Nom du module.

action_name

VARCHAR2

Null

Non

Nom de l'action.

client_id

VARCHAR2

Null

Non

ID spécifique à l'application de la session de base de données.

plsql_entry

VARCHAR2

Null

Non

Point d'entrée PL/SQL.

Génération d'un rapport AWR

Pour générer un rapport AWR, utilisez la procédure rdsadmin.rdsadmin_diagnostic_util.awr_report.

L'exemple suivant génère un rapport AWR pour la plage d'instantanés comprise entre 101 et 106. Le fichier texte en sortie est nommé awrrpt_101_106.txt. Vous pouvez accéder à ce rapport à partir d AWS Management Console.

EXEC rdsadmin.rdsadmin_diagnostic_util.awr_report(101,106,'TEXT');

L'exemple suivant génère un rapport HTML pour la plage d'instantanés comprise entre 63 et 65. Le fichier HTML en sortie est nommé awrrpt_63_65.html. La procédure écrit le rapport dans un répertoire de base de données autre que le répertoire par défaut et nommé AWR_RPT_DUMP.

EXEC rdsadmin.rdsadmin_diagnostic_util.awr_report(63,65,'HTML','AWR_RPT_DUMP');

Extraction de données AWR dans un fichier de vidage

Pour extraire des données AWR dans un fichier de vidage, utilisez la procédure rdsadmin.rdsadmin_diagnostic_util.awr_extract.

L'exemple suivant extrait la plage d'instantanés comprise entre 101 et 106. Le fichier de vidage en sortie est nommé awrextract_101_106.dmp. Vous pouvez accéder à ce fichier via la console.

EXEC rdsadmin.rdsadmin_diagnostic_util.awr_extract(101,106);

L'exemple suivant extrait la plage d'instantanés comprise entre 63 et 65. Le fichier de vidage en sortie est nommé awrextract_63_65.dmp. Le fichier est stocké dans un répertoire de base de données autre que le répertoire par défaut et nommé AWR_RPT_DUMP.

EXEC rdsadmin.rdsadmin_diagnostic_util.awr_extract(63,65,'AWR_RPT_DUMP');

Génération d'un rapport ADDM

Pour générer un rapport ADDM, utilisez la procédure rdsadmin.rdsadmin_diagnostic_util.addm_report.

L'exemple suivant génère un rapport HTML pour la plage d'instantanés comprise entre 101 et 106. Le fichier texte en sortie est nommé addmrpt_101_106.txt. Vous pouvez accéder au rapport via la console.

EXEC rdsadmin.rdsadmin_diagnostic_util.addm_report(101,106);

L'exemple suivant génère un rapport ADDM pour la plage d'instantanés comprise entre 63 et 65. Le fichier texte en sortie est nommé addmrpt_63_65.txt. Le fichier est stocké dans un répertoire de base de données autre que le répertoire par défaut et nommé ADDM_RPT_DUMP.

EXEC rdsadmin.rdsadmin_diagnostic_util.addm_report(63,65,'ADDM_RPT_DUMP');

Génération d'un rapport ASH

Pour générer un rapport ASH, utilisez la procédure rdsadmin.rdsadmin_diagnostic_util.ash_report.

L'exemple suivant génère un rapport ASH qui inclut les données des 14 dernières minutes. Le nom du fichier en sortie utilise le format ashrptbegin_timeend_time.txt, où begin_time et end_time utilisent le format YYYYMMDDHH24MISS. Vous pouvez accéder au fichier via la console.

BEGIN rdsadmin.rdsadmin_diagnostic_util.ash_report( begin_time => SYSDATE-14/1440, end_time => SYSDATE, report_type => 'TEXT'); END; /

L'exemple suivant génère un rapport ASH qui inclut les données depuis le 18 novembre 2019 à 18h07 jusqu'au 18 novembre 2019 à 18h15. Le nom du rapport HTML en sortie est ashrpt_20190918180700_20190918181500.html. Le rapport est stocké dans un répertoire de base de données autre que le répertoire par défaut et nommé AWR_RPT_DUMP.

BEGIN rdsadmin.rdsadmin_diagnostic_util.ash_report( begin_time => TO_DATE('2019-09-18 18:07:00', 'YYYY-MM-DD HH24:MI:SS'), end_time => TO_DATE('2019-09-18 18:15:00', 'YYYY-MM-DD HH24:MI:SS'), report_type => 'html', dump_directory => 'AWR_RPT_DUMP'); END; /

Accès aux rapports AWR à partir de la console ou de la CLI

Pour accéder aux rapports AWR ou exporter des fichiers de vidage, vous pouvez utiliser le AWS Management Console ou AWS CLI. Pour plus d’informations, consultez Téléchargement d'un fichier journal de base de données.

Pour utiliser les liens de base de données Oracle avec des instances de base de données Amazon RDS au sein du même VPC (cloud privé virtuel) ou de VPC appairés, un itinéraire valide doit exister entre les deux instances de base de données. Vérifiez l'itinéraire valide entre les instances de bases de données à l'aide de vos tables de routage VPC et la liste de contrôle d'accès (ACL) réseau.

Le groupe de sécurité de chaque instance de base de données doit autoriser le trafic entrant dans l'autre instance de base de données et le trafic sortant de cette instance. Les règles entrantes et sortantes peuvent faire référence à des groupes de sécurité à partir du même VPC ou d'un VPC appairé. Pour de plus amples informations, veuillez consulter Mise à jour de vos groupes de sécurité pour référencer des groupes de sécurité du VPC appairé.

Si vous avez configuré un serveur DNS personnalisé grâce aux jeux d'options DHCP de votre VPC, votre serveur DNS personnalisé doit pouvoir résoudre le nom de la cible du lien de la base de données. Pour plus d'informations, consultez Configuration d'un serveur DNS personnalisé.

Pour plus d'informations sur l'utilisation des liens de base de données avec Oracle Data Pump, consultez Importation à l'aide d'Oracle Data Pump.

Définition de l'édition par défaut d'une instance de base de données

Vous pouvez redéfinir les objets de base de données dans un environnement privé appelé une édition. Vous pouvez utiliser la redéfinition basée sur l'édition pour mettre à niveau les objets de base de données d'une application avec un temps d'arrêt minimal.

Vous pouvez définir l'édition par défaut d'une instance de bases de données Amazon RDS Oracle à l'aide de la procédure Amazon RDS rdsadmin.rdsadmin_util.alter_default_edition.

L'exemple suivant définit l'édition par défaut de l'instance de bases de données Amazon RDS Oracle sur RELEASE_V1.

EXEC rdsadmin.rdsadmin_util.alter_default_edition('RELEASE_V1');

L'exemple suivant redéfinit l'édition par défaut de l'instance de base de données Amazon RDS Oracle sur la valeur par défaut d'Oracle.

EXEC rdsadmin.rdsadmin_util.alter_default_edition('ORA$BASE');

Pour de plus amples informations concernant la redéfinition basée sur l'édition d'Oracle, veuillez consulter About Editions and Edition-Based Redefinition dans la documentation Oracle.

Activation de l'audit pour la table SYS.AUD$

Pour activer l'audit sur la table de suivi d'audit de base de données SYS.AUD$, utilisez la procédure Amazon RDSrdsadmin.rdsadmin_master_util.audit_all_sys_aud_table. La seule propriété d'audit prise en charge est ALL. Vous ne pouvez pas auditer ou ne pas auditer des instructions ou des opérations individuelles.

L'activation de l'audit est prise en charge pour les instances de base de données Oracle qui exécutent les versions suivantes :

  • Oracle Database 21c (21.0.0)

  • Oracle Database 19c (19.0.0)

  • Oracle Database 12c version 2 (12.2)

  • Oracle Database 12c version 1 (12.1.0.2.v14) et ultérieures

La procédure audit_all_sys_aud_table possède les paramètres suivants.

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

p_by_access

booléen

true

Non

Définissez ce paramètre sur true pour auditer BY ACCESS. Définissez ce paramètre sur false pour auditer BY SESSION.

Note

Dans une base de données de conteneur (CDB) à locataire unique, les opérations suivantes fonctionnent, mais aucun mécanisme visible par le client ne peut détecter l'état actuel des opérations. Les informations d'audit ne sont pas disponibles au sein de la base de données enfichable (PDB). Pour plus d'informations, consultez Limitations des CDB RDS for Oracle.

La requête suivante retourne la configuration d'audit actuelle de SYS.AUD$ pour une base de données.

SELECT * FROM DBA_OBJ_AUDIT_OPTS WHERE OWNER='SYS' AND OBJECT_NAME='AUD$';

Les commandes suivantes activent l'audit de ALL sur SYS.AUD$ BY ACCESS.

EXEC rdsadmin.rdsadmin_master_util.audit_all_sys_aud_table; EXEC rdsadmin.rdsadmin_master_util.audit_all_sys_aud_table(p_by_access => true);

La commande suivante active l'audit de ALL sur SYS.AUD$ BY SESSION.

EXEC rdsadmin.rdsadmin_master_util.audit_all_sys_aud_table(p_by_access => false);

Pour de plus amples informations, veuillez consulter AUDIT (Traditional Auditing) dans la documentation Oracle.

Désactivation de l'audit pour la table SYS.AUD$

Pour désactiver l'audit sur la table de suivi d'audit de base de données SYS.AUD$, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_master_util.noaudit_all_sys_aud_table. Cette procédure ne prend aucun paramètre.

La requête suivante retourne la configuration d'audit actuelle pour SYS.AUD$, pour une base de données :

SELECT * FROM DBA_OBJ_AUDIT_OPTS WHERE OWNER='SYS' AND OBJECT_NAME='AUD$';

La commande suivante désactive l'audit de ALL sur SYS.AUD$.

EXEC rdsadmin.rdsadmin_master_util.noaudit_all_sys_aud_table;

Pour de plus amples informations, veuillez consulter NOAUDIT (Traditional Auditing) dans la documentation Oracle.

Nettoyage de builds d'index en ligne interrompues

Pour nettoyer des builds d'index en ligne qui ont échoué, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_dbms_repair.online_index_clean.

La procédure online_index_clean possède les paramètres suivants.

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

object_id

binary_integer

ALL_INDEX_ID

Non

ID d'objet de l'index. En général, vous pouvez utiliser l'ID d'objet du texte d'erreur ORA-08104.

wait_for_lock

binary_integer

rdsadmin.rdsadmin_dbms_repair.lock_wait

Non

Spécifiez rdsadmin.rdsadmin_dbms_repair.lock_wait, la valeur par défaut pour tenter de verrouiller l'objet sous-jacent et réessayer jusqu'à ce qu'une limite interne soit atteinte si le verrouillage échoue.

Spécifiez rdsadmin.rdsadmin_dbms_repair.lock_nowait pour essayer d'obtenir un verrouillage sur l'objet sous-jacent, sans réessayer si le verouillage échoue.

L'exemple suivant nettoie une build d'index en ligne ayant échoué.

declare is_clean boolean; begin is_clean := rdsadmin.rdsadmin_dbms_repair.online_index_clean( object_id => 1234567890, wait_for_lock => rdsadmin.rdsadmin_dbms_repair.lock_nowait ); end; /

Pour de plus amples informations, veuillez consulter ONLINE_INDEX_CLEAN Function dans la documentation d'Oracle.

Ignorer les blocs corrompus

Pour ignorer les blocs corrompus pendant les analyses d'index et de table, utilisez le package rdsadmin.rdsadmin_dbms_repair.

Les procédures suivantes encapsulent la fonctionnalité de la procédure sys.dbms_repair.admin_table et ne prennent aucun paramètre :

  • rdsadmin.rdsadmin_dbms_repair.create_repair_table

  • rdsadmin.rdsadmin_dbms_repair.create_orphan_keys_table

  • rdsadmin.rdsadmin_dbms_repair.drop_repair_table

  • rdsadmin.rdsadmin_dbms_repair.drop_orphan_keys_table

  • rdsadmin.rdsadmin_dbms_repair.purge_repair_table

  • rdsadmin.rdsadmin_dbms_repair.purge_orphan_keys_table

Les procédures suivantes prennent les mêmes paramètres que leurs homologues du package DBMS_REPAIR pour les bases de données Oracle :

  • rdsadmin.rdsadmin_dbms_repair.check_object

  • rdsadmin.rdsadmin_dbms_repair.dump_orphan_keys

  • rdsadmin.rdsadmin_dbms_repair.fix_corrupt_blocks

  • rdsadmin.rdsadmin_dbms_repair.rebuild_freelists

  • rdsadmin.rdsadmin_dbms_repair.segment_fix_status

  • rdsadmin.rdsadmin_dbms_repair.skip_corrupt_blocks

Pour de plus amples informations sur la gestion de la corruption de base de données, veuillez consulter DBMS_REPAIR dans la documentation Oracle.

Exemple Réponse aux blocs corrompus

Cet exemple présente le flux de travail de base pour répondre aux blocs corrompus. Vos étapes dépendront de l'emplacement et de la nature de votre corruption de bloc.

Important

Avant de tenter de réparer les blocs corrompus, consultez attentivement la documentation DBMS_REPAIR.

Pour ignorer les blocs corrompus pendant les analyses d'index et de table
  1. Exécutez les procédures suivantes pour créer des tables de réparation si elles n'existent pas déjà.

    EXEC rdsadmin.rdsadmin_dbms_repair.create_repair_table; EXEC rdsadmin.rdsadmin_dbms_repair.create_orphan_keys_table;
  2. Exécutez les procédures suivantes pour vérifier s'il existe des enregistrements et les purger si nécessaire.

    SELECT COUNT(*) FROM SYS.REPAIR_TABLE; SELECT COUNT(*) FROM SYS.ORPHAN_KEY_TABLE; SELECT COUNT(*) FROM SYS.DBA_REPAIR_TABLE; SELECT COUNT(*) FROM SYS.DBA_ORPHAN_KEY_TABLE; EXEC rdsadmin.rdsadmin_dbms_repair.purge_repair_table; EXEC rdsadmin.rdsadmin_dbms_repair.purge_orphan_keys_table;
  3. Exécutez la procédure suivante pour rechercher les blocs corrompus.

    SET SERVEROUTPUT ON DECLARE v_num_corrupt INT; BEGIN v_num_corrupt := 0; rdsadmin.rdsadmin_dbms_repair.check_object ( schema_name => '&corruptionOwner', object_name => '&corruptionTable', corrupt_count => v_num_corrupt ); dbms_output.put_line('number corrupt: '||to_char(v_num_corrupt)); END; / COL CORRUPT_DESCRIPTION FORMAT a30 COL REPAIR_DESCRIPTION FORMAT a30 SELECT OBJECT_NAME, BLOCK_ID, CORRUPT_TYPE, MARKED_CORRUPT, CORRUPT_DESCRIPTION, REPAIR_DESCRIPTION FROM SYS.REPAIR_TABLE; SELECT SKIP_CORRUPT FROM DBA_TABLES WHERE OWNER = '&corruptionOwner' AND TABLE_NAME = '&corruptionTable';
  4. Utilisez la procédure skip_corrupt_blocks pour activer ou désactiver l'ignorance de corruption pour les tables affectées. Selon la situation, vous devrez peut-être également extraire des données dans une nouvelle table, puis supprimer la table contenant le bloc corrompu.

    Exécutez la procédure suivante pour permettre d'ignorer la corruption pour les tables affectées.

    begin rdsadmin.rdsadmin_dbms_repair.skip_corrupt_blocks ( schema_name => '&corruptionOwner', object_name => '&corruptionTable', object_type => rdsadmin.rdsadmin_dbms_repair.table_object, flags => rdsadmin.rdsadmin_dbms_repair.skip_flag); end; / select skip_corrupt from dba_tables where owner = '&corruptionOwner' and table_name = '&corruptionTable';

    Exécutez la procédure suivante pour ne pas ignorer la corruption.

    begin rdsadmin.rdsadmin_dbms_repair.skip_corrupt_blocks ( schema_name => '&corruptionOwner', object_name => '&corruptionTable', object_type => rdsadmin.rdsadmin_dbms_repair.table_object, flags => rdsadmin.rdsadmin_dbms_repair.noskip_flag); end; / select skip_corrupt from dba_tables where owner = '&corruptionOwner' and table_name = '&corruptionTable';
  5. Une fois tous les travaux de réparation terminés, exécutez les procédures suivantes pour supprimer les tables de réparation.

    EXEC rdsadmin.rdsadmin_dbms_repair.drop_repair_table; EXEC rdsadmin.rdsadmin_dbms_repair.drop_orphan_keys_table;

Redimensionnement des espaces de table, des fichiers de données et des fichiers temporaires

Par défaut, les espaces de table Oracle sont créés avec l'option « auto extend » activée et sans aucune restriction de taille maximum. À cause de ces paramètres par défaut, les espaces de table peuvent parfois trop se développer. Nous vous recommandons de spécifier une taille maximum appropriée sur les espaces de table permanents et temporaires, et de surveiller attentivement l'utilisation de l'espace.

Redimensionnement des espaces de table permanents

Pour redimensionner un espace de table permanent dans une instance de base de données RDS for Oracle, utilisez l'une des procédures Amazon RDS suivantes :

  • rdsadmin.rdsadmin_util.resize_datafile

  • rdsadmin.rdsadmin_util.autoextend_datafile

La procédure resize_datafile possède les paramètres suivants.

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

p_data_file_id

nombre

Oui

L'identifiant du fichier de données à redimensionner.

p_size

varchar2

Oui

La taille du fichier de données. Spécifiez la taille en octets (par défaut), kilooctets (Ko), mégaoctets (Mo) ou gigaoctets (Go).

La procédure autoextend_datafile possède les paramètres suivants.

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

p_data_file_id

nombre

Oui

L'identifiant du fichier de données à redimensionner.

p_autoextend_state

varchar2

Oui

L'état de la fonction d'auto-extension. Spécifiez ON pour étendre automatiquement le fichier de données et OFF pour désactiver l'extension automatique.

p_next

varchar2

Non

La taille de la prochaine incrémentation du fichier de données. Spécifiez la taille en octets (par défaut), kilooctets (Ko), mégaoctets (Mo) ou gigaoctets (Go).

p_maxsize

varchar2

Non

L'espace disque maximal autorisé pour l'extension automatique. Spécifiez la taille en octets (par défaut), kilooctets (Ko), mégaoctets (Mo) ou gigaoctets (Go). Vous pouvez spécifier UNLIMITED pour supprimer la limite de taille de fichier.

L'exemple suivant redimensionne le fichier de données 4 à 500 Mo.

EXEC rdsadmin.rdsadmin_util.resize_datafile(4,'500M');

L'exemple suivant désactive l'option d'auto-extension pour le fichier de données 4. Il active également l'extension automatique pour le fichier de données 5, avec une incrémentation de 128 Mo et aucune taille maximum.

EXEC rdsadmin.rdsadmin_util.autoextend_datafile(4,'OFF'); EXEC rdsadmin.rdsadmin_util.autoextend_datafile(5,'ON','128M','UNLIMITED');

Redimensionnement des espaces de table temporaires

Pour redimensionner un espace de table permanent dans une instance de base de données RDS for Oracle, incluant un réplica en lecture, utilisez l'une des procédures Amazon RDS suivantes :

  • rdsadmin.rdsadmin_util.resize_temp_tablespace

  • rdsadmin.rdsadmin_util.resize_tempfile

  • rdsadmin.rdsadmin_util.autoextend_tempfile

La procédure resize_temp_tablespace possède les paramètres suivants.

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

p_temp_tablespace_name

varchar2

Oui

Nom de l'espace de table temporaire à redimensionner.

p_size

varchar2

Oui

La taille de l'espace de table. Spécifiez la taille en octets (par défaut), kilooctets (Ko), mégaoctets (Mo) ou gigaoctets (Go).

La procédure resize_tempfile possède les paramètres suivants.

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

p_temp_file_id

nombre

Oui

L'identifiant du fichier temporaire à redimensionner.

p_size

varchar2

Oui

La taille du fichier temporaire. Spécifiez la taille en octets (par défaut), kilooctets (Ko), mégaoctets (Mo) ou gigaoctets (Go).

La procédure autoextend_tempfile possède les paramètres suivants.

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

p_temp_file_id

nombre

Oui

L'identifiant du fichier temporaire à redimensionner.

p_autoextend_state

varchar2

Oui

L'état de la fonction d'auto-extension. Spécifiez ON pour étendre automatiquement le fichier temporaire et OFF pour désactiver l'extension automatique.

p_next

varchar2

Non

La taille de la prochaine incrémentation du fichier temporaire. Spécifiez la taille en octets (par défaut), kilooctets (Ko), mégaoctets (Mo) ou gigaoctets (Go).

p_maxsize

varchar2

Non

L'espace disque maximal autorisé pour l'extension automatique. Spécifiez la taille en octets (par défaut), kilooctets (Ko), mégaoctets (Mo) ou gigaoctets (Go). Vous pouvez spécifier UNLIMITED pour supprimer la limite de taille de fichier.

Les exemples suivants redimensionnent un espace de table temporaire nommé TEMP pour qu'il fasse 4 Go.

EXEC rdsadmin.rdsadmin_util.resize_temp_tablespace('TEMP','4G');
EXEC rdsadmin.rdsadmin_util.resize_temp_tablespace('TEMP','4096000000');

L'exemple suivant redimensionne un espace de table temporaire basé sur le fichier temporaire avec l'identifiant de fichier 1 pour qu'il fasse 2 Mo.

EXEC rdsadmin.rdsadmin_util.resize_tempfile(1,'2M');

L'exemple suivant désactive l'option d'auto-extension pour le fichier temporaire 1. Il définit également la taille maximale d'extension automatique du fichier temporaire 2 à 10 Go, avec une incrémentation de 100 Mo.

EXEC rdsadmin.rdsadmin_util.autoextend_tempfile(1,'OFF'); EXEC rdsadmin.rdsadmin_util.autoextend_tempfile(2,'ON','100M','10G');

Pour plus d'informations sur les réplicas en lecture pour les instances de base de données Oracle, consultez Utilisation de réplicas en lecture pour Amazon RDS for Oracle.

Purge de la corbeille

Lorsque vous supprimez une table, votre base de données Oracle ne supprime pas immédiatement son espace de stockage. La base de données renomme la table et la place, ainsi que les objets associés, dans une corbeille. La purge de la corbeille supprime ces éléments et libère leur espace de stockage.

Pour purger l'intégralité de la corbeille, suivez la procédure Amazon RDS rdsadmin.rdsadmin_util.purge_dba_recyclebin. Toutefois, cette procédure ne peut pas purger la corbeille des objets SYS et RDSADMIN. Si vous devez purger ces objets, contactez AWS Support.

L'exemple suivant purge l'ensemble de la corbeille.

EXEC rdsadmin.rdsadmin_util.purge_dba_recyclebin;

Définition des valeurs affichées par défaut pour une édition complète

Pour modifier les valeurs affichées par défaut pour une édition complète sur votre instance Amazon RDS for Oracle, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.dbms_redact_upd_full_rdct_val. Notez que vous créez une politique d'édition à l'aide du package PL/SQL DBMS_REDACT, comme expliqué dans la documentation sur Oracle Database. La procédure dbms_redact_upd_full_rdct_val spécifie les caractères à afficher pour les différents types de données affectés par une politique existante.

La procédure dbms_redact_upd_full_rdct_val possède les paramètres suivants.

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

p_number_val

nombre

Null

Non

Modifie la valeur par défaut des colonnes de type de données NUMBER.

p_binfloat_val

binary_float

Null

Non

Modifie la valeur par défaut des colonnes de type de données BINARY_FLOAT.

p_bindouble_val

binary_double

Null

Non

Modifie la valeur par défaut des colonnes de type de données BINARY_DOUBLE.

p_char_val

char

Null

Non

Modifie la valeur par défaut des colonnes de type de données CHAR.

p_varchar_val

varchar2

Null

Non

Modifie la valeur par défaut des colonnes de type de données VARCHAR2.

p_nchar_val

nchar

Null

Non

Modifie la valeur par défaut des colonnes de type de données NCHAR.

p_nvarchar_val

nvarchar2

Null

Non

Modifie la valeur par défaut des colonnes de type de données NVARCHAR2.

p_date_val

date

Null

Non

Modifie la valeur par défaut des colonnes de type de données DATE.

p_ts_val

timestamp

Null

Non

Modifie la valeur par défaut des colonnes de type de données TIMESTAMP.

p_tswtz_val

timestamp with time zone

Null

Non

Modifie la valeur par défaut des colonnes de type de données TIMESTAMP WITH TIME ZONE.

p_blob_val

blob

Null

Non

Modifie la valeur par défaut des colonnes de type de données BLOB.

p_clob_val

clob

Null

Non

Modifie la valeur par défaut des colonnes de type de données CLOB.

p_nclob_val

nclob

Null

Non

Modifie la valeur par défaut des colonnes de type de données NCLOB.

L'exemple suivant remplace la valeur expurgée par défaut par * pour le type de données CHAR :

EXEC rdsadmin.rdsadmin_util.dbms_redact_upd_full_rdct_val(p_char_val => '*');

L'exemple suivant modifie les valeurs expurgées par défaut pour les types de données NUMBERDATE et CHAR :

BEGIN rdsadmin.rdsadmin_util.dbms_redact_upd_full_rdct_val( p_number_val=>1, p_date_val=>to_date('1900-01-01','YYYY-MM-DD'), p_varchar_val=>'X'); END; /

Après avoir modifié les valeurs par défaut pour l'édition complète avec la procédure dbms_redact_upd_full_rdct_val, redémarrez votre instance de base de données pour que la modification prenne effet. Pour plus d'informations, voir Redémarrage d'une instance de base de données.