tib cim bestpractices

8/11/2019 Tib Cim BestPractices

1/114

TIBCOMDM

Best Practices Guide

Software Release 8.3.1Document Updated May 2014

Two-Second Advantage


2/114

Important Information

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDEDOR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITEDADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLEDSOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FORANY OTHER PURPOSE.

USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF ALICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSEAGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USERLICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THESOFTWARE (AND WHICH IS DUPLICATED IN LICENSE.PDF) OR IF THERE IS NO SUCH SOFTWARELICENSE AGREEMENT OR CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATEDIN THE LICENSE FILE(S) OF THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMSAND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND ANAGREEMENT TO BE BOUND BY THE SAME.

This document contains confidential information that is subject to U.S. and international copyright laws andtreaties. No part of this document may be reproduced in any form without the written authorization of TIBCOSoftware Inc.

TIBCO, Two-Second Advantage, TIB, TIBCO Adapter, Predictive Business, Information Bus, TIBCOBusinessConnect, TIBCO ActiveMatrix BusinessWorks, TIBCO Enterprise Message Service are either registeredtrademarks or trademarks of TIBCO Software Inc. in the United States and/or other countries.

Enterprise Java Beans (EJB), Java Platform Enterprise Edition (Java EE), Java 2 Platform Enterprise Edition(J2EE), and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle Corporationin the U.S. and other countries.

All other product and company names and marks mentioned in this document are the property of theirrespective owners and are mentioned for identification purposes only.

THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALLOPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAMETIME. SEE THE README.TXT FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON ASPECIFIC OPERATING SYSTEM PLATFORM.

THIS DOCUMENT IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS ORIMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS.CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BEINCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKEIMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED INTHIS DOCUMENT AT ANY TIME.

THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY ORINDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING

BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES.This Product is covered by U.S. Patent No. 7,472,101.

Copyright 1999-2014 TIBCO Software Inc. ALL RIGHTS RESERVED.

TIBCO Software Inc. Confidential Information


3/114

TIBCO MDM Best Practice Guide

| iii

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vChanges from the Previous Release of This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

TIBCO MDM Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Other TIBCO Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Connecting with TIBCO Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

How to Join TIBCOmmunity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiHow to Access TIBCO Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

How to Contact TIBCO Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Planning a TIBCO MDM Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Multienterprise versus Single Enterprise Tenancy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Multienterprise and Single Enterprise Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Multienterprise and Single Enterprise Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Chapter 2 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

File System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Temporary Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Sent and Received Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Work Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Scheduling Database Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Performance Considerations While Running Purge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Backup Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Data files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13


4/114


iv | Contents

Reducing Space Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Chapter 3 Design Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Attribute Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Designing Data Models for Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Identifying Related Entities and Attributes in a Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Using the TIBCO MDM Relationship Table in Repositories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Sparse Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Record Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Identifying Record Relationships during the Design Phase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Managing the Cardinality of Record Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Managing Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Softlinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Effective Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Data Source Identification and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Naming Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

User-Defined Table and Column Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 4 Installation and Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Installation Choices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Single Node Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Highly Available or Fault Tolerant (HAFT) Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

ActiveSpaces and TIBCO MDM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Java Versions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Optimizing CPU Utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Database Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Table Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Database Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

JMS Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

WebSphere MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Sequence Numbers and Caches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Objects and Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Managing Multiple TIBCO MDM Instances with Caches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Cache Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Managing Users and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Security Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Lightweight Directory Access Protocol (LDAP) Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44


5/114


Contents |v

Data Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Security Auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Rulebases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Validation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Initialization Rulebase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Using Enumerations with Rulebases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Security and Rulebases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Optimizing Performance with Rulebases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Using Lookups with Rulebases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Indexes and Rulebases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Using Drop-Down Lists with Rulebases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Initialization Rulebases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Propagation and Rulebases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Constraints and Rulebases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Chapter 5 Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51

Task Prioritization through Isolation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

TIBCO MDM Memory Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Multiple TIBCO MDM Instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Capacity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Using TIBCO MDM Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Using Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Partial Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Chapter 6 Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59

Initial Loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Current Data Acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Initial Load With Cleansing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Input Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Importing Nested Data Mapped to Multiple Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Avoiding Failures during Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Importing Large Batches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Changing the Input Map During Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Imports in the Approval Stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Using the CONTAINS Attribute for Imports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Using SQL-Based Datasources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Loading Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


6/114


vi | Contents

