[Oracle] Control file questi sconosciuti

[monkey72]

a lavoro ho un'applicazione client/server su dbms Oracle 9.2, nel backup notturno (utility backup di windows 2k), oltre al ottenuto dump con export full ho inserito anche la struttura del database, però mi da puntualmente errore su alcuni file che sembra siano in uso, tra questi i .ctl, control file di oracle
intanto vorrei chiarirmi le idee su cosa contengono esattamente questi file, vagamente mi sembra di ricordare che siano file binari che contengono info sul DB quale il nome e la struttura in generale ma se qualcuno avesse qualche link ad articoli sarebbe meglio :D
poi semmai sulle proprietà, se qualcuno sa quale potrebbe essere il motivo per cui sono in uso

tnx
monkey ;)

p.s. oltre a questi .ctl, il backup notturno ignora anche alcuni file .dbf di dati ed indici per lo stesso motivo

[Casper8]

Originariamente inviato da monkey72
a lavoro ho un'applicazione client/server su dbms Oracle 9.2, nel backup notturno (utility backup di windows 2k), oltre al ottenuto dump con export full ho inserito anche la struttura del database, però mi da puntualmente errore su alcuni file che sembra siano in uso, tra questi i .ctl, control file di oracle
intanto vorrei chiarirmi le idee su cosa contengono esattamente questi file, vagamente mi sembra di ricordare che siano file binari che contengono info sul DB quale il nome e la struttura in generale ma se qualcuno avesse qualche link ad articoli sarebbe meglio :D
poi semmai sulle proprietà, se qualcuno sa quale potrebbe essere il motivo per cui sono in uso

tnx
monkey ;)

p.s. oltre a questi .ctl, il backup notturno ignora anche alcuni file .dbf di dati ed indici per lo stesso motivo

I file .ctl (i control file) sono tutto !;) contengono tutte le informazioni sulla struttura del db! E' assolutamente essenziale che non si danneggino! pena :muro: :muro: :muro: :muro:
difatti sono normalmente multiplexati (credo che tu ne abbia almeno 3 copie sincrone);
Solo non capisco perchè farne il backup se fai un full export; senza entrare nel merito - anche perchè io conosco più la 8i - essenziale è avere un db con la stessa struttura di quello che hai in produzione ma senza dati; in modo che se proprio ti si distruggono tutti i tablespace recuperi tutto dalla full export senza problemi di sorta.
Per quanto riguarda i .dbf, ti esclude sempre gli stessi? Poi dipende se per un tablespace esiste un solo .dbf o più di uno.
Perchè se è uno solo e cerchi di fare il backup con il db in open se DBW ci sta lavorando, il s.o. lo considera in uso; sarebbe opportuno che i .dbf fossero più di uno in modo da poterli mettere in backup uno alla volta senza fermare il db.
Questo sempre che tu abbia un db 24/7.

Spero di non aver detto troppe sciocchezze:mc: :mc:

Ciao

[monkey72]

Originariamente inviato da Casper8
I file .ctl (i control file) sono tutto !;) contengono tutte le informazioni sulla struttura del db! E' assolutamente essenziale che non si danneggino! pena :muro: :muro: :muro: :muro:
difatti sono normalmente multiplexati (credo che tu ne abbia almeno 3 copie sincrone);
Solo non capisco perchè farne il backup se fai un full export;

anche secondo me è inutile, ma il mio collega ha voluto così... poverino non è tutta colpa sua non ci arriva proprio! ;)
Originariamente inviato da Casper8
senza entrare nel merito - anche perchè io conosco più la 8i - essenziale è avere un db con la stessa struttura di quello che hai in produzione ma senza dati; in modo che se proprio ti si distruggono tutti i tablespace recuperi tutto dalla full export senza problemi di sorta.

l'export full quindi esporta anche i tablespace?
Originariamente inviato da Casper8
Per quanto riguarda i .dbf, ti esclude sempre gli stessi?

si...
Originariamente inviato da Casper8
Poi dipende se per un tablespace esiste un solo .dbf o più di uno.
Perchè se è uno solo e cerchi di fare il backup con il db in open se DBW ci sta lavorando, il s.o. lo considera in uso;

che è DBW?
Originariamente inviato da Casper8
sarebbe opportuno che i .dbf fossero più di uno in modo da poterli mettere in backup uno alla volta senza fermare il db.
Questo sempre che tu abbia un db 24/7.

che è un db 24/7?

grazie Casper... ;)

[Casper8]

Originariamente inviato da monkey72
anche secondo me è inutile, ma il mio collega ha voluto così... poverino non è tutta colpa sua non ci arriva proprio! ;)

l'export full quindi esporta anche i tablespace?

si...

che è DBW?

che è un db 24/7?

grazie Casper... ;)

Allora:

