Sur proposition de mon ami Mohamed El-Yazid Boubidi, voici un article intéressant sur le paramétrage de la fonctionnalité UNDO de la base de données Oracle.

En effet, à partir de Oracle9i, les rollback segments sont rebaptisés "journaux d'annulations".

Traditionnellement les informations d'annulation des transaction sont stockés dans des rollback segments jusqu'à ce qu'une instruction COMMIT ou ROLLBACK soit exécutée, et à partir de ce moment, ces segments sont disponibles pour être réutilisés.

En plus, avec la gestion automatique des annulations (apparue en 10g), le DBA peut spécifier une durée de conservation supplémentaire des informations d'annulation après le COMMIT, afin d'éviter les erreurs de type "snapshot too old" sur les longues instructions.

Ceci est fait en définissant le paramètre UNDO_RETENTION. Sa valeur par défaut étant de 900 secondes (5 minutes), vous pouvez le modifier afin de garantir qu’Oracle conserve les journaux d'annulations pour des périodes plus longues. Vous devrez peut-être aussi garantir que cette durée de conservation soit respectée, et ceci en activant l’option "GARANTI" du tablespace UNDO.

Toutefois, il convient d'ajuster les paramètres importants suivants :

1 - La taille du tablespace UNDO

2 - Le paramètres d'initialisation UNDO_RETENTION

1. Calculer le UNDO_RETENTION pour une certaine taille du tablespace UNDO :

Vous pouvez choisir d'affecter une taille spécifique pour le tablespace UNDO, puis de définir le paramètre UNDO_RETENTION sur une valeur optimale en fonction de cette taille et de l'activité de votre base de données. C’est la façon de faire si votre espace disque est limité et que vous ne pouvez pas allouer plus d'espace pour le tablespace UNDO. La formule suivante vous aidera à optimiser ce paramètre :

Utilisez les instructions suivantes pour déterminer les valeurs actuelles (ces requêtes utilisent les statistiques de v$UNDOSTAT, exécutez les après avoir utilisé le UNDO pendant une période représentative).

Pour déterminer la taille actuelle du UNDO :

SELECT SUM(a.bytes) "UNDO_SIZE" FROM v$datafile a, v$tablespace b, dba_tablespaces c

WHERE c.contents = 'UNDO' AND c.status = 'ONLINE' AND b.name = c.tablespace_name AND a.ts# = b.ts#;

UNDO_SIZE

---------------

209 715 200

Pour déterminer le nombre de blocs UNDO générés par seconde :

SELECT MAX(undoblks/((end_time-begin_time)*3600*24)) "UNDO_BLOCK_PER_SEC"

FROM v$undostat;

UNDO_BLOCK_PER_SEC

--------------------------------

3,12166667

Pour déterminer la taille des blocks de base de données :

SELECT TO_NUMBER(value) "DB_BLOCK_SIZE (Byte)" FROM v$parameter

WHERE name = 'db_block_size';

DB_BLOCK_SIZE (Byte)

-----------------------------

4 096

En applicant la formule citée ci-dessus, le temps de conservation optimal sera le suivant :

209 715 200 / (3.12166667 * 4 096) = 16 401 (Sec)   soit environ 4h30.

On peut aussi obtenir le même résultat en une seule requête :

SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE (MB)", SUBSTR(e.value,1,25) "UNDO RETENTION (Sec)",

        ROUND((d.undo_size / (to_number(f.value) * g.undo_block_per_sec))) "OPTIMAL UNDO RETENTION (Sec)"

