0

Oracle RDS : effectuer des backup RMAN en mode PaaS.

twitterlinkedinmail

AWS, dans son offre RDS, empêche l’utilisateur d’accéder au serveur ou est hébergée la base de données. Ce qui fait que l’utilisation de binaires type “expdp”, “dgmgrl” ou encore “rman” ne sera pas possible sur le serveur. Par contre, AWS autorisera l’utilisateur à effectuer des backup RMAN directement en base.

Pour cela, l’utilisateur s’appuiera sur la procédure “rdsadmin.rdsadmin_rman_util” du package, bien connu sous AWS RDS, qui est “rdsadmin“.

Une procédure assez similaire avait été traitée pour les instances de bases SQL Server pour RDS : https://blog.capdata.fr/index.php/aws-backup-restore-sql-server-rds-iaas-ec2-et-vice-versa/

 

Quelques recommandations

AWS RDS offre la possibilité de faire des backup RMAN, en revanche, il ne sera pas possible de faire directement une restauration RMAN sur une base Oracle RDS.
Il faudra passer par le processus dédié qu’Amazon met en place via des backup automatiques : par exemple, l’outil AWS CLI utilisera pour cela la commande :

aws rds restore-db-instance-to-point-in-time …..

Mais alors pourquoi effectuer une sauvegarde RMAN alors que AWS ne sait la restaurer sur une autre instance Oracle RDS ?
Plusieurs scenarii à cela peuvent être envisagés :
– maîtriser sa propre stratégie de backup  (full, incremental, archivelog) et pouvoir externaliser les fichiers (sur S3 ou autres cibles externes)
– Utiliser les fichiers RMAN pour faire une restauration de base sur un serveur EC2 ou on-premise.
– Isoler un jeu de backup RMAN pour des besoins d’exercices comptables dans le cadre d’une compliance demandé par un cabinet d’audit
…..

 

Sauvegardes RMAN sous Oracle RDS

Pre requis

  • Les paramètres

De nombreux paramètres utilisés par la procédure rdsadmin.rdsadmin_rman_util  seront communs à chaque appel. La liste des paramètres sera la suivante :

p_owner : Propriétaire du répertoire spécifié dans p_directory_name.
p_directory_name : Nom de répertoire de la base de données.
p_label  : nom donné pour le backup
p_compress  : Active ou non la compression (TRUE/FALSE)
p_include_archive_logs  : sauvegarde avec archivelogs (TUE/FALSE)
p_include_controlfile : sauvegarde avec controlfile (TRUE/FALSE)
p_parallel : sauvegarde sur plusieurs canaux (nombre à spécifier)
p_rman_to_dbms_output : affiche les instructions RMAN à l’écran via DBMS_OUTPUT (TRUE/FALSE). Spécifier également “set serverouput on”
p_section_size_mb : taille de chaque fichier de backup (correspond au MAXPIECESIZE dans RMAN)
p_validation_type : recherche de corruption de blocs bases de données. Specifier “PHYSICAL” (par défaut) ou “PHYSICAL+LOGICAL”

 

  • Le DIRECTORY

Avant de commencer à effectuer une sauvegarde RMAN, il faudra s’assurer de disposer d’un DIRECTORY base de données dans lequel stocké les fichiers RMAN.
Celui ci pourra se créer via la commande :

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

PL/SQL procedure successfully completed.

SQL> select OWNER, DIRECTORY_NAME,DIRECTORY_PATH from dba_directories where DIRECTORY_NAME='BACKUP_RMAN';

OWNER      DIRECTORY_NAME            DIRECTORY_PATH
---------- ------------------------- ---------------------------------------------
SYS        BACKUP_RMAN               /rdsdbdata/userdirs/01

 

  • Gérer le mode ARCHIVELOG de la base

Vérifier que la base est bien en mode ARCHIVELOG et que la destination des archivelogs ne comporte pas d’erreurs :

SQL>  select NAME,CREATED,LOG_MODE,OPEN_MODE,DATABASE_ROLE from v$database;

NAME      CREATED   LOG_MODE     OPEN_MODE            DATABASE_ROLE
--------- --------- ------------ -------------------- ----------------
CAPDATA   20-JUN-19 ARCHIVELOG   READ WRITE           PRIMARY


SQL> select DEST_ID,DEST_NAME,STATUS,TARGET,NAME_SPACE,DESTINATION,PROCESS,ERROR from v$archive_dest where status='VALID';

   DEST_ID DEST_NAME            STATUS    TARGET           NAME_SP DESTINATION                              PROCESS    ERROR
---------- -------------------- --------- ---------------- ------- ---------------------------------------- ---------- ----------
         1 LOG_ARCHIVE_DEST_1   VALID     PRIMARY          SYSTEM  /rdsdbdata/db/CAPDATA_A/arch/redolog     ARCH

 

Définir la rétention des archivelogs avant de lancer une sauvegarde. Par exemple, nous pourrons conserver 12 heures d’archivelogs sur disque afin de pouvoir les exploiter par un autre processus (LogMinner par exemple).

SQL> exec rdsadmin.rdsadmin_util.set_configuration( name => 'archivelog retention hours', value => '12');

PL/SQL procedure successfully completed.

SQL> commit;

Commit complete.

SQL> exec rdsadmin.rdsadmin_util.show_configuration;
NAME:archivelog retention hours
VALUE:12
DESCRIPTION:ArchiveLog expiration specifies the duration in hours before archive/redo log files are automatically deleted.
NAME:tracefile retention
VALUE:10080
DESCRIPTION:tracefile expiration specifies the duration in minutes before tracefiles in bdump are automatically deleted.

PL/SQL procedure successfully completed.
  • Les versions compatibles

Noter que pour effectuer des backup RMAN sur une base de données Oracle RDS, vous devez disposer d’une base ayant une des versions AWS suivantes :

