oracle count(*)无数据_Oracle的INSTANCE CAGING在数据库资源池中的作用

现在的服务器都十分强大，哪怕一台两路服务器也可以拥有3-40个核，7-80个线程，远比十多年前的一台小机强大。在一台X86服务器上运行Oracle数据库，最大的问题是CPU资源很难得到充分的利用。我们曾经对十多个客户的数据库服务器的资源使用情况进行过调研分析，发现大多数数据库服务器的高峰期CPU平均使用率低于30%，一些小系统高峰期CPU平均使用率低于5%，甚至很大比例的系统低于1%。一个数据库独立运行于一台服务器甚至一个RAC集群的模式造成了大量的资源浪费。从另外一个角度看，很多服务级别要求不高的数据库仍然运行于RAC环境，这些系统实际上并不需要7*24，4个9的可用性，偶尔停上几十分钟也不太会影响业务，使用RAC确实是完全不必要的。如果用Rac onenode构建数据库资源池来运行这些数据库系统，可以大大节约服务器资源，也可以省下大量的Oracle许可证资源(当然对于我们目前大部分数据库并没有购买许可证的情况来说，这个节约是虚拟的)。为了节约资源，我们可以在一台服务器上运行多个数据库实例(Oracle 11g开始的RAC ONE NODE技术对这种模式提供了强大的支持)。不过我们还是担心多个数据库实例运行在一台服务器上会不会相互干扰。事实上，在一些一台服务器上运行多个数据库实例的用户，或者采用12c容器数据库承载多个PDB数据库的用户侧，已经出现了由于某个系统过度消耗资源而导致出现运维事故的问题了。比如某个小系统做了一个应用升级，应用存在一个小BUG，就可能把整台服务器的CPU资源耗尽，使得这台服务器上的多个数据库同时出现性能问题甚至宕机。这实际上是资源隔离做的不足。在同一个物理机上运行多个应用最关键的是隔离。实际上虚拟机，容器等都是为了做资源隔离的。而在裸机上运行多个数据库实例，也需要这种隔离机制。在以前的Oracle数据库版本中，实现资源隔离是十分麻烦的事情，不过从Oracle 11g开始，Oracle支持Instance Caging后，这些都变得十分简单了。比如我们要在一台服务器上部署三套数据库A,B,C，我们希望A使用一半的CPU资源，B,C各使用你25%的CPU资源，在Instance Caging技术的加持下就十分简单了。比如这台服务器有两颗18核的CPU，合计72线程。那么我们设置A数据库的CPU_COUNT=36，其他两个数据库的CPU_COUNT=18。然后在三个数据库中启用一个resource manager plan，就可以了(哪怕是defalut plan都可以)。resource plan不仅仅可以实现instance caging，隔离CPU资源，还可以控制IO，undo使用量、并行查询等，今天我们重点讨论CPU资源的隔离。下面我们通过一个案例来看看如何通过instance caging来控制某个数据库实例的CPU使用，比如：

alter system set cpu_count = 18; alter system set resource_manager_plan = 'default_plan';

这两个参数都是动态参数，可以随时在线修改。不过为了防止数据库出问题，在生产环境下，还是不要频繁修改。我们来做个实验，把CPU_COUNT设置为5，然后启动压测，看看OS的CPU使用情况：

可以看到，虽然压力很大，不过Instance Caging还是很好的实现了资源隔离控制。从resource plan的相关指标上看：

因为资源管理的限制，出现了大量的CPU等待的现象。活跃会话数也被限制在5左右。我们把CPU_COUNT加大到20，再来看看：

CPU资源被很好的限制在20左右。Oracle的Instance Caging做的还是挺不错的。

在当前的压测负载下，CPU_COUNT=20足以满足要求，等待CPU的会话数量也比较少。

从上面我们可以看出INSTANCE CAGING可以通过CPU_COUNT来有效的控制数据库实例的CPU资源使用。那么在资源池环境下，我们该如何来设置CPU_COUNT呢？

如果我们在一台服务器上设置所有的CPU_COUNT的总和小于物理服务器的CPU线程数，那么服务器的CPU资源不会出现不足的现象，不过当某些实例需要更多的CPU资源，并且其他数据库实例比较空闲的时候，因为CAGING的原因，会导致部分CPU资源浪费。如果我们把所有实例的CPU_COUNT设置超过物理CPU线程数的时候，可以让物理服务器的CPU资源得到充分的使用，但是如果所有的数据库实例都处于繁忙状态的时候，物理CPU可能会不够用。因此在实际的应用中，我们还是要根据实际情况来选择合理的策略，同时我们需要加强操作系统资源的监控，确保系统安全运行。数据库资源池可以提高资源使用率，节约成本，不过任何好处都是有代价的，我们在运维上需要更为精细。