WebSphere Enterprise Service Bus, Versione 6.2.0 Sistemi operativi: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Esecuzione manuale dell'aggiornamento di Cloudscape

Durante l'upgrade di WebSphere ESB versione 6.2, gli strumenti di migrazione tentano di eseguire l'upgrade solo delle istanze di Cloudscape a cui si accede attraverso il framework embedded. La nuova versione di Cloudscape è la versione 10.1.x, basata su Derby. L'aggiornamento automatico esclude le istanze di Cloudscape che eseguono transazioni con i server attraverso il framework Network Server. Questa esclusione elimina il rischio di danneggiare applicazioni di terze parti che accedono alle stesse istanze di database di WebSphere ESB È necessario eseguire manualmente l'aggiornamento delle istanze del database a cui si ha accesso attraverso il framework Network Server. Altrettanto vale per i database la cui migrazione automatica non riesce.

Prima di iniziare

Non utilizzare Cloudscape v10.1.x come database di produzione. Utilizzarlo solo per scopi di sviluppo e test.

Per saperne di più: La nuova versione di Cloudscape combina il runtime Derby con vantaggi aggiuntivi, come IBM® QA (Quality Assurance) e NLS (National Language Support).
  • Per informazioni sulla code base open source di Cloudscape v10.1.x, vedere le pagine Web del prodotto Cloudscape..
  • Per informazioni sulle incompatibilità tra Cloudscape v10.1.x e v5.1.60x (e le versioni precedenti alla v5.1.60x) consultare Migrazione di IBM Cloudscape alla Versione 10.
Per le istanze di Cloudscape a cui si ha accesso attraverso il framework embedded, determinare per quali il processo di aggiornamento automatico non è riuscito per nulla e per quali è stato eseguito un aggiornamento parziale. La sezione Verifica della migrazione automatica di Cloudscape v10.1.x indica come recuperare gli errori e i dati diagnostici dei database dai vari log di migrazione. I messaggi dei log contengono sia il nome di percorso precedente del database che quello nuovo, che devono essere utilizzati per eseguire la migrazione manuale. Annotare con precisione questi nomi di percorso.

Per ridurre al minimo il rischio di errori di migrazione per i database di cui è stato eseguito solo un aggiornamento parziale durante il processo di migrazione automatica, eliminare il nuovo database. Risolvere i problemi relativi al nuovo database secondo i dati diagnostici dei log, quindi eseguire la migrazione manuale del database originario.

Informazioni su questa attività