Import Control Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Database Loader versus Normal Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Creating indexes for data sources (Database Loader only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Chapter 7 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Customizing Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Using Java with Customized Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Working with Transitions in Customized Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Working with Caches in Customized Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Using Rules in Customized Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Performance Considerations in Customized Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Handling Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Tuning Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Using GetRecord for Tuning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Using Rulebases for Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Subflows versus Spawned Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Subflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Spawned Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Chapter 8 Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Optimizing Performance with Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Single Sign-On and Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Using Cache with Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Concurrent Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Synchronous Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Workflows and Synchronous Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Chapter 9 Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

UI Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Search Optimization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Rulebases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Database Optimizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Timing Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Preload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Using JMX Console for Monitoring Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Chapter 10 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88TIBCO ActiveMatrix BusinessWorks Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90


7/114


Contents |vii

Using TIBCO ActiveMatrix BusinessWorks with TIBCO MDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Recovering Failed Messages and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93


8/114


viii | Contents


9/114

TIBCO MDM Best Practices Guide

Figures | i

Figures

Figure 1 Message Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52


10/114


ii | Figures


11/114


Tables | iii

Tables

Table 1 General Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Table 2 Comparison between multi-enterprise and single-enterprise tenancy . . . . . . . . . . . . . . . . . . . . . . . 4


12/114


iv | Tables


13/114


|v

Preface

TIBCOMDM is a tool to manage master data of your organization by providinga framework for governance, rules, and processes.

TIBCO MDM ensures accuracy and efficiency both inside the enterprise as well asthroughout the value chain so that multiple processes are optimally coordinated.TIBCO MDM delivers a multidomain horizontal platform to manage all types of

information including products, customers, vendors, reference data, backendsystems, and so on.

Topics

Changes from the Previous Release of This Guide, page vi

Related Documentation, page vii

Typographical Conventions, page ix

Connecting with TIBCO Resources, page xi


14/114


vi | Changes from the Previous Release of This Guide

Changes from the Previous Release of This Guide

This is the first release of this guide.

P f | ii


15/114


Preface |vii

Related Documentation

This section lists documentation resources you may find useful.

TIBCO MDM Documentation

The following documents form the TIBCO MDM documentation set:

TIBCO MDM Release Notes: Read the release notes for a list of new andchanged features. This document also contains lists of known and closed

issues for this release.

TIBCO MDM Installation and Configuration: Read this manual for instructionson site preparation, installation, and configuration.

TIBCO MDM Users Guide: Read this manual to learn the TIBCO MDMfeatures. This manuals guides you to use the product. It describes thefunctionality as well as all the screens.

TIBCO MDM System Administration: This manual explains features relevant tothe system administrator.

TIBCO MDM Customization: Read this manual to understand how theapplication can be customized to your enterprise needs.

TIBCO MDM Workflow Reference: This manual is a reference for theautomation of business processes.

JAVA API Reference: This Help includes a list of workflows that are used in

TIBCO MDM.

TIBCO MDM Web Services: This manual is a reference for using web services.

TIBCO MDM Best Practices: Read this manual to learn the best practices whileusing the TIBCO MDM features and functionalities.

Other TIBCO Product Documentation

You may find it useful to read the documentation for the following TIBCOproducts:

TIBCO MDM Process Designer Users Guide: This guide is a reference fordesigning workflows using the TIBCO MDM Process Designer graphical userinterface.

TIBCO MDM Process Designer Tutorial: This guide is a tutorial for designing

workflows using the TIBCO MDM Process Designer graphical user interface.

viii | Related Documentation


16/114


viii | Related Documentation

TIBCO MDM Repository Designer Users Guide: This guide is a reference fordesigning repositories using the TIBCO MDM Repository Designer graphicaluser interface.

TIBCO MDM Repository Designer Tutorial: This guide is a tutorial for designingrepositories using the TIBCO MDM Repository Designer graphical userinterface.

TIBCO MDM Rulebase Designer Users Guide: This guide is a reference fordesigning rulebases using the TIBCO MDM Rulebase Designer graphical userinterface.

TIBCO MDM Rulebase Designer Tutorial: This guide is a tutorial for designing

rulebases using the TIBCO MDM Rulebase Designer graphical user interface

TIBCO Enterprise Message Service: This software allows the application tosend and receive messages using the Java Message Service (JMS) protocol. Italso integrates with TIBCO Rendezvous and TIBCO SmartSocketsmessaging products.

TIBCO ActiveMatrix BusinessWorks: This is a scalable, extensible, andeasy-to-use integration platform that allows you to develop and testintegration projects. It includes a graphical user interface (GUI) for definingbusiness processes and an engine that executes the process.

TIBCO BusinessConnect: This software allows your company to send andreceive XML or non-XML business documents over the Internet. Based on amutually agreed upon process flow and common document format, you andyour trading partners can conduct secure and verifiable business transactionsonline.

Preface | ix


17/114


Preface | ix

Typographical Conventions

The following typographical conventions are used in this manual.

Table 1 General Typographical Conventions

Convention Use

code font Code font identifies commands, code examples, filenames, pathnames, andoutput displayed in a command window. For example:

Use MyCommandto start the foo process.

bold code

fontBold code font is used in the following ways:

In procedures, to indicate what a user types. For example: Type admin.

In large code samples, to indicate the parts of the sample that are ofparticular interest.

In command syntax, to indicate the default parameter for a command. For

example, if no parameter is specified, MyCommandis enabled:MyCommand [enable| disable]

italic font Italic font is used in the following ways:

To indicate a document title. For example: See TIBCO ActiveMatrixBusinessWorks Concepts.

To introduce new terms. For example: A portal page may contain several

portlets. Portletsare mini-applications that run in a portal. To indicate a variable in a command or code syntax that you must replace.

For example: MyCommandPathName

Keycombinations

Key names separated by a plus sign indicate keys pressed simultaneously. Forexample: Ctrl+C.

Key names separated by a comma and space indicate keys pressed one after the

other. For example: Esc, Ctrl+Q.

The note icon indicates information that is of special interest or importance, forexample, an additional action required only in certain circumstances.

The tip icon indicates an idea that could be useful, for example, a way to applythe information provided in the current section to achieve a specific result.

x | Typographical Conventions


18/114


x | Typographical Conventions

The warning icon indicates the potential for a damaging situation, for example,data loss or corruption if certain steps are taken or not taken.

Table 1 General Typographical Conventions (Contd)

Convention Use

Preface |xi


19/114


|

Connecting with TIBCO Resources

How to Join TIBCOmmunity

TIBCOmmunity is an online destination for TIBCO customers, partners, andresident experts. It is a place to share and access the collective experience of theTIBCO community. TIBCOmmunity offers forums, blogs, and access to a varietyof resources. To register, go to http://www.tibcommunity.com.

How to Access TIBCO Documentation

You can access TIBCO documentation here:

http://docs.tibco.com

How to Contact TIBCO Support

For comments or problems with this manual or the software it addresses, contactTIBCO Support as follows:

For an overview of TIBCO Support, and information about getting startedwith TIBCO Support, visit this site:

http://www.tibco.com/services/support

If you already have a valid maintenance or support contract, visit this site:

https://support.tibco.com

Entry to this site requires a user name and password. If you do not have a username, you can request one.

xii | Connecting with TIBCO Resources
http://www.tibcommunity.com/http://docs.tibco.com/http://www.tibco.com/services/supporthttps://support.tibco.com/https://support.tibco.com/http://www.tibco.com/services/supporthttp://docs.tibco.com/http://www.tibcommunity.com/


20/114


|

|1


21/114


|

Chapter 1 Overview

This document provides the best practices based on contributions from TIBCOMDM users who develop the software and implement it in a variety of TIBCOMDM projects. Some best practices may contradict others, because differenttargeted audiences may have mutually exclusive goals for the usage of thesoftware.

The information contained in this document is provided as is. Apply yourjudgement and experience with TIBCO MDM to determine whether a particularbest practice applies to your environment.

Topics

Planning a TIBCO MDM Project, page 2

Multienterprise versus Single Enterprise Tenancy, page 3

2 | Chapter 1 Overview


22/114


Planning a TIBCO MDM Project

TIBCO should be implemented in a phased manner to suit the requirements ofyour organization. A so-called big-bang approach delays completion of theimplementation and the realization of return-on-investment (ROI). If you use thebig-bang approach, it can take years to achieve a full implementation of allrequirements across all business functions.

Instead, you should start with a smaller project with phased implementationcycles and define goals and ROI for each phase. Each project or phase can provideROI to your business. With a phased approach the implementation team candesign incrementally, make corrections in subsequent phases, and betterunderstand TIBCO MDM architecture's quirks and best practices. For a successfulTIBCO MDM project, you must train the implementation staff on the tools andmethodology.

Multienterprise versus Single Enterprise Tenancy |3


23/114


Multienterprise versus Single Enterprise Tenancy

An enterprise (also referred to as a company) is a logical unit that has almostcomplete data isolation (some global objects, such as global partners and datasources are shared). With TIBCO MDM, you can manage multiple enterprises inthe same instance. Managing one enterprise in an instance is called singleenterprise tenancy. Managing multiple enterprises in an instance is calledmultienterprise tenancy.

Multienterprise and Single Enterprise Design ConsiderationsYou must decide early in the design process whether to use TIBCO MDM withmulti-enterprise or single-enterprise tenancy. You should take several factors intoconsideration when making this decision. For example, multienterprise tenancy isa good design choice if you use all the enterprises similarly and you want a singlepoint of operational control.

Single enterprise tenancy is a good choice if you want physically separated

enterprises to which you can separately assign the required resources. Thischoice, however, comes with overhead costs: the total resources needed tomaintain multiple single enterprise tenancies is significantly higher than thoserequired for a multienterprise tenancy.

Before deciding on a multienterprise or single enterprise tenancy, considerwhether your configuration is likely to change. Separating an enterprise from amultienterprise tenancy to create a single enterprise tenancy is possible. However,

doing so is tedious and requires several manual steps and consultation withTIBCO Support. Merging an enterprise from a single enterprise tenancy to amultienterprise tenancy is relatively easier but does require some manual steps.These steps may include recreating the enterprise in multienterprise tenancy andimporting the data and meta-data into the new environment).

