Customer Master - Best Practice

Informatica MDM - 9.0.1 & XU SP 2

Version: DRAFT

Publication Record

Date
Revised
04/12/2010

Primary
Author
Manoj K

Version

Summary of Changes
Best Practice -Initial Draft

Best Practice -Siperian MDM

------------------------------------------------SP1- Are there any general guidelines/best practices for coding logic in user exits?

ANS
(1) A general recommendation for any code in a user exit procedure, or called from a
user exit procedure, is that the code should only use dynamic SQL statements and
no direct SQL statements, as Siperian drops and recreates various objects at runtime, which can cause Oracle to invalidate the packages.
(2) The range of error codes for user exit errors is -24314 to -24399. Do not raise
an exception within the user exit. Each of the user exits has a return code and
error message out parameter. These should be set to indicate an error.
SP2 -How do you do Schema Migration aka Environment Staging in Siperian?
ANS
Environment Staging (i.e. Schema Migration) Best Practices
Overview
Environment Staging is the process by which Hub Metadata is moved (or commonly termed
"migrated") from one Hub to another. Siperian customers design their environments to have
multiple Hubs which represent the "stages" of development and deployment. The Hub Metadata
is moved from development Hub to QA to Production and so forth.
Prior to XU SP1 environment staging was accomplished through a set of scripts. In XU SP1
migration is now done with Metadata Manager (MET) and the capability to move design objects in
between Hubs, environment staging can now be accomplished at a more fine grained level.

SP3-What are the best practices for tuning match rules?

Check the pdf.
SP4 -What is the best practice for adding classes to Metadata Manager?

In Metadata Manager, there are two ways to add the classes. They are:

Go to Administration Tab and click onClasses

Note

Avoid changing the out-of-the-box meta-model , as it will be overridden during the

upgrades.
Or

Go to the Find tab and in the Details pane, you can add properties to a Class.

Note

Use this option to add User Extensions to an existing class, as this will not be deleted
during upgrades.

SP5 -Best practices: Uninstalling Data Quality

Follow the steps mentioned below to uninstall Data Quality:

On the Data Quality Server:

1. Run StopV3Services
2. Check that the following Data Quality services have stopped in the processes:
o ImplRepo_Service
o Naming_Service
o ImR_Activator
o MySQL

On the Data Quality Server and Data Quality Client:

3. Backup any custom dictionaries you have created.
4. Backup the Data Quality license.bin file.
5. Export your Data Quality plans, making sure that you close Data Quality
Workbench when this is completed.
6. Run the Data Quality Uninstaller.

Note
It is a known issue that the Data Quality 8.6 uninstaller may hang (CR 182340).
This issue has been resolved in Data Quality 8.6 SP1.
If the issue persists, then kill the Data Quality Uninstaller using the Windows
Task Manager.

7. At a command prompt type net stop mysql.

8. Confirm that MySQL has actually stopped.
9. Delete the entire Informatica Data Quality directory.
10. Reboot the machine.
11. Reinstall Data Quality.

SP 6 -We have a need to create a new AM_HISTORY_DATA tablespace on history

Problem Description
We have a need to create a new AM_HISTORY_DATA tablespace on history
Cause
Solution
Scenario:
Your AM_HISTORY_D Data tablespace is growing in size. You wan to manage your
HISTORY database storage more effectively and efficiently.
Solution:
There is no standard configuration process in Informia Archive for maintaining additional
tablespaces in HISTORY. Once the tables are created, the Informia Archive product will
never move them or drop them, so Informia Archive does not need to know what
tablespace the HISTORY tables exist in.
To this end, you can add as many tablespaces in the HISTORY database as necessary.
You can move any HISTORY tables to new tablespaces to meet your needs.
As a best practice, you may want to create a "LARGE" tablespace, "MEDIUM"
tablespace and a "SMALL" tablespace and move your HISTORY tables accordingly. You
could break this down even further into application-size tablespaces - e.g., INV_LARGE,
INV_MEDIUM, ONT_LARGE, ONT_MEDIUM, etc.
Archive cycles will merge data into a history table. It doesnt care what tablespace the
table is in. So you do not need to change any configuration in Informia Archive if you
move tables to a new tablespace in the HISTORY database.
However, new HISTORY tables that are created will be put into the tablespace marked as
the AM HISTORY DATA tablespace type. To change this to a new tablespace, go to the
Tablespaces Workbench (Adminstrator -> Tablespaces). Delete the entry for the
HISTORY tablespace that has a type of AM HISTORY DATA, then add the new
tablespace for AM HISTORY DATA type for the HISTORY instance.