- 11.2.0.4.v19 ou versions 11.2 supérieures

- 12.1.0.2.v15 ou versions 12.1 supérieures

- 12.2.0.1.ru-2019-01.rur-2019-01.r1 ou versions 12.2 supérieures

Sauvegarde complète

Pour effectuer une sauvegarde de type FULL DATABASE, nous utiliserons la procédure “rdsadmin.rdsadmin_rman_util.backup_database_full“.
La commande ci dessous est un exemple de backup Full de notre base CAPDATA sur le nouveau repertoire ‘BACKUP_RMAN’ créé auparavant.

set serveroutput on
BEGIN
 rdsadmin.rdsadmin_rman_util.backup_database_full(
   p_owner                 => 'SYS', 
   p_directory_name        => 'BACKUP_RMAN',
   p_parallel              => 2, 
   p_section_size_mb       => 50,
   p_rman_to_dbms_output   => TRUE);
END;
/

le mode “serveroutpt on” combiné à l’option “p_rman_to_dbms_output” nous permet d’obtenir le mode verbeux du processus, notamment la commande exacte lancée par RMAN qui est :

RUN_RMAN_CMD: /rdsdbbin/oracle/bin/rman TARGET / LOG /rdsdbdata/log/trace/rds-rman-backup-database-2019-06-21.08-59-25.417855000.txt
@/rdsdbdata/tmp/rds-rman-backup-database-2019-06-21.08-59-25.417855000.input
Recovery Manager: Release 12.1.0.2.0 - Production on Fri Jun 21 08:59:29 2019
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved.
connected to target database: CAPDATA (DBID=703110999)
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
2> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/rdsdbdata/userdirs/01/BACKUP-2019-06-21-08-59-25-%F';
3> CONFIGURE BACKUP OPTIMIZATION ON;
4> RUN {
5> ALLOCATE CHANNEL d1 DEVICE TYPE DISK FORMAT '/rdsdbdata/userdirs/01/BACKUP-2019-06-21-08-59-25-backup-%T-%U';
6> ALLOCATE CHANNEL d2 DEVICE TYPE DISK FORMAT '/rdsdbdata/userdirs/01/BACKUP-2019-06-21-08-59-25-backup-%T-%U';
7> crosscheck archivelog all;
8> BACKUP DATABASE SECTION SIZE 50M;
9> RELEASE CHANNEL d1;
10> RELEASE CHANNEL d2;
11> }
12>

Nous pourrons lire dans le Directory pour voir si les fichiers sont bien présents :

SQL> select * from table (rdsadmin.rds_file_util.listdir(p_directory => ‘BACKUP_RMAN’));

FILENAME                                                     TYPE         FILESIZE MTIME
------------------------------------------------------------ ---------- ---------- -------------------
01/                                                          directory        4096 2019/06/21 09:09:33
BACKUP-2019-06-21-08-59-25-backup-20190621-0gu4l1nu_4_1      file            49152 2019/06/21 08:59:42
BACKUP-2019-06-21-08-59-25-backup-20190621-01u4l1nk_4_1      file         45965312 2019/06/21 08:59:35
BACKUP-2019-06-21-08-59-25-backup-20190621-0gu4l1nu_6_1      file            57344 2019/06/21 08:59:42
BACKUP-2019-06-21-08-59-25-backup-20190621-02u4l1nk_1_1      file         35233792 2019/06/21 08:59:33
BACKUP-2019-06-21-08-59-25-backup-20190621-02u4l1nk_6_1      file         45842432 2019/06/21 08:59:41
BACKUP-2019-06-21-08-59-25-backup-20190621-01u4l1nk_6_1      file         49684480 2019/06/21 08:59:36
BACKUP-2019-06-21-08-59-25-backup-20190621-0mu4l1nu_2_1      file            49152 2019/06/21 08:59:42
BACKUP-2019-06-21-08-59-25-backup-20190621-0gu4l1nu_5_1      file            90112 2019/06/21 08:59:42
BACKUP-2019-06-21-08-59-25-backup-20190621-01u4l1nk_7_1      file         38756352 2019/06/21 08:59:37
BACKUP-2019-06-21-08-59-25-backup-20190621-0ou4l1nu_1_1      file          6463488 2019/06/21 08:59:42
BACKUP-2019-06-21-08-59-25-backup-20190621-0gu4l1nu_1_1      file          2351104 2019/06/21 08:59:42
BACKUP-2019-06-21-08-59-25-backup-20190621-02u4l1nk_3_1      file         42885120 2019/06/21 08:59:39
BACKUP-2019-06-21-08-59-25-backup-20190621-01u4l1nk_8_1      file         22667264 2019/06/21 08:59:38
BACKUP-2019-06-21-08-59-25-backup-20190621-0gu4l1nu_3_1      file            49152 2019/06/21 08:59:42
BACKUP-2019-06-21-08-59-25-backup-20190621-02u4l1nk_2_1      file         35938304 2019/06/21 08:59:38
BACKUP-2019-06-21-08-59-25-backup-20190621-01u4l1nk_2_1      file         33734656 2019/06/21 08:59:34
BACKUP-2019-06-21-08-59-25-backup-20190621-02u4l1nk_7_1      file         19382272 2019/06/21 08:59:42
BACKUP-2019-06-21-08-59-25-backup-20190621-01u4l1nk_5_1      file         48603136 2019/06/21 08:59:36
BACKUP-2019-06-21-08-59-25-backup-20190621-0mu4l1nu_1_1      file          6356992 2019/06/21 08:59:42
BACKUP-2019-06-21-08-59-25-backup-20190621-02u4l1nk_4_1      file         37306368 2019/06/21 08:59:40
BACKUP-2019-06-21-08-59-25-backup-20190621-0gu4l1nu_2_1      file           573440 2019/06/21 08:59:42
BACKUP-2019-06-21-08-59-25-c-703110999-20190621-00           file          8421376 2019/06/21 08:59:43
BACKUP-2019-06-21-08-59-25-backup-20190621-02u4l1nk_5_1      file         52469760 2019/06/21 08:59:40
BACKUP-2019-06-21-08-59-25-backup-20190621-01u4l1nk_3_1      file         28262400 2019/06/21 08:59:34
BACKUP-2019-06-21-08-59-25-backup-20190621-01u4l1nk_1_1      file         25346048 2019/06/21 08:59:33