In multienterprise tenancies, using a single data store you can use a single set ofreporting tools for data analysis and aggregation across enterprises.

You should also consider performance characteristics. In most cases, TIBCOrecommends a multienterprise tenancy if the enterprises are small (fewer than 50million records). Enterprises with records exceeding 300 million records should inmost cases be configured as single enterprise tenancies.



24/114


Multienterprise and Single Enterprise Comparison

The following table compares the features in a multienterprise tenancy with thefeatures in a single enterprise tenancy:

Table 2 Comparison between multi-enterprise and single-enterprise tenancy

Feature Multienterprise Single Enterprise

Setup

Multiple enterprises inone TIBCO MDMinstance.

Database, cache, JMS,among others, shared byall enterprises in instance.(You cannot assignquotas to eachenterprise.)

Each enterprise is in a separateTIBCO MDM instance.Database, cache, JMS, among

others, separate for eachenterprise.

Maintenance

Software maintenance for

all enterprises ismanaged together.

Software maintenance for each

enterprise is managedseparately.

Configuration

All configurations areshared, including singlesign-on and rolemapping, installedplug-ins and language

packs, messageprioritization, messagelisteners, file watchers,ConfigValues andconfigurations.

Some of thecustomizations, such aslook and feel, businessprocess rules, workflows,and rulebases, can beenterprise-specific.

Configurations for eachenterprise are separate.

Multienterprise versus Single Enterprise Tenancy |5


25/114


Data Isolation

Data stored in shareddatabase and cache.TIBCO MDM enforceslogical separationbetween the enterprisedata. (Global businesspartners and lookup datasources defined for the

TIBCO MDM enterprisethrough rulebases areshared across allenterprises.)

All data is isolated.

Performance

Performancerequirements of differententerprises can

potentially conflict. Alarge enterprise willconsume a large share ofsystem resources.

Performance characteristics ofeach enterprise can be managedseparately.

Table 2 Comparison between multi-enterprise and single-enterprise tenancy

Feature Multienterprise Single Enterprise



26/114


|7


27/114


Chapter 2 Maintenance

This chapter explains the best practices for maintenance.

Topics

File System Management, page 8

Database Maintenance, page 10

Reducing Space Requirements, page 14

8 | Chapter 2 Maintenance


28/114


File System Management

Beginning with TIBCO MDM 8.0 release version, file system management is nowsimplified. Most data that was previously stored on the file system is now storedin a database. File system is used primarily for two important sets of files:

Files uploaded to TIBCO MDM for attributes of type = FILE

Temporary files generated during the processing of master data.

Temporary DirectoryOn the file system, most of the generated files are temporary files. These arestored under $MQ_COMMON_DIR/Temp. The files stored under$MQ_COMMON_DIR/Tempare not required after they are used up by workflowprocesses, and can be deleted periodically. TIBCO recommends keeping the filesystem growth under check by periodically running the supplied script(bin/tibcrontab.sh) to clean up the older files or using a cronfacility in theUnix system.You can run the script through a scheduler. The script deletes theunnecessary files and you can customize the retention period.

Reclaiming Space by Deleting Temporary Files

In emergency situations, all the files and sub-directories under the$MQ_COMMON_DIR/Tempdirectory can be removed to reclaim space. Ensure that noworkflows are running when deleting all files from this directory. Runningworkflows may need recently created temporary files. To ensure no workflowsare running, shut down all TIBCO MDM instances or retain the files generated inthe last 10 days.

Sent and Received Directories

While sending messages in or out of TIBCO MDM through JMS, TIBCO MDMalso creates sentand receiveddirectories in $MQ_COMMON_DIR. These files are

used for tracing, reconciliation, and debugging only. The sentand receiveddirectories keep a copy of the sent or received messages and you can removethese directories without affecting any process. These files are used for tracing,reconciliation, and debugging only.

Work Directory

Do not delete files stored under the $MQ_COMMON_DIR/workfolder. This folderdoes not grow significantly and is not expected to have many files.

File System Management |9


29/114


