Category: Oracle Database

Oracle Policy-Managed Cluster – Growing for DBaaS

Leave a comment

Policy-Managed Cluster在Oracle 11gR2中被引进，在Oracle 12c中使用dbca创建RAC数据库的时候，Policy-Managed选项已然成为默认值。 Policy-Managed RAC

那么到底什么是Policy-Managed方式的集群和数据库呢？与以前的Admin-Managed方式有何区别？何种环境适合使用这种新的方式进行管理？本文尝试回答这些问题，并且做出简单的测试。

什么是Policy-Managed方式？

基于策略的管理方式，是以服务器池（Server Pools）为基础的，简单地说，就是先定义一些服务器池，池中包含一定量的服务器，然后再定义一些策略，根据这些策略Oracle会自动决定让多少数据库实例运行在池中的几台机器上。数据库实例名后缀、数据库实例个数、所运行的主机，这些都是通过策略决定的，而不是数据库管理员事先定好的。

与Admin-Managed方式有何区别？

实际上上面的表述已经明确说明了，Policy-Managed和Admin-Managed方式的差别。让我们再回顾一下，在以往我们创建一个RAC数据库大概是怎样的方法，我们在dbca的界面中会选择要将数据库实例运行在整个集群中的几台机器上，或者是2台或者是3台，甚或是更多，但是只要在安装的时候选定几台机器，那么以后如果不做增减节点的操作，就始终会在这几台机器上运行。而且，通常会根据主机名称的排序自动将每台主机上的数据库实例依次命名为dbname1到dbnameN。这些在管理员安装完毕以后，都不会再自动变化，这就是Admin-Managed方式。

何种环境适合使用这种新的方式进行管理？

当管理大量的服务器集群，并且在这些集群中运行着多种不同重要程度，不同策略的RAC数据库时，为了简化管理，建议使用Policy-Managed方式，实际上Oracle也建议只有在超过3台的服务器的时候才使用Policy-Managed来管理整个数据库集群。想象一下使用Policy-Managed方式可以达到的效果：如果我们有10台服务器组成，根据不同的应用的重要性定义服务器池的关键程度，然后在其中某些机器意外停机的情况下，仍然可以自动地保持足够多的机器给重要的系统提供数据库服务，而将不关键的系统数据库服务器个数降低到最低限度。

那么Policy-Managed方式到底长什么样？

在默认安装完Oracle 12c的RAC数据库之后，发现数据库实例始终只会启动在一个节点中。检查服务器池配置。

[oracle@dbserver2 ~]$ srvctl config srvpool
Server pool name: Free
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: Generic
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: orcl_pool
Importance: 0, Min: 0, Max: 1
Category: hub
Candidate server names:

Free池和Generic池是默认存在的，orcl_pool池则是在dbca创建数据库的时候由我们自己定义的。其中Min: 0, Max: 1表示在这个池中最少允许有0台机器，最多允许有1台机器被使用。所以这也造成了使用这个服务器池的数据库实例始终只会启动在一个节点中，即使这在我们最初的定义中是一个RAC数据库。

当前的数据库实例启动在节点2中，比较一下节点1和节点2服务器使用情况的输出。

[grid@dbserver2 ~]crsctl status server dbserver1 -f
NAME=dbserver1
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=Free --此处显示未Free，表示节点1中不属于任何正在运行的服务器池资源。
STATE_DETAILS=
ACTIVE_CSS_ROLE=hub

[grid@dbserver2 ~] crsctl status server dbserver2 -f
NAME=dbserver2
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=ora.orcl_pool --此处显示节点2正运行在orcl_pool服务器池资源中。
STATE_DETAILS=
ACTIVE_CSS_ROLE=hub

接下来需要修改一下配置，让RAC数据库以我们熟知的方式启动在多个节点上。 –修改orcl_pool池中最少运行一台机器，最多运行2台机器，还记得我们前面说的关键程度吗？importance表示该池的关键程度，数字越大表示关键程度越高，越优先被考虑满足Min条件。

[oracle@dbserver2 ~]$ srvctl modify srvpool -serverpool orcl_pool -importance 5 -min 1 -max 2

–重新检查服务器池信息，可以看到已经修改成功，Min: 1, Max: 2

[oracle@dbserver2 ~]$ srvctl config srvpool
Server pool name: Free
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: Generic
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: orcl_pool
Importance: 5, Min: 1, Max: 2
Category: hub
Candidate server names:

–查看当前服务器池的状态，可以看到orcl_pool池中激活的服务器包括了节点1和节点2两台机器。

[grid@dbserver1 ~]$ crsctl status serverpool
NAME=Free
ACTIVE_SERVERS=