On pourra également interroger la vue “v$rman_backup_job_details” habituelle pour vérifier la prise en compte de notre sauvegarde dans le controlfile :

SQL> select START_TIME,END_TIME,INPUT_BYTES/1024/1024,OUTPUT_BYTES/1024/1024,STATUS,INPUT_TYPE,ELAPSED_SECONDS/60 “Minutes”
from v$rman_backup_job_details where START_TIME > sysdate – 1 order by START_TIME;

START_TIME          END_TIME            INPUT_BYTES/1024/1024 OUTPUT_BYTES/1024/1024 STATUS                  INPUT_TYPE    Minutes
------------------- ------------------- --------------------- ---------------------- ----------------------- ------------- ----------
2019/06/21 08:59:32 2019/06/21 08:59:44              741.0625             559.164063 COMPLETED               DB FULL       .2

 

Sauvegarde incrémentale

Il sera possible d’effectuer un backup de type INCREMENTAL. Pour cela nous utiliserons la procédure “rdsadmin.rdsadmin_rman_util.backup_database_incremental“.

  • Le block change tracking

Le block change tracking pourra être activer afin d’optimiser les backup incrémentaux, nous utiliserons la procédure “rdsadmin.rdsadmin_rman_util.enable_block_change_tracking”

SQL> exec rdsadmin.rdsadmin_rman_util.enable_block_change_tracking;

PL/SQL procedure successfully completed.

SQL> select * from v$block_change_tracking;

STATUS     FILENAME                                                          BYTES     CON_ID
---------- ------------------------------------------------------------ ---------- ----------
ENABLED    /rdsdbdata/db/CAPDATA_A/changetracking/o1_mf_gjs99w4p_.chg     11599872          0

par la suite, un backup incrémental pourra être lancé.
On oubliera pas de définir le paramètre “p_level” , d’abord avec un “p_level” à 0, puis un “p_level” à 1 :

BEGIN
    rdsadmin.rdsadmin_rman_util.backup_database_incremental(
        p_owner               => 'SYS', 
        p_directory_name      => 'BACKUP_RMAN',
	p_level		      => 1,
        p_parallel            => 2,  
        p_section_size_mb     => 50,
        p_rman_to_dbms_output => TRUE);
END;
/

Comme pour la sauvegarde FULL, il sera possible d’aller voir dans le directory BACKUP_RMAN les fichiers générés, ainsi qu’interroger la vue v$rman_backup_job_details pour voir si notre sauvegarde incrémentale est bien passée. A noter que le paramètre “p_rman_to_dbms_output” à TRUE permet de voir directement à l’écran la sortie de la commande RMAN.
Grâce au block change tracking activé, on voit que, lors du passage du “p_level” 1, RMAN ne traite plus que 300Mo de blocks de données en entrée au lieu des 740Mo lors du backup full.

SQL> select START_TIME,END_TIME,INPUT_BYTES/1024/1024,OUTPUT_BYTES/1024/1024,STATUS,INPUT_TYPE,ELAPSED_SECONDS/60 "Minutes" from v$rman_backup_job_details
  2  where START_TIME > sysdate - 1 and INPUT_TYPE like '%INCR%' order by START_TIME;

START_TIME          END_TIME            INPUT_BYTES/1024/1024 OUTPUT_BYTES/1024/1024 STATUS               INPUT_TYPE       Minutes
------------------- ------------------- --------------------- ---------------------- ----------------------- ------------- ----------
2019/06/21 09:49:41 2019/06/21 09:50:06             744.40625              561.40625 COMPLETED            DB INCR          .416666667
2019/06/21 09:50:32 2019/06/21 09:50:55            300.820313               9.984375 COMPLETED            DB INCR          .383333333

 

Sauvegarde archivelogs 

Pour la sauvegarde des archivelogs, nous pourrons utiliser 4 méthodes distinctes à savoir

  • sauvegardes des archivelogs complet
  • sauvegardes des archivelogs à partir d’une plage de dates
  • sauvegardes des archivelogs à partir d’une plage de SCN
  • sauvegardes des archivelogs à partir d’une plage de séquences
La sauvegarde archivelogs complète

On lancera la procédure “backup_archivelog_all” pour cette opération :

BEGIN
    rdsadmin.rdsadmin_rman_util.backup_archivelog_all(
        p_owner               => 'SYS', 
        p_directory_name      => 'BACKUP_RMAN',
        p_parallel            => 2,  
        p_rman_to_dbms_output => TRUE);
END;
/

Pour vérifier, soit on regarde la liste des fichiers dans ‘BACKUP_RMAN’, soit on interroge la vue v$rman_backup_job_details.

SQL> select START_TIME,END_TIME,INPUT_BYTES/1024/1024,OUTPUT_BYTES/1024/1024,STATUS,INPUT_TYPE,ELAPSED_SECONDS/60 "Minutes" from v$rman_backup_job_details
  2  where START_TIME > sysdate - 1 and INPUT_TYPE like '%ARC%' order by START_TIME;

START_TIME          END_TIME            INPUT_BYTES/1024/1024 OUTPUT_BYTES/1024/1024 STATUS               INPUT_TYPE       Minutes
------------------- ------------------- --------------------- ---------------------- ----------------------- ------------- ----------
2019/06/21 10:07:55 2019/06/21 10:07:57            6.93212891             6.93701172 COMPLETED            ARCHIVELOG    .033333333
la sauvegarde archivelogs avec plage de dates

