Database considerations

A simple development environment can rely on the out-of-box database configuration using Apache Derby. Installing with Derby lets you quickly get WebSphere Portal installed and running in a proof-of-concept environment. For a production environment, use one of the other supported Database Management Systems.

Data storage and failover become more complex as the network environment becomes complex. In a complex and high-demand environment, data may be distributed across multiple database servers for high-volume storage and failover configuration. For example, in a production environment, the demand for quick response time in a high-demand situation combined with the need for failover capability distributed across multiple database servers is likely to require transferring the database to a more robust server. Therefore, learn the limitations of using Derby and determine how transferring to another database affects the capacity and scalability of an environment. Also consider that the version of Derby provided with WebSphere Portal has stress and failover limitations that are expected to be resolved in a later release of Derby performance improvements.

Derby is a built-in Java database that provides a small footprint, is self tuning, and is ideal 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 because 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.

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 Java™ heap size is not large enough. Because information is added to the databases as you use the portal, perform database transfer as soon as you realize that a high volume of data needs to be stored and failover is necessary. Transferring the database sooner rather than later avoids the problems typically caused by transferring a high volume of data at a later stage to the other supported databases, including not having adequate Java heap size.

When using a database management system used by multiple applications, schedule database transfer activities and preparation to off-peak hours or maintenance windows. Shared system catalog tables are modified during database transfer work which prevents production applications from accessing data.

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 the wkplc_sourceDb.properties, wkplc_dbdomain and wkplc_dbtype.properties files to update the source database information as an additional step before attempting the database transfer functions.

Data cannot be transferred from DB2 for z/OSto any other supported database.


Parent

Plan to install WebSphere Portal

  Added the following note: "Important: Data cannot be transferred from ...


+

Search Tips   |   Advanced Search