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命令的实例：