In questo articolo vorrei illustrare il modo per poter convertire il database Oracle dalla versione Enterprise Edition alla versione Standard e viceversa, trattato dal documento ID 117048.1 del metalink.
Questa procedura permette la conversione senza in alcun modo che l’istanza installata con una o con l’altra versione venga modificata.
Nel mio caso converto una istanza dalla Enterprise Edition in una Standard ma funziona anche viceversa.
Il test è stato fatto in ambiente Solaris 10.5 con Oracle EE 11.0.2.3.
L’installazione della versione Enterprise è stata eseguita nel path /app/oracle/product/11.2.0.3/dba_1/dbs.
Il primo passo è quello di installare la versione Stardard con le relative librerie, in un’altra ORACLE_HOME, senza ovviamente creare nessuna altra istanza, praticamente solo il software.
…
Ho diviso per punti per maggior chiarezza.
1) Una volta installata, eseguire lo shutdown normal o immediate del database EE e fermare il LISTENER relativo.
La versione Standard è stata installata nel path /app/oracle/product/11.2.0.3/dba_se/dbs.
La versione Standard è stata installata nel path /app/oracle/product/11.2.0.3/dba_se/dbs.
2) Copiare tutto il contenuto dal percorso della EE /oracle11g/app/oracle/product/11.2.0.3/dba_1/dbs
alla Standard /app/oracle/product/11.2.0.3/dba_se/dbs, dove ci sono tutte le informazioni di base dell’istanza come per esempio SP file e altro.3) Copiare tutto il contenuto /app/oracle/product/11.2.0.3/db_1/network/admin/ della EE in /app/oracle/product/11.2.0.3/db_se/network/admin/ alla SE, per allineare le impostazioni del LISTENER.
4) A questo punto eseguire alcune modifiche nel profile file .profile dell’utente specifico che esegue tutti i servizi oracle, che nel mio caso si chiama oracle.
Modificare l’enviroment dell’utente oracle relative alla ORACLE_HOME modificando :
ORACLE_HOME=/oracle11g/app/oracle/product/11.2.0.3/db_1 con ORACLE_HOME=/oracle11g/app/oracle/product/11.2.0.3/db_se; export ORACLE_HOME
E il listener:
TNS_ADMIN=$ORACLE_BASE/product/11.2.0.3/db_1/network/admin con
TNS_ADMIN=$ORACLE_BASE/product/11.2.0.3/db_se/network/admin/; export TNS_ADMIN
5) Eseguire un altro login con l’utente oracle oppure ricaricare le nuove variabili e fare ripartire il LISTENER con il commando:
LSNRCTL start
Poi verificare con lo stato con LSNRCTL status
LSNRCTL for Solaris:Version 11.2.0.3.0 - Production on 07-DEC-2012 17:31:27 Copyright (c) 1991, 2011, Oracle. All rights reserved. Welcome to LSNRCTL, type "help" for information. LSNRCTL> status Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1523))) STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR for Solaris: Version 11.2.0.3.0 - Production Start Date 07-DEC-2012 17:26:44 Uptime 0 days 0 hr. 4 min. 46 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Listener Parameter File /oracle11g/app/oracle/product/11.2.0.3/db_se/network/admin/listener.ora Listener Log File /oracle11g/app/oracle/diag/tnslsnr/jdesun/listener/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1523))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=acme)(PORT=1523))) The listener supports no services The command completed successfully LSNRCTL> exitNotiamo che il LISTENER ha caricato le impostazione dale nuove librerie della SE.
Prima di eseguire lo start del database ho provveduto a modificare il path della versione EE per verificare se l’istanza viene caricata con le nuove library della versione SE.
Quindi dalla shell Solaris eseguo il comando:
mv -R /app/oracle/product/11.2.0.3/dba_1 /oracle11g/app/oracle/product/11.2.0.3/dba_ee
6) Adesso posso eseguire lo startup dell’istanza eseguendo il login come SYS.
sqlplus “/ as sysdba” SQL*Plus: Release 11.2.0.3.0 Production on Sun Dec 9 14:52:55 2012 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Release 11.2.0.3.0 - 64bit Production StartupVerificare con il commando l’esito con:
SELECT BANNER FROM V$VERSION; BANNER ------------------------------------------------- Oracle Database 11g Release 11.2.0.3.0 - 64bit Production PL/SQL Release 11.2.0.3.0 - Production CORE 11.2.0.3.0 TNS for Solaris: Version 11.2.0.3.0 - Production NLSRTL Version 11.2.0.3.0 - ProductionEnterprise Manager Console
Ho verificato inoltre la disponibilità del EMC di Oracle , facendo emctl stop dbconsole e successivamente emctl start dbconsole.
Compare un errore per la mancanza della cartella JDESUN_JDE900 nella nuova ORACLE_HOME SE.
copio da /oracle11g/app/oracle/product/11.2.0.3/db_1_ee/JDESUN_JDE900 in /oracle11g/app/oracle/product/11.2.0.3/db_se/ con
cp -R JDESUN_JDE900 /oracle11g/app/oracle/product/11.2.0.3/db_se/
Faccio un controllo per un eventuale cambio di permission e di owner da parte OS.
emctl start dbconsole OC4J Configuration issue. /oracle11g/app/oracle/product/11.2.0.3/db_se/oc4j/j2ee/OC4J_DBConsole_JDESUN_JDE900 not found.Copio /oracle11g/app/oracle/product/11.2.0.3/db_1_ee/oc4j/j2ee in /oracle11g/app/oracle/product/11.2.0.3/db_se/oc4j/j2ee
cp -R OC4J_DBConsole_JDESUN_JDE900 /oracle11g/app/oracle/product/11.2.0.3/db_se/oc4j/j2ee
emctl start dbconsole https://JDESUN:5500/em/console/aboutApplication Starting Oracle Enterprise Manager 11g Database Control ............................................................................................. failed. ------------------------------------------------------------------ Logs are generated in directory /oracle11g/app/oracle/product/11.2.0.3/db_se/JDESUN_JDE900/sysman/logApro il log per verificare l'errore:
2012-12-10 11:33:16,255 Thread-85 ERROR engine: [host,JDESUN,PagingActivity] : nmeegd_GetMetricData failed : /oracle11g/app/oracle /product/11.2.0.3/db_1/bin/nmupm: not found 2012-12-10 11:33:16,255 Thread-85 WARN collector: <nmecmc.c> Error exit. Error message: /oracle11g/app/oracle/product/11.2.0.3/db _1/bin/nmupm: not found 2012-12-10 11:33:16,256 Thread-85 ERROR command: "/oracle11g/app/oracle/product/11.2.0.3/db_1/bin/nmupm" file not found, launch aborted due to (errno=2: No such file or directory)Andando a verificare ho visto che EM puntava ancora ai vecchi binari della EE nel path ..../db_1/...che però precedentemente per sicurezza avevo modificato in db_1ee
Ad istanza già avviata ho rinominato da .../db_1ee/... in .../db_1/... e rilanciato:
$ emctl start dbconsole Oracle Enterprise Manager 11g Database Control Release 11.2.0.3.0 Copyright (c) 1996, 2011 Oracle Corporation. All rights reserved. https://JDESUN:5500/em/console/aboutApplication Starting Oracle Enterprise Manager 11g Database Control ..... started. ------------------------------------------------------------------ Logs are generated in directory /oracle11g/app/oracle/product/11.2.0.3/db_se/JDESUN_JDE900/sysman/logEseguo il login con l’utente per esempio SYS creato precedentemente.
Noto che effettivamente trattandosi di un SE non posso entrare nel menu Performance abilitato solo per la versione EE.
Ovviamente questo si tratta di un test manuale su come cambiare EMC dalla EE alla SE, esiste sempre e comunque la soluzione classica eseguendo:
emca -deconfig dbcontrol db -repos drope successivamente
emca -config dbcontrol db -repos create
Aspetto commenti e ulteriori test...
2 commenti:
Il documento MOS a cui fai riferimento: 117048.1, parla della conversione da Standard a Enterprise.
Tu senza farti troppi scrupoli passi da una Enterprise ad una Standard, magari funziona abbastanza, ma Oracle nella nota "Converting An Enterprise Edition Database To Standard Edition [ID 139642.1]" dichiara che in questo caso l'unico metodo certificato richiede l'export/import del database.
Ciao Roberto, in effetti l'unico modo certificato come dichiarato da Oracle è imp/exp anche se mi lascia molti dubbi in merito. Nella prova che ho effettuato l'istanza creata prima con la EE e poi passata in SE funziona molto bene.
Secondo me, quando si esegue questa operazione non occorre far nulla perchè caricando le librerie della SE vengono disabilitati comunque quelle della EE e quindi tutte le funzioni associate.
Nel mio Data Dictionary non ci sono oggetti invalidi ovviamente con le SE non verranno chiamati, sono sempre lì ma non danno problemi.
In effetti questa frase dell'articolo "After the Import in the Standard Edition database, you only need to drop all user schemas related to Enterprise Edition features, such as the MDSYS account (used with Oracle Spatial)." secondo me rafforza la mia ipotesi che comunque poi Oracle ti faccia cancellare manualmente tutti gli oggetti relativi alla EE.
E' chiaro concludendo che si tratta di un test quindi o si installa la EE o la SE, e in un'ambiente di PROD non possono coesistere. In una possibile migrazione tutto questo è reso ancora più agevole se non si usano delle features di struttura dati relative alla EE, come per esempio il Partitioning.
Inoltre ho installato la stessa patch la 14585499 per la
11.2.0.3 in entrambi gli ambienti senza problemi, prima nella SE e poi nella EE.
Posta un commento