If you are using a lot of attributes for which data type is defined as FILE, the filesare stored under $MQ_COMMON_DIR/work. As these files are version ed, the spacerequired to store data will increase proportional to the number of attributesdefined as file and versions of such records.

Scheduling Database Maintenance

TIBCO recommends scheduling a file clean-up job to run at periodic intervals. Todo this, use the tibcrontab.sh/.batsample script found in MQ_HOME/bin. Thisjob deletes temporary files created by TIBCO MDM. The sample script can beedited for different retention periods.



30/114


Database Maintenance

TIBCO recommends setting up a maintenance schedule for TIBCO MDM to clearolder logs and temporary files, and keep the database clean and manageable.

For more details about the purge and tibcrontab functions, see TIBCO MDMSystemAdministration.

Scheduling Database Purge

The purge operation removes older record versions, changes history andworkflow trace data and helps maintain a clean database. You can invoke thepurge operation as a workflow, a command-line tool, or as a scheduled job.TIBCO recommends scheduling the data purge to run regularly.

Beginning with TIBCO MDM 8.3.1release version, you can use interval-basedpurge to target records updated in a specified interval. Schedule history purges,for example, to run with an interval equal to 7 days to keep the history fromgrowing too large. You can also use purge to remove data which is no longerneeded. For example, test data which you can delete using the command-linepurge.

If invoked as a workflow, the purge operation can only be run in two modes:deleting older record versions and deleting history. If invoked as a command-linetool, use the various options to trim unused test data, data sources, andrepositories.

See Chapter 9, Configuring Purge in the TIBCO MDMSystemAdministration formore details about the purge operation.

Performance Considerations While Running Purge

While running, purge uses significant resources from the database, cache and textindex. While you can continue to use the system, the TIBCO MDM may appearsluggish. When data is removed from the database, the database updates all

indexes.

Purge consumes a large amount of database resources and therefore maynegatively affect performance. To avoid this, schedule purges to coincide withperiods of low or no activity and also schedule only one purge job at a time. If yourun a purge for the first time or after a long period after the last purge, it may takemore time to complete than a regularly scheduled purge.

Database Maintenance |11


31/114


If you are running a purge for a repository (to clean up all records), performing animport for the same repository can generate resource contention and deadlocks.This can significantly slow the purge and import process.

Performance Impact of Synchronization on Purge

Synchronization of master data with external systems generates a large amount oftrack and trace data. Even if the amount of incremental data being synchronizedis small, TIBCO MDM tracks of the decision to skip all the records which were notsynchronized. If you are doing excessive synchronization, purge the data tomaintain the database size. TIBCO provides a purge job to trim thesynchronization data.

Synchronization

Consider the impact of Synchronization on capacity planning. The amount ofsynchronized data can be substantial and often requires significant disk space.

When you synchronize data (except DBDump), TIBCO MDM maintains a

detailed history. This history includes the following: Synchronization status: When and with which system or partner.

Synchronized data: The data for each record that was synchronized. Thechanged data is recorded because data can be transformed duringsynchronization.

Change ManagementUse a version control system to track all configurations and customizations.Instead of deploying the files directly to TIBCO MDM instances, check them intothe version control system, then use scripts to deploy them to target servers.TIBCO provides a sample script to automate deployment from version controlsystem.

To customize the components provided in the $MQ_COMMON_DIR/Work/standard

folder, make a copy of the component in an enterprise-specific folder. TIBCOMDM prioritizes files within enterprise-specific folders even if they have thesame name as the files under the standard folder. You can change artifacts underthe standard folder with a new version or hot fix, however are alwaysoverwritten.



32/114


Backup Strategies

TIBCO MDM data is stored in two separate data stores: files and a relationaldatabase.

Configurations

TIBCO recommends keeping all configuration files in a version control system totrack changes. Take regular backups whenever these components are changed.When creating backups, be sure to do the following:

Ensure that all configuration files in $MQ_HOME/Configare backed up. Thesefiles affect the behavior of the TIBCO MDM application.

Back up the ECM.earfile. This is the TIBCO MDM application that getsunpacked and deployed into the application server. TIBCO recommendsbacking up this file for every change made to its contents, such as visualcustomization, custom function, custom workflow activities and custom webservices.

Check in all the modified application server configuration files into yourversion control system. The configuration files for the supported applicationservers are:

Standalone.xml, for JBoss Application Server

/Configfiles for WebLogic Application Server and WebSphereApplication Server

For more information on configuration files, refer to the Installing onApplication Server chapter in the TIBCO MDM Installation and ConfigurationGuide.

Store all the enterprise-specific configurations in $MQ_COMMON_DIR. Back upand check these configurations into your version control system on a regularbasis.

Data files

All TIBCO MDM data files are in the $MQ_COMMON_DIR/workdirectory which youshould back up. You do not need to back up files under the following directories:

/temp

/sent

/received

Backup Strategies |13


33/114


Database

In addition to your company's general backup strategy, TIBCO recommends thatyou do the following for TIBCO MDM:

Always back up the database first before backing up $MQ_COMMON_DIR.

Back up the entire schema for TIBCO MDM.



34/114


Reducing Space Requirements

You can reduce disk space requirements by employing the following strategies:

Use in-memory workflows.

Reduce the amount of data collected for each workflow step, including theintermediate documents.

Remove the output parameter if the output document of a step is not needed.

Modify the out-of-the-box workflow to remove parameters you do not need to

extract the attributes. Tune the in-memory workflow by specifying appropriate values for track and

trace levels.

Review the options and configurations for workflow and rulebase tracing.You can eliminate some of these if you do not need to specify log options ofEvaluateRulebase to generate error report file.

Review the configuration of your production environment to ensure that

request and response files for web service requests are not generated.

|15

D i C id ti


35/114


Chapter 3 Design Considerations

This chapter explains the best practices during the design and development of aTIBCO MDM solution.

Topics

Attribute Groups, page 16

Repositories, page 17

Sparse Repositories, page 20

Record Relationships, page 21

Managing Hierarchies, page 23

Softlinks, page 25

Effective Dates, page 26

Data Source Identification and Design, page 27

Naming Conventions, page 28

User-Defined Table and Column Names, page 29

16 | Chapter 3 Design Considerations

Attrib te Gro ps


36/114


Attribute Groups

