Multiple db2unit versions in a database

Each release of this framework will have its own schema, this allows to have multiple versions of this framework in a single database. This fact will ease the migration process of the other stored procedures or functions being tested, because they do not have to be modified in order to be adapted to the new version.

Once you are sure a given version of this framework is not longer used in your database, you could uninstall it.

Installation with restrictive rights

You can install this framework in a database where you do not have DBADM authority. However, the DBA should have created for you different objects and have granted you the necessary rights to use them. The DBA should execute the file 01-ObjectsAdmin.sql and additionally give you the following rights:

grant execute on module LOGGER_1RC.logadmin to user USERNAME;
grant execute on module LOGGER_1RC.logger to user USERNAME;

grant createtab on database to user USERNAME;
grant createin on schema DB2UNIT_1 to user USERNAME;
grant use of tablespace MAX_VALUES_TS to user USERNAME

The user that will create this framework should have the necessary rights to create objects in the assigned schema. In a similar way, the user that installs this framework should have access to log4db2.

Once you have these rights, you can install the utility with the -A option (Non-administrative objects.)

install -A

Install with a fake log4db2

If you do not want to use log4db2 (something that is not recommended to do), you can install a fake one from: https://github.com/angoca/log4db2/tree/master/src/examples/sql-pl/disable. The files there allow you to create the necessary tables and empty procedures to simulate log4db2. db2unit will use the fake procedures, and this will not generate any negative impact on peformance or functionality. Instead, you will not get any operation log of db2unit, something that could help you to get messages to explain the behavior of the tool.

Steps to check log4db2

When installing db2unit, there are several steps to check if that log4db2 is already installed. If that framework is not present, or incorrectly installed, you can face an error like this:

log4db2 is not installed. Step X

X represents any of the following steps of the check process:

  1. Check LOGGER module in LOGGER_X schema.
  2. Check public LOGGER module.
  3. Check LOG procedure in LOGGER module.
  4. Check GET_LOGGER procedure in LOGGER module.
  5. Check date.
  6. Test the log4db2 procedures for no errors.

Memory and storage distribution

The installation process creates several tables in the default tablespace which is normally a 4KB pagesize. It does not assign any tablespace for those configuration tables. You can modify the installation scripts in order to assign your own tablespaces instead of using a default tablespace.

There is an additional tablespace, for a big table, but this is only used for anchoring datatypes. You can put that table in another tablespace that fit that page size (32KB). Anyway, that table will never store data.

All schemas, tablespaces and bufferpools are defined in the 01-ObjectsAdmin.sql. If you do not have the necessary right to create these objects in the database, you can give this script to your DBA to create the necessary objects.