NAME=Generic
ACTIVE_SERVERS=

NAME=ora.orcl_pool
ACTIVE_SERVERS=dbserver1 dbserver2

在修改完毕以后，节点1中的数据库实例就会自动启动，我们可以通过crsctl命令查看服务器的状态，其中STATE_DETAILS字段显示了正在启动资源，在正常启动完毕以后该字段会显示为空。

[grid@dbserver2 ~]$ crsctl status server dbserver1 -f
NAME=dbserver1
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=ora.orcl_pool
STATE_DETAILS=STARTING RESOURCES
ACTIVE_CSS_ROLE=hub

现在就出现了一个比较尴尬的情况（对于我们以前管理RAC的常识来说），由于dbserver1中的实例是后启动的，因此实例名后缀为2，而dbserver2中的实例名后缀是1，实际上，在Policy-Managed管理的RAC环境中，无需关注到底哪个实例启动在哪台机器上，我们需要的就是通过SCAN IP，通过Service名去访问数据库就好，而不需要通过实例名访问数据库。但是这里为了测试一下功能，还是决定1归1，2归2，我有说过我是完美主义者吗？

--先将dbserver1上的数据库服务资源reolocate到dbserver2中，这样实例2就运行回到了dbserver2中。
[grid@dbserver1 ~]crsctl relocate resource ora.orcl12c.db -s dbserver1 -n dbserver2
--再将dbserver1中的实例启动，因为实例2已经启动在dbserver2中，因此即使此时该实例是后启动的，但是仍然还是会命名为实例1。
[oracle@dbserver1 ~] srvctl start instance -db orcl12c -node dbserver1

最后将这个RAC数据库再改回到只会启动一个实例的默认状态。

[oracle@dbserver2 ~] srvctl modify srvpool -serverpool orcl_pool -min 0 -max 1

以后，无论是启动在哪台机器上，数据库的实例名永远会是dbname_1（注意，这里有一个下划线，这是Policy-Managed数据库实例的命名规则）。而我们访问数据库，则不应该指定实例名。比如：

sqlplus sys/passwd@db-cluster-scan:1521/orcl12c as sysdba

因为现在你已经无需关心到底实例是启动在哪台机器上了，后面是一个资源池，是不是有些熟悉这样的表述，是的，没错，Cloud! 我们也贴上了Cloud这个红到发紫的词，这就是Oracle私有云解决方案的构成组件之一。

How to cleanup ADRCI Homes

Leave a comment

ADRCI (ADR Command Interpreter) 是伴随Oracle 11g推出的新工具，由于各种log的位置纷繁复杂，因此在Oracle 11g中，Oracle将数据库、监听、客户端等的Log统一转到了diagnostic_dest初始化参数所指向的目录下的diag目录中，并且提供了ADRCI实用程序来进行高效查询及管理。在这之前我曾经写过两篇跟ADRCI相关的文章。
ADRCI Purge is NOT What You Think It Should Be：ADRCI的Purge命令用于清除日志文件中的内容，但是使用起来并非尽如人意。
Oracle11g for Windows ADRCI Issue：在Windows中使用ADRCI会产生的小问题，当然很久没有用过Windows，不知道这个问题是不是还依然存在。

ADRCI看上去是个很好的东西，但是除了show alert相对简单之外，其它的各种命令和查询条件的指定实际上比较繁琐，因此ADRCI在我周边的使用者寥寥可数，我算是坚持使用的为数不多者。因为使用者不多，所以对于ADRCI中一些极为简单的操作，了解者也比较少。

本文也是如此，如何删除在ADRCI中显示出来的多余的Homes？解决方法简单到令人发指。

问题重现，在命令中show homes显示出6个Home，这通常是由于安装过其它的数据库实例，然后删除的时候遗留下来的Log目录仍然存在。对于完美主义者来说这难以容忍。

[oracle@emnotech rdbms]$ adrci

ADRCI: Release 12.1.0.1.0 - Production on Mon Aug 18 01:34:31 2014

Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

ADR base = "/u01/app/oracle"
adrci> show home
ADR Homes:
diag/clients/user_oracle/host_266584670_80
diag/tnslsnr/emnotech/listener
diag/rdbms/orcl/orcl
diag/rdbms/slob/SLOB
diag/rdbms/slob/orcl
diag/rdbms/slob/slob

如上所示，ADR的基础目录在/u01/app/oracle，而各个Home都在其下的diag目录中，因此我们直接ls看一下目录结构。

