SelectEtoile : Base de connaissance SGBD

Posts Tagged 'undo'

Gestion des UNDO Tablespaces

 

Contexte

Les segments d’annulations (undo segments) sont utilisés principalement dans les cas suivants :

            => Annulation d'une transaction (permettant de restaurer la valeur d'origine à partir des undo segments qui contiennent l'image de la valeur d'origine)

            => Récupération de transaction (sur échec et réouverture de base permettant une restauration des transactions non validées contenues dans les redo log)

            => Cohérence en lecture (permettant aux autres utilisateurs de consulter les valeurs contenues dans les undo segments pour les transactions non validées)

            => par les flashback queries (permettant d’avoir une image des données telles quelle étaient dans le temps - en se basant sur une date ou sur un SCN)

Il y a 3 types de undo segments (cas du mode Automatic Undo Management) :

            - ACTIVE : utilisé par une transaction en cours,

            - UNEXPIRED : plus actif mais qui contient des données potentiellement utilisables par les flash-back queries,

            - EXPIRED : hors de la période de rétention. Oracle les garde quand même, au cas où (réutilisation sur une base LRU)

Quand il y a un besoin d'extent dans le tablespace de UNDO :

            a) Oracle essaie d'abord de s'allouer de l'espace libre

            b) s'il n'y en a plus tape dans EXPIRED

            c) s'il n'y en a plus tape dans UNEXPIRED

            d) s'il n'y en a plus panique.

b) compromet les flash-back queries, mais pas dans la période de rétention.

En revanche c) compromet non seulement les flashback queries dans la période de rétention mais devient également un risque d'ORA-01555 (snapshot too old)

Enfin d) peut être bloquant pour la base.

 

 

Objectif

Contrôle de la répartition des undo segments :

select status, round(sum(bytes)/1024/1024,0) "SIZE (M)"  from dba_undo_extents group by status

Identification et suivi de l’activité UNDO par rapport à une session :

SELECT rn.name "Rollback Segment Name",

                        rs.xacts "Active Transactions" ,

                        t.used_ublk "Nb Used Blocs",

t.start_time "Start time",

                        s.username ||' ('|| s.sid|| ',' || s.serial# ||')' "DB User (SID, SERIAL#)",

                        p.spid "Process ID",

                        s.osuser "OS User", s.machine "Machine", s.program "Program"

            FROM v$rollname rn,v$rollstat rs, v$transaction t, v$session s, v$process p

            WHERE rn.usn = rs.usn and

                        rs.usn = t.xidusn and

                        s.taddr = t.addr and

                        s.paddr = p.addr

            ORDER BY 1

Identification et suivi de l’activité UNDO par rapport à une requête :

SELECT rn.name "Rollback Segment Name",

                        rs.xacts "Active Transactions" ,

                        t.used_ublk "Nb Used Blocs",

                        s.username ||' ('|| s.sid|| ',' || s.serial# ||')' "DB User (SID, SERIAL#)",

                        sq.sql_text "SQL Text", p.spid "Process ID",

                        s.osuser "OS User", s.machine "Machine", s.program "Program"

            FROM v$rollname rn,v$rollstat rs, v$transaction t, v$session s,v$sqlarea sq, v$process p

            WHERE rn.usn = rs.usn and

                        rs.usn = t.xidusn and

                        s.taddr = t.addr and

                        s.sql_address = sq.address(+) and

                        s.sql_hash_value = sq.hash_value(+) and

                        s.paddr = p.addr

            ORDER BY 1

 

 

Bug existant :

A noter un important bug 5387030 - Automatic tuning of undo_retention causes unusual extra space allocation, dont voici un extrait de l’article Métalink  :

When undo tablespace is using NON-AUTOEXTEND datafiles, V$UNDOSTAT.TUNED_UNDORETENTION may be calculated too high preventing undo block from being expired and reused. In extreme cases the undo tablespace could be filled to capacity by these unexpired blocks.

An alert may be posted on DBA_ALERT_HISTORY that advises to increase the space when it is not really necessary if this fix is applied.

If the user sets their own alert thresholds for undo tablespaces the bug may prevent alerts from being produced.

Workaround:

alter system set "_smu_debug_mode" = 33554432;

This causes the v$undostat.tuned_undoretention to be calculated as the maximum of:

- maxquerylen secs + 300

- undo_retention specified in init.ora

Articles tagged

Temps de recouvrement d'une base

 

Il faut d’abord bien comprendre que lorsqu’un utilisateur, insert, modifie ou supprime des données, seul le journal de transaction est écrit immédiatement sur le disque. Les données modifiées sont écrites dans le cache d’ASE. Pour des raisons de performance, leurs écritures sur disque sont différées. C’est le processus checkpoint ou la commande checkpoint qui provoque l’écriture des données modifiés en cache sur disque. C’est ce même processus qui déplace le point de troncature pour permettre la purge du journal de transactions.

 

Si le serveur est arrêté avec « un arrêt immédiat » (On fige le journal de transaction en l’état, il n’y a pas de checkpoint ni de purge) ou alors suite à un arrêt brutal, les données modifiées en cache qui ne sont pas écrites sur disque sont flashées. Lorsque le serveur redémarre, il va rechercher ces données en se basant sur le journal de transaction.

 

Pour réaliser cette tache le serveur se lance dans un processus de  recovery de la base qui se décompose en trois étapes :

  • Analyse : C’est la lecture du journal de transaction afin de construire les taches à effectuer dans le REDO PASS et le UNDO PASS.
  • Redo Pass : C’est l’écriture des données, des transactions validées, sur disque
  • Undo Pass : C’est l’annulation des transactions qui n’ont pas abouties ou bien qui étaient marquées comme à défaire.

 

 

Donc selon la périodicité des checkpoints et le taille du journal de transaction, l’étape de REDO peut-être très longue.

Error 3475 during recovery

Quand on détecte l'erreur 3475 dans l'errorlog durant le recovery d'une base, le serveur marquera cette base à 'not recovered' et la gardera offline (La base peut avoir le status 64 ou 68 dans sysdatabases)


Il est nécessaire de bypasser le recovery et d'augmenter le journal de transaction


Pour cela, suivre la procédure suivante :

- faire un update de la table sysdatabases et positionner le status de la base à -32768 (garder en mémoire la valeur de la colonne status avant modification)
- faire un 'checkpoint' sur la base master
- Lancer un 'shutdown with nowait'
- redémarrer le server (il ne va pas faire de recovery sur la base en question)
- Ajouter le ou les devices de logs
- Faire un update sur sysdatabases en remettant la valeur sauvegardée au début.
- Faire checkpoint in master
- Rebooter un derniere fois le serveur SYBASE.

Maintenant, le recovery devrait se faire sans problème.