- 性能——flat file 比数据库快。Fixed-width 文件比delimited 文件快，因为delimited文件需要解析（parsing）。如果是很复杂的传输，那么建议先把flat file导到关系型数据库，再通过mappings访问数据库，因为这样可以用自定义select SQL 语句进行过滤。
- Mapping——一个mapping 可以设计多个目标（targets），那么你可以用特定的顺序（用Target Load Ordering实现）去load目标。推荐限制mapping中的复杂逻辑的数据。这样不只更容易去调适，而且可以同步运行而更好的利用系统资源。
- Objects and transformations——首先考虑业务需求，因为这些objects都是用来满足需求的。尽早的过滤无用的数据。
- Log File Organization
- 日志文件夹推荐为默认的文件夹。
- 可以到PowerCenter Troubleshooting Guide的附件C（Appendix C）去查询错误编号（error code）。
- Scheduling Techniques
- Multiple workflow比stand-alone workflow更好。简化了load任务的执行（可能各个任务有一定的顺序等）；还有内嵌工作流可以简化load的复杂度。
- 如果工作流执行失败，只能指定工作流的任务重新开始工作流，而不能从失败点开始。然而，有一个可能创建的任务和流程是基于error handling的。
- 在程序内或跨程序的并发sessions/workflows的执行向导。
两个约束：Available system resources 和 Memory and processors
并发时注意：一个session一个process可能正确，但多个session的话，就有可能影响性能或可能相互影响，所以需要反复测试（trial and error）去确定可以运行多少个session；这些session应该在非高峰期（off-peak）运行，这样能使用更多的资源。
- 事件通知（event notification）——可以通过发送email（成功时或失败时）
- Backup Strategy
- Individual objects——individual objects 不能还原，只能还原整个repository，但是可以还原repository到其它数据库，再拷贝到当前的repository；还有一个方法就是export xml 文件。
- 服务器管理
- 通知——Repository server能发送消息通知用户服务器将关机，另外，如果有人创建、修改、删除repository objects也能被通知。通知的消息通过Informatica client tools 接收。
- 系统资源和性能监控——pmprocs utility for UNIX
- 在UNIX 服务器崩溃（crash）或者Oracle实例崩溃（instance crash），要执行怎样的清理工作——检查repository数据库是否能成功复原，如果可以起到PowerCenter server，检查pmserver.err日记，判断服务器是否允许正确。也可以用psef|grep pmserver去看服务器进程（load manager）是否运行
- 元数据（metadata）
- Metadata 的命名规范或repository管理的推荐方式（目的是可以提取（extract）并使用到其它repository）
可以为所有的repository objects、sources、targets、transformations等进行描述。也可以对表的每列进行描述，可以包括列size、scale、data type、primary keys。
决定metadata的多少通常由项目的时间线（timelines）驱动的。因为越详细的描述，将花费越多的时间。
有一些第三方工具可以进行对metadata的管理。
- 提取（extract）metadata的过程
Informatica 和和主要的BI供应商都高效的运用metadata exchange（MX）视图去report和query the Informatica metadata。
Informatica 强烈不鼓励（discourage）直接访问repository，即使用SELECT访问。因为PowerCenter的发布可能会改变repository表的表现，从而导致维护工作量。而视图的创建就是为了访问metadata。
另外一些产品，如：Informaticas Metadata Reporter和PowerAnalyzer允许更强劲的报表。