[oracle@emnotech rdbms]pwd
/u01/app/oracle/diag/rdbms
[oracle@emnotech rdbms] ls -l
total 8
drwxr-x---. 3 oracle oinstall 4096 Jun  3 14:20 orcl
drwxr-xr-x. 5 oracle oinstall 4096 Aug  1 00:36 slob
[oracle@emnotech rdbms]$ ls -l slob
total 12
-rw-r-----.  1 oracle oinstall    0 Jun  5 03:16 i_1.mif
drwxr-xr-x. 16 oracle oinstall 4096 Jun  5 03:16 orcl
drwxr-xr-x. 16 oracle oinstall 4096 Jun  5 03:35 slob
drwxr-xr-x. 16 oracle oinstall 4096 Aug  1 00:36 SLOB

可以看到目录结构与ADRCI命令行中显示的完全一样，所以，解决方法就是直接rm掉不需要的目录。

[oracle@emnotech rdbms]rm -rf slob
[oracle@emnotech rdbms] ls -l
total 4
drwxr-x---. 3 oracle oinstall 4096 Jun  3 14:20 orcl

友情提示：一定要屡次确认才可以执行rm -rf这样危险的命令，每次对这个命令敲回车我都心惊胆战、心存敬畏。

[oracle@emnotech rdbms]$ adrci

ADRCI: Release 12.1.0.1.0 - Production on Mon Aug 18 01:35:23 2014

Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

ADR base = "/u01/app/oracle"
adrci> show home
ADR Homes:
diag/clients/user_oracle/host_266584670_80
diag/tnslsnr/emnotech/listener
diag/rdbms/orcl/orcl
adrci>

再次进入ADRCI中查看Homes，世界清静了。

Oracle Database In-Memory (12.1.0.2) Frequently Asked Question

Leave a comment

Oracle Database In-Memory选件于美国时间6月10日已经发布，发布会视频参看：http://www.oracle.com/us/corporate/events/dbim/index.html

什么时候Oracle Database In-Memory选件能够发布？

该选件将包含在Oracle Database 12c的第一个Pacthset（12.1.0.2）中一起发布。

价格如何？

价格会在发布日的时候决定。

新的Oracle Database In-Memory选件是否会替代In-Memory Database Cache（就是TimesTen技术）选件？

当然不，完全不一样的应用场景。In-Memory Database Cache是在应用程序层通过TimesTen来管理的内存性质的数据库，这是为了让OLTP应用享受到对于存储在Oracle数据库中一部分表的超低延迟访问而设计的。

Oracle Database In-Memory选件是否会替代TimesTen？

当然不。像上面所说，TimesTen通常是部署在应用层的，可能是作为一个独立的数据库，也可能是作为在Oracle数据库前面的In-Memory Database Cache。TimesTen提供的是超低延迟数据访问，由此提供了极速的响应时间。由此受益的OLTP系统通常不会创建用于报表应用的索引，也因此通常无法从数据库层的Oracle Database In-Memory选件中获得多少性能提升。

Oracle Database In-Memory选件是否会替代Exalytics？

当然不。并不是所有客户都需要在他们的系统中拥有强力的分析能力，而Exalytics是Oracle的一体化策略分析平台。它提供了丰富的分析工具和可视化工具，以及大量的标准报表、预测分析、数据发现，是为了最优化地运行BI和EPM工作的平台，是对数据库层的补充而不是竞争。 Exalytics也不仅仅是针对Oracle Database 12c的，它可以处理多种数据源，包括Teradata、Oracle database 11g、SAP Netweaver等。

那么在Exalytics中使用的是什么关系型内存数据库引擎呢？

Exalytics使用的是TimesTen In-Memory Database for Exalytics。在TimesTen产品发展路线图中也包含着跟Oracle Database In-Memory选件相类似的列式存储技术，而且是使用的相同的底层列式处理架构。这项技术计划在2014年跟Oracle Database In-Memory选件一起在相同的时间窗口发布。实际上，TimesTen和Oracle Database In-Memory选件在Oracle公司内部是由同一个小组来开发的，共享相同的创新技术以及底层架构。

那么在Exalytics中使用的内存数据库引擎在未来会变成Oracle Database In-Memory选件吗？

没有这个计划。Oracle期望TimesTen会持续研发。

Oracle Database In-Memory选件是否会替代Exadata？

当然不。这个问题太幼稚，就不做解释了。

好吧，那到底什么是Oracle Database In-Memory选件呢？

这是一项新的技术，内置在Oracle数据库中，通过内存中的列式存储数据来获得超快的数据处理能力。

当使用Oracle Database In-Memory时，数据库的大小受限于服务器中的可用内存容量吗？

