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à:
- Amministratore del server che accede all'istanza di Cloudscape
- Una umask che possa accedere all'istanza di database
Altrimenti, è possibile che si verifichino errori di runtime secondo i quali l'istanza di database è di sola lettura.
Procedura
- 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.
- Solo per il framework Network Server: Mettere offline il database. Nessun client può accedervi durante il processo di migrazione.
- 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:

Sulle piattaforme Linux® e UNIX®: Utilizzare lo script db2jmigrate.sh che si trova nella seguente directory: install_root/derby/bin/embedded/...
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.
- 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.
- 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.
- Selezionare il nome del server.
- Fare clic su Dettagli modifica livello di log.
- Opzionale: Se è stato abilitato Tutti i componenti, è consigliabile disattivarlo e abilitare i componenti specifici.
- 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.
- 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.
- Selezionare Applica, quindi OK.
- 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.
- 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)
- 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
- Per i database la cui migrazione non è riuscita, risolvere i problemi secondo i dati di errore registrati. Quindi eseguire di nuovo lo script di migrazione.
- Per accedere mediante il framework embedded ai database la cui migrazione è riuscita, modificare le origini dati in modo che puntino ai nuovi nomi di database.
- Per accedere mediante il framework Network Server ai database la cui migrazione è riuscita,
è possibile utilizzare il driver JDBC DB2 Universal oppure il driver JDBC Derby Client.
- Se si desidera che le proprie configurazioni JDBC esistenti continuino a utilizzare il driver JDBC DB2 Universal, modificare le origini dati in modo che puntino ai nuovi nomi di database.
- Se si desidera utilizzare il driver JDBC Derby Client, che può supportare le origini dati XA, modificare i provider JDBC in modo che utilizzino la nuova classe driver JDBC Derby Client e le nuove classi di implementazione delle origini dati.
Quindi riconfigurare tutte le origini dati esistenti in modo che utilizzino le classi helper di origine dati Derby corrette e puntino al nuovo nome del database.
Consultare la sezione Impostazioni necessarie minime per l'origine dati, per vendor
nel Centro informazioni di WebSphere Application Server Network Deployment, Versione 6.1 per tutti i nuovi nomi di classe.
- Eseguire gli script di upgrade del database nella directory install_root/dbscripts/nome_componente/Derby per eseguire l'upgrade delle tabelle e dello schema del database al livello di WebSphere ESB versione 6.2.
Per ulteriori informazioni, consultare Esecuzione dell'aggiornamento dei database per la migrazione.