On utilisera pour cela la procédure “backup_archivelog_date” avec les paramètres ‘p_from_date’ et ‘p_to_date’ :

BEGIN
    rdsadmin.rdsadmin_rman_util.backup_archivelog_date(
        p_owner               => 'SYS', 
        p_directory_name      => 'BACKUP_RMAN',
        p_from_date           => '21/06/2019 09:00:00',
        p_to_date             => '21/06/2019 10:00:00',
        p_parallel            => 2,  
        p_rman_to_dbms_output => FALSE);
END;
/

On vérifie :

SQL> select START_TIME,END_TIME,INPUT_BYTES/1024/1024,OUTPUT_BYTES/1024/1024,STATUS,INPUT_TYPE,ELAPSED_SECONDS/60 "Minutes" from v$rman_backup_job_details
  2  where START_TIME > sysdate - 1 and INPUT_TYPE like '%ARC%' order by START_TIME;

START_TIME          END_TIME            INPUT_BYTES/1024/1024 OUTPUT_BYTES/1024/1024 STATUS               INPUT_TYPE       Minutes
------------------- ------------------- --------------------- ---------------------- ----------------------- ------------- ----------
21/06/2019 10:07:55 21/06/2019 10:07:57            6.93212891             6.93701172 COMPLETED            ARCHIVELOG    .033333333
21/06/2019 10:20:03 21/06/2019 10:20:05            6.77636719             6.78076172 COMPLETED            ARCHIVELOG    .033333333
la sauvegarde archivelogs avec plage SCN

Nous utiliserons la procédure “backup_archivelog_scn” avec les paramètres principaux ‘p_from_scn’ et ‘p_to_scn’ .
On recherchera, par exemple les derniers archivelogs générés avec les SCN associés (avec 1 h d’historique) :

SQL> select NAME,FIRST_TIME,FIRST_CHANGE# from v$archived_log where FIRST_TIME > sysdate - (1/24) order by 3;

NAME                                                         FIRST_TIME          FIRST_CHANGE#
------------------------------------------------------------ ------------------- -------------
/rdsdbdata/db/CAPDATA_A/arch/redolog-258-1-1011452844.arc    21/06/2019 11:14:42        612259
/rdsdbdata/db/CAPDATA_A/arch/redolog-259-1-1011452844.arc    21/06/2019 11:19:42        612396
/rdsdbdata/db/CAPDATA_A/arch/redolog-260-1-1011452844.arc    21/06/2019 11:24:42        612566
/rdsdbdata/db/CAPDATA_A/arch/redolog-261-1-1011452844.arc    21/06/2019 11:29:42        612706
/rdsdbdata/db/CAPDATA_A/arch/redolog-262-1-1011452844.arc    21/06/2019 11:34:40        612840
/rdsdbdata/db/CAPDATA_A/arch/redolog-263-1-1011452844.arc    21/06/2019 11:39:40        612993
/rdsdbdata/db/CAPDATA_A/arch/redolog-264-1-1011452844.arc    21/06/2019 11:44:40        613124
/rdsdbdata/db/CAPDATA_A/arch/redolog-265-1-1011452844.arc    21/06/2019 11:49:40        613257
/rdsdbdata/db/CAPDATA_A/arch/redolog-266-1-1011452844.arc    21/06/2019 11:54:40        613420
/rdsdbdata/db/CAPDATA_A/arch/redolog-267-1-1011452844.arc    21/06/2019 11:59:41        613550
/rdsdbdata/db/CAPDATA_A/arch/redolog-268-1-1011452844.arc    21/06/2019 12:04:41        613838

A partir de la, on sera libre de prendre une plage de SCN :

BEGIN
    rdsadmin.rdsadmin_rman_util.backup_archivelog_scn(
        p_owner               => 'SYS', 
        p_directory_name      => 'BACKUP_RMAN',
        p_from_scn            => 612396,
        p_to_scn              => 613550,
        p_parallel            => 2,  
        p_rman_to_dbms_output => TRUE);
END;
/

On vérifie

SQL> select START_TIME,END_TIME,INPUT_BYTES/1024/1024,OUTPUT_BYTES/1024/1024,STATUS,INPUT_TYPE,ELAPSED_SECONDS/60 "Minutes" from v$rman_backup_job_details
  2  where START_TIME > sysdate - 1 and INPUT_TYPE like '%ARC%' order by START_TIME;

START_TIME          END_TIME            INPUT_BYTES/1024/1024 OUTPUT_BYTES/1024/1024 STATUS               INPUT_TYPE       Minutes
------------------- ------------------- --------------------- ---------------------- ----------------------- ------------- ----------
21/06/2019 10:07:55 21/06/2019 10:07:57            6.93212891             6.93701172 COMPLETED            ARCHIVELOG    .033333333
21/06/2019 10:20:03 21/06/2019 10:20:05            6.77636719             6.78076172 COMPLETED            ARCHIVELOG    .033333333
21/06/2019 12:16:56 21/06/2019 12:16:58            2.36523438             2.36816406 COMPLETED            ARCHIVELOG    .033333333

 

la sauvegarde archivelogs avec plage de sequences

Comme pour la date ou le SCN, le backup RMAN avec plage de sequences s’appuiera sur un numéro de séquence d’archivelog généré. La procédure “backup_archivelog_sequence” utilisera les paramètres ‘p_from_sequence’ et ‘p_to_sequence’.

SQL> select NAME,FIRST_TIME,SEQUENCE# from v$archived_log where FIRST_TIME > sysdate – (2/24) ;

