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-roleLa 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 :
- AWS : Backup Restore SQL Server RDS vers une EC2 ou On-Premise et vice versa ! (Emmanuel RAMI) [AWSSQL Server]
- Oracle RDS : récupérer les tracefiles, comment faire ? (Emmanuel RAMI) [AWSOracle]
- Réplication MySQL : Resynchronisation d’un Slave MySQL (Capdata team) [MySQL]
- Utiliser ASMCMD (Capdata team) [OracleVintage]
- AWS Oracle RDS Read Replicas : un Active Dataguard en mode PaaS ? (Emmanuel RAMI) [AWSNon classéOracle]