Tâches de base de données DBA courantes pour les instances de base de données Oracle - Amazon Relational Database Service

Tâches de base de données DBA 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 limite également l'accès à certaines tables et procédures système 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 comporte 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 (MODIFIER BASE DE DONNÉES) 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, les espaces de table sont créés avec l'option auto extend activée et aucune restriction de taille maximum. 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 comprise entre 1 et 10 gigaoctets maximum :

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

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

CREATE TEMPORARY TABLESPACE temp01;

Nous vous recommandons de ne pas utiliser d'espaces de table smallfile, car vous ne pouvez pas redimensionner les espaces de table smallfile avec Amazon RDS for Oracle. Toutefois, vous pouvez ajouter un fichier de données à un espace de table smallfile.

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é users2 pour qu'il fasse 200 Mo.

ALTER TABLESPACE users2 RESIZE 200M;

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

ALTER TABLESPACE users2 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 comporte 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');

Configuration 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 comporte 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 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 de plus amples informations, veuillez consulter 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 remplace le fuseau horaire par celui 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.

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 plus d'informations sur les tables externes, consultez 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 de répertoires dans l'espace principal de stockage des données. 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 d’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 de plus amples informations, veuillez consulter 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 :

  • 11.2.0.4.v24 ou versions 11.2 ultérieures

  • 12.1.0.2.v20 ou versions 12.1 ultérieures

  • 12.2.0.2.ru-2020-04.rur-2020-04.r1 ou versions 12.2 ultérieures

  • 18.0.0.0.ru-2020-04.rur-2020-04.r1 ou versions 18c ultérieures

  • 19.0.0.0.ru-2020-04.rur-2020-04.r1 ou versions 19c ultérieures

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.

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, qui est 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_diagnotic_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 l'interface de ligne de commande

Pour accéder aux rapports AWR ou exporter des fichiers de vidage, vous pouvez utiliser AWS Management Console ou l’AWS CLI. Pour de plus amples informations, veuillez consulter 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 plus d'informations, consultez 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 :

  • 11.2.0.4.v18 et versions 11.2 ultérieures

  • 12.1.0.2.v14 et versions 12.1 ultérieures

  • Toutes les versions 12.2.0.1

  • Toutes les versions 18.0.0.0

  • Toutes les versions 19.0.0.0

La procédure audit_all_sys_aud_table comporte 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.

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 de l'espace de table temporaire dans un réplica en lecture

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.

Pour redimensionner l'espace temporaire dans un réplica en lecture pour une instance de base de données Oracle, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.resize_temp_tablespace ou rdsadmin.rdsadmin_util.resize_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

temp_tbs

varchar2

Oui

Nom de l'espace de table temporaire à redimensionner.

size

varchar2

Oui

Vous pouvez spécifier 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

file_id

binary_integer

Oui

Identifiant de fichier de l'espace de table temporaire à redimensionner.

size

varchar2

Oui

Vous pouvez spécifier la taille en octets (par défaut), kilooctets (Ko), mégaoctets (Mo) ou gigaoctets (Go).

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

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 sur un réplica en lecture.

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

Pour de plus amples informations sur les réplicas en lecture pour les instances de base de données Oracle, veuillez consulter Utilisation des réplicas en lecture Oracle pour Amazon RDS.

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;