Source Environment Tracking

All records in the Oracle Health Insurance database have four audit columns. These capture the date on which the record was created, the user that created it, the date that the record was last updated and the user that last updated it. The user fields are keys to the Oracle Health Insurance user table.

When a new record is created as a result of an imported migration set, the user(s) and time stamps stored in the standard auditing columns are in context of the target environment; these fields do not store auditing information pertaining to the source environment. For this reason, the configuration items that can be selected for migration have eight additional auditing fields. These fields are on both top level and dependent detail items. The comprehensive list of items that are extended with these fields can be found in Creating a Migration Set. The following eight fields are stored for configuration records on a target environment:

Field	Type	Description
src_created_by	char	user that created the record on the original source environment
src_created_date	date	date that the record was created on the original source environment
created_by_data_set	char	code of the data set that led to the creation of this record
created_by_environment	char	code of the source environment of the data set that led to the creation of this record
src_last_updated_by	char	user that last updated the record on the original source environment
src_last_updated_date	date	date that the record was last updated on the original source environment
last_updated_by_data_set	char	code of the data set that led to the last update of this record
last_updated_by_environment	char	code of the source environment of the data set that led to the last update of this record

These fields are present in both the source and target environments, but only the records in the target environment will have values. The two fields that capture a user store a character string with the user login name as provisioned on the source environment. The two fields that capture the source environment store a character string with the SID of the database on which the source environment is running.

Consider the following example. The source environment database is identified by the character string "SRCE". The target environment database is identified by the character string "TRGT". The migration set is identified by the character string "MIG01" and is imported on the target environment on 01-AUG-2012 by user WILLIAMS. The table shows the auditing columns including the four 'standard' columns, for both environments, in context of an arbitrary configuration rule. The rule is originally created in the source environment and is migrated to the target environment, where it did not exist prior to the migration.

Fields	SRCE	TRGT
created_by*	key to JONES	key to WILLIAMS
creation_date*	05-JUL-2012	01-AUG-2012
last_updated_by	key to HUGHES	key to WILLIAMS
last_updated_date	07-JUL-2012	01-AUG-2012
src_created_by*	no value	JONES
src_creation_date*	no value	05-JUL-2012
created_by_data_set*	no value	MIG01
created_by_environment*	no value	SRCE
src_last_updated_by	no value	HUGHES
src_last_updated_date	no value	07-JUL-2012
last_updated_by_data_set	no value	MIG01
last_updated_by_environment	no value	SRCE

The fields marked by a (*) are never updated. The unmarked fields may be updated by future migrations that hold an update for this particular configuration item.

It is possible that a target environment also acts as a source environment for another target environment. In this scenario the values of the additional "src" auditing columns transcend from one environment to another.

Consider the following example. The table shows the auditing columns for three environments in context of an arbitrary configuration rule that was originally created on environment A, was then migrated to environment B on 01-AUG-2012 by user WILLIAMS and finally migrated from B to environment C on 20-AUG-2012 by user JACKSON.

Fields	A	B	C
created_by	key to JONES	key to WILLIAMS	key to JACKSON
creation_date	05-JUL-2012	01-AUG-2012	20-AUG-2012
last_updated_by	key to HUGHES	key to WILLIAMS	key to JACKSON
last_updated_date	07-JUL-2012	01-AUG-2012	20-AUG-2012
src_created_by	no value	JONES	JONES
src_creation_date	no value	05-JUL-2012	05-JUL-2012
created_by_data_set	no value	MIG_A_TO_B	MIG_B_TO_C
created_by_environment	no value	A	B
src_last_updated_by	no value	HUGHES	HUGHES
src_last_updated_date	no value	07-JUL-2012	07-JUL-2012
last_updated_by_data_set	no value	MIG_A_TO_B	MIG_B_TO_C
last_updated_by_environment	no value	A	B

It is also possible that the migrated item already exists on the target environment. This can be the result of manually keying in the same configuration or of a previous migration. In such a situation the migration function only assigns values to the six 'last_updated' fields.

Consider the following example. The table shows the auditing columns for two environments in context of an arbitrary configuration rule that was originally created on environment A, was then migrated to environment B on 01-AUG-2012 by user WILLIAMS and finally migrated back from B to environment A on 01-SEP-2012 by user JACKSON.

Fields	A	B	A
created_by	key to JONES	key to WILLIAMS	key to JONES
creation_date	05-JUL-2012	01-AUG-2012	05-JUL-2012
last_updated_by	key to HUGHES	key to WILLIAMS	key to JACKSON
last_updated_date	07-JUL-2012	01-AUG-2012	01-SEP-2012
src_created_by	no value	JONES	no value
src_creation_date	no value	05-JUL-2012	no value
created_by_data_set	no value	MIG_A_TO_B	no value
created_by_environment	no value	A	no value
src_last_updated_by	no value	HUGHES	HUGHES
src_last_updated_date	no value	07-JUL-2012	07-JUL-2012
last_updated_by_data_set	no value	MIG_A_TO_B	MIG_B_TO_A
last_updated_by_environment	no value	A	B