5.6 管理程序包开发

设想具有下面特征的开发环境：

●没有实施任何标准。

●在SYS或SYSTEM账户下创建对象。

●简单地考虑表和索引的适当分布以及大小调整。

●设计每个应用程序，如同它是计划运行在数据库中的唯一应用程序。

这些条件并不符合实际需要，在购买的程序包应用程序的实现过程中很少会遇到这些情况。适当管理程序包的实现涉及前面针对应用程序开发过程所介绍的相同问题。本节将概述应该如何处置程序包，从而使它们最适合于开发环境。

5.6.1 生成图表

大多数CASE工具能将程序包反向工程为物理数据库图表。反向工程包括分析表结构和生成物理数据库图表，这些物理数据库图表与表结构是一致的，通常通过分析列名、约束和索引来标识键列。然而，物理数据库图表和实体关系图表之间一般没有一对一的相互关系。通常从程序包供应商处获得程序包的实体关系图表，它们在规划程序包数据库的接口时非常有帮助。

5.6.2 空间需求

大多数基于Oracle的程序包都可以非常精确地估计出在产品使用期间数据库资源的使用率。然而，这些程序包通常并未考虑在数据加载和软件升级期间它们的使用率需求。应该注意监控大型数据加载期间程序包的撤消需求。如果程序包在升级操作期间创建所有表的副本，则可能需要备用的DATA表空间。

5.6.3 调整目标

如同自定义应用程序具有调整目标一样，程序包也必须具有调整目标。建立并跟踪这些控制值将帮助标识需要调整的程序包区域（参见第8章）。

5.6.4 安全性需求

遗憾的是，许多使用Oracle数据库的程序包分为两类：从另一个数据库系统迁移到Oracle，或者假设具有对象拥有者账户的完整DBA权限。

如果在不同的数据库系统上第一次创建程序包，它们的Oracle端口将很可能无法完全利用Oracle的函数功能，如序列、触发器和方法。调整这种程序包以满足需求时，可能需要修改源代码。

如果假设程序包具有完全的DBA授权，则它必须和其他关键数据库应用程序存储在不同的数据库中。大多数需要DBA授权的程序包都会这样做，从而可将新用户添加到数据库。应该准确地确定程序包管理员账户实际需要哪些系统级权限（通常是CREATE SESSION和CREATE USER）。可创建专门的系统级角色，将系统权限的限制集提供给程序包管理员。

在非Oracle数据库上第一次开发的程序包可能需要使用与另一个Oracle移植程序包相同的账户。例如，多个应用程序可能都需要数据库账户SYSADM的所有权。解决这种与完全可信度之间冲突的唯一方法是在不同的数据库中创建两个程序包。

5.6.5 数据需求

程序包具有的任何处理需求，特别是在数据输入方面的需求，都必须清楚地定义。这些需求通常都完全归档在程序包文档中。

5.6.6 版本需求

所支持的应用程序可能依赖于Oracle的特定版本和特性。如果使用程序包应用程序，则需要将内核版本升级计划建立在供应商对不同Oracle版本支持的基础上。此外，供应商可能切换支持的优化器特性。例如，需将COMPATIBLE参数设置为特定值。数据库环境需要尽可能灵活，从而支持这些改动。

因为这些限制超出了控制，所以应该尝试将程序包应用程序与它自己的实例隔离。如果频繁地在应用程序中查询数据，应用程序与它自己实例的隔离将增加对数据库链接的依赖性。需要针对支持一个实例中多个应用程序的维护成本，来评估支持多个实例的维护成本。

5.6.7 执行计划

生成执行计划需要访问针对数据库运行的SQL语句。SGA中的共享SQL区域维护对数据库执行的SQL语句（可通过V$SQL_PLAN视图访问）。匹配SQL语句和应用程序的特定部分是一个耗时的过程。应尝试标识特定的区域（这些区域的功能和性能对应用程序的成功至关重要），并与程序包的支持团队协同工作，以解决性能问题。可使用自动工作负荷存储库（Automated Workload Repository，参见第8章）收集所有在测试周期中生成的命令，然后确定在该命令集中大多数资源密集型查询的解释计划。如果命令仍在共享SQL区域中，可通过V$SQL查看统计信息，并且通过V$SQL_PLAN查看解释计划；在Cloud Control 12c中，可同时查看两者。

5.6.8 验收测试过程

购买的程序包应该满足与自定义应用程序相同的功能需求。应在选择程序包之前开发验收测试过程，可以根据程序包选择标准生成这些过程。通过以这种方式进行测试，可测试你自己需要的功能，而不是程序包开发人员认为你所需要的功能。

如果程序包由于功能或性能问题而无法完成验收测试，则需要确保指定具体的选项。不能仅因为是购买的应用程序，而忽略应用程序的关键成功因素。

5.6.9 测试环境

建立测试环境时，遵循下列指导原则：

●它必须大于生产环境。需要能预见到将来的性能并测试扩展性。

●它必须包含已知的数据集、解释计划、性能结果和数据结果集。

●它必须用于数据库和工具的每个版本，以及用于新的特性。

●它必须支持生成多个测试条件，从而允许估计特性的经营成本。并不希望必须依赖于结果的要点分析。理想情况下，可在数据库变大时确定特性的成本／利益曲线。

●它必须足够灵活，允许估计不同的许可成本选项。

●它必须有效地用作技术实现方法学的一部分。

测试事务性能时，确保持续跟踪不断递增的加载速率。一般来说，当表上的索引到达内部第二层时，它们就会减慢加载性能。查看第8章可了解索引和加载性能的细节。

在测试时，示例查询应该具有下面各个组：

●执行连接的查询，包括合并连接、嵌套循环、外部连接以及散列连接。

●使用数据库链接的查询。

●使用数据库链接的DML语句。

●每种类型的DML语句（INSERT、UPDATE和DELETE语句）。

●每种主要类型的DDL语句，包括表创建、索引重构以及授权。

●使用并行查询的查询（如果在当前环境中使用了该选项）。

示例集应该不是伪造的，它应该表示具体的操作，并且必须可重复。生成示例集时应该回顾主要的操作组以及用户执行的OLTP操作。结果不会反映数据库中的每个动作，但有助于了解升级的意义，从而帮助减轻风险，并对实现新的选项做出更好的决策。