Oracle实例由上述内存组件和相关的后台进程组成，这些内存组件提高了数据库系统的运行，而后台进程负责管理系统或者内存组件，使得整个数据库系统协调一致的工作。但是并非所有的Oracle实例都能满足Teamcenter生产系统的需求，尤其是那些只采用默认参数的数据库实例，还有就是运行了较长时间（几年）的数据库实例。另外，即使数据库实例使用自动内存管理，Oracle也只是给出一个建议，因此本文将围绕数据库及其实例的优化方法，帮助实现对Teamcenter数据库实例的优化。
本篇文章不会介绍Oracle内存组件具体是用来做什么的，也不会介绍每个组件的工作原理，我们只从Teamcenter数据库实例应该如何适应Oracle数据库的哪些关键技术、新特性或相关参数设置等角度，来帮助大家掌握提升Teamcenter系统整体性能的方法和经验。
Teamcenter数据库实例应该采用何种内存管理方式
我们经常在创建Teamcenter数据库实例时会遇到一些基本参数如何设置的问题，比如，是否需要使用自动内存管理，使用自动内存管理会有哪些好处，SGA各内存组件的大小又该如何调整和设置。面对诸多疑问我们总结出如下数据库优化思路，希望能给各位读者带来帮助。
因Oracle11g在引入AMM（Automatic Memory Management，自动内存管理）特性后，Oracle的内存管理变得更加灵活和多样，可以组合出以下5种内存管理方式：
-
自动内存管理 -
自动共享内存管理(Automatic SharedMemory Management,ASMM) -
手动共享内存管理 -
自动PGA管理 -
手动PGA管理
那么很多人在创建Teamcenter数据库实例时，不太清楚应该如何设置内存参数及其大小，到底应该采用哪种方式更合适自己呢？
要回答这个问题，我们可以观察一下Oracle版本的进化历史，9i引入了pga_aggregate_target参数，可以自动对PGA进行调整；10g引入了sga_target参数，可以自动对SGA进行调整；而11g对这两部分进行了综合，引入了memory_target参数，可以自动调整所有的内存，也就是AMM特性。由此可见从手动内存管理至自动内存管理是Oracle版本进化的一个主要特征。为此我们给出如下建议：
1. Teamcenter数据库实例选择的是Oracle11g及以上版本，服务器内存又足够大时，我们可以采用自动内存管理模式，这种模式管理上简单有效，不用关注太多细节，但这种方式也不能完全确保数据库以最大效率去运行，原因就是数据库启动时会按一个固定比例来分配SGA_TARGET（MEMORY_TARGET *60%）和PGA_AGGREGATE_TARGET（MEMORY_TARGET *40%）两个参数的大小。当Teamcenter系统负载较重时，而数据库服务器的物理内存又不是很充足的情况下，这种自动内存管理机制并非是最佳选择。
2. Teamcenter数据库实例选择的是Oracle10g时，可以考虑自动共享内存管理（ASMM），因为这样只需确保SGA有一个足够的运行空间即可，SGA内部各组件的大小不用过多关注。如果我们的Oracle选择的是11g，采用该方式就是将AMM切换到ASMM管理，即不启用11g的AMM特性，退化到10G的ASMM特性。采用ASMM方式同样具有局限性，就是只确保SGA内部是自动管理的，而且有一个上限值就是sga_target设定的大小。所以大家采用该方式后要经常注意观察SGA内部各组件的利用率问题。
3. 无论是SGA，还是PGA，全部采用手动管理。这要求对数据库基本知识和各组件运行原理能够完全掌控，采用这种方式需要对Teamcenter系统的最大运行压力进行测试和数据监测，然后依据监测结果给出SGA和PGA各组件的大小。当服务器硬件配置保持不变，而数据库实例又运行了较长（半年以上）时间的基础上，其整体性能正在逐渐下降，这时可以通过数据监测手动调整内存组件大小来改善Oracle的整体性能。
将SGA锁定到物理内存
目前专业数据库服务器的物理内存配置是相当高的，这些物理内存如果不能充分利用起来将是一项严重的浪费。LOCK_SGA和PRE_PAGE_SGA参数在Teamcenter数据库实例上用的不算太多，但是通过优化这两个参数可能会给我们带来比较乐观的性能提升。LOCK_SGA参数的作用是将SGA锁定在物理内存内，这样就不会发生SGA使用虚拟内存的情况，可以提高数据的读取速度，因为磁盘I/O操作永远是尽量避免和减少的。该参数默认值为FALSE，将其改为TRUE后，则整个SGA将会锁定在内存中。PRE_PGA_SGA参数的作用是启动数据库实例时，将整个SGA读入物理内存。对于内存充足的数据库服务器而言，可以提高系统的运行效率。我们可以修改该参数为TRUE即可。这样会提高数据库运行效率，但会增加数据库的启动时间。
注意：如果将初始化LOCK_SGA参数设置为TRUE，则AMM是不可用的，需要指定SGA_TARGET和PGA_AGGREGATE_TARGET参数的大小才行。
将常用数据常驻内存
在生产数据库中，为了提高用户的访问速度，对于经常使用的表可以使其常驻内存中，避免对该表访问产生频繁的磁盘I/O行为，这样可以提高用户的访问响应时间。虽然造成一定的内存占用，但是使用内存访问确实缩短了访问的响应时间，在某种程度上是更有效的，对于内存充足的服务器而言都应该考虑这种优化方式。
Teamcenter系统要优化基础操作，首要任务就是优化对象加载时间。比如用户表、权限表、流程表、对象锁表、关系表等，如果不将此类表加载到数据库内存中，反复读取会影响系统使用效率。根据分析与研究，我们认为以下数据库表需要被放置到内存中：
PAM_ACE
PAM_ACL
PATTACHMENT_TYPES
PATTACHMENTS
PDATA_0
PEPMTASK
PIMANTYPE
PIPM_ACE
PITEMMASTER
PITEMVERSIONMASTER
POM_F_LOCK
POM_M_LOCK
POM_R_LOCK
PPOM_USER
PPSVIEWTYPE
PSIGNOFF
PUSER
优化重做日志缓冲区
重做日志缓冲区是使一段临时存储重做数据的内存区，所有变化的数据前项和修改后的数据都保存在重做日志缓冲区中，由LGWR进程负责写入重做日志文件。如果需要优化重做日志缓冲区，必须首先确认发生了与重做日志缓冲区相关的等待事件，否则不应该随便调整重做日志缓冲区的尺寸。我们可以通过相关等待（WAIT）视图和事件（EVENT）视图，确认等待事件以及该事件涉及的文件和会话。
Teamcenter的REDO日志文件大小初始安装为100M，但在实际业务中往往偏小，导致日志文件切换和归档频繁，容易产生大量的I/O操作和等待事件，从而引起性能问题，因此，建议将初始化REDO日志文件大小改为500M，但是该大小也不是一成不变的，需要根据Teamcenter系统的运行状况去监测是否发生等待事件，如果发生等待事件可以考虑增大日志文件的大小、更换高速磁盘设备、或将REDO日志文件与数据文件、控制文件等分配到不同的磁盘上，以减少磁盘I/O操作。
优化共享池
共享池共分为两部分：库高速缓存和数据字典高速缓存。其中库高速缓存存放SQL语句的正文、编译后的代码以及最终的执行计划，而数据字典高速缓存存放SQL语句操作相关的数据库对象，如表、索引、列以及其他对象的定义和权限信息。对于库高速缓存而言，重用SQL语句可以减少硬解析的时间从而减少SQL语句的响应时间，而数据字典高速缓存则减少了对SQL语句涉及的数据库对象和权限定义的磁盘访问，也减少了SQL语句的响应时间。对共享池的优化目的就在于不影响性能的条件下增加提供SQL代码以及数据字典的使用率。
1. 对于Teamcenter数据库实例而言可以通过以下脚本查询共享池的空闲率。
2. 空闲率小于20%时，应该调大共享池，可通过以下语句设定大小（？代表需要设定的值）。
3. 使用如下脚本，查询共享池的命中率。
4. 根据上述结果查看命中率（PIN）是否符合要求，如果命中率小于99%（0.99），则说明硬解析太多，解决这个问题可以考虑以下方法：
-
增加共享池的大小； -
使用绑定变量； -
调整cursor_sharing参数值。
优化PGA内存
所谓的PGA优化就是确保那些大规模的数据排序放到PGA中完成，而不是使用虚拟内存从而占用操作系统的交换区（SWAP AREA）。这样就需要合理地设置PGA的大小，从而使得排序区符合Teamcenter系统的要求。
Teamcenter系统报表在输出过程中会频繁进行SQL调用和排序，这样就会占用PGA排序区的资源，当cache hit percentage=100（比例100%）时，说明所有的排序语句都是在PGA排序区完成的。
由此可见，可通过以下语句来查询PGA排序区进行排序的百分比。
当输出结果VALUE值为100，说明所有的Teamcenter系统内的排序行为都是在PGA的排序区完成，如果出现部分排序不在PGA的排序区完成，则VALUE值将小于100，当VALUE值小于90以下时，那么就必须要增大PGA排序区的大小，甚至还需要增大整个PGA的大小。对于PGA及其排序区大小的调整方法，可参考以下命令完成（其中的数值只是示意，具体大小要根据自己的实际情况决定）。
优化表空间
在数据库系统中，存储空间是较为重要的资源，合理利用空间，不但能节省空间，还可以提高系统效率和工作性能。Oracle可以存放海量数据，所有数据都在数据文件中存储。而数据文件的大小受操作系统的限制，并且过大的数据文件对数据的存取性能影响非常大。同时Oracle是跨平台的数据库，Oracle数据可以轻松地在不同平台上移植，那么如何才能提供统一存取格式大容量呢？Oracle采用表空间来解决。
在项目上，我们经常遇到服务器的磁盘存储空间不足导致表空间使用不足、表空间设置存在问题，数据文件过大导致较多空间碎片产生等情况发生，这也会造成Oracle数据库的整体性能下降。遇到上述情况我们需要通过增加数据文件、使数据文件自增长或移动数据文件的方式来改善表空间的管理。
为提高Teamcenter系统排序操作的并发能力、减少开销，避免Oracle空间管理操作混在一起进行。应该考虑增加临时表空间的数量、增大临时表空间的大小，将临时表空间与其他表空间放到不同的磁盘驱动器上，减少I/O竞争。
减少并分散数据库I/O操作
为了分散数据库的I/O操作，需要将Teamcenter数据库实例的以下文件放到不同的磁盘上进行存储：
将重做日志文件跟数据文件分离，路径更改到某盘目录下；
将快速闪回恢复区路径变更到某盘目录下；
将控制文件变更到某盘目录下；
将临时表空间文件变更到某盘目录下。
注：如果操作系统是类Unix操作系统，可以将每个文件的路径设置成不同的位置即可。
上述内容是从Teamcenter使用角度来考虑Oracle内存组件和数据库实例应该如何设置才能满足一个较大平台并发访问数据库的需求。这些理论可以帮助实施人员提前做好Teamcenter数据库的各种规划，也可以帮助大家在遇到问题时能够找到解决问题的思路。尤其是那些初学者，在安装Teamcenter系统时尽量多做一些考虑，以确保未来整个系统运行的稳定和高效。写作本篇文章的目的不在于手把手教大家如何去调试这些组件和参数，而是提醒大家Oracle有这方面的技术，一定要懂得应用才行，具体如何操作需要读者不断地积累知识并灵活使用。
本篇文章对于Teamcenter系统运行在单数据库实例上而言已经足够使用。但是对于复杂的RAC（Real Application Cluster,真应用集群，提供高可靠性和平衡系统负载）集群，ASM自动存储管理（提供智能化数据库文件的存储和高可用）、DataGuard（Oracle提供的容灾产品，保障数据库高可用及灾难恢复）、Oracle12c提供的多租户容器数据库等新技术而言，以上内容的介绍显得有些微不足道，但有一个好的开端总比止步不前要好。
天圣华信息多年来根植于国防军工行业，以对军工制造模式的深刻理解，数字化、自动化业务的丰富积累和“专注军工智能，鼎力中国制造”的坚定初心，服务于我们的客户。