Attribute groups in TIBCO MDM group together attributes that are similar orshare security constraints. You can use Attribute groups to:

Display records in an automatically generated tabbed UI.

Define security and data visibility settings.

Assign data custodians for governance and route work items.

Assign rejection comments for a group instead of individual attributes.

You can apply rules to attribute groups to manage and organize attributes and toperform the following actions:

Hide entire attributes-based users, roles, or actions (for example, create andedit)

Group together attributes that have similar behavior. For example, you cangroup together read-only attributes, or attributes that are hidden for certainusers.

Create a data entry wizard by hiding attribute groups until certain conditionsare met. For example, you can hide subsequent attribute groups until the firstattribute group has been populated.

Hide attribute groups from specified users. Such rules must also be reflectedin any validation rules. Otherwise, the rule may fail validation because a usercannot populate a field they cannot see.

Repositories |17

Repositories


37/114


Repositories

A repository can have a large number of attributes and a well-designed repositorykeeps these attributes separate. For example, the number of base attributes thatapply to all records across all categories should not exceed 100.

Designing Data Models for Repositories

Use standard database modeling principles to identify attributes, objects, andrelationships during the initial design of new data models.

After you have identified all the objects and relationships, consider the questionsin the following table:

Design Principle Checklist

Are there be frequent traversals to many levels of relationships? Shouldthese objects be denormalized to reduce the depth of hierarchy?

Are there many small objects which can be denormalized into onebigger object? This may result in a sparse table with many nullattributes. If you have many small tables which are associated withanother table in a relationship, consider denormalizing it and mergingthem into one.

Are there too many relationships between objects? Could theserelationships be reduced?

Is a relationship cardinality expected to be very high (for example,100s)? If so, consider removing the relationship and using a softlink.Alternatively, you can use an intermediate object to group the childrecords.

Are the attribute sizes, especially for Strings correct? After the data ispopulated, you can change the attribute sizes, however it is difficult.

Some of the attribute size changes are not allowed, so TIBCOrecommends that you define the correct attribute size during thedesign stage.


D i P i i l Ch kli t


38/114


Designing Data Models for Repositories Using the Out-of-the-Box UI

If you are using a TIBCO MDM out-of-the-box UI, the complexity and depth ofdata model can have a significant impact on the UI. Small, highly normalized data

models, for example, result in poor UI usability and performance because youneed to perform many clicks to view all data.

To optimize out-of-the-box UI performance and usability, consider the followingpoints when designing a data model:

Each attribute group is typically mapped as one tab on record UI. Attributegroups are arranged according to the sequence assigned and attributes arearranged in the order of position within the attribute group. You can provide

additional UI specifications to combine data from more than one attributegroup or adjust the positions of groups and attributes by changing the order.

The relationships and related records show up in the navigation hierarchy.

Effective dates introduce the drop-down boxes to enable users to navigatebetween different time periods.

Using Perspectives you can select different views. By default, the UI provides

a set of attributes in record header and in relationship hierarchy. You canchange this by configuring the desired attributes through Configurator.

Are the attribute data types correct? If in doubt, consider using String.After the data is populated, you can still change the data types but it is

difficult. In some cases, change in data type is not possible due to staledata which causes the conversion to fail. In String datatype providedattributes are defined as String. In this case, TIBCO MDM skips thechecks to see if the data is the appropriate data type. In such cases, usevalidation rules to validate the data.

Do you really need effective dates for repository and relationships?Effective dates impact performance and introduce complexity in rules,

use this feature sparingly.

Can you present any perspectives in a simplified view of the datamodel?

Are there a large amount of specialized objects that result in smalltables, each with little additional information? If so, combine them intorepository.

Does the repository have a large number of attributes? If so, considersplitting it.

Design Principle Checklist

Repositories |19

Identifying Related Entities and Attributes in a Repository


39/114


Identifying Related Entities and Attributes in a Repository

TIBCO MDM already has defined entities to manage. Follow these steps toidentify all related entities and attributes:

1. Normalize the resulting model.

2. Associate the subentities with entities through relationships or foreign keylookups.

3. Separate the entities from the list that store data coming from external sources.For example, if you are getting addresses from external systems to store inTIBCO MDM, the address may be mapped to the repository ADDRESS andthe data acquired from the external system is a data source DS_ADDRESS.

4. Denormalize the tables with access patterns in mind. For example, you canhave a Customer entity where a customer has a phone number stored inPhone entity. However, if one of the phone numbers is the main phone that isalways accessed along with the customer and is logically considered part ofthe customer details, you may want to store this phone number as an attributein the Customer entity itself.

5. Group attributes logically and assign positions to the attributes within groupso that they are sequenced in a logical order.

Using the TIBCO MDM Relationship Table in Repositories

The TIBCO MDM relationship table is a generic association table that stores thefollowing types of associations and relationships:

Relationships between records, defined in the repository model Association of repository with output maps and input maps

Association between input maps for multirepository import and betweenoutput maps for multirepository export.

Association between attributes and attribute groups.

Hierarchy of classification codes and association with records.

Different types of relationships are identified by different relationship types. Forexample, a separate table is used for storing the associated data for eachrelationship associated with a repository that also has any relationship attributes.

More than one relationship of the same type is not possible between any tworecords. To create such relationships first create an intermediate association object.


Sparse Repositories


40/114


p p

Sparse repositories have many columns that do not apply to all the records andmay be null for most. Such null columns are efficiently handled by databases.

TIBCO MDM does not allow inheritance. This means that if the model requiresyou to model subobjects that vary slightly, model them in the same repository anduse a record type to identify different types of objects. This is calleddenormalization of the data model.

Repositories have a limit of 1024 attributes. However, with category-specificattributes, you can define unlimited attributes as category-specific. You can usethis method to exceed 1024 attributes in a repository.

Record Relationships |21

Record Relationships


41/114


p

Using Record relationships in TIBCO MDM you can bundle together and retrievecollections of related records. When a parent record is queried, TIBCO MDM mustevaluate all of the related records and potentially retrieve these and any relatedsubrecords (if configured to do so). Relationships in TIBCO MDM can be apowerful tool. However, misused relationships can negatively impactperformance.

Use relationships only when they are required to obtain bundles of data. Someexamples include the following:

Using the relationship between a rail line table and the track table you canquery all of the tracks that make up a line.

Using the relationship between CarModel and CarParts you can identifywhich car Models use which car parts. (You can use reverse relationships inTIBCO MDM, so an extra validation check is to see if the reverse would alsomake sense.)

Identifying Record Relationships during the Design Phase

Identify the relationships early in the design phase because relationships affectthe whole solution. The later you define or remove relationships the larger theimpact it has on the design.

TIBCO MDM supports the concept of a many to many relationship. In BusinessStudio you can document different multiplicities, but these need to be enforced by

using rulebases to travel up and down the relationship tree counting instances.

Managing the Cardinality of Record Relationships

TIBCO MDM manages all relationships as peer to peer, many-to-many. Therefore,you need not define cardinality. However, it is better to define cardinality in therepository model for documentation. If cardinality has to be enforced, use the

rulebase.

If the cardinality is expected to be more than 500, you encounter performanceissues. For example, if a Car comprises over 500 parts, you should group the parts(door parts, cabin parts, suspension parts). This reduces the amount of 'crawling'over relationships that TIBCO MDM needs to complete. Larger cardinality resultsin performance degradation for all channels, especially on the UI.


Use the following strategies to keep cardinality manageable:


42/114


Create an intermediate group object. For example, if a customer has morethan 500 accounts, create an account group object to bunch accounts such

that each group has no more than 100 accounts. Configure TIBCO MDM to exclude relationships from parent to child or

reverse if the navigation is always in one direction.

Define the relationships as a softlink. The relationships between records areexplicitly maintained if defined as a softlink, and are not searched asversion-specific.


43/114


Parameter Description


44/114


tibco.optimization.recordbundle.excluderelationship Specifies whichrelationships you can

ignore for navigationthrough bundling. The listcan include relationshipsdefined for either direction(forward or backward). Itis typically used to enforceone way navigation.

com.tibco.cim.optimization.recordview.skipcustomvalidation

Specifies that customvalidation class specifiedfor a record can bebypassed for viewing. Thedefault value is true,unless you want tooverride the validationclass with some custom

code.

com.tibco.cim.ui.optimization.recordsearch.relationship.

depth

Defines the depth of thehierarchy available forConfiguration of the searchpanel. This parameterdetermines the depth ofsearch within the

hierarchy.

com.tibco.cim.optimization.recordsearch.relationship.dep

th

Defines the depth of thehierarchy for search. Itapplies to web services.

Softlinks |25

Softlinks


45/114


Consider using a softlink if two records are related and referred to together but

are not updated together. Softlinked records are obtained whenever required andhave the following attributes:

You cannot propagate data down to softlinked records.

Querying softlinked records using the SOAP GetRecord service does notreturn any soft linked records.

Softlinked records are not validated when the root record changes.

Despite these limitations, softlinks are an effective way to relate records togetherin a fast, efficient manner.


Effective Dates


46/114


Future effective dates in TIBCO MDM are a means to complete and confirm

records that become active at a specified date in the future. This is useful forexpected changes such as new product releases, changes to employment details,and price changes.

When using future effective dates, keep the following best practices in mind:

Always try to use effective dates in a linear fashion between record versions.Ensure that the later version of a record has the later effective date than theearlier versions. If this is not the case, the earlier versions (for example,version 5 with a later effective date than version 6) can overwrite the goldencopy, which can lead to data inconsistencies. To avoid this, use rulebases andapproval cycles to confirm the dates being used are correct and that earlierdates are not used.

Effective dates in repositories and records have an impact on both memoryand performance in TIBCO MDM.

Versions are only identifiers and do not imply ordering. A version 6 maybecome the golden copy before version 3.

Data Source Identification and Design |27

Data Source Identification and Design


47/114


Developers spend a great deal of effort to ensure that the data from other systems

is mapped correctly to TIBCO MDM. You can import such external data usingdata source.

Most data sources have already been identified for use in TIBCO MDM and newones are built to fill in gaps or present the existing information better. Thefollowing best practices should help design data sources to gain maximumbenefit:

Whenever possible identify which data sources present the most accuratecollection of data for any repositories and use it to populate your primary keyfields and any other data fields.

Use the same data source for any tables that store similar information. Forexample, if you have a data source that provides all customer ID information,use this for all tables (such as Business and Normal customers) where the ID isrequired. Splitting it over two or more data sources gives rise toinconsistencies and degrades the quality of the data within TIBCO MDM.

You can join more than one data source to merge data into a single repository.You can then map different data source data to different parts of the repositoryin just one action.

Do not transform the data while mapping data source to input map usinginput map expressions, which is slow and has limited functionality. Insteaduse rulebase during import to transform the data.

If a lot of data transformation and lookups are required, prepare the databefore importing it into TIBCO MDM. While TIBCO MDM is able to completelookups and change data, it may be computationally expensive and timeconsuming. For example, a simple data lookup where an ID is converted intoa text value is acceptable within TIBCO MDM. However, if it has to look up avalue and then execute a collection of rules based on this value, which thenchanges other attributes, TIBCO recommends performing this externally.TIBCO MDM executes these rules every time a record (in hundreds or

thousands) is presented to it. There are a variety of ways to achieve this. Forexample, you can use the following:

TIBCO Clarity for data discovery and data transformation.

ActiveMatrix BusinessWorks (or similar) to access the data required fromthe source system. Process the data internally to produce an end result thatadheres to the required business rules.

Other ETL tools such as Kettle.


Naming Conventions


48/114


TIBCO MDM provides a large number of resources, including data repositories,

data sources, synchronization profiles, and synchronization formats. TIBCOrecommends using a naming convention for each type of object. The following arethe recommended suffixes for each type of object:

Repositories: None

Back end Systems: BS

Data sources: DS

Input Maps: IM

Output Maps: OP

Classifications: CS

Synchronisation Formats: SF

Synchronisation Profiles: SP

Subsets: SB

TIBCO recommends providing a descriptive name. The name of data sources, forexample, should reflect where the data source is getting its data and from whattype of data it contains. Studio projects can be assigned a prefix based on theprojects containing enterprise. For example, PR1 for a project from enterprise 1and PR2 for a project from enterprise 2.