mi dispiace per il tuo collega... cmq come si dice dalle mie parti... "Attaca il ciuccio dove dice il padrone" :D :D :D :D ... vabbé:O

L'export full esporta tutti gli oggetti del db; in caso di ripristino si regola sui tablesbace del db di destinazione, per cui deve trovare ts con gli stessi nomi che avevano quando è stato fatto il backup. Il metodo più sicuro è conservarti lo script di creazione del db e il full export. In questo modo sei in grado di riprodurre la situazione al momento del backup. Scusa se lo preciso ma è del tutto evidente che lo script di creazione del db deve assolutamente essere tenuto aggiornato..;)

DBW è il DataBaseWriter, cioè il processo che Oracle usa per scrivere fisicamente i dati sul db.

Per db 24/7 si intende un database che è in open 24ore su 24 per 7giorni su 7; in questo caso, evidentemente, le politiche di backup sono più critiche. Sempre fermo restando che puoi cmq fare la full export e che se la fai 'consistente' (quindi CONSISTENT=Y) ottieni un salvataggio perfettamente allineato.

Spero di esserti stato di qualche aiuto...:( :(

Ciao e buon week-end:sborone:

[monkey72]

Originariamente inviato da Casper8
Allora:

mi dispiace per il tuo collega... cmq come si dice dalle mie parti... "Attaca il ciuccio dove dice il padrone" :D :D :D :D ... vabbé:O

a me dispiace per me! :D
Originariamente inviato da Casper8
L'export full esporta tutti gli oggetti del db; in caso di ripristino si regola sui tablesbace del db di destinazione, per cui deve trovare ts con gli stessi nomi che avevano quando è stato fatto il backup. Il metodo più sicuro è conservarti lo script di creazione del db e il full export. In questo modo sei in grado di riprodurre la situazione al momento del backup. Scusa se lo preciso ma è del tutto evidente che lo script di creazione del db deve assolutamente essere tenuto aggiornato..;)

si, non so se le patch che la ditta fornitrice dell'applicazioni rilascia spesso, vanno a modificare la struttura del db, cmq ci farò caso, sono script SQL
però in questo caso basterà all'occorrenza ricreare il DB con gli script di creazione, applicare tutte le patch e poi fare l'import
Originariamente inviato da Casper8
DBW è il DataBaseWriter, cioè il processo che Oracle usa per scrivere fisicamente i dati sul db.

Per db 24/7 si intende un database che è in open 24ore su 24 per 7giorni su 7; in questo caso, evidentemente, le politiche di backup sono più critiche.

per vedere queste impostazioni?
e in tal caso a cosa mi serve tenerle se so che dalle 18:00 fino alle 7:00 nessuno utlizzerà più l'applicazione?
Originariamente inviato da Casper8
Sempre fermo restando che puoi cmq fare la full export e che se la fai 'consistente' (quindi CONSISTENT=Y) ottieni un salvataggio perfettamente allineato.

infatti!
Originariamente inviato da Casper8
Spero di esserti stato di qualche aiuto...:( :(

Ciao e buon week-end:sborone:
altrochè se mi sei stato d'aiuto! :)

grazie ancora e buon weekend anche a te ;)

[dr.stein]

I ctl file li devi copiare a servizi spenti, altrimenti oracle li locka e non te li fa accedere....

un senso nel fare la copia brutale piuttosto che la full exp c'e' ed è il fatto e che mentre con la full exp si generano una serie di istruzioni sql che sono in grado di ricreare struttura e dati, nel secondo caso sto copiando fisicamente i dati (in struttura interna).

La differenza è sottile ma c'e', sebbene nella maggioranza dei casi non c'e' motivo di usare la copia brutale:

-Con la full exp copi i dati a livello astratto, indipendentemente da come sono fisicizzati:

ESEMPIO: Full exp su un db di test risiedente su un singolo disco e esportazione su un server di produzione con 8 dischi ognuno dedicati a fisicizzare determinate tabelle, indici o viste materializzate.... in questo caso avresti piu' control file in piu' posti fisici diversi del tuo server, ma con la full exp non te ne devi preoccupare.

-Con la full exp impegni in restore anche il tempo di ricreazione dei dati stessi, degli indici, delle viste mat. e ammenicoli vari...
con la copia brutale dei control file stoppi il servizio, restori, riparti e sei come prima....

- Fai la full exp su un sistema a locale italiano.... poi fai la imp su un sistema a locale inglese.... ti zompano tutte le date!!!!!!! Con la copia dei ctl file non succede!!!

Insomma... ci sono vantaggi e svantaggi per entrambe le soluzioni, sono due modalità di backup diverse che hanno strumenti e fini diversi.... se non costa nulla, copiare anche i ctl file non la vedo come una fesseria! ;)

Init.ora lo backuppate ?

[monkey72]

Originariamente inviato da dr.stein
I ctl file li devi copiare a servizi spenti, altrimenti oracle li locka e non te li fa accedere....

un senso nel fare la copia brutale piuttosto che la full exp c'e' ed è il fatto e che mentre con la full exp si generano una serie di istruzioni sql che sono in grado di ricreare struttura e dati, nel secondo caso sto copiando fisicamente i dati (in struttura interna).

La differenza è sottile ma c'e', sebbene nella maggioranza dei casi non c'e' motivo di usare la copia brutale:

-Con la full exp copi i dati a livello astratto, indipendentemente da come sono fisicizzati:

ESEMPIO: Full exp su un db di test risiedente su un singolo disco e esportazione su un server di produzione con 8 dischi ognuno dedicati a fisicizzare determinate tabelle, indici o viste materializzate.... in questo caso avresti piu' control file in piu' posti fisici diversi del tuo server, ma con la full exp non te ne devi preoccupare.

-Con la full exp impegni in restore anche il tempo di ricreazione dei dati stessi, degli indici, delle viste mat. e ammenicoli vari...
con la copia brutale dei control file stoppi il servizio, restori, riparti e sei come prima....

- Fai la full exp su un sistema a locale italiano.... poi fai la imp su un sistema a locale inglese.... ti zompano tutte le date!!!!!!! Con la copia dei ctl file non succede!!!

Insomma... ci sono vantaggi e svantaggi per entrambe le soluzioni, sono due modalità di backup diverse che hanno strumenti e fini diversi.... se non costa nulla, copiare anche i ctl file non la vedo come una fesseria! ;)

Init.ora lo backuppate ?
no, l'init.ora no, ma quello contiene solo i TNS names se non sbaglio?
quindi te dici che se volessi backuppare i ctl devo stoppare i servizi... mmh... semmai una volta ogni tanto rispetto ad un export full giornaliero...

tnx ;)

