Some time after a database design has been implemented, you may be considering a change to the database design. As a result, you should reconsider the major design issues that you had with the previous design. You should consider the following:
Before you make changes affecting the entire database, you should review all the logical and physical design decisions. For example, when altering a table space, you should review your design decision regarding the use of SMS or DMS storage types. (See "Designing and Choosing Table Spaces".)
You must consider which environment variables (if any) need to be changed on your particular operating system. If any environment variables are changed, you need to restart the system for the new environment variables to take effect. Review whether you should reset the profile registry variables in the Global Profile registry before altering your database. You can then reset the profile registry variables to those that are best suited to the new database environment. If only profile registry variables have been changed, the system does not need to be restarted.
If you are planning changes to any nodegroups (both adding or deleting nodes, or moving existing nodes), you should see Chapter 17. "Scaling Your Configuration" for details on what should be done.
If you are planning changes to the database, you should review the values for the configuration parameters. Some of the values can be adjusted from time-to-time as part of the ongoing changes made to the database based on how it is used.
To change the database configuration on the Windows NT and OS/2 platforms, use the Performance Configuration SmartGuide. This SmartGuide helps you tune performance and balance memory requirements for a single database per instance by suggesting which configuration parameters to modify and providing suggested values for them. To use this SmartGuide:
In most cases the values recommended by the Performance Configuration SmartGuide will provide better performance than the default values, because they are based on information about your workload and you own particular server. However, note that the values are designed to improve the performance of, though not necessarily optimize, your database system. They should be thought of as a starting point on which you can make further adjustments to obtain optimized performance.
For details on how to refine your system by benchmarking, and to configure your system, see Chapter 19. "Benchmark Testing" and Chapter 20. "Configuring DB2".
For multiple partitions: When you have a database that is partitioned across more than one partition, the configuration file should be the same on all database partitions. Consistency is required since the SQL compiler compiles distributed SQL statements based on information in the local node configuration file and creates an access plan to satisfy the needs of the SQL statement. Maintaining different configuration files on database partitions could lead to different access plans, depending on which database partition the statement is prepared. Use db2_all to create the same configuration file on all database partitions.