将原来SQL Server上的应用设计原封不动地用在Oracle上，就会导致严重的后果。这种决定最糟糕的两个后果是：
1. Oracle中采用与SQL Server同样的数据库连接体系结构（每个查询使用一个连接）。
2. 开发人员在SQL中使用直接量（而不是绑定变量）。
这两个结果导致系统无法支持所需的用户负载（数据库服务器的可用内存会耗尽），即使用户能登录和使用应用，应用的性能也极差。
1. 在Oracle中使用一个连接
Windows单进程体系结构会限制Oracle数据库服务器总共只有大约1.75 GB的RAM。由于每个Oracle连接要同时处理多条语句，所以Oracle连接通常比SQL Server连接占用更多的RAM。
注意 Windows环境中还能通过其他办法得到更多的RAM，如利用/AWE开关选项，但是只有诸如Windows Server Datacenter Edition等版本的操作系统才支持这个选项，而在这个项目中并没有使用这种版本。
2. 使用绑定变量
重用已解析的查询计划（称为软解析，soft parse）相比，解析包含有硬编码变量的语句（称为硬解析，hard parse）需要的时间更长，而且要消耗更多的资源。硬解析会减少系统能支持的用户数，但程度如何不太明显。这部分取决于多耗费了多少资源，但更重要的因素是库缓存所用的闩定（latching）机制。硬解析一个查询时，数据库会更长时间地占用一种低级串行化设备，这称为闩（latch），有关的详细内容请参见第6章。这些闩能保护Oracle共享内存中的数据结构不会同时被两个进程修改（否则，Oracle最 后会得到遭到破坏的数据结构），而且如果有人正在修改数据结构，则不允许另外的人再来读取。对这些数据结构加闩的时间越长、越频繁，排队等待闩的进程就越 多，等待队列也越长。你可能开始独占珍贵的资源。有时你的计算机显然利用不足，但是数据库中的所有应用都运行得非常慢。造成这种现象的原因可能是有人占据 着某种串行化设备，而其他等待串行化设备的人开始排队，因此你无法全速运行。数据库中只要有一个应用表现不佳，就会严重地影响所有其他应用的性能。如果只 有一个小应用没有使用绑定变量，那么即使其他应用原本设计得很好，能适当地将已解析的SQL放在共享池中以备重用，但因为这个小应用的存在，过一段时间就会从共享池中删除已存储的SQL。这就使得这些设计得当的应用也必须再次硬解析SQL。真是一粒老鼠屎就能毁了一锅汤。
如果使用绑定变量，无论是谁，只要提交引用同一对象的同一个查询，都会使用共享池中已编译的查询计划。这样你的子例程只编译一次就可以反复使用。这样做效率很高，这也正是数据库期望你采用的做法。你使用的资源会更少（软解析耗费的资源相当少），不仅如此，占用闩的时间也更短，而且不再那么频繁地需要闩。这些 都会改善应用的性能和可扩缩性。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/110321/viewspace-608529/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/110321/viewspace-608529/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
