..
Bonjour,
Bon... pas de panique, il y a toujours un moyen de s'en sortir (en principe...).
A ta place je ne m'embêterais pas avec un recover, qui me fait toujours un peu peur. En plus je ne crois pas qu'il va résoudre ton problème de datafile.
Que contient le tablespace CWMLITE ? Des tables et des index ?
Je tenterais la chose suivante :
- déplacer les tables et les index de CWMLITE vers un tablespace bidon que tu auras préalablement créé. Ca se fait avec des instructions du genre "alter table xxx move tablespace ZZZ" et "alter index xxx rebuild online tablespace ZZZ". Attention car faire un move sur une table rend ses index unusable, ça fait une petite interruption de service le temps de les reconstruire
- droper le tablespace CWMLITE puis le recréer correctement
- redéplacer les tables et les index dans CWMLITE
Merci pour ta réponse!
Si je suis très vague dans mes indications c'est parce que la base a été mise en place il y a longtemps et personne de l'équipe n'était en place à l'époque
Je ne comprends pas trop pourquoi un "recover datafile" semble si dangereux à tout le monde? Il y a t'il des risques importants?
C'est que c'est bien tenant : à priori je sais maintenant qu'il va juste aller chercher la sequence d'archivelog au moment du offline et celle juste après, pas plus
Après, les archivelogs ont l'air d'être archivées directement sur bande :
Quand je fais "archive log list", le répertoire pointé est vide et avec la commande "list backup of archivelog all summary" sur rman le type d'unité est "SBT_TAPE"
Donc je ne suis pas sûr qu'il va pouvoir les récuperer facilement sur bande aussi facilement qu'il les y sauvegarde.
Pour la manipulation que tu me conseilles, elle implique de mettre la base en mount. Enfin je pense...et vu que c'est en prod, ça va être un peu "borderline" pour moi de faire ça sur un tablespace que je ne connais pas du tout
Le CWMLITE est le tablespace pour le OLAP de oracle, je crois que ça optimise des requêtes...j'ai pas très bien compris, c'est expliqué dans ce lien :
http://www.supinfo-projects.com/fr/2005/oracle_olap/1/
A son propos :
- son datafile ONLINE fait 1Mo/20Mo
- il est absent des tables dba_tables, dba_segments et dba_extents et j'ai du mal à trouver des infos sur lui à cause de ça . Je n'ai toujorus pas réussi à trouver son owner et ses objets éventuels
Serait t'il vide : ?
Je ne suis même pas sur que la base se sert de ce truc, peut être que ça a été installé par defaut et il va falloir que je regarde comment savoir si il est utilisé
Bonjour,
La manip que je t'ai indiquée n'implique pas du tout que la base soit en mount. Déplacer des tables et des index ça se fait très bien base ouverte (heureusement car ça m'a sauvé la mise bien des fois).
Pour savoir ce qu'il y a dans ce satané tablespace, tu peux essayer (mais je pense que tu l'as déjà fait) : select * from dba_segments where tablespace_name='CWMLITE'.
En effet, CWMLITE est utilisé par l'option OLAP d'Oracle. Le tablespace doit contenir, en principe, les objets du schéma OLAPSYS... ce schéma OLAPSYS existe-t-il bien sur ta base ?
J'ai en effet déjà essayé le select et ce tablespace n'est pas présent dans les tables dba_tables, dba_segments et dba_extents
Je ne sais donc pas de quoi il est rempli pourtant ça prends un tout petit Mo, c'est donc un peu difficile d'en déplacer les objets
Je n'ai pas de schéma OLAPSYS sur la base ça confirmerait donc bien que ce tablespace ne sert à rien
Quand tu dis "ça prend un tout petit Mo"... tu veux dire que c'est ce que tu vois quand tu cherches la place occupée dans la tablespace CWMLITE (via la vue dba_free_space par exemple) ?
Tout cela semble effectivement indiquer que ce tablespace ne sert à rien.
Pour enfoncer le clou, tu peux vérifier si l'option OLAP est installée sur ta base.
Tu peux le savoir avec la requête
select * from v$option
Bonjour,
Il faut simplement t'assurer d'avoir l'ensemble des archologs nécessaires pour la manip ie les archologs générés depuis la mise 'offline' du datafile.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2 Je n'ai pas tenté le RECOVER car ça fait peur et que c'est une base de prod. Est ce qu'il y a vraiment, comme je le pense, aucun risque avec la commande "RECOVER DATAFILE numdatafile"? (au pire il renvoie une erreur?)
Si tel est le cas tu lances simplement le recover datafile <num datafile>; et Oracle fera le reste ;-)
Cdt,
Alain
Hello,
Je te conseille plutot ceci:
Startup mount:
Supprimer le fichier os
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 alter database datafile 'chemin complet du fichier du tablespace' offline drop; alter database open; DROP TABLESPACE <ton tablespace> including contents;
Voilou
jko
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager