KESAKO ?Depuis la version 10, Oracle nous nourrit de nouvelles fonctionnalités fort intéressantes au niveau des sauvegardes / options de récupérations...
La Flashback Recovery Area (FRA pour les intimes) est souvent utilisée. Il s'agit d'un volume que l'on doit spécifier... mais comment justement gérer et vérifier l'utilisation de ce volume ?
Note : je travaille sur un environnement RAC, donc je fais parfois appel aux vues GV$... si tel n'est pas votre cas, corrigez en remplaçant le GV$ par V$ et, dans les ordres ALTER SYSTEM, supprimez les clauses sid='*'.
Activation
On détermine un volume distinct et on lui attribue une taille maximale. Optionnellement, on active ensuite le flashback DB : depuis la version 11, cette activation peut se faire base ouverte.
| Code SQL : | Sélectionner tout |
1 2 3 | ALTER SYSTEM SET db_recovery_file_dest='+ORA_DVP_FRA' scope=both sid='*' ; ALTER SYSTEM SET db_recovery_file_dest_size=10G scope=both sid='*' ; ALTER DATABASE FLASHBACK ON ; |
Une petite requête pour déterminer notre besoin de taille pour les archivelogs, par jour
| Code SQL : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | SELECT trunc(first_time) JOURS, sum((blocks+1)*block_size)/1024/1024/1024 TAILLE_GO, count(*) NBR_FICHIERS FROM gv$archived_log GROUP BY trunc(first_time) ORDER BY trunc(first_time) DESC ; JOURS TAILLE_GO NBR_FICHIERS ------------------- ----------- ------------ 09.10.2017 00:00:00 8.97 110 15.10.2017 00:00:00 160.27 1506 16.10.2017 00:00:00 8.50 104 17.10.2017 00:00:00 33.72 322 18.10.2017 00:00:00 6.95 98 07.10.2017 00:00:00 16.88 172 08.10.2017 00:00:00 5.25 62 13.10.2017 00:00:00 8.87 102 05.10.2017 00:00:00 9.41 106 06.10.2017 00:00:00 9.37 116 19.10.2017 00:00:00 16.44 162 10.10.2017 00:00:00 8.24 106 11.10.2017 00:00:00 19.95 198 12.10.2017 00:00:00 22.02 200 20.10.2017 00:00:00 2.76 36 14.10.2017 00:00:00 18.53 184 |
En d'autres termes, rien que pour la partie des archivelogs, il me faut compter sur 250 Go d'espace pour tenir trois jours... ou alors je dois m'assurer que le besoin du 15.10.2017 était exceptionnel...
Lorsqu'elle est activée, la FRA va se purger quand elle peut, ceci souvent en adéquation avec votre politique de backup (rman retention policy). Si vous déterminez que vos backups prennent place en FRA, que vous les maintenez trois jours, il vaut que le volume soit suffisant. Si tel n'est pas le cas, vous allez geler votre base de données avec le désormais célèbre message ORA-19809: limit exceeded for recovery files
Désactivation
Lorsque la FRA est totalement pleine, la base gèle, et il est souvent stressant de libérer les espaces nécessaires lorsque la production n'est plus en état. C'est pour cette raison que je taille toujours ma FRA 10 Go en dessous de la taille du volume sous-jacent, ceci afin de me laisser du champ au cas où, malgré toutes mes précautions, je me retrouverais en situation de crise : il est toujours plus rapide de lui redonner ces 10 Go que de devoir attendre de nouveaux espaces de stockage...
La désactivation de la FRA se fait en lui désattribuant son volume.
| Code SQL : | Sélectionner tout |
1 2 | ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '' scope=both sid='*'; ALTER DATABASE FLASHBACK OFF; |
Monitoring
Lorsque le volume est spécifié et la base utilisée, deux tables vont nous être utiles : je vous transmets ici deux requêtes un peu plus parlantes :
Pour déterminer le volume utilisé réellement par rapport au volume défini par db_recovery_file_dest_size
| Code SQL : | Sélectionner tout |
1 2 3 4 5 6 | SELECT space_limit/1024/1024/1024 LIMITE_GO, SPACE_USED/1024/1024/1024 UTILISE FROM V$RECOVERY_FILE_DEST; LIMITE_GO UTILISE ------------- ---------- 180 97.9775391 |
Et, plus spécifiquement, le pourcentage utilisé pour chacune des options possibles
| Code SQL : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | SELECT * FROM V$RECOVERY_AREA_USAGE; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES -------------------- ------------------ ------------------------- --------------- CONTROL FILE 0 0 0 REDO LOG 0 0 0 ARCHIVED LOG 6.56 6.4 131 BACKUP PIECE 0 0 0 IMAGE COPY 0 0 0 FLASHBACK LOG 47.87 26.28 439 FOREIGN ARCHIVED LOG 0 0 0 |
La même chose, mais en taille :
| Code SQL : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 | SELECT u.FILE_TYPE, u.NUMBER_OF_FILES FICHIERS, d.space_limit/1024/1024/1024/100*PERCENT_SPACE_USED UTILISE FROM V$RECOVERY_AREA_USAGE U, V$RECOVERY_FILE_DEST D; FILE_TYPE FICHIERS UTILISE -------------------- ---------- ---------- CONTROL FILE 0 0 REDO LOG 0 0 ARCHIVED LOG 129 11.646 BACKUP PIECE 0 0 IMAGE COPY 0 0 FLASHBACK LOG 439 86.166 FOREIGN ARCHIVED LOG 0 0 |
... - J'utilise moins de 50 % de la taille que je me suis fait allouer...
- Mes backups sont faits sur bandes, donc n'apparaissent pas dans la FRA (ce qui me permet de maintenir une FRA pas trop énorme)
- Mes redo logs et mes control files sont stockés hors FRA
- Je n'utilise pas de réplication, donc pas d'archivelogs étrangers
- J'utilise le flashback database
Dans cette situation bien précise, il va donc falloir que je prenne économiquement une décision :
- soit je continue à travailler de la sorte, et je rends 40 % de la place allouée, en réduisant alors mon volume FRA dans ASM ;
- soit j'utilise plus optimalement ma FRA en y déposant, entre autres, des copies de mes fichiers de contrôle, un membre de chacun de mes redo...