NAME                                                         FIRST_TIME           SEQUENCE#
------------------------------------------------------------ ------------------- ----------
/rdsdbdata/db/CAPDATA_A/arch/redolog-248-1-1011452844.arc    21/06/2019 10:24:40        248
/rdsdbdata/db/CAPDATA_A/arch/redolog-249-1-1011452844.arc    21/06/2019 10:29:40        249
/rdsdbdata/db/CAPDATA_A/arch/redolog-250-1-1011452844.arc    21/06/2019 10:34:40        250
/rdsdbdata/db/CAPDATA_A/arch/redolog-251-1-1011452844.arc    21/06/2019 10:39:40        251
/rdsdbdata/db/CAPDATA_A/arch/redolog-252-1-1011452844.arc    21/06/2019 10:44:40        252
/rdsdbdata/db/CAPDATA_A/arch/redolog-253-1-1011452844.arc    21/06/2019 10:49:41        253
/rdsdbdata/db/CAPDATA_A/arch/redolog-254-1-1011452844.arc    21/06/2019 10:54:41        254
/rdsdbdata/db/CAPDATA_A/arch/redolog-255-1-1011452844.arc    21/06/2019 10:59:41        255
/rdsdbdata/db/CAPDATA_A/arch/redolog-256-1-1011452844.arc    21/06/2019 11:04:41        256
/rdsdbdata/db/CAPDATA_A/arch/redolog-257-1-1011452844.arc    21/06/2019 11:09:41        257
/rdsdbdata/db/CAPDATA_A/arch/redolog-258-1-1011452844.arc    21/06/2019 11:14:42        258
/rdsdbdata/db/CAPDATA_A/arch/redolog-259-1-1011452844.arc    21/06/2019 11:19:42        259
/rdsdbdata/db/CAPDATA_A/arch/redolog-260-1-1011452844.arc    21/06/2019 11:24:42        260
/rdsdbdata/db/CAPDATA_A/arch/redolog-261-1-1011452844.arc    21/06/2019 11:29:42        261
/rdsdbdata/db/CAPDATA_A/arch/redolog-262-1-1011452844.arc    21/06/2019 11:34:40        262
/rdsdbdata/db/CAPDATA_A/arch/redolog-263-1-1011452844.arc    21/06/2019 11:39:40        263
/rdsdbdata/db/CAPDATA_A/arch/redolog-264-1-1011452844.arc    21/06/2019 11:44:40        264
/rdsdbdata/db/CAPDATA_A/arch/redolog-265-1-1011452844.arc    21/06/2019 11:49:40        265
/rdsdbdata/db/CAPDATA_A/arch/redolog-266-1-1011452844.arc    21/06/2019 11:54:40        266
/rdsdbdata/db/CAPDATA_A/arch/redolog-267-1-1011452844.arc    21/06/2019 11:59:41        267
/rdsdbdata/db/CAPDATA_A/arch/redolog-268-1-1011452844.arc    21/06/2019 12:04:41        268
/rdsdbdata/db/CAPDATA_A/arch/redolog-269-1-1011452844.arc    21/06/2019 12:09:41        269
/rdsdbdata/db/CAPDATA_A/arch/redolog-270-1-1011452844.arc    21/06/2019 12:14:41        270

L’appel à la procédure :

BEGIN
    rdsadmin.rdsadmin_rman_util.backup_archivelog_sequence(
        p_owner               => 'SYS', 
        p_directory_name      => 'BACKUP_RMAN',
        p_from_sequence       => 250,
        p_to_sequence         => 268,
        p_parallel            => 2,  
        p_rman_to_dbms_output => FALSE);
END;
/

Et le résultat :

SQL> select START_TIME,END_TIME,INPUT_BYTES/1024/1024,OUTPUT_BYTES/1024/1024,STATUS,INPUT_TYPE,ELAPSED_SECONDS/60 "Minutes" from v$rman_backup_job_details
  2  where START_TIME > sysdate - 1 and INPUT_TYPE like '%ARC%' order by START_TIME;

START_TIME          END_TIME            INPUT_BYTES/1024/1024 OUTPUT_BYTES/1024/1024 STATUS               INPUT_TYPE       Minutes
------------------- ------------------- --------------------- ---------------------- ----------------------- ------------- ----------
21/06/2019 10:07:55 21/06/2019 10:07:57            6.93212891             6.93701172 COMPLETED            ARCHIVELOG    .033333333
21/06/2019 10:20:03 21/06/2019 10:20:05            6.77636719             6.78076172 COMPLETED            ARCHIVELOG    .033333333
21/06/2019 12:16:56 21/06/2019 12:16:58            2.36523438             2.36816406 COMPLETED            ARCHIVELOG    .033333333
21/06/2019 12:25:18 21/06/2019 12:25:21            5.14501953             5.15039063 COMPLETED            ARCHIVELOG      .05

La validation

La validation des fichiers d’une base de données se fera via l’appel à la procédure “rdsadmin.rdsadmin_rman_util.validate_database”  dans laquelle nous pourrons définir des paramètres.
Soit l’on souhaite effectuer une validation par défaut, auquel cas, un simple appel à ‘exec rdsadmin.rdsadmin_rman_util.validate_database’ suffira, sinon des paramètres pourront être appelés :

BEGIN
    rdsadmin.rdsadmin_rman_util.validate_database(
        p_validation_type     => 'PHYSICAL+LOGICAL', 
        p_parallel            => 4,  
        p_section_size_mb     => 50,
        p_rman_to_dbms_output => TRUE);
END;
/

Le paramètre ‘p_rman_to_dbms_output’ est à TRUE, nous aurons donc à l’écran le rapport sur les datafiles.
Exemple  :

