Database considerations

 

+

Search Tips   |   Advanced Search

 

Portal's out-of-box database is Apache Derby.

Derby is a built-in Java database that...

• provides a small footprint
• is self tuning
• works for solutions where the database must be hidden

Derby works in a non-clustered environment with a small number of users, such as a portlet development or testing environment or a proof-of-concept environment.

The Derby database that is installed by default is not intended for use in a production environment or for authoring Web content.

While using one database is supported, for high performance and availability, use multiple databases. Derby does not support clustered environments, enabling security in a database-only mode, or vertical cloned environments in which multiple application servers are configured on a single server. Use one of the other supported databases in a production environment or when authoring Web content, as they are better able to handle large amounts of data and can be tuned for performance.

With appropriate tuning, other databases can provide performance gains. Other databases support vertical and horizontal clusters and cloning. Use multiple databases for high performance and availability.

Other databases require increased CPU and memory resources and add complexity to the configuration environment.

When you choose to transfer data to another supported database, perform the database transfer before you use the portal extensively. Large amounts of data in the databases can cause the database transfer to fail if your Java heap size is not large enough. Because information is added to the databases as you use the portal, perform the database transfer as soon as it is practical to avoid problems in a production environment.

Data can be transferred from a Derby database, but cannot be transferred to a Derby database.

If you are transferring from a database other than the default database, you will need to edit...

• wkplc_comp.properties
• wkplc_dbtype.properties

...to update the source and target database information.

 

Permissions gotcha

If you get error similar to...

[exec] [java] [01/13/10 11:24:11.275 PST] Transferring table --{ RELEASE.PAGE_INST_DD}-- to table --{E_RELEASEUSR.PAGE_INST_DD }--3408
01/13/10 01:27PM EXEC [exec] [java]
[01/13/10 11:24:11.384 PST] Transferring table --{ RELEASE.CTX_CLBCTX}-- to table --{E_RELEASEUSR.CTX_CLBCTX }--3409
01/13/10 01:27PM EXEC [exec] [java]
[01/13/10 11:24:11.456 PST] Transferring table --{ RELEASE.CTX_DMNOBJREF}-- to table --{E_RELEASEUSR.CTX_DMNOBJREF }--3410
01/13/10 01:27PM EXEC [exec] [java]
[01/13/10 11:24:11.571 PST] ERROR: Error occurred gathering data from the source database3411
01/13/10 01:27PM EXEC [exec] [java] java.lang.NullPointerException3412
01/13/10 01:27PM EXEC [exec] [java] at db2j.y.aq._b29(Unknown Source)3413
01/13/10 01:27PM EXEC [exec] [java] at db2j.y.aq.openContainer(Unknown Source)3414
01/13/10 01:27PM EXEC [exec] [java] at db2j.q.g.openContainer(Unknown Source)3415
01/13/10 01:27PM EXEC [exec] [java] at db2j.h.g.readConglomerate(Unknown Source)3416
01/13/10 01:27PM EXEC [exec] [java] at db2j.z.e.conglomCacheFind(Unknown Source)3417
01/13/10 01:27PM EXEC [exec] [java] at db2j.z.a.z_(Unknown Source)3418
01/13/10 01:27PM EXEC [exec] [java] at db2j.z.a.openStoreCost(Unknown Source)3419
01/13/10 01:27PM EXEC [exec] [java] at db2j.cu.a.getStoreCostController(Unknown Source)3420
01/13/10 01:27PM EXEC [exec] [java] at db2j.b.bm.jf_(Unknown Source)3421
01/13/10 01:27PM EXEC [exec] [java] at db2j.b.bm.estimateCost(Unknown Source)3422
01/13/10 01:27PM EXEC [exec] [java] at db2j.bw.h._z21(Unknown Source)3423

The root cause of this failure might be due to permissions on a log file in cloudscape/wpsdb/log. The permissions error can be caused if the initial install was done as a privileged user and the associated portal server that was part of the install is still running when the db-transfer is initiated.

To fix, stop portal and change appropriate file ownership and permissions before before executing the transfer.

Portlet Not Available

If you have performed database transfer in a clustered environment, explicitly copy...

wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/icm.properties

...from the primary node on which the database-transfer task was processed to all secondary nodes. This ensures that the secondary nodes have the new JCR database values specified in the icm.properties file.

1. Stop the portal server on the secondary node.

2. Copy...
   wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/icm.properties

   ...from the primary node and replace the icm.properties file on the secondary node with the new file from the primary node.

3. Start the portal server on the secondary node.

 

See also

1. Database topologies
2. Planning for databases

 

Parent topic

Planning for WebSphere Portal