[eBs 11.5.9] Undo tablespace offline [Résolu]

[guigui_cwoco]

Bonjour,

Sur notre instance 11.5.9 (base 9.2.0.7), j'ai re créé un tablespace pour les UNDO. Le nouveau tablespace est UNDO_TBS1, l'ancien est APPS_UNDOTS1.

J'ai permuté la tablespace dans la base
=>

Code :

1
2
3
4
5
6
7
8
 
SQL> SHOW parameter undo
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- undo_management                  string      AUTO
undo_retention                       integer     1800
undo_suppress_errors              BOOLEAN     FALSE
undo_tablespace                    string      UNDO_TBS1

Jusque la pas de problemes.

Les données de l'ancien tablespace sont bien expirées
=>

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
SQL> SELECT 'Il y a ' || count(*) || ' transactions ' || STATUS || ' dans le tablespace ' || tablespace_name FROM DBA_UNDO_EXTENTS GROUP BY STATUS, tablespace_name ORDER BY tablespace_name, STATUS;
 
'ILYA'||COUNT(*)||'TRANSACTIONS'||STATUS||'DANSLETABLESPACE'||TABLESPACE_NAME   
--------------------------------------------------------------------------------
Il y a 162 transactions EXPIRED dans le tablespace APPS_UNDOTS1                 
Il y a 143 transactions EXPIRED dans le tablespace UNDO_TBS1                    
Il y a 4 transactions UNEXPIRED dans le tablespace UNDO_TBS1                    
 
 
SQL> SELECT count(*) FROM dba_undo_extents WHERE tablespace_name = 'APPS_UNDOTS1'
  2  MINUS
  3  SELECT count(*) FROM dba_undo_extents WHERE tablespace_name = 'APPS_UNDOTS1' AND STATUS = 'EXPIRED';
 
no rows selected
 
 
SQL> SELECT count(*) FROM v$recover_file;
 
  COUNT(*)                                                                      
----------                                                                      
         0

Donc a priori l'ex UNDO tablespace ne sert plus a rien.

Je décide donc de le mettre OFFLINE dans le but de le supprimer plus tard.

Code :

1
2
3
4
5
6
7
8
9
10
11
 
SQL> ALTER tablespace APPS_UNDOTS1 offline;
 
Tablespace altered.
 
 
SQL> SELECT tablespace_name, STATUS FROM dba_tablespaces WHERE tablespace_name ='APPS_UNDOTS1';
 
TABLESPACE_NAME                STATUS                                           
------------------------------ ---------                                        
APPS_UNDOTS1                   OFFLINE

Et la probleme :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
SQL> SELECT count(*) FROM v$recover_file;
 
  COUNT(*)                                                                      
----------                                                                      
         2                                                                      
 
SQL> SELECT file#, file_name from v$recover_file, dba_data_files where v$recover_file.file# = dba_data_files.file_id;
 
FILE#    FILE_NAME                                                                       
--------------------------------------------------------------------------------
6        E:\ORACLE\PROD\PRODDATA\DATA\RBS01.DBF                                          
 
378      E:\ORACLE\PROD\PRODDATA\DATA\RBS02.DBF

Lorsque je remet le tablespace ONLINE, tout rentre dans l'ordre.

Evidemment utilisant une 11.5.9, dès que l'ex tablespace est OFFLINE, j'ai tout un tas d'erreur de Workflow (Concurrent Managers) ...

Selon vous est ce que ce comportement est tres normal ?!
Comment se débarasser de ce tablespace ? Un DROP ?! Oui mais je suis pas tres rassurée (surtout en NOARCHIVELOG).

Merci

[orafrance]

tu as bien arrêté l'appli et redémarré ta base ? Ce sont bien les datafiles de APPS_UNDO ?

[guigui_cwoco]

Effectivement ce sont bien les DATAFILES de APPS_UNDOTS1.

J'ai redémarré le tier appl mais rien n'y fait.
Le probleme semble plus orienté sur la base, car meme avec le tier appl stoppé, base fraichement redémarrée avec aucun clients dessus, j'ai cette erreur.

En cherchant un peu plus, meme sur un tablespace de données, en le mettant 'OFFLINE', Oracle, est en defaut (via v$recover_files). Donc je comprends qu'en mettant un tablespace OFFLINE, Oracle ne puisse pas acceder aux fichiers, mais concernant l'UNDO c'est un peu bizarre puisqu'il n'y a aucune données critique ...

[guigui_cwoco]

Quelques nouvelles fraiches :
SR que j'ai ouverte pour ce probleme ==>

11-DEC-06 17:04:03 GMT

.
QUESTION
=========
Why do offline datafiles appear in v$recover_file as though media recovery were needed?



11-DEC-06 17:14:19 GMT

.
ANSWER
=======
I was able to reproduce the same behavior in 10g as well. Based on Bug 4341939 this was closed as normal behavior and not a bug.Tablespaces ta
ken offline are are in "technically" in recover state. The reason this is done
is to ensure that datafiles will be recovered if needed when they go back online

[orafrance]

en effet, c'est bien la base de données qu'il faut redémarrer

[guigui_cwoco]

Je reconfirme demain sur ma base de test, mais le probleme persiste meme apres redémarrage de la base.

Comme le dis Metalink, ca semble normal ... Oracle a besoin de faire un 'recovery' lorsque le tablespace sera remis ONLINE ...

Question qui me viens a l'esprit ==>
Bref cependant, si ma base tourne, et imaginons un cas de figure ou la base tourne en mode NOARCHIVELOG avec un tablespace OFFLINE depuis 2 semaines ... Quand on le remet ONLINE, d'ou Oracle reprend les datas a appliqyer au tablespace précédemment OFFLINE ?!

[orafrance]

tu peux essayer de te remettre en undo_managment MANUAL, démarrer, supprimer l'ancien UNDO, te remettre en auto et redémarrer ta base.

[guigui_cwoco]

Apparement le fait de mettre un tablesapce OFFLINE, entraine Oracle a remplir la vue v$recover_file.

De toute évidence, un fichier d'UNDO expiré n'a aucune raison d'etre conservé.

Je voulais le mettre OFFLINE pour voir le comportement d'Oracle avant de faire un DROP, mais dans ce cas de figure, le DROP est la meilleure solution (testé et approuvé par mes soins )

J'ai supprimé mon tablespace et datafiles, tout est OK.

Maintenant pourquoi les CONCURRENT MANAGERS tombaient en erreur, stipulant qu'ils ne trouvait pas mes fichiers de données d'UNDO, je l'explique par ceci (extrait de Metalink) :

As long as the old rollback segments exist on the database (even if offline) they will continue to be accessed to check the time a TX committed at. If the old RBS are dropped, then only the undos are checked.