List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
4    OK     0              12030        12799           3792
File Name: /rdsdbdata/db/CAPDATA_A/datafile/o1_mf_users_gf76fbhb_.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data       0              0
Index      0              0
Other      0              769
channel d1: validation complete, elapsed time: 00:00:01
List of Control File and SPFILE
===============================
File Type    Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
SPFILE       OK     0              2
channel d2: validation complete, elapsed time: 00:00:01
List of Control File and SPFILE
===============================
File Type    Status Blocks Failing Blocks Examined
------------ ------ -------------- ---------------
Control File OK     0              562

 

Le rapatriement dans Amazon S3

Une fois que l’on a terminé nos sauvegardes RMAN de notre base, s’il l’on souhaite les exploiter vers une instance externe (on-prem ou EC2), nous devons les copier vers un stockage S3 par exemple. Ainsi, l’objectif sera de les envoyer de notre directory nommé ‘BACKUP_RMAN’ vers un bucket S3 que l’on appelera ‘backuprman2019’.
On peut lister les derniers backup présents sur notre directory Oracle :

SQL> select * from table(rdsadmin.rds_file_util.listdir(p_directory => 'BACKUP_RMAN')) order by 4 desc ;

FILENAME                                                     TYPE         FILESIZE MTIME
------------------------------------------------------------ ---------- ---------- -------------------
01/                                                          directory       12288 21/06/2019 12:25:20
BACKUP-2019-06-21-12-25-13-backup-20190621-3fu4ldpg_1_1      file           196096 21/06/2019 12:25:20
BACKUP-2019-06-21-12-25-13-backup-20190621-3eu4ldpe_1_1      file          2499072 21/06/2019 12:25:19
BACKUP-2019-06-21-12-25-13-backup-20190621-3du4ldpe_1_1      file          2706944 21/06/2019 12:25:19
BACKUP-2019-06-21-12-16-51-backup-20190621-3cu4ld9p_1_1      file           132608 21/06/2019 12:16:57
BACKUP-2019-06-21-12-16-51-backup-20190621-3bu4ld9p_1_1      file          2351616 21/06/2019 12:16:57
BACKUP-2019-06-21-10-19-57-backup-20190621-3au4l6ek_1_1      file           382976 21/06/2019 10:20:04
BACKUP-2019-06-21-10-19-57-backup-20190621-38u4l6ej_1_1      file          3680256 21/06/2019 10:20:03
BACKUP-2019-06-21-10-19-57-backup-20190621-39u4l6ej_1_1      file          3048448 21/06/2019 10:20:03
BACKUP-2019-06-21-10-07-50-backup-20190621-36u4l5ns_1_1      file          3429888 21/06/2019 10:07:56
BACKUP-2019-06-21-10-07-50-backup-20190621-35u4l5ns_1_1      file          3731456 21/06/2019 10:07:56
BACKUP-2019-06-21-10-07-50-backup-20190621-37u4l5ns_1_1      file           114176 21/06/2019 10:07:56
BACKUP-2019-06-21-09-50-27-c-703110999-20190621-03           file          9306112 21/06/2019 09:50:55
BACKUP-2019-06-21-09-50-27-backup-20190621-33u4l4nr_1_1      file            40960 21/06/2019 09:50:53
BACKUP-2019-06-21-09-50-27-backup-20190621-31u4l4nq_2_1      file            40960 21/06/2019 09:50:52
BACKUP-2019-06-21-09-50-27-backup-20190621-31u4l4nq_1_1      file            40960 21/06/2019 09:50:51
BACKUP-2019-06-21-09-50-27-backup-20190621-2ru4l4nl_6_1      file            40960 21/06/2019 09:50:51
.........

Ce seront ces fichiers qui devront être transférés vers notre nouveau bucket S3 backuprman2019.

La partie configuration AWS

Cette partie devra être réalisée une seule fois afin de prendre en charge les échanges entre les services bases de données RDS et Amazon S3.
On suppose que l’utilisateur aura le rôle adéquat afin de manipuler les services IAM, RDS et S3, ou que la machine EC2 aura ce rôle.
Pour plus d’informations, il faudra configurer aws cli via “aws configure”. La configuration des étapes ci dessous passera par l’outil aws cli.

  • Le bucket

Tout d’abord, nous allons créer ce nouveau bucket. ATTENTION, il faudra bien ajouter l’option “–create-backup-configuration LocationContraint” avec la région souhaitée (Ici Paris) car sinon, par défaut, le bucket est créé sur la région ‘eu-east-1’.

C:\ aws s3api create-bucket –bucket backuprman2019 –region eu-west-3 –create-bucket-configuration LocationConstraint=eu-west-3
{
“Location”: “http://backuprman2019.s3.amazonaws.com/”
}

  • La policy pour le bucket S3

Il s’agira maintenant d’autoriser la base RDS à accéder au bucket S3 nouvellement créé. Pour cela, il faudra définir une nouvelle stratégie, puis un nouveau rôle.
On utilisera le nom ARN de notre bucket on nommera notre policy ‘rds-s3-backup-policy‘.

Pour définir la nouvelle policy, le mieux sera de la créer dans un fichier ‘policy-rds.json‘ et l’appeler par la suite avec aws cli.
Le fichier json comportera l’entrée suivante :

{
     "Version": "2012-10-17",
     "Statement": [
       {
         "Sid": "s3integration",
         "Action": [
           "s3:GetObject",
           "s3:ListBucket",
           "s3:PutObject"
         ],
         "Effect": "Allow",
         "Resource": [
           "arn:aws:s3:::backuprman2019", 
           "arn:aws:s3:::backuprman2019/*"
         ]
       }
     ]
   }

Puis avec l’aws cli