La sezione seguente illustra i passaggi per la migrazione delle istanze di Cloudscape a cui si accede mediante entrambi i framework, sia embedded che Network Server. I passaggi applicabili solo al framework Cloudscape Network Server sono indicati come tali. Come migliore pratica per la migrazione, assicurarsi che il proprio ID utente abbia una delle seguenti autorità: Altrimenti, è possibile che si verifichino errori di runtime secondo i quali l'istanza di database è di sola lettura.
Procedura
  1. Solo per il framework Network Server: Assicurarsi che tutti i client del database Cloudscape possano supportare Cloudscape v10.1.x. I client WebSphere ESB del database devono avere in esecuzione la versione 6.0.1.x o superiore di WebSphere ESB.
  2. Solo per il framework Network Server: Mettere offline il database. Nessun client può accedervi durante il processo di migrazione.
  3. Prendere in esame uno script di migrazione di Cloudscape di esempio fornito da WebSphere ESB. In base al sistema operativo, WebSphere ESB fornisce uno dei seguenti script di migrazione:
    • For Linux operating systemFor UNIX operating system Sulle piattaforme Linux® e UNIX®: Utilizzare lo script db2jmigrate.sh che si trova nella seguente directory: install_root/derby/bin/embedded/...
    • For Windows operating system Sulle piattaforme Windows®: Utilizzare lo script db2jmigrate.bat che si trova nella seguente directory: install_root\derby\bin\embedded\...
    È possibile modificare lo script secondo i requisiti del proprio ambiente. Consultare Migrazione di IBM Cloudscape alla Versione 10 per informazioni sulle opzioni che possono essere utilizzate con lo script. Per esempio, è possibile utilizzare l'opzione -DB2j.migrate.ddlFile=nomefile per specificare il file DDL per il nuovo database.
  4. Per generare log di debug del database durante l'esecuzione dello script di migrazione, assicurarsi che la traccia di debug di migrazione sia attiva. Per impostazione predefinita, questa funzione di tracciamento è abilitata. Riattivare la traccia di debug se è disabilitata.
    1. Per impostare le opzioni di traccia nella console di gestione, fare clic su Risoluzione dei problemi > Accesso e tracciamento nella struttura ad albero di navigazione della console.
    2. Selezionare il nome del server.
    3. Fare clic su Dettagli modifica livello di log.
    4. Opzionale: Se è stato abilitato Tutti i componenti, è consigliabile disattivarlo e abilitare i componenti specifici.
    5. Opzionale: Selezionare il nome di un gruppo o componente. Per ulteriori informazioni, consultare Impostazioni del livello di registrazione nel Centro informazioni di WebSphere Application Server Network Deployment, Versione 6.1. Se il server selezionato non è in esecuzione, non sarà possibile vedere i singoli componenti in modalità grafica.
    6. Immettere una stringa di traccia nella casella della stringa di traccia. In questo caso, immettere una delle seguenti:
      • all traces*=all
      • com.ibm.ws.migration.WASUpgrade=all

      Per ulteriori informazioni sul tracciamento, consultare Utilizzo della traccia nel Centro informazioni di WebSphere Application Server Network Deployment, Versione 6.1.

    7. Selezionare Applica, quindi OK.
  5. Specificare il nome precedente del database e il percorso completo post-migrazione del nuovo nome del database quando si esegue lo script. Per esempio: E:\WebSphere\ProcServer\derby\bin\embedded>db2jMigrate.bat VecchioDB NuovoDB I log della migrazione automatica forniscono i nomi di percorso esatti da specificare sia per il database precedente che per il database di destinazione. È necessario utilizzare questo nuovo nome di database di destinazione per specificare il nuovo database, in quanto le origini dati migrate di Cloudscape (aggiornate dalle utilità di migrazione di WebSphere ESB) ora puntano al nome del database di destinazione. Il testo di esempio seguente mostra come vengono visualizzati i nomi dei database di destinazione nei messaggi di log:
    Cloudscape migration of database instance C:\temp\migration2\profiles\Srv01\
    installedApps\ghongellNode01Cell\DynamicQuery.ear\EmployeeFinderDB to 
    new database instance C:\WebSphere\ESB
    \profiles\Srv01\databases\C__WAS602_ProcServer_profiles_ProcSrv01_
    installedApps_ghongellNode01Cell_DynamicQuery.ear_
    EmployeeFinderDB failed, reason: java.sql.SQLException: 
    Failure creating target db
    Per le istanze di Cloudscape a cui si ha accesso attraverso il framework Network, immettere un nome qualsiasi di propria scelta per il nuovo database. Ricordare di modificare le origini dati esistenti in modo che puntino al nuovo nome del database.
  6. Al termine del processo di migrazione, esaminare i log di migrazione del database per verificare i risultati. Il nome di percorso di ciascun log di migrazione del database è install_root/logs/derby/nomePercorsoCompletoDB_migrationLog.log.
    In caso di migrazione riuscita, il log di migrazione database mostra un messaggio simile al testo seguente:
    Check E:\WebSphere\ESB\derby\myOldDB_migrationLog.log for progress 
    Migration Completed Successfully 
    E:\WebSphere\ESB\derby\bin\embedded>
    Altrimenti, il log mostra messaggi di errore nel formato riportato nell'esempio seguente:
    Check E:\WebSphere\ESB\derby\myOldDB_migrationLog.log for progress
    ERROR: An error occurred during migration. See debug.log for more details.
    ERROR XMG02: Failure creating target db
    java.sql.SQLException: Failure creating target db
        at com.ibm.db2j.tools.migration.MigrationState.getCurrSQLException(Unknown 
        Source)
        at com.ibm.db2j.tools.migration.MigrateFrom51Impl.handleException(Unknown
        Source)
        at com.ibm.db2j.tools.migration.MigrateFrom51Impl.go(Unknown Source)
        at com.ibm.db2j.tools.migration.MigrateFrom51Impl.main(Unknown Source)
        at com.ibm.db2j.tools.MigrateFrom51.main(Unknown Source)
  7. Per maggiori dettagli su un errore di migrazione, consultare il log di debug corrispondente al log di migrazione database. Il nome completo del percorso di un log di debug è install_root/logs/derby/nomePercorsoCompletoDB_migrationDebug.log
    Le righe seguenti sono un esempio di testo di debug.
    sourceDBURL=jdbc:db2j:E:\WebSphere\myOldDB
     newDBURL=jdbc:derby:e:\tempo\myNewDB
     ddlOnly=false
    connecting to source db <jdbc:db2j:E:\WebSphere\myOldDB>
    connecting to source db <jdbc:db2j:E:\WebSphere\myOldDB> took   0.611 seconds
    creating target db <jdbc:derby:e:\tempo\myNewDB>
    creating target db <jdbc:derby:e:\tempo\myNewDB> took   6.589 seconds
    initializing source db data structures
    initializing source db data structures took   0.151 seconds
    recording DDL to create db <E:\WebSphere\myOldDB>
    recording DDL to create db <E:\WebSphere\myOldDB> took   5.808 seconds

Risultati

Come indicato nei passaggi precedenti, il log di migrazione database visualizza un messaggio Migration Completed Successfully oppure un messaggio contenente eccezioni di migrazione non riuscita.

Operazioni successive


task Argomento Attività

Termini di utilizzo | Feedback


Icona data/ora Ultimo aggiornamento: 02 Luglio 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/tdat_vtv_mancloudsmig.html
Copyright IBM Corporation 2005, 2010. Tutti i diritti riservati.
Questo centro informazioni utilizza la tecnologia Eclipse. (http://www.eclipse.org).