Appendix C: Oracle Tablespaces

For Oracle databases, CIC Database Migration Assistant uses the following tablespaces:

• ININ data/index tablespaces: The tablespaces where database objects for the ININ_MIGRATION schema reside.

• Target data/index tablespaces: The tablespaces where CIC 4.0 data and database objects (tables, indexes, stored procedures) reside.

The data and index tablespaces lay out logical storage locations, which tie to physical storage locations by way of the Oracle tablespace configuration. Table data reside in the data tablespaces, and index data reside in the index tablespaces. The system uses CIC 2015 R1 or later data/index tablespaces for data that are specific to the 2015 R1 or later database that you are migrating into. The ININ data/index tablespaces contain information for all database migrations, not specific to any 2015 R1 or later schema. While the schema name (ININ_MIGRATION) does logically separate the migration history data from other CIC 2015 R1 or later schemas, using separate ININ data and index tablespaces allows you to specify separate storage locations. The separate storage locations allow you to take one CIC 2015 R1 or later schema and its attendant tablespaces offline without disturbing the ININ_MIGRATION historical migration information.

The ININ data/index tablespaces can be the same as the CIC 2015 R1 or later data/index tablespaces, but Genesys recommends that they be different. The data stored in the ININ data/index tablespaces are migration progress log entries for the Interaction Recorder and Customer Satisfaction Survey migrations, and some table-specific migration history data.

The tables and indexes that the migration process creates reside in the ININ data/index tablespaces and contain data related only to migrating data into specific schemas that use those tablespaces.

Typically, Genesys recommends that any single CIC 2015 R1 or later schema have its own data and index tablespace so that disk space is managed independently for each 2015 R1 or later schema. Migrating CIC 3.0 data into a CIC 2015 R1 or later schema creates tables that do key mapping/translation between 3.0 primary/foreign keys and 4.0 primary/foreign keys. The key translation tables are in the same tablespace because they are related directly to the 2015 R1 or later data.

The following example illustrates why it is a good idea to separate the CIC 2015 R1 or later tablespaces from the ININ tablespaces. Let's say a single Oracle instance hosts 3 different CIC 4.0 schemas, one for a different CIC server. One schema is for production, another for special projects, and a third for testing out CIC 2015 R1 or later. Let's say also that each of those schemas has their own data and index tablespaces. At one point, you migrate some data from a CIC 3.0 database to the 2015 R1 or later test schema for evaluation purposes. Once you complete testing, the test schema and tablespaces are wiped clean or deleted. The production system goes live, and data migrates from a CIC 3.0 schema to the 2015 R1 or later production schema. In that scenario, if the ININ data/index tablespaces were the same ones as the 2015 R1 or later test schema's tablespaces, migration history and logging is lost. If the ININ data/index tablespaces were not any of the 2015 R1 or later tablespaces (test/evaluation, special projects, production), that history and log is not lost regardless of what happens to the other schemas and their tablespaces.

Losing the data in the ININ tablespaces does not prevent any future migrations from completing successfully. So, it is not required for the ININ tablespaces to be separate and protected.