FROM

      ( SELECT SUM(a.bytes) undo_size

        FROM v$datafile a, v$tablespace b, dba_tablespaces c

        WHERE c.contents = 'UNDO' AND c.status = 'ONLINE' AND b.name = c.tablespace_name AND a.ts# = b.ts#) d,

        v$parameter e,

        v$parameter f,

      ( SELECT MAX(undoblks/((end_time-begin_time)*3600*24)) undo_block_per_sec

        FROM v$undostat) g

WHERE e.name = 'undo_retention' AND f.name = 'db_block_size' ;

ACTUAL UNDO SIZE (MB)        UNDO RETENTION (Sec)        OPTIMAL UNDO RETENTION (Sec)

-------------------------------------------------------------------------------------------------------------------------

200                                           10800                                     16401

2. Calculer l taille du tablespace UNDO nécessaire pour supporter l'activité de la base de données :

Si vous n'êtes pas limité par l'espace disque, alors il serait préférable de choisir une durée UNDO_RETENTION qui convienne mieux (pour utiliser le FLASHBACK par exemple). Allouer la taille appropriée pour le tablespace UNDO en fonction de l'activité de la base de données :

Avec la requête suivante, on obtient :

SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE (MB)", SUBSTR(e.value,1,25) "UNDO RETENTION (Sec)",

      (TO_NUMBER(e.value) * TO_NUMBER(f.value) * g.undo_block_per_sec) / (1024*1024)
"NEEDED UNDO SIZE (MB)"

FROM

     ( SELECT SUM(a.bytes) undo_size FROM v$datafile a, v$tablespace b, dba_tablespaces c

       WHERE c.contents = 'UNDO' AND c.status = 'ONLINE' AND b.name = c.tablespace_name AND 
       a.ts# = b.ts# ) d,

      v$parameter e,

      v$parameter f,

   ( SELECT MAX(undoblks/((end_time-begin_time)*3600*24)) undo_block_per_sec FROM
     v$undostat ) g

WHERE e.name = 'undo_retention' AND f.name = 'db_block_size'

ACTUAL UNDO SIZE (MB)        UNDO RETENTION (Sec)        NEEDED UNDO SIZE (MB)

--------------------------------------------------------------------------------------------------------------

200                                           10800                                     131,695313

La requête précédente peut renvoyer un "NEEDED UNDO SIZE" inférieur à la taille actuel du UNDO. Si tel est le cas, vous gaspillez peut être de l'espace. Vous pouvez réduire la taille de votre tablespace UNDO ou augmenter votre paramètre UNDO_RETENTION pour utiliser l'espace supplémentaire.

Oraclement votre.

Bonjour,

De part mon métier, j'ai eu souvent à rencontrer des DBA's qui n'utilisent pas RMAN pour leurs sauvegardes/récupérations, mais plustôt les outils d'export/import, ou le plus souvent encore, des scripts OS qui nécessitent l'arrêt de la BD (appelés scripts UMB pour User Managed Backup).

En général, ils ont hérités ces comportement des anciens DBA's qui les ont précédé, et tant que ça marche, pourquoi changer ?

Voici donc quelques raisons pour les inciter à faire le pas, et les faire entrer dans le monde "merveilleux" de RMAN :

1) C'est d'abord un standard. Il est bien documenté et bien testé.

2) Il est simple à utiliser, tunnable et surveillable. Pourquoi alors se compliquer la vie ?

3) Plusieurs fonctionalités non disponibles avec les scripts UMB : Récupération au niveau DB, Tablespace, Table et Bloc ; Validation des backups ; Vérification des corruptions de blocs ; Duplication et clonage ...

4) Plusieurs nouvelles fonctionnalités en 10g : Incremental Backups, Block Media Recovery, Unused Block Compression, "in-place" Encryption and Compression, ASM Support, ...

5) Autres nouveautés en 11g : prise en charge de Data Recovery Advisor (DRA), à travers les commandes SHOW FAILURE, ADVISE FAILURE et REPAIR FAILURE.

6) C'est l'outils de récupération pas excellence (I s'appelle Recovery Manager et non Backup Manager) écrit par les développeurs Oracle pour les BD Oracle.

7) RMAN garde l'historique des sauvegardes dans son catalogue, et sais comment les gérer.

8) RMAN peut-être utilisé pour des récupérations complètes ou incomplètes.

9) RMAN permet d'exécuter la plupart des commandes SQL. Donc plus besoin de d'utiliser plusieurs outils.

10) Enfin, RMAN possède des commades importantes, qui n'existent pas en SQL, tels que : SET NEWNAME FOR DATABASE, DBNEWID, ...

J'espère qu'avec tous cela, vous êtes convaincus de la nécessité d'utiliser cet outil et de ses nombreux avantages. Alors profitez-en, c'est gratuit ;-)

Oraclement votre.