13 ottobre 2007

Da 64 a 32 bit (e viceversa)

Nei giorni scorsi ho dovuto affrontare un'emergenza: una macchina di produzione Itanium (IA64) ha smesso di funzionare per ragioni relative allo storage esterno. Rimaneva lo standby fisico a 32 bit, che comunque doveva andare presto in produzione al posto dell'IA64.

Pazienza, dopo avere applicato gli ultimi log all'istanza standby, ho cominciato la procedura di failover.
Subito ho avuto un piccolo problema per via della R1 del database 10g, che aveva una sintassi leggermente diversa per il failover manuale (grrr!), ma alla fine il role transition è andato bene.
Ma non tutto è andato per il verso giusto. Infatti, entrando come utente qualsiasi nel database, spuntava fuori l'errore:

ORA-06553: PLS-801: internal error [56319]
Error accessing package DBMS_APPLICATION_INFO


Suonava come un problema di dizionario dati. E infatti, a quanto si intuiva dalla documentazione, bisogna fare uso di ?/rdbms/admin/utlirp.sql, seguito da utlrp.sql, come si può leggere nelle istruzioni nell'header del file stesso (da seguire assolutamente).
Il dizionario è andato a posto e il db ha ricominciato a funzionare correttamente.

3 commenti:

clusterrac2 ha detto...

ma quante belle cosine io avrei scritto nel dettaglio questi passi subuto dopo aver risolto il GAP:

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 .

• Se la macchina che “ospita” il DB non ha settato la variabile esposta sotto eseguire il settaggio:

export LD_LIBRARY_PATH=$ORACLE_HOME/lib


• Settare I 3 parametri Oracle (init.ora)

aq_tm_processes=0
_system_trig_enabled=false
job_queue_processes=0


• Eseguire lo shutdown del DB:

• Eseguire lo startup UPGRADE + attivazione forzata STBY:

SQL> startup upgrade

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;


(quest’ultima operazione aprirà il DB attraverso la clausola RESETLOGS)


poi :

@utlirp.sql

@catpatch.sql

Attenzione alla fine di questo step, nel caso si utilizza l’utility Oracle Text non è valida;
dovrebbe essere sufficiente de-installarlo e installarlo nuovamente.

@utlrp.sql

• Settare/commentare i 3 parametri, dell’init.ora modificati precedentemente


• Effettuare lo shutdown del DB

• Effettuare lo startup del DB :

Naturalmente aprendo in RESETLOGS avviene una nuova incarnation,e quindi gli arch precedenti non saranno più validi!! :)

bye

Rudy ha detto...

Con l'"activate standby" apro il database con resetlogs; perché mai dovrei farlo, perdendo dati?

La documentazione Oracle parla chiaro: non bisogna farlo con i physical standby.

ce ha detto...

..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)


poi comunque mi sembrava che dicevi che avevi dovuto usare una sintassi "diversa" :) ...

bye