Db2: increasing the page size

You can increase the page size for your tablespace in Db2.

1. Export the data from the tables listed in the Table 1 to a temporary dump file. Table 1 lists the history tables and transaction tables for which you must increase the page size. For sharded environments, Table 1 provides the tabletype for each table.

   Table 1. Increasing page size for tables

   Table	Tabletype	Name of Table
   History Tables	TRANSACTION	yfs_payment_h yfs_promotion_award_h
   Transaction Tables	TRANSACTION	yfs_payment yfs_inbox yfs_promotion_award
   	MASTER	yfs_category yfs_item_locale yfs_customer_payment_method
   	CONFIGURATION	yfs_sourcing_rule_dtl plt_property_metadata

   Note: In a sharded environment, the tables mentioned earlier may exist in multiple shards for multiple colonies. For example, in a sharded environment with two colonies, the transaction shards for Colonies 1 and 2 contain the yfs_payment_h tables.

   Note: When altering tables that have a lot of extensions, check whether the page size for such tables would change after the alteration is done. If the page size changes, you must increase the page size for the tables, as described in this section.

   Note: When you drop a table, the associated views are also deleted. After you increase the page size for the tables, ensure that you recreate any views that were deleted.
2. Drop the tables that are specified in step 1 from the database. If upgrading in sharded mode, drop the tables from each shard, which contains the tables, for each colony.
3. After running the initupgrade task, remove the alters for the tables specified in step 1.
   In a nonsharded environment, alters are found in the following directories:

   • <INSTALL_DIR>/Migration/9.5/database/scripts/db2/history contains alters for the history tables.
   • <INSTALL_DIR>/Migration/9.5/database/scripts/db2/transaction contains alters for the transaction tables.

   In a sharded environment, alters are found in the following directories:

   • <INSTALL_DIR>/Migration/9.5/database/scripts/db2/history/TRANSACTION contains alters for all history tables of the TRANSACTION tabletype, such as the yfs_payment_h table.
   • <INSTALL_DIR>/Migration/9.5/database/scripts/db2/transaction/MASTER contains alters for all transaction tables of the MASTER tabletype, such as the yfs_category table.
   • <INSTALL_DIR>/Migration/9.5/database/scripts/db2/transaction/CONFIGURATION contains alters for all transaction tables of the CONFIGURATION tabletype, such as the yfs_sourcing_rule_dtl table.
   • <INSTALL_DIR>/Migration/9.5/database/scripts/db2/transaction/TRANSACTION contains alters for all transaction tables of the TRANSACTION tabletype, such as the yfs_inbox table.
4. To copy existing extensions from <INSTALL_DIR_OLD> to <INSTALL_DIR>, such as:
   • Theme, CSS, Config resources, Data types files, and so forth
   • Extended APIs, Events, and XSL templates
   • Modifications made in the database, resources, and template directories

     Rebuild the resources.jar file by running the deployer.sh utility (or deployer.cmd on Windows) from the <INSTALL_DIR>/bin directory. For example:

     
     ./deployer.sh -t resourcejar 
     

5. After running the history and transaction alters, run the dbverify script. To prevent dbverify from generating "IndexAdds" SQLs for dropped indexes, ensure that the dropped indexes are listed in the <INSTALL_DIR>/extensions/schemagenerator/indexes_not_created.txt file. Or, if the INDEXES_NOT_CREATED property in the <INSTALL_DIR>/properties/sandbox.cfg file is configured, add the list of dropped indexes to the file referenced by the property.
6. Execute the SQLs generated by the dbverify script in your database.
7. Import the data exported in step 1 into your database.