tag:blogger.com,1999:blog-11965249.post777888984105294435..comments2024-01-15T11:31:46.282+01:00Comments on Rudy's DBland: Da 64 a 32 bit (e viceversa)Rudyhttp://www.blogger.com/profile/05494812158299383717noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-11965249.post-11274117905518993792007-11-25T20:33:00.000+01:002007-11-25T20:33:00.000+01:00..la postilla dice POTRESTI perdere dati ma scusa .....la postilla dice POTRESTI perdere dati ma scusa se hai appliacto tutti gli archive disponibili nn perdi niente di sicuro.Va be comunque voleva essere un suggerimento ad una procedura certidicata con Oracle e provata presso un cliente (oltretutto in 10gr1 si possono avere probmemi propio "COMMIT TO SWITCHOVER TO PRIMARY;" e oracle (a seguito di SR) autorizzava appunto ad usare ACTIVATE ..in particolar modo se nn usi i redolog standby..puoi perdere dati di sicuro :) ovvero quelli nn ancora archiviati) ..ma ci mancherebbe ....se hai fatto cosi ci credo :) (un idea ,non ovviamente tutto lo studio, sull'activate 219554.1)<BR/><BR/><BR/>poi comunque mi sembrava che dicevi che avevi dovuto usare una sintassi "diversa" :) ... <BR/><BR/>byecehttps://www.blogger.com/profile/01646693132480258501noreply@blogger.comtag:blogger.com,1999:blog-11965249.post-11415130815724506182007-11-25T10:02:00.000+01:002007-11-25T10:02:00.000+01:00Con l'"activate standby" apro il database con rese...Con l'"activate standby" apro il database con resetlogs; perché mai dovrei farlo, perdendo dati?<BR/><BR/>La <A HREF="http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/role_management.htm#i1026491" REL="nofollow">documentazione Oracle parla chiaro</A>: non bisogna farlo con i physical standby.Rudyhttps://www.blogger.com/profile/03336758415691248899noreply@blogger.comtag:blogger.com,1999:blog-11965249.post-8065339221715136002007-11-24T18:43:00.000+01:002007-11-24T18:43:00.000+01:00ma quante belle cosine io avrei scritto nel dettag...ma quante belle cosine io avrei scritto nel dettaglio questi passi subuto dopo aver risolto il GAP:<BR/><BR/>Precedentemente a questa operazione il DB originale e quello di destinazione hanno WORD SIZE differenti,dovuti all’hardware su cui appoggiano, questo non comporta “gravi” problemi durante l’applicazione degli arch e durante la lettura di dati .<BR/><BR/>• Se la macchina che “ospita” il DB non ha settato la variabile esposta sotto eseguire il settaggio:<BR/><BR/>export LD_LIBRARY_PATH=$ORACLE_HOME/lib<BR/><BR/><BR/>• Settare I 3 parametri Oracle (init.ora)<BR/><BR/> aq_tm_processes=0<BR/> _system_trig_enabled=false<BR/> job_queue_processes=0<BR/><BR/><BR/>• Eseguire lo shutdown del DB:<BR/> <BR/>• Eseguire lo startup UPGRADE + attivazione forzata STBY:<BR/><BR/>SQL> startup upgrade <BR/><BR/>SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;<BR/><BR/><BR/>(quest’ultima operazione aprirà il DB attraverso la clausola RESETLOGS)<BR/><BR/><BR/>poi :<BR/><BR/>@utlirp.sql<BR/><BR/>@catpatch.sql<BR/><BR/>Attenzione alla fine di questo step, nel caso si utilizza l’utility Oracle Text non è valida;<BR/>dovrebbe essere sufficiente de-installarlo e installarlo nuovamente.<BR/><BR/>@utlrp.sql<BR/><BR/>• Settare/commentare i 3 parametri, dell’init.ora modificati precedentemente <BR/><BR/><BR/>• Effettuare lo shutdown del DB<BR/><BR/>• Effettuare lo startup del DB :<BR/><BR/>Naturalmente aprendo in RESETLOGS avviene una nuova incarnation,e quindi gli arch precedenti non saranno più validi!! :)<BR/><BR/>byeclusterrac2https://www.blogger.com/profile/12504527516294530058noreply@blogger.com