Ensure that all repositories are given a table name instead of using generated

table names. Specifying table names makes the names consistent across differentenvironments (development, test, production). Using generated table names canlead to portability issues. The table name you specify must be unique in thedatabase schema. The naming convention for table names is to prefix it with aproject acronym. For example, a customer table name can be E2_CUSTOMERwhereE2 is the project name.

By following these it should be possible to give unique names to each resource in

TIBCO MDM that reflects its type, function, and the enterprise to which itbelongs.

User-Defined Table and Column Names |29

User-Defined Table and Column Names


49/114


TIBCO MDM enables user-defined names for database entities such as tables and

columns. TIBCO MDM automatically generates names with internal conventionsif no table or column names are provided. These automatically-generated namescan be cryptic or generic. Automatically-generated names are likely to change ifthe table is ported from one repository to another. Metadata associated withautomatically-generated names can also change. In most cases, TIBCOrecommends specifying the database tables and columns.Automatically-generated names are useful in development environments, whereusers do not want to name tables and columns and do not want to exposedatabase details.

User-defined tables and columns make it easier for external tools like TIBCOSpotfire to access the database. User-defined names are also more easilyunderstood by SQL programmers.

User-defined table names must be unique within the same database instance. Youcannot assign the same table name to more than one repository even if they aredefined in different enterprises as long as these enterprises are deployed in thesame TIBCO MDM instance. You cannot import metadata into another enterprisewithin the same instance because attempts to create a duplicate table.



50/114


|31

Chapter 4 Installation and Configuration


51/114


This chapter explains the best practices for installation and configuration.

Topics

Installation Choices, page 32

JMS Management, page 40

Caches, page 41

Security, page 43

Analytics, page 45 Synchronization, page 46

Rulebases, page 47

32 | Chapter 4 Installation and Configuration

Installation Choices


52/114


This section discusses the decisions you must make when installing TIBCO

MDM.

Single Node Installations

Single-node installations provide the simplest installation and permit quick starts.For most development purposes single-node installations are acceptable and thebest choice. For single-node installations, all the required software is installed on

one machine, port numbers are unchanged, and TIBCO MDM is started in seedermode with no external server.

If you are going to perform a single-node installation, consider using theembedded PostgresSQL database so you can use the simplified installer withoutseparate database installs.

The default setup works well for small datasets (for example, under 50K). Thedefault setup also works for larger datasets if you import or export data in chunks

of 50K. For larger datasets, database tuning may be required.

User testing (such as User Acceptance Testing) generally requires a separateenvironment.

Highly Available or Fault Tolerant (HAFT) Installations

TIBCO recommends using highly-available or fault-tolerant (HAFT) installations

in any production or preproduction environment. To create a HAFT installation,configure several ActiveSpaces nodes across your production and nonproductionenvironments to support failover. As of TIBCO MDM 8.3.1 release version, youcan also create the spaces externally and configure them as needed.

You need not set up the application servers into clustered mode to ensure they arehighly available. TIBCO MDM nodes use a load balancer to distribute the loadbetween multiple TIBCO MDM nodes. In most cases, using a software load

balancer such as a webserver is sufficient.Ensure that all TIBCO MDM instances use the same cache configuration file.

Configuring TIBCO MDM Instances as Seeders in HAFT Installations

If you configure TIBCO MDM instances as seeders, each instance connects to thesame metaspace and forms a cluster. Seeders can continue operating even aftertheir connection to external ActiveSpaces nodes is lost. In addition, seedersreduce network traffic.

Installation Choices |33

Configuring Subnets in HAFT Installations

Typically, production and preproduction boxes are installed on similar hardwareh k ( b ) h f f


53/114


in the same network space (subnet). This type of setup can cause a configurationerror to easily confuse the cache and messaging setups between theseenvironments. To avoid such confusion, ensure that the:

Configured ActiveSpaces nodes do not read from each others metaspaces byusing separate metaspaces and modifying listen and discovery URLs for eachenvironment. The suggested naming convention for metaspace names isenv_MDMwhere is a three to five character acronym for theenvironment.

You can partition the JMS setup between environments by using different portnumbers or JMS server machines.

Sizing Considerations in HAFT Installations

When sizing your environments, set the CPU maximum loading to 75% for anysingle TIBCO MDM node when one or more of the other nodes fail. CPU usage ismuch lower in normal operation, but in this type of sizing the application can

perform without degradation in case of failure. Contact TIBCO support forassistance in setting up your environment.

Set up a web server or load balancer to equally distribute the load among allTIBCO MDM instances. Ensure that sticky sessions are configured. Sticky sessionsmean that once a session is started on one of the TIBCO MDM instances allsubsequent requests for that session will be sent to same TIBCO MDM instance.

Size the cache to keep all the master data in memory. If the required memory is

greater than 16 GB, consider using an external cache server (and switching TIBCOMDM to use leech mode). External cache servers maintain cached data even whenTIBCO MDM is restarted, to avoid reloading.

Use the disk sizing spread sheet provided by TIBCO Support to estimate the diskspace required, as the space requirement depends on your repository definitions.

Configuring EMS in HAFT Installations

When setting up highly-available or fault-tolerant (HAFT) EMS servers forTIBCO MDM, use database-backed queue storage (against a DB cluster). Thisalleviates any issues with SAN boxes and file-based replication. Note that adatabase-backed EMS storage can negatively impact performance. Consult theEMS documentation to understand the benefits and drawbacks of using EMS.TIBCO recommends that you set the expiry on Change Notification Messagequeue to a small number, for example one to two minutes.


Security Considerations

The following information lists some important security considerations to use:


54/114


Use SSL configurations between TIBCO MDM and the EMS cluster to

improve security if the EMS servers are in different geographical and networklocations.

Use authentication to secure the EMS connections.

Create a list of allowed servers to protect communication between Patternsand TIBCO MDM when you start Patterns engines,

Set up an authentication realm to secure the JMX connection.

Use SSL for browser to TIBCO MDM server connections.

Logging

Set logging to DEBUG for development and test environments and to INFO orERROR for production environments.

If access to the TIBCO MDM machine is restricted for developers:

Move the log files to separate directories and drives or mounts so developerscan read the contents.