C:\ aws iam create-policy --policy-name rds-s3-backup-policy --policy-document file://policy-rds.json
{
    "Policy": {
        "PolicyName": "rds-s3-backup-policy",
        "PermissionsBoundaryUsageCount": 0,
        "CreateDate": "2019-06-21T13:35:33Z",
        "AttachmentCount": 0,
        "IsAttachable": true,
        "PolicyId": "ANPAQIMXBNKBLEYWLTCIH",
        "DefaultVersionId": "v1",
        "Path": "/",
        "Arn": "arn:aws:iam::018033502850:policy/rds-s3-backup-policy",
        "UpdateDate": "2019-06-21T13:35:33Z"
    }
}

Notons le nom ARN de notre policy : arn:aws:iam::018033502850:policy/rds-s3-backup-policy

  • Le rôle IAM pour approbation

Ensuite, il faudra créer un rôle qui aurait pour but d’effectuer une relation d’approbation entre Amazon RDS et le bucket S3.
Nous passerons également par un fichier json nommé ‘rds-s3-approb.json‘ sous la forme suivante :

{
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
            "Service": "rds.amazonaws.com"
          },
         "Action": "sts:AssumeRole"
       }
     ]
   }  

L’appel de aws cli :

C:\ aws iam create-role --role-name rds-s3-approb-role --assume-role-policy-document file://rds-s3-approb.json
{
    "Role": {
        "AssumeRolePolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Action": "sts:AssumeRole",
                    "Effect": "Allow",
                    "Principal": {
                        "Service": "rds.amazonaws.com"
                    }
                }
            ]
        },
        "RoleId": "AROAQIMXBNKBLRYFQ3BT7",
        "CreateDate": "2019-06-21T13:50:24Z",
        "RoleName": "rds-s3-approb-role",
        "Path": "/",
        "Arn": "arn:aws:iam::018033502850:role/rds-s3-approb-role"
    }
}

On note également l’ARN de ce rôle : arn:aws:iam::018033502850:role/rds-s3-approb-role

La stratégie créée devra être attaché au rôle :

C:\ aws iam attach-role-policy --policy-arn arn:aws:iam::018033502850:policy/rds-s3-backup-policy --role-name rds-s3-approb-role

  • Le rôle pour l’instance RDS

Nous allons enregistrer l’instance capdata avec le rôle ‘rds-s3-approb-role’ que nous avons créé juste avant. Utiliser l’ARN du rôle pour cela.

C:\ aws rds add-role-to-db-instance --db-instance-identifier capdata --feature-name S3_INTEGRATION --role-arn arn:aws:iam::018033502850:role/rds-s3-approb-role

La feature_name S3_INTEGRATION est le nom générique pour l’option propre à ce rôle. Celui ci ne devra pas être changé.

 

  • le groupe d’options RDS

La prochaine étape consiste à modifier le groupe d’options enregistré pour l’instance Oracle RDS que nous avons créé.
Comme nous ne pourrons changer le groupe d’option par défaut, il faudra en créer un nouveau et l’affecter à notre instance capdata.
On crée le groupe d’options nommé ‘capdata-121-optionsgroup’ pour la version Enterprise Edition du moteur 12.1.

C:\ aws rds create-option-group --option-group-name capdata-121-optiongroup --engine-name oracle-ee --major-engine-version 12.1 --option-group-description "Option groupe pour capdata"
{
    "OptionGroup": {
        "OptionGroupName": "capdata-121-optiongroup",
        "OptionGroupDescription": "Option groupe pour capdata",
        "EngineName": "oracle-ee",
        "MajorEngineVersion": "12.1",
        "Options": [],
        "AllowsVpcAndNonVpcInstanceMemberships": true,
        "OptionGroupArn": "arn:aws:rds:eu-west-3:018033502850:og:capdata-121-optiongroup"
    }
}


L’instance devra prendre en compte ce nouveau groupe d’options :

C:\ aws rds modify-db-instance --db-instance-identifier capdata --option-group-name "capdata-121-optiongroup"  --apply-immediately

Cette caractéristique sera nécessaire parmi les informations retournées par la commande :

       "OptionGroupMemberships": [
           {
               "OptionGroupName": "capdata-121-optiongroup",
               "Status": "pending-apply"
           },
           {
               "OptionGroupName": "default:oracle-ee-12-1",
               "Status": "pending-removal"
           }
       ],

On valider la prise en compte avec l’instruction “describe-db-instances

C:\ aws rds describe-db-instances --db-instance-identifier capdata --query "DBInstances[*].[OptionGroupMemberships]"
[
    [
        [
            {
                "OptionGroupName": "capdata-121-optiongroup",
                "Status": "in-sync"
            }
        ]
    ]
]

A partir de la, on peut affecter à notre groupe d’options l’option propre

C:\ aws rds add-option-to-option-group --option-group-name "capdata-121-optiongroup" --options OptionName=S3_INTEGRATION,OptionVersion=1.0
{
    "OptionGroup": {
        "OptionGroupName": "capdata-121-optiongroup",
        "OptionGroupDescription": "Option groupe pour capdata",
        "EngineName": "oracle-ee",
        "MajorEngineVersion": "12.1",
        "Options": [
            {
                "OptionName": "S3_INTEGRATION",
                "OptionDescription": "Enables S3_INTEGRATION for data ingestion",
                "Persistent": false,
                "Permanent": false,
                "OptionVersion": "1.0",
                "OptionSettings": [],
                "DBSecurityGroupMemberships": [],
                "VpcSecurityGroupMemberships": []
            }
        ],
        "AllowsVpcAndNonVpcInstanceMemberships": false,
        "VpcId": "vpc-09c93b8bac48a99ff",
        "OptionGroupArn": "arn:aws:rds:eu-west-3:018033502850:og:capdata-121-optiongroup"
    }
}

Copie des backup RMAN vers S3

