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 courantes liées au journal 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 à la journalisation 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.
Pour plus d'informations, consultez Fichiers journaux de base de données Oracle.
Rubriques
- Configuration du mode FORCE LOGGING
- Configuration d'une journalisation supplémentaire
- Changement de fichiers journaux en ligne
- Ajout de journaux redo en ligne
- Suppression de journaux redo en ligne
- Redimensionnement de journaux redo en ligne
- Conservation des journaux redo archivés
- Accès aux journaux de reprise en ligne et archivés
- Téléchargement des journaux de reprise archivés à partir d'Amazon S3
Configuration du mode FORCE LOGGING
En mode FORCE LOGGING, Oracle enregistre toutes les modifications apportées à la base de données, à l'exception de celles apportées aux espaces de table temporaires et aux segments temporaires (NOLOGGING
des clauses sont ignorées). Pour de plus amples informations, veuillez consulter Specifying FORCE LOGGING Mode
Pour définir le mode FORCE LOGGING, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.force_logging
. La procédure force_logging
possède les paramètres suivants.
Nom du paramètre | Type de données | Par défaut | Oui | Description |
---|---|---|---|---|
|
booléen |
true |
Non |
Définissez ce paramètre sur |
L'exemple suivant met la base de données en mode FORCE LOGGING.
EXEC rdsadmin.rdsadmin_util.force_logging(p_enable =>
true
);
Configuration d'une journalisation supplémentaire
Si vous activez la journalisation supplémentaire, LogMiner dispose des informations nécessaires pour prendre en charge les lignes chaînées et les tables en cluster. Pour de plus amples informations, veuillez consulter journalisation supplémentaire
Oracle Database n'active pas la journalisation supplémentaire par défaut. Pour activer et désactiver la journalisation supplémentaire, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.alter_supplemental_logging
. Pour plus d'informations sur la façon dont Amazon RDS gère la conservation des journaux redo archivés pour les instances de base de données Oracle, consultez Conservation des journaux redo archivés.
La procédure alter_supplemental_logging
possède les paramètres suivants.
Nom du paramètre | Type de données | Par défaut | Obligatoire | Description |
---|---|---|---|---|
|
varchar2 |
— |
Oui |
|
|
varchar2 |
null |
Non |
Type de journalisation supplémentaire. Les valeurs valides sont |
L'exemple suivant active la journalisation supplémentaire.
begin rdsadmin.rdsadmin_util.alter_supplemental_logging( p_action => '
ADD
'); end; /
L'exemple suivant active la journalisation supplémentaire pour toutes les colonnes de taille maximale et de longueur fixe.
begin rdsadmin.rdsadmin_util.alter_supplemental_logging( p_action => '
ADD
', p_type => 'ALL
'); end; /
L'exemple suivant active la journalisation supplémentaire pour les colonnes de clés primaires.
begin rdsadmin.rdsadmin_util.alter_supplemental_logging( p_action => '
ADD
', p_type => 'PRIMARY KEY
'); end; /
Changement de fichiers journaux en ligne
Pour changer des fichiers journaux, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.switch_logfile
. La procédure switch_logfile
ne comporte aucun paramètre.
L'exemple suivant change des fichiers journaux.
EXEC rdsadmin.rdsadmin_util.switch_logfile;
Ajout de journaux redo en ligne
Une instance de base de données Amazon RDS exécutant Oracle démarre avec quatre journaux redo en ligne de 128 Mo chacun. Pour ajouter des journaux redo supplémentaires, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.add_logfile
.
La procédure add_logfile
possède les paramètres suivants.
Note
Les paramètres s'excluent mutuellement.
Nom du paramètre | Type de données | Par défaut | Obligatoire | Description |
---|---|---|---|---|
|
positives |
null |
Non |
Taille du fichier journal en octets. |
|
varchar2 |
— |
Oui |
Taille du fichier journal. Vous pouvez spécifier la taille en kilo-octets (Ko), mégaoctets (Mo) ou gigaoctets (Go). |
La commande suivante ajoute un fichier journal de 100 Mo.
EXEC rdsadmin.rdsadmin_util.add_logfile(p_size => '
100M
');
Suppression de journaux redo en ligne
Pour supprimer des journaux redo, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.drop_logfile
. La procédure drop_logfile
possède les paramètres suivants.
Nom du paramètre | Type de données | Par défaut | Obligatoire | Description |
---|---|---|---|---|
|
positives |
— |
Oui |
Numéro de groupe du journal. |
L'exemple suivant supprime le journal doté du numéro de groupe 3.
EXEC rdsadmin.rdsadmin_util.drop_logfile(grp =>
3
);
Vous pouvez uniquement supprimer des journaux dont le statut est inutilisé ou inactif. L'exemple suivant permet d'obtenir les statuts des journaux.
SELECT GROUP#, STATUS FROM V$LOG; GROUP# STATUS ---------- ---------------- 1 CURRENT 2 INACTIVE 3 INACTIVE 4 UNUSED
Redimensionnement de journaux redo en ligne
Une instance de base de données Amazon RDS exécutant Oracle démarre avec quatre journaux redo en ligne de 128 Mo chacun. L'exemple suivant montre comment vous pouvez utiliser les procédures Amazon RDS for redimensionner vos journaux en remplaçant leur taille de 128 Mo par 512 Mo.
/* Query V$LOG to see the logs. */ /* You start with 4 logs of 128 MB each. */ SELECT GROUP#, BYTES, STATUS FROM V$LOG; GROUP# BYTES STATUS ---------- ---------- ---------------- 1 134217728 INACTIVE 2 134217728 CURRENT 3 134217728 INACTIVE 4 134217728 INACTIVE /* Add four new logs that are each 512 MB */ EXEC rdsadmin.rdsadmin_util.add_logfile(bytes => 536870912); EXEC rdsadmin.rdsadmin_util.add_logfile(bytes => 536870912); EXEC rdsadmin.rdsadmin_util.add_logfile(bytes => 536870912); EXEC rdsadmin.rdsadmin_util.add_logfile(bytes => 536870912); /* Query V$LOG to see the logs. */ /* Now there are 8 logs. */ SELECT GROUP#, BYTES, STATUS FROM V$LOG; GROUP# BYTES STATUS ---------- ---------- ---------------- 1 134217728 INACTIVE 2 134217728 CURRENT 3 134217728 INACTIVE 4 134217728 INACTIVE 5 536870912 UNUSED 6 536870912 UNUSED 7 536870912 UNUSED 8 536870912 UNUSED /* Drop each inactive log using the group number. */ EXEC rdsadmin.rdsadmin_util.drop_logfile(grp => 1); EXEC rdsadmin.rdsadmin_util.drop_logfile(grp => 3); EXEC rdsadmin.rdsadmin_util.drop_logfile(grp => 4); /* Query V$LOG to see the logs. */ /* Now there are 5 logs. */ select GROUP#, BYTES, STATUS from V$LOG; GROUP# BYTES STATUS ---------- ---------- ---------------- 2 134217728 CURRENT 5 536870912 UNUSED 6 536870912 UNUSED 7 536870912 UNUSED 8 536870912 UNUSED /* Switch logs so that group 2 is no longer current. */ EXEC rdsadmin.rdsadmin_util.switch_logfile; /* Query V$LOG to see the logs. */ /* Now one of the new logs is current. */ SQL>SELECT GROUP#, BYTES, STATUS FROM V$LOG; GROUP# BYTES STATUS ---------- ---------- ---------------- 2 134217728 ACTIVE 5 536870912 CURRENT 6 536870912 UNUSED 7 536870912 UNUSED 8 536870912 UNUSED /* If the status of log 2 is still "ACTIVE", issue a checkpoint to clear it to "INACTIVE". */ EXEC rdsadmin.rdsadmin_util.checkpoint; /* Query V$LOG to see the logs. */ /* Now the final original log is inactive. */ select GROUP#, BYTES, STATUS from V$LOG; GROUP# BYTES STATUS ---------- ---------- ---------------- 2 134217728 INACTIVE 5 536870912 CURRENT 6 536870912 UNUSED 7 536870912 UNUSED 8 536870912 UNUSED # Drop the final inactive log. EXEC rdsadmin.rdsadmin_util.drop_logfile(grp => 2); /* Query V$LOG to see the logs. */ /* Now there are four 512 MB logs. */ SELECT GROUP#, BYTES, STATUS FROM V$LOG; GROUP# BYTES STATUS ---------- ---------- ---------------- 5 536870912 CURRENT 6 536870912 UNUSED 7 536870912 UNUSED 8 536870912 UNUSED
Conservation des journaux redo archivés
Vous pouvez conserver les journaux de restauration archivés localement sur votre instance de base de données pour les utiliser avec des produits tels qu'Oracle LogMiner (DBMS_LOGMNR
). Une fois que vous avez conservé les journaux redo, vous pouvez les utiliser LogMiner pour analyser les journaux. Pour plus d'informations, consultez la section Utilisation LogMiner pour analyser les fichiers de journalisation
Pour conserver les journaux redo archivés, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.set_configuration
. La procédure set_configuration
possède les paramètres suivants.
Nom du paramètre | Type de données | Par défaut | Obligatoire | Description |
---|---|---|---|---|
|
varchar |
— |
Oui |
Nom de la configuration à mettre à jour. |
|
varchar |
— |
Oui |
Valeur pour la configuration. |
L'exemple suivant conserve les journaux redo pendant 24 heures.
begin rdsadmin.rdsadmin_util.set_configuration( name => 'archivelog retention hours', value => '24'); end; / commit;
Note
La validation est obligatoire pour que la modification prenne effet.
Pour voir combien de temps les journaux redo archivés sont conservés pour votre instance de base de données, utilisez la procédure Amazon RDS rdsadmin.rdsadmin_util.show_configuration
.
L'exemple suivant affiche la durée de conservation des journaux.
set serveroutput on EXEC rdsadmin.rdsadmin_util.show_configuration;
La sortie affiche le paramètre actuel pour archivelog retention hours
. La sortie suivante montre que les journaux redo archivés sont conservés pendant 48 heures.
NAME:archivelog retention hours
VALUE:48
DESCRIPTION:ArchiveLog expiration specifies the duration in hours before archive/redo log files are automatically deleted.
Étant donné que les journaux redo archivés sont conservés sur votre instance de base de données, vérifiez que votre instance de base de données dispose d'un stockage alloué suffisant pour les journaux conservés. Pour déterminer la quantité d'espace que votre instance de base de données a utilisée au cours des X dernières heures, vous pouvez exécuter la requête suivante en remplaçant X par le nombre d'heures.
SELECT SUM(BLOCKS * BLOCK_SIZE) bytes FROM V$ARCHIVED_LOG WHERE FIRST_TIME >= SYSDATE-(
X
/24) AND DEST_ID=1;
RDS for Oracle ne génère des journaux de reprise archivés que si la période de rétention des sauvegardes de votre instance de base de données est supérieure à zéro. Par défaut, la période de rétention des sauvegardes est supérieure à zéro.
Lorsque la période de rétention des journaux archivés expire, RDS for Oracle supprime les journaux de reprise archivés de votre instance de base de données. Pour prendre en charge la restauration de votre instance de base de données à un moment donné, Amazon RDS conserve les journaux de reprise archivés en dehors de votre instance de base de données pendant la période de rétention des sauvegardes. Pour modifier la période de rétention des sauvegardes pour votre instance de base de données, consultez Modification d'une instance de base de données Amazon RDS.
Note
Dans certains cas, vous pouvez utiliser JDBC sur Linux pour télécharger les journaux redo archivés et connaître des temps de latence élevés et des réinitalisations de connexion. Dans ces cas, les problèmes peuvent être causés par le paramétrage du générateur de nombres aléatoires sur votre client Java. Nous vous recommandons de définir vos pilotes JDBC pour l'utilisation d'un générateur de nombres aléatoires sans blocage.
Accès aux journaux de reprise en ligne et archivés
Vous souhaiterez peut-être accéder à vos fichiers de journalisation en ligne et archivés pour le minage à l'aide d'outils externes tels que GoldenGate Attunity, Informatica, etc. Pour accéder à ces fichiers, procédez comme suit :
-
Créez des objets de répertoire qui donnent un accès en lecture seule aux chemins d'accès de fichiers physiques.
Utilisation de
rdsadmin.rdsadmin_master_util.create_archivelog_dir
etrdsadmin.rdsadmin_master_util.create_onlinelog_dir
. -
Lisez les fichiers à l'aide de PL/SQL.
Vous pouvez lire les fichiers en utilisant PL/SQL. Pour de plus amples informations sur la lecture de fichiers à partir d'objets de répertoire, veuillez consulter Établissement de la liste des fichiers situés dans un répertoire d'instance de base de données et Lecture de fichiers dans un répertoire d'instance de base de données.
L'accès aux journaux des transactions est pris en charge pour les versions suivantes :
-
Oracle Database 21c
-
Oracle Database 19c
Le code suivant crée des répertoires qui fournissent un accès en lecture seule à vos fichiers de journalisation Redo en ligne et archivés :
Important
Ce code retire également le privilège DROP ANY DIRECTORY
.
EXEC rdsadmin.rdsadmin_master_util.create_archivelog_dir; EXEC rdsadmin.rdsadmin_master_util.create_onlinelog_dir;
Le code suivant supprime les répertoires pour vos fichiers journaux redo en ligne et archivés.
EXEC rdsadmin.rdsadmin_master_util.drop_archivelog_dir; EXEC rdsadmin.rdsadmin_master_util.drop_onlinelog_dir;
Le code suivant accorde et révoque le privilège DROP ANY DIRECTORY
.
EXEC rdsadmin.rdsadmin_master_util.revoke_drop_any_directory; EXEC rdsadmin.rdsadmin_master_util.grant_drop_any_directory;
Téléchargement des journaux de reprise archivés à partir d'Amazon S3
Vous pouvez télécharger les journaux de reprise archivés sur votre instance de base de données à l'aide du package rdsadmin.rdsadmin_archive_log_download
. Si les journaux de reprise archivés ne sont plus sur votre instance de base de données, vous pouvez les télécharger à nouveau à partir d'Amazon S3. Ensuite, vous pouvez les exploiter ou les utiliser pour récupérer ou répliquer votre base de données.
Note
Vous ne pouvez pas télécharger des Journaux de reprise archivés sur des instances de réplica en lecture.
Téléchargement des journaux de reprise archivés : étapes de base
La disponibilité de vos journaux de reprise archivés dépend des politiques de rétention suivantes :
-
Politique de conservation des sauvegardes : les journaux liés à cette politique sont disponibles dans Amazon S3. Les journaux étrangers à cette politique sont supprimés.
-
Politique de conservation des journaux archivés : les journaux liés à cette politique sont disponibles sur votre instance de base de données. Les journaux étrangers à cette politique sont supprimés.
Si les journaux ne figurent pas sur votre instance mais sont protégés par votre période de rétention des sauvegardes, utilisez rdsadmin.rdsadmin_archive_log_download
pour les télécharger à nouveau. RDS for Oracle enregistre les journaux dans le répertoire /rdsdbdata/log/arch
sur votre instance de base de données.
Pour télécharger des journaux de reprise archivés à partir d'Amazon S3
-
Configurez votre période de conservation pour vous assurer que les journaux redo archivés que vous avez téléchargés sont conservés pendant la durée où vous en avez besoin. Veillez à valider (
COMMIT
) votre changement.RDS conserve vos journaux téléchargés conformément à la politique de conservation des journaux archivés, à compter du moment où les journaux ont été téléchargés. Pour découvrir comment définir la politique de rétention, consultez Conservation des journaux redo archivés.
-
Attendez jusqu'à 5 minutes pour que la modification de la politique de rétention des journaux archivés prenne effet.
-
Téléchargez les journaux de reprise archivés à partir d'Amazon S3 à l'aide de
rdsadmin.rdsadmin_archive_log_download
.Pour plus d’informations, consultez Téléchargement d'un journal de reprise archivé unique et Téléchargement d'une série de journaux de reprise archivés.
Note
RDS vérifie automatiquement le stockage disponible avant le téléchargement. Si les journaux demandés consomment un pourcentage élevé d'espace, vous recevez une alerte.
-
Vérifiez que les journaux ont bien été téléchargés à partir d'Amazon S3.
Vous pouvez consulter l'état de votre tâche de téléchargement dans un fichier bdump. Les fichiers bdump ont le nom des chemin d'accès
/rdsdbdata/log/trace/dbtask-
. A l'étape de téléchargement précédente, vous avez exécuté une instructiontask-id
.logSELECT
qui renvoie l'ID de tâche dans un type de donnéesVARCHAR2
. Pour plus d'informations, consultez des exemples similaires dans Surveillance du statut d'un transfert de fichiers.
Téléchargement d'un journal de reprise archivé unique
Pour télécharger un journal de reprise archivé unique dans le répertoire /rdsdbdata/log/arch
, utilisez rdsadmin.rdsadmin_archive_log_download.download_log_with_seqnum
. Cette procédure utilise le paramétrage suivant.
Nom du paramètre | Type de données | Par défaut | Obligatoire | Description |
---|---|---|---|---|
|
nombre |
— |
Oui |
Numéro de séquence du journal de reprise archivé. |
L'exemple suivant télécharge le journal avec le numéro de séquence 20.
SELECT rdsadmin.rdsadmin_archive_log_download.download_log_with_seqnum(seqnum => 20) AS TASK_ID FROM DUAL;
Téléchargement d'une série de journaux de reprise archivés
Pour télécharger une série de journaux de reprise archivés dans le répertoire /rdsdbdata/log/arch
, utilisez download_logs_in_seqnum_range
. Votre téléchargement est limité à 300 journaux par requête. La procédure download_logs_in_seqnum_range
possède les paramètres suivants.
Nom du paramètre | Type de données | Par défaut | Obligatoire | Description |
---|---|---|---|---|
|
nombre |
— |
Oui |
Numéro de séquence initial de la série. |
|
nombre |
— |
Oui |
Numéro de séquence final de la série. |
L'exemple suivant télécharge les journaux portant les numéros de séquence 50 à 100.
SELECT rdsadmin.rdsadmin_archive_log_download.download_logs_in_seqnum_range(start_seq => 50, end_seq => 100) AS TASK_ID FROM DUAL;