Delegate an TIBCO MDM user as the Support Engineer to login to TIBCOMDM to get logs and run diagnostic queries.

Set up the TIBCO MDM instance to access JMX remotely.

ActiveSpaces and TIBCO MDM

TIBCO MDM uses ActiveSpaces, an in-memory grid, to minimize the reading thedatabase and reducing the end-to-end response time. Configuring ActiveSpacesto provide the best performance is an iterative process. Use the followingguidelines to help configure ActiveSpaces for your own needs.

Seeder and Leech Modes

Although TIBCO MDM is configured in the Seeder mode, it is not always theoptimal choice. You can change the modes using the TIBCO MDM Configurator.You must restart all the TIBCO MDM instances after making such changes.

The following information describes and compares Seeder and Leech modes:

Seeder: In Seeder mode, TIBCO MDM uses the CacheConfig.xmlfile tocreate its own embedded cache node on the same machine that TIBCO MDM

is running. This setup is advantageous because the allocated memory is


running on the same machine as TIBCO MDM and therefore has substantialperformance gain. However, this increases the memory requirements on thehost machine considerably.


55/114


y

Leech: TIBCO MDM in leech mode does not create an embedded cache andrelies on external cache servers. This setup means that you can spread out thecache over several machines. If TIBCO MDM cannot access any cache nodes itfails and does not function correctly.

If TIBCO MDM instance is a Seeder, the memory used by the TIBCO MDMinstance is also the same as the cache configuration. This memory is in addition tothe JVM heap assigned.

Virtualized Environments and ActiveSpaces

TIBCO does not recommend virtualized environments for ActiveSpaces and anyoperation on a virtual machine that stops or re-initializes the network makes thecache non-functional. For example, if you plan to take a snapshot, you should firstshut down the caches.

Sizing Considerations for ActiveSpaces

TIBCO Support has a collection of resources for accurately estimating the spacerequired for your solution. TIBCO MDM provides a Cache Calculationspreadsheet to use in your calculations. For more information on documentation,refer to TIBCO MDM System Administration.

As in all memory-based applications (especially long running ones), ActiveSpacesis susceptible to memory fragmentation similar to the main memory

fragmentation. Symptoms include increased CPU utilization, slower responsetimes, and higher page reads.

TIBCO recommends scheduling a restart to clean and rebuild the cache. Also,never allocate more than 80% of physical memory to ActiveSpaces. For the cacheto utilize the memory efficiently, all instances of cache must use the sameCacheConfig.xml.

Configuring ActiveSpaces

TIBCO MDM ships the following three configurations, any of which are a goodstarting point for different environments:

Config/CacheConfig.xml

CacheConfig.dev.xml

CacheConfig.large.xml)


All the TIBCO MDM nodes must use identical cache configuration file and allseeders must have identical memory allocations. You can accomplish this byusing the same CacheConfig.xmlfor each TIBCO MDM instance. When an


56/114


external cache server is added, it must support the memory specified in this

configuration file.Review the following two example CacheConfig.xmlfiles provided with TIBCOMDM:

CacheConfig.dev

and

CacheConfig.large

For more information about your configuration, refer to TIBCO MDMSystemAdministration.

CacheConfig.dev

and

CacheConfig.large

Setting the replication count to greater than 0 configures ActiveSpaces to makecopies of data across different ActiveSpaces nodes, but it requires more memory.CacheConfig.large.xmlhas preconfigured caches which must be replicated.

Java Versions

Currently, TIBCO MDM requires the Java versions listed below. Consult thereadme shipped with your installation of TIBCO MDM for the most up-to-datesoftware requirements.

JBoss Application Server

JRE 7

Sun JVM

Weblogic Application Server

JRE 6

Sun JVM or JRrockit JVM

WebSphere Application Server

JRE 6

IBM JVM

For HP platforms, use HP JVMs.


TIBCO MDM is not certified with Open JDK. However, if you use Open Java andencounter TIBCO MDM problems that require support, download and point tothe Oracle release (JAVA_HOME). You can then verify that the issue is reproducibleb f i TIBCO


57/114


before contacting TIBCO support.

Optimizing CPU Utilization

Due to the Inbound-Outbound nature of TIBCO MDM, you cannot achieve morethan 45% CPU utilization. A large number of cores and CPUs produce a largenumber of threads, which result in a high throughput. The CPU utilizationincreases if the Inbound-Outbound is performing well including the database,networks, and file system performance. To increase the CPU usage, you can:

Increase thread counts for workflow queue, HTTP, web services, AsyncCallQueue, and Active login. As you increase the threads, you need to allocatemore memory to JVM. A reasonable estimate is 300 MB per workflow or asyncqueue listener (whichever has a higher number of listeners) or 200 MB perweb service thread. Increasing the thread count without increasing the JVMheap, may result in Out of Memory errors. If your bundles are of average size(20-40 records per bundles), the memory per thread is 250 MB and 150 MB

respectively.

Start more TIBCO MDM instances on the same machine and assign each nodeidentical memory and threads to maintain a well balanced load.


Database Management


58/114


This section discusses the best practices for database management.

Table Spaces

Generally large tables should be kept in separate table spaces but newertechnologies may make this practice redundant. Oracle Automatic StorageManagement (ASM), for example, does not require storing large tables in separatetablespaces. Nevertheless, if you keep a large table in its own separate tablespace,

the database administrator can manage the tables more efficiently.

Database Performance

Database performance changes as data is added or deleted. When more than 10%of data has changed or been added, a database may require DBA attention. TheDBA should review the following:

Set up a job to collect optimization statistics regularly. Set up a job to generate Automatic Database Diagnostic Monitor (ADDM),

Automatic Workload Repository (AWR), or similar reports at regularintervals.

Review the report for recommendations and adjust database parametersaccordingly. For example, reports may indicate changes to memory allocatedto a database instance. If an ADDM report is regularly checked and acted

upon, no database performance issues can occur.

Regularly purge data using the purge program. (See Scheduling DatabasePurge, on page 10.)

If there are many deletes (due to purge), indexes and tables may becomefragmented and after reviewing the statistics report you may have todefragment the indexes regularly.

If a database report shows that inserts or deletes are running slow, it mayindicate that:

Disks are slow or access paths ar

tib cim bestpractices

Documents