不。由用户来决定哪些对象会存在In-Memory列式缓存中。如果一张表太大了，无法完全缓存在In-Memory列存中，Oracle会尝试将尽可能多的数据保持在内存中（以列的形式），剩下的仍然存储在闪存或者磁盘中（以原来行的形式），这样的操作非常高效并且是完全透明的。 你可以有选择性的定义一部分数据库，比如将热表、热分区、经常访问的列放入内存中。这就让除了Oracle原有的那些跨越内存、闪存、磁盘的各种优化方式之外，Oracle Database In-Memory选件还能够专门为频繁访问的业务关键数据提供帮助。当然，如果数据库足够小，全部表都能使用Oracle Database In-Memory选件。

Oracle Database In-Memory选件只会对分析/报表类业务有帮助吗？

虽然确实分析/报表类业务能够从列式存储中获得最多的收益，但是其他类型业务也同样能够受益。比如通过减少需要的索引，就能够加速OLTP业务。通常在以前的混合负载业务中需要在表上创建很多的多字段索引来支撑报表类型的查询，如今In-Memory列存则对DML操作造成更少的影响，而又可以提供相同的查询性能。 减少索引还能够带来优化和管理的简便，DBA不再需要去rebuild那些碎片化的索引，也不再需要去研究为什么优化器选择了错误的索引。

从Oracle Database In-Memory功能中能够期望获得多少性能提升？

使用该选项能够为多种查询负载提供显著的性能提升。从一个非常简单的星型查询到一个非常复杂的具有多个子查询的SQL，就算所有的的表都在内存中，In-Memory列式缓存仍然会胜过普通的Buffer Cache。 比如说，In-Memory列存在查询很少列上的很多行时，会提供极高的性能，通常这类查询都是分析类的查询，在这类查询上使用In-Memory列存和使用普通缓存（Buffer Cache）相比，有超过100倍的性能提升。

当使用Oracle Database In-Memory选件的时候，我该对索引做些什么吗？

你可以保留以前的所有索引，就像以前那样运行你的应用。Oracle优化器完全能够感知到内存中的列式数据，只有当确认使用这些列式数据会有性能提升的时候才会使用到，如果优化器认为从索引访问中能够获得更好的性能，那么就会自动去读取普通缓存（Buffer Cache）中的数据，就跟以前一样。 不过，如果将一些多列索引设置为invisible，引导Oracle优化器更多地去选择列式缓存，可能会带来额外的速度提升。然后，你可以删除掉这些无用的索引，这样又能带来进一步的性能提升，因为Oracle数据库需要维护的索引更少了。

如果使用Oracle Database In-Memory选项，数据库现在的功能会受影响吗？

没有任何一项现有的Oracle数据库功能会受到Oracle Database In-Memory选项的限制；很多操作还能在性能上获得显著提升；一些原本为了提高性能所做的操作（比如创建索引）会变得不再重要；安全性、高可用性以及其它的所有功能都跟以前一模一样，完全不受影响。 当然在DML操作上会有一些额外消耗，因为In-Memory列存要时刻跟表数据保持同步，但是这部分列存是完全在内存中的，所以不需要额外的Logging操作。

Oracle Database In-Memory选项在高可用性上跟其它厂商的内存数据库相比如何？

因为In-Memory列存并没有给Oracle数据库施加任何限制，因此在高可用性上可以享受Oracle数据库完整的丰富的高可用解决方案，而其它厂商的高可用性均不太完备。

如何规划In-Memory列存所需要的内存大小？

In-Memory Area（用于保存In-Memory列存的内存区域）是SGA中的一块新的缓存池，该缓存大小由初始化参数INMEMORY_SIZE指定，如果一旦设定，最小是100MB。因为In-Memory Area是SGA的一部分，因此其最大大小受制于分配了其它所有内存池之后的SGA中的剩余空间。INMEMORY_SIZE默认是0，也就是不启用Oracle Database In-Memory选项。 由于In-Memory Area是一块静态区域，所以不会被自动内存管理算法所影响。 如果想要修改In-Memory Area的大小，需要重启数据库实例，在RAC数据库中，可以在各实例的内存中复制In-Memory列存，因此可以通过重启节点的方式来最小化对应用的影响。

在RAC环境中，是否In-Memory列存是在集群的所有节点中完全镜像的？

在RAC环境中，用户可以自行设定使用以下三种选项中的任何一种： 1. 在所有实例的内存中镜像相同的表数据。这样每个实例都会读取自己的本地内存，通常这用于较小的表。 2. 表数据分布在所有实例的内存中。这样每个实例内存中只会保存表中的一部分数据，没有冗余复制。 3. 表数据分布在所有实例的内存中，并且为高可用性保留2份镜像。这种工作机制很像ASM的条带化和冗余性。