Newsgroup: it.comp.software.database
Titolo: AIUTO! Pasticcio Datafile Oracle

Ciao.
Snnoo daniela.
Lavoro in una ditta che fa software e usiamo molto oracle.
Ho combinato un pasticcio e non riesco a rimediare.
qualcuno di voi ha una dritta da darmi?
vi illustro la situazione:
ho creato un datafile su una tablespace perchè era piena e ci dovevo
aggiungere un utente esportato da un altra macchina.
però mi sono accorta che l'utente usava una tablespace con nome diverso (di
solito usiamo sempre la prima per questo l'avevo dato per scontato) quindi
l'importazione dava degli errori, così ho cancellato l'utente e l'ho rifatto
sta volta assegandogli la tablespace giusta e l'importazione è andata a buon
fine.
Ma qui viene la cavolata che ho fatto io:
ho messo offline la tablespace a cui avevo aggiunto inutilmente spazio
creando un nuovo datafile, ho cancellato manualmente il nuovo file che avevo
fatto e su cui non ci dovrebbe essere nulla di utile dato che l'utete l'ho
cancellato, e poi riprovando a mettere online la tablespace mi dava errore.
lo so che è una cavolata ma avevo poco posto sulla partizione e avevo già
creato anche un altro file da 1 giga per la seconda tablespace!
ho provato a recuperare il file con easyricovery ma non lo trova più.
ho provato a copiarne un altro grosso uguale e rinominarlo ma da errore
perchè si accorge che l'intestazione è incongruente...
insomma, googlagando qua e la abbiamo usato il comando sql per droppare il
datafile incriminato dalla tablespace, e lo ha fatto con successo.
eseguendo il comando alter database backup controlfile to trace e
controllando il cotrol file il datafile in questione non è più menzionato...
e allora perchè il problema resta?
perchè la tablespace non va online? cercando di metterla online da l'errore:
ora-01122 il file di database 19 non ha superato la verifica.
ora-01110 file di dati 19 xxx.DBF'
ora-01251 versione di intestazione file sconosciuta per il numero di file
19.
certo, se reinstallo tutti gli utenti e i relativi dati va a posto ma c'è
tanta, veramente tanta roba su quel db, ci scocciava, e quasi tutta è
proprio su quelal tablespace.
(sempre che rimettendola online non si siano persi i dati, spero di no,
vero????)
...qualcuno ha una dritta da darci???
grazie infinite in anticipo all'angelo che ha una soluzione...
Daniela,

Prova a far ripartire il servizio:
se non parte (il database non si apre) allora
  - shutdown immediate;
  - startup mount;
  - alter database datafile <'nome'> (o numero) offline <puoi anche 
usare l'opzione 'drop';
Poi dovresti poter aprire il database con il comando
  - alter database open;
In questo modo dovresti salvare il resto della tablespace.
Se va bene se non va posta quello che ti risponde.
By
Pippo ha scritto:


 Se va bene se non va posta quello che ti risponde.
il mio collega pensava di fare una cosa del tipo, si copiano i datafile
della tablespace incasinata, si butta (su oracle) la tablespace (ma on
fisicamete) e si ricrea, dadole di nuovo quei file e usando l'opzione reuse.
secondo voi può fuzionare?
io soon sempre + convinta che se invece di perderci 2 giorni buttavo gli
utenti, la tablespace e li rifacevo entrambi, a quest'ora sarei già
operativa e invece ci siamo ancora dietro... e vedrai che alla fine ci
toccherà fare così...
bah, on pesavo oracle fosse  così stupido, e si ch elo uso da più du 7 anni
anche se ua caz... così non la'vevo mai fatta...
comunque grazie.
ciao.

Mentre cercavo di capire la differenza tra una select e un drop database


allora dovresti fare così se sei in archivelog e/o hai ancora tutti i
redo necessari:
ALTER DATABASE CREATE DATAFILE 'filename';
RECOVER DATAFILE 'filename'
e poi quando ti chiede i redo log passagli i nomi dal più vecchio in su.
ciao.

 e poi quando ti chiede i redo log passagli i nomi dal più vecchio in su.
che sarebbero?
sperando ci siano ancora dato che son 2 gironi che proviamo di tutto?
comunque non vorrei portarmi sfiga ma sono IO che ho cancellato il file, on
s'è daeggiato.
se potessi torare a PRIMA di aver creato quel maledetto datafile... magari!
-- 
ciao.
Il Sito di LEO.
http://digilander.libero.it/iltoponano

 se potessi torare a PRIMA di aver creato quel maledetto datafile... magari!
i redo log sono i file che contengono lo storico dell'attività
transazionale del db. Se siete in archivelog mode, dovresti riuscire
a recuperare completamente il datafile, altrimenti dipende solo dalla
fortuna. In quest'ultimo caso puoi tentare un recovery until time o
until change.
cmq i redo li vedi così:
select member from v$logfile;
per la sfiga.......bé vorrei vedere chi non ha mai sbagliato sul lavoro  ;)

 ha scritto nel messaggio
news:pan.2007.10.25....@tiscali.it...
sta diventando un po' arabo adesso per me, comunque sto cercando su google.
ma mi puoi dire...come faccio a sapere se sono in archvelog mode?(mi viene
da pensare di no però se nessuno sa cos'è e in 2 gg non sen'è parlato, sta
macchina non l'ho in stallata io...)
come posso tentare sto recovery util time/change?
grazie.
ciao.

Mentre cercavo di capire la differenza tra una select e un drop database


per verificare se sei in archivelog da una sessione sqlplus
digita:
archive log list
l'output è simile a questo:
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /d1000_stg/orarchive
Oldest online log sequence     76
Next log sequence to archive   78
Current log sequence           78
SQL>
se invece non sei in archivelog la prima riga è ovviamente diversa:
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     11
Current log sequence           13
Il recovery until change/time significa che si segue una procedura
per recuperare il datafile in modo incompleto, ossia sino ad
un change number (SCN) o sino ad un istante (espresso come data-ora)
che si presuppone siano entrambi PRIMA del disastro (cancellazione
del file in questo caso).

 ha scritto nel messaggio
news:pan.2007.10.25....@tiscali.it...
i log sembra che ci siano.
tento un recover prima del fattaccio, se non fuziona... beh mi sa che mi
arredo... che faccio prima a sto punto.
comunque grazie.
ciao.

 del file in questo caso).
e cosa succede all'INTERO DB ?
non sarebbe melgio fare tutto su un db di standby :)
felice_pago
.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

Mentre cercavo di capire la differenza tra una select e un drop database


vabbè se fai un until change su un datafile che già sai che
era vuoto.....è solo per permettergli di rimettere online
il tablespace.
Meglio ancora sarebbe avere i backup no  ;)

 non sarebbe melgio fare tutto su un db di standby :)
sarebbe stato meglio non fare la cazzata iniziale.
vi annucio la morte ufficiale del db.
l'abbiamo ucciso, solo il db eh, mica tutto oracle.
e ora lo stiamo ricreando.
1 minuto di silenzio...
(mica posso andare avanti 10 gg cosě poi... mi serve la macchina
fuzionante...)
ciao.

Mentre cercavo di capire la differenza tra una select e un drop database


R.I.P.
;)