[11g] tablespace user à restaurer

[lunab54]

Bonjour,

un de nos partenaires a cassé sa base... Il a avoulu faire de la place et à supprimer un datafile en arrêtant le service vraisemblablement (c'est assez confus, on a du mal à savoir exactement le process...)

malheureusement ses sauvegardes sont pas terribles :
- sauvegarde à chaud (Base Ouverte) par l'outil de sauvegarde Windows 2008 d'un seul tablespace user celui qui nous intérresse (?!)
- dump (exp) corrompu (!?)
- ect...

au final dans ce désastre ne reste qu'un datafile d'un tablespace sauvegardé par Windows Backup à chaud.

Il n'était pas en mode transportable et pas sauvegardé avec RMAN ni à froid.

pas de redo pas de control associés , la cata quoi !

J'ai reproduit son instance même systéme, même version d'Oracle, même nom d'instance, même user sys, system...

Quels sont mes chances de récupérer des données de ce table space isolée ?

merci d'avance pour votre réponse et éventuellement instructions

[lunab54]

Bon je vois que ca n'enflamme pas les foules...

avec une naiveté crasse j'ai créé un table space reprenant toutes les caractérisitques de mon tablespace nom, taille emplacement...

je l'ai mis hors ligne et j'ai permuté le datafile.

au moement de remettre le tablespace Online j'ai le message suivant :

Code :

1
2
3
echec de de traitement de la commande sql ora-0112 échec de controle de vérification du fichier BdD 6
ora-01110: fichier de données 6 : 'c:\....'
ora-01210: l'en tête du fichier de données à un support altéré"

ca me choque pas plus que ça...

j'ai essaye un recover datafile et j'ai le même genre de message ORA-01110,ORA-1122, ORA-1210

c'est vraiment fini ? y a rien à faire ?

merci de votre aide s'il vous plait

[Pomalaix]

Sans aucune garantie, peut-être réussirez-vous à ouvrir la base malgré ses incohérences, grâce au paramètre suivant à placer dans le PFILE :

Code :

_ALLOW_RESETLOGS_CORRUPTION=TRUE

Si la base consent à s'ouvrir, alors il faut faire un export FULL et le réimporter dans une base neuve.

[lunab54]

Merci Pomalaix,

je suis déjà dans une base neuve et elle démarre bien même avec ce tablespace de données user (pas system).

Par contre le tablespace en question vient d'une autre instance qui elle est morte à jamais (pas de redo, pas de control rien le désert ).

le vais essayer un export du tablespace en question pour voir....

[lunab54]

hum...

l'export dudit tablesapce ne donne rien

Code :

ORA-31655: aucun objet de donnÚes ou de mÚtadonnÚes n'a ÚtÚ sÚlectionnÚ pour le travail

je crois que c'est mort non ?

[Pomalaix]

Envoyé par lunab54

je suis déjà dans une base neuve et elle démarre bien même avec ce tablespace de données user (pas system).

Quand je disais "démarrer", j'entendais par là "avec tous les tablespaces ONLINE".
Si votre tablespace est OFFLINE, vous ne risquez pas d'en exporter quoi que ce soit... De plus, comme indiqué, il ne suffit pas d'exporter uniquement le contenu de ce tablespace, mais bien de la base complète, pour recréer une base neuve et propre. (La vôtre n'est plus propre, elle sera incohérente).

[IndianaAngus]

Les données de ton tablespace users sont, je pense, perdu.
Pas de backup rman à chaud ou autre à froid, le backup du tablespace à chaud par windows backup ne tiens pas compte des block qui étaient en mémoire, donc le tablespace est incoherent et tu n'arriveras pas l'ouvrir.
Tu peux peut être récupérer les données des autres tablespaces avec la solution de Pomalaix.

[Pomalaix]

Envoyé par IndianaAngus

Tu peux peut être récupérer les données des autres tablespaces avec la solution de Pomalaix.

Le but de ma proposition, c'est de réussir à ouvrir la base, et en particulier le tablespace problématique, en court circuitant les vérifications de cohérence. Si ça marche, alors on pourra exporter les données de ce tablespace USERS.