[Casper8]

Originariamente inviato da monkey72
no, l'init.ora no, ma quello contiene solo i TNS names se non sbaglio?
quindi te dici che se volessi backuppare i ctl devo stoppare i servizi... mmh... semmai una volta ogni tanto rispetto ad un export full giornaliero...

tnx ;)

Il file init.ora contiene i parametri di startup del db; così se fai, ad esempio, un ALTER SYSTEM e non aggiorni l'init.ora, al successivo shutdown/startup del db il parametro modificato tornerà al valore iniziale.
Una copia dell'init.ora aggiornata è importante!:sofico:

Per il resto personalmente ti consiglio caldamente di tenere un secondo db identico al primo (come struttura logico-fisica) ma vuoto;) ;) Così ti sarà sufficiente il full-export e, in caso di 'guai', riuscirai a rimettere su il db in un tempo relativamente breve e con poche 'ricuciture' da fare:cool:

Ciao:sborone:

[monkey72]

Originariamente inviato da Casper8
Il file init.ora contiene i parametri di startup del db; così se fai, ad esempio, un ALTER SYSTEM e non aggiorni l'init.ora, al successivo shutdown/startup del db il parametro modificato tornerà al valore iniziale.
Una copia dell'init.ora aggiornata è importante!:sofico:

Per il resto personalmente ti consiglio caldamente di tenere un secondo db identico al primo (come struttura logico-fisica) ma vuoto;) ;) Così ti sarà sufficiente il full-export e, in caso di 'guai', riuscirai a rimettere su il db in un tempo relativamente breve e con poche 'ricuciture' da fare:cool:

Ciao:sborone:
oddio lo avevo confuso col TNSNAMES.ORA :D :muro:
x il consiglio... saggio, penso che lo seguirò ;)
quindi in conclusione full export e init.ora, i ctl non mi servono, visto che è improbabile che possa utilizzare un oracle in lingua diversa...
tnx
monkey ;)

[monkey72]

oggi pomeriggio ho finito un corso Oracle di una settimana, ora mi è tornata in mente questa discussione e, a parte che da una rilettura veloce dei post, con un pò di cognizione in più devo dire che di fesserie ne abbiamo dette!!! :D e semmai in un altro momento e ad'un'altra ora potrei anche provare a dirvi quali sono, cmq, a parte tutta questa noiosa introduzione, volevo aggiungere per quanto riguarda il backup, valutando le diverse ipotesi con il prof al corso si è concluso che con un export full ed un salvataggio del modello del database dovrebbero bastare in Ora 9.2 per ricreare completamente la struttura ed il contenuto del db... perchè il modello conterrebbe anche quello che nelle versioni precedenti di oracle si chiama init.ora e che nella 9.2 si chiama parameter file, i control file contengono indicazione sui percorsi dei datafile, ma e le macchine sono diverse potrebbero non servire a nulla... che ne dite?