Une fois ces pre requis validés, nous pourrons effectuer les copies de fichiers backup RMAN vers le bucket S3 ‘capdatarman2019’.
C’est la fonction “rdsadmin.rdsadmin_s3_tasks.upload_to_s3” qui permettra de faire cette opération avec, en paramètres, les valeurs suivantes :

  • p_bucket_name : le nom du bucket S3
  • p_directory_name : le nom du directory Oracle
  • p_s3_prefix : le préfixe des noms de fichiers présents dans S3
  • p_prefix : le préfixe des noms de fichiers présents dans le directory

Exemple, nous voulons rapatrier tous les fichiers prefixés par ‘BACKUP-2019-06-21%’ depuis le directory BACKUP_RMAN vers le bucket S3 ‘backuprman2019’ :

SQL > SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3(p_bucket_name => 'backuprman2019', p_prefix => 'BACKUP', p_s3_prefix  => '', 
  p_directory_name =>  'BACKUP_RMAN') AS TASK_ID 
  FROM DUAL;

Ce qui donne un task id, de la forme :

TASK_ID
———————————————-
1561389117542-1872

Nous pourrons suivre l’évolution de la tâche en interrogeant directement le bucket s3 :

C:\ aws s3 ls s3://backuprman2019
2019-06-24 15:12:04   25673728 BACKUP-2019-06-24-15-06-15-backup-20190624-01u4tkbd_1_1
2019-06-24 15:12:14   33734656 BACKUP-2019-06-24-15-06-15-backup-20190624-01u4tkbd_2_1
2019-06-24 15:12:12   28262400 BACKUP-2019-06-24-15-06-15-backup-20190624-01u4tkbd_3_1
2019-06-24 15:12:09   45981696 BACKUP-2019-06-24-15-06-15-backup-20190624-01u4tkbd_4_1
2019-06-24 15:12:16   48603136 BACKUP-2019-06-24-15-06-15-backup-20190624-01u4tkbd_5_1
2019-06-24 15:12:08   49684480 BACKUP-2019-06-24-15-06-15-backup-20190624-01u4tkbd_6_1
2019-06-24 15:12:15   38723584 BACKUP-2019-06-24-15-06-15-backup-20190624-01u4tkbd_7_1
2019-06-24 15:12:07   13762560 BACKUP-2019-06-24-15-06-15-backup-20190624-01u4tkbd_8_1
2019-06-24 15:12:02   34521088 BACKUP-2019-06-24-15-06-15-backup-20190624-02u4tkbd_1_1
2019-06-24 15:12:14   35414016 BACKUP-2019-06-24-15-06-15-backup-20190624-02u4tkbd_2_1
2019-06-24 15:12:13   42885120 BACKUP-2019-06-24-15-06-15-backup-20190624-02u4tkbd_3_1
2019-06-24 15:12:10   37306368 BACKUP-2019-06-24-15-06-15-backup-20190624-02u4tkbd_4_1
2019-06-24 15:11:58   52469760 BACKUP-2019-06-24-15-06-15-backup-20190624-02u4tkbd_5_1
2019-06-24 15:12:07   42541056 BACKUP-2019-06-24-15-06-15-backup-20190624-02u4tkbd_6_1
2019-06-24 15:12:14      49152 BACKUP-2019-06-24-15-06-15-backup-20190624-02u4tkbd_7_1
2019-06-24 15:12:08   52461568 BACKUP-2019-06-24-15-06-15-backup-20190624-0gu4tkbm_1_1
......

ou via la procédure “rdsadmin.rds_file_util.read_text_file”  avec le log dans le répertoire BDUMP :

SQL> select text from table(rdsadmin.rds_file_util.read_text_file('BDUMP','dbtask-1561389117542-1872.log'));

TEXT
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2019-06-24 15:11:57.621 UTC [INFO ] File #1: Uploading the file /rdsdbdata/userdirs/01/BACKUP-2019-06-24-15-06-15-backup-20190624-02u4tkbd_5_1 to Amazon S3 with bucket name backuprman2019 an
d key BACKUP-2019-06-24-15-06-15-backup-20190624-02u4tkbd_5_1.

2019-06-24 15:11:58.384 UTC [INFO ] The file /rdsdbdata/userdirs/01/BACKUP-2019-06-24-15-06-15-backup-20190624-02u4tkbd_5_1 was uploaded to Amazon S3 with bucket name backuprman2019 and key
BACKUP-2019-06-24-15-06-15-backup-20190624-02u4tkbd_5_1.

2019-06-24 15:11:58.384 UTC [INFO ] File #2: Uploading the file /rdsdbdata/userdirs/01/BACKUP-2019-06-24-15-09-19-backup-20190624-0ru4tkh4_1_1 to Amazon S3 with bucket name backuprman2019 an
d key BACKUP-2019-06-24-15-09-19-backup-20190624-0ru4tkh4_1_1.

2019-06-24 15:11:58.779 UTC [INFO ] The file /rdsdbdata/userdirs/01/BACKUP-2019-06-24-15-09-19-backup-20190624-0ru4tkh4_1_1 was uploaded to Amazon S3 with bucket name backuprman2019 and key
BACKUP-2019-06-24-15-09-19-backup-20190624-0ru4tkh4_1_1.

2019-06-24 15:11:58.780 UTC [INFO ] File #3: Uploading the file /rdsdbdata/userdirs/01/BACKUP-2019-06-24-15-09-19-backup-20190624-19u4tkhk_1_1 to Amazon S3 with bucket name backuprman2019 an
d key BACKUP-2019-06-24-15-09-19-backup-20190624-19u4tkhk_1_1.

…. 

le log de fin se terminant par

2019-06-24 15:12:15.831 UTC [INFO ] The task finished successfully.

105 rows selected.

 

Une fois sur s3, il sera possible de rapatrier sur un EC2, ou un serveur “on premise” les fichiers RMAN composant cette base RDS.

Cordialement

 

Emmanuel RAMI

 

 

Continuez votre lecture sur le blog :

twitterlinkedinmail

Emmanuel RAMI

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.