【技术开发 技术文章】
1、传统工作量的分配
在标准环境还总，不同sizes的独立的计算单元被永久的分配的不同的应用中，例如人力资源、数据仓库、客户关系管理和批发零售。
这些计算单元需要对其高峰工作量进行评估测量。如果高峰工作量只发生在几个小时之内，则可能有大量的时间资源处于idle的状态。
2、网格工作量的分配
在网格计算中，提供了一个计算单元的全局池，不同的计算单元可以被临时的分配到特定的应用中。计算单元可以在应用中进行动态的交换。例如，在business较多时，更多的单元可以被用于CRM（客户关系管理）应用中，business高峰期过去后，CRM占用的一些单元就可以被转移到批发零售应用中。
网格计算使不用的资源减到最小。这意味着使用网格技术的环境总体开销要少于不使用网格技术的环境。
3、什么是Service
Service的概念是在oracle 8i中被引入，意味着listener在cluster中的各个nodes和Instances中做链接的工作量均衡。但随后，Service的概念、定义和实施被戏剧性的延伸了。Services是一个工作量管理的特性，它从总体上组织在Database中的工作执行，从而提高工作的可管理性、可测量性、可协调性和可恢复性。一个Service是Database中一组相关任务的组合体，有共同的功能和预期目标，相对其他Service，也有共同的相对优先级。Service的概念为single Instance中运行的应用管理竞争的单系统提供与多个Instance和Database的镜像。
通过使用标准接口Services，例如DBCA、企业管理器、SRVCTL，可以被配置、管理、enabled、disabled，并以单独的实体进行测量。
Services 提供可用性。当发生中断后，一个Service可以自动的通过其他正常的Instances获得恢复。
Services提供了性能调节的新的粒度。在Services环境中，工作量是可见并可衡量的。在主要的系统中，sessions是匿名并共享的，通过“Service和SQL”的调节取代了通过“session和SQL”的调节
当工作量增加时，一个Service可占用的Instances的数量是可以动态增加的，并且当工作量减少时，也可以收缩。这种资源的动态调配使得需求按照成本效益的方法得到满足。
4、RAC中Services的高可用性
在RAC环境中，高可用性的焦点是保护逻辑定义的应用Services。这个焦点比Instances上的高可用性更灵活。
Services必须被独立的定位，并且RAC的高可用性架构被利用对其进行实施。
Services通过不断的装载共享到cluster中的多个Instances中而成为可用的。任何Instance都可提供Services，负责运行期间的请求、失败和计划维护工作。cluster中的某些地方，Services总是可用的。
为了落实工作量的平衡和连续可用性的Services的特点，CRS为在oracle cluster registry（OCR）中的每个Service保存了高可用性的配置。高可用性的配置定义了一个优先的、可用的Instances集合，以便支持相应的Service。
一个优先的Instance 集合定义了Instances的number，这些Instances将支持相应的Service。它也会辨识在cluster中的每个Instance，从而在系统启动时确定Service将运行在哪个Instance上。
一个可用的Instance最初是不支持Service的。但当最优的Instance无力支持Service时，才会开始接受对于相应Service的链接。如果一个最优Instance失败，则Service将被透明的转交给为该Service定义的一个可用的Instance上。
note：一个可用Instance可以变成一个最优Instance，反过来也是一样。
5、RAC中可用的Service配置
* active/spare：这种Service配置，最简单的冗余——被称作主次或是1+1冗余被扩展到N+M冗余的一般情况。这里，N是提供Service的primary RAC Instances的数量，M是可以提供Service的多余的RAC Instances的数量。以上图中例子所示，在一个有三个节点的环境中，设置一个Instance提供AP Service，第二个Instance提供GL Service，第三个Instance为这两个Service提供故障转移功能。在正常的操作期间，这个spare节点仍可被其他应用利用。
* active/symmetric：此类Service设置中，相同的Services集合运行在每个Instance中。例如上图中，所有的三个节点上都运行着AP和GL Services。每个Instance都为其他Instances提供了共享负载和故障转移的功能。
* active/asymmetric：这种Service设置中，Services的能力需求相对较低。具体如图中例子。
6、Service的属性
在single Instance中，每个Service都有如下的属性：
* 全局唯一的name：它用于在本地cluster和全局的data guard中识别Service
* threshold：用于较好的控制响应时间和cpu的开销
* 相对于其他Service的优先级，以资源开销的比率或是优先级来定义
在RAC环境中，Services有两个额外的属性：
* 高可用性设置：一个描述符，用于指明当系统starts时，Service在Instances中的分配
* preconnection：对一致的预连接（preconnected）Service的定义，也被称作是shadow（影子）Instances。该preconnect Service可以在发生失败事件时跨越可用的Instances集，来支持响应的Service。当通过DBCA或是SRVCTL添加一个Service时，preconnect Service被自动的创建，并被CRS管理。这个Service被命名为<SERVICE>_PRECONNECT（这里我还是不太理解啊，米有看懂）
7、Service 类型
oracle 10g中支持两类Service：应用Service和内部Service。应用Services的主要功能是分派工作量。完成相同业务功能的sessions被一起分组。对于oracle应用，AP、AR、GL、MFG、WIP、BOM等，在Database中形成了功能上的分工，所以可以被分类为Services。
除了应用Services外，RDBMS也支持两个内部的Services：
* SYS$BACKGROUND：只用于后台进程。
* SYS$USERS：对于user sessions，它是默认的Service，不与任何应用Service相关联。
这两个内部Services支持所有的工作量管理特性，并且都不能被stop或是disable。
对于每个Database，最多只能有64个Services，62个应用Services和两个内部Services。并且，Service的name必须限于64个characters。
note：shadow Services也包括在应用Service的范畴。此外，对于每个advanced queue的创建，一个Service也被创建。
8、Service的创建
像其他Database objects一样，Services也是通过data dictionary和动态性能视图来维护并追踪的。
每个Service都有一个唯一的name用于辨识它在本地cluster和全局data guard中的位置。
对于single-instance oracle，可以通过DBMS_SERVICE包创建Services。
在startup Instance时，也会根据初始化参数SERVICE_NAMES的值隐式的创建Services。
对于RAC环境中的高可用性特点，应该要么通过DBCA，要么通过命令行工具SRVCTL来创建Services。这个定义过程也隐式的创建了高可用性业务规则，并将通过CRS进行自动管理从而保持Services的可用性。高可用性业务规则被保存在OCR中。
1）用DBCA创建Services
在使用DBCA创建RAC Database时，可以添加或是删除Services，建立非常好的的设置，为Services配置透明的应用故障转移（transparent Application failover TAF）。在用DBCA创建、修改或是删除Service时，它会为Services配置CRS资源，同时设置net Service实体，并将其start。当用DBCA删除Services时，DBCA stop Service，删除CRS为其分配的资源，并删除网络服务实体。
在数据库被创建以后，也可使用DBCA执行关于Database Services 简单的管理操作。
2）用SRVCTL创建Services
图中建立了两个Services，AP和GL，存储在cluster repository中，并通过CRS管理。AP的首选Instance是RAC01，可用Instance是RAC02。
此外在oracle 10g中，RAC中一个Service可以有多个primary nodes。
note：还可使用SRVCTL的-P选项设置一个Service的transparent Application failover，该参数值可以是NONE、BASIC、PRECONNECT。
图中，初始化定义了ERP Service，其preferred Instances是RAC01和RAC02，available Instances是RAC03和RAC04。
起初，ERP连接都是指向RAC01和RAC02的。当RAC02失败并down机后，CRS检测到RAC02的的失败，由因为ERP的基数是2，则CRS会在一个available Instance上重建一个Service，这里选用了RAC03 。此时，ERP的连接请求被指向了RAC01和RAC03上，用于提供当前的服务。尽管CRS可以restart RAC02，但是ERP Service并不会回退给RAC02。此时，RAC02和RAC04是available Instances。
note：可以手工的发起SRVCTL命令relocate Service，使服务回退给RAC02 。
9、everything switches to Services
* data dictionary 为Services提供维护
* automatic workload repository（AWR）管理着Services的性能。AWR记录了Service相关的SQL执行时间、等待类型和资源开销。当响应时间超过某个阙值，AWR会发出alerts。特定的动态性能视图显示了当前Service在历史一小时内的状态信息。
* Database resource Manager可用于Services的管理从而优化Instance中的应用工作量。
* 此外，jobs scheduler 、并发进程、streams queue也可在Service下运行。
* RAC的高可用性架构确保了Services在一个site是可用的。
* data guard broker与RAC相结合，可以通过转移primary Service到其他data guard site从而获得容灾性。
10、在client 应用中使用Services
应用程序和中间层连接池通过使用TNS连接描述符选择Service。例如：
ERP=(DESCRIPTION=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=node-1vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node-2vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node-3vip)(PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=node-4vip)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=ERP)))
注意，address列表中不应该使用hostname，而应该使用虚拟ip（VIP）从而确保当连接的node宕机后能得到及时的ip迁移，从而快速返回timeout。
下面显示的分别是thick和thin JDBC连接描述：
url=”jdbc:oracle:oci:@ERP”
url=”jdbc:oracle:thin:@ERP”
note：LOAD_BALANCE=ON 用于oracle net，从而随机的将请求发到连接描述符的地址。这被称作是client的负载平衡。
11、对Services使用资源管理器
Database resource Manager可以根据Services来分配工作。它通过直接将comsumer groups绑定到Services中来管理在一个Instance上Services的相对优先级。当一个client连接使用一个Service，在连接是consumer group被透明的分派。从而是resource Manager可以根据它们的Service重要性管理工作请求。
具体来个例子：
例子中，在将consumer groups映射到Services前，必须先创建consumer groups，并为每个consumer groups分配资源计划。资源计划可以是以优先级为基础的或是以比率为基础的。例子中，先创建了创建了HIGH_PRIORITY consumer group，并将其映射到AP Service。可以同理创建LOW_PRIORITY consumer group。
最后，授权给相应的权限。
12、在Services中使用scheduler
在RAC环境中，scheduler对于每个Database使用一个job table，对于每个Instance使用一个job coordinator。job coordinator彼此之间进行交互，从而获得当前的信息。
scheduler可以使用Services并且给RAC环境带来好处。一个特定job class使用的Service是在job class被创建时确定的。在执行过程中，job classes中分配的jobs和job classes是在Services内运行的。job classes使用Service确保了scheduler的工作被辨识用于工作量的管理和性能的调优。
对于高可用性，scheduler提供了Service的类同来代替Instance的类同。jobs不是scheduled到特定的Instance下运行，而是scheduled到特定的Service下执行。所以，如果一个Instance 宕机，job仍然会被在其他提供该Service的Instance上运行。
note：通过指明运行jobs的Service，job cooradinator会平衡相应的工作量，从而获得更好的性能。
上一个具体的实例：
例子中，假设已经定义了一个叫HOT_BATCH_SERV的Service。先建立了一个叫HOT_BATCH_CLASS的batch queue由scheduler管理。并将其与HOT_BATCH_SERV相互关联。
随后，定义job。
13、Service上使用并发操作
对于并发查询和并发DML操作，并发查询从属进程可以从查询coordinator中继承Service用于操作阶段。但是当前Services并不限制用于执行并发查询的Instances的集合。通过一个Service的链接发起一个并发的查询，可能会使用不属于该Service部分的Instances去执行。一个从属进程属于指定的Service，即使在不支持该Service的Instance上。如图（ERP是相应的Service名）：
14、metric thresholds和Service
可以为特定Instance上的每个Service指定两个metric thresholds：
* 调用的响应时间：ELAPSED_TIME_PER_CALL。响应时间的设定目的在于指明希望的运行时间，至多在某个范围之内。
* CPU调用时间：CPU_TIME_PER_CALL
AWR会监控Service 的时间，并会在性能超过指定的threshold时发出警报。
对于每个Service的相应统计信息，可用下面的语句：
SELECT service_name, elapsedpercall, cpupercall FROM V$SERVICEMETRIC;
对于前一小时的数据，可以查看视图V$SERVICEMETRIC_HISTORY
具体设置metric threshold的实例：
exec DBMS_SERVER_ALERT.SET_THRESHOLD(-
METRICS_ID => dbms_server_alert.elapsed_time_per_call,
WARNING_OPERATOR => dbms_server_alert.operator_ge,
WARNING_VALUE => ‘500000′,
CRITICAL_OPERATOR => dbms_server_alert.operator_ge,
CRITICAL_VALUE => ‘750000′,
OBSERVATION_PERIOD => 15,
CONSECUTIVE_OCCURRENCES => 3,
INSTANCE_NAME => ‘I0n’,
OBJECT_TYPE => dbms_server_alert.object_type_service,
OBJECT_NAME => ‘ERP’);
此例中，ELAPSED_TIME_PER_CALL threshold被加到ERP Service上。该metric会对每个访问相应的Service的user进行elapsed 时间的衡量。
当在一个15分钟的周期中，三次连续超过0.5秒，将会报警告信息。如果在一个15分钟的周期中，三次连续超过0.75秒，将报严重警报。
note：此threshold必须在RAC中所有支持该Service的Instance都进行设置。
15、Service的聚合统计和跟踪
默认情况，重要的统计信息和等待事件是按照每个Service来收集的。一个应用程序可以通过MODULE和ACTION names辨识Service中事务的重要性，进一步限定Service。通过分类的工作量，这可更准确的定位性能较差的事务。当使用连接池在系统中进行性能监控或是事务进程监控时，这是十分重要的。因为在这些系统中，sessions是共享的，则使得审计比较困难。
SERVICE_NAME、MODULE和ACTION实际是V$SESSION中的字段。SERVICE_NAME会在user登陆时被自动设置。MODULE和ACTION名称通过应用程序调用DBMS_APPLICATION_INFO包或是特殊的OCI调用来设置。MODULE应该被设置为当前执行的程序认可的名称。而ACTION应该被设置为user在该module中执行的特定行为。传统的跟踪是针对每个session进行的。而现在是根据Service进行相应工作量的统计。
在每个Instance上，主要的统计信息和等待事件是自动以Service为单位统计收集的，无需设置。但想要获得更好的粒度级别的统计信息，需要使用DBMS_MONITOR包中的SERV_MOD_ACT_STAT_ENABLE存储过程。SERV_MOD_ACT_STAT_DISABLE停止已经开始的统计。此外开启与关闭统计都是对每个Instance中访问Database的Service应用进行的。并且在Instance重启后仍然存在。该存储过程可以在三个级别上定义跟踪统计：SERVICE_NAME，SERVICE_NAME/MODULE和SERVICE_NAME/MODULE/ACTION。
具体实例：
16、trcsess工具
SERV_MOD_ACT_STAT_ENABLE存储过程产生的统计结果被放在多个追踪文件中。trcsess工具将选择的trace files输出基于session id、client id、Service name、action name和module name进行合并。从而将信息合并到一个文件中，该文件可由tkprof进一步利用。
17、Service的性能视图
V$SESSION和V$ACTIVE_SESSION_HISTORY中可以查看相应的Service、module和action信息。
V$SERVICE_STATS、V$SERVICE_EVENT、V$SERVICE_WAIT_CLASS、V$SERVICEMETRIC和V$SERVICEMETRIC_HISTORY中查看调用时间和性能统计信息。
当允许统计收集特殊的modules和action时，性能统计信息可以在每个Instance上的V$SERV_MOD_ACT_STATS视图中查看。
大约有300多个与性能有关的统计跟踪信息可以在V$SYSSTAT中查看到。其中，28个统计指标是跟踪的Services信息。要查看按照Services统计的数据，可以执行下面的语句：
SELECT DISTINCT stat_name FROM v$service_stats;
28个统计指标中，DB time和DB CPU是值得一提的。DB time统计了每个call的平均响应时间。DB CPU是平均每个call占用的实际的CPU时间。这两个参数的差值就是该Service的等待时间。由此，可了解到相应时间的百分比，从而进一步追踪相关的等待原因。
note：DBA_ENABLED_AGGERGATIONS显示了关于允许的请求统计集合信息。
18、对Services的管理
根据想要执行的管理任务，可以选用EM、DBCA或是SRVCTL进行管理。
在RAC环境中，与Services相关的管理任务主要有：
* disable一个Service用于在一个指定的Instance或是所有的Instance上disable特定的Service。disable state主要用于下面的情况：当由于维护的原因，Service处于down的状态，为了避免CRS此时不恰当的对其进行恰当的restart。通过在所有Instances上disable一个实体Service影响所有的Instances。
* enable一个Service主要是使处于disable的Service重新运行在CRS中，重新可以由CRS自动restart并分配。即使相应的Service已经被stopped，也可执行enable一个Service的操作。当一个Service被创建后，enable是默认的状态。如果Service已经为enable状态，则此command将被忽略。enable的Services是可以被started，而disable的Services是不能被started的。通过在Service所在的所有Instances上执行enable一个Service的命令将影响到所有Instance。
* start一个Service命令用于在特定的Instance上start一个或多个Services。只有enabled的Service才可以被start。如果试图start一个Service，但是当前运行该Service的Instances已经达到其基数，该命令将会失败。
* stop用于在cluster Database全局或是在指定Instance上，停止一个或是多个Services。如果想要保持某个Service的stop状态，应该在stop该Instance后disable相应的Service。否则它可能被自动的restart。
* remove 一个Service用于在所有或是特定Instances中，从cluster Database中删除其相应的而设置。在可以remove前，必须先stop相应Service。可以只删除某特定Instances上的一个Service。
* relocate一个Service用于从source Instance迁移Service到target Instance。target Instance必须是在该Service的preferred或available列表中。此操作将强行将sessions断开。relocate Service是临时的操作，除非你修改了永久的配置。
* modify一个Service的配置用于永久的修改一个Service的配置。此修改将会在Service被restart后生效。这允许管理员将一个Service从一个Instance移动到其他Instance。此外，此命令改变一个Service的preferred和available Instances。
display当前Service的状态。
当使用DBCA或是SRVCTL创建Service之后，只能用EM对其进程管理。当使用DBCA添加Services时，DBCA会配置相应的net Service实体，并starts它们。当使用DBCAremove Services时，DBCA stop相应的Service，remove相应的CRS资源。并remove它的net Service实体。
当使用SRVCTL创建Service，必须单独使用SRVCTL命令start 它。
使用SRVCTL命令的实例：
