[20151203]关于grd对性能影响.txt

[20151203]关于grd对性能影响.txt

--前几天写了1篇,统计分析对grd的影响,提到一些大表在晚上分析后会出现资源重新分配,参考链接
--blog.itpub.net/267265/viewspace-1851145/

--我们的生产系统业务并不是很忙,今天做一点"危险"的测试,让另外1个实例掌控某些另外实例经常访问的对象。

--先看看没有切换的awr报表(昨天的10-11点)rac部分:

RAC Statistics  DB/Inst: xxxx/xxxx1  Snaps: 9593-9594
                                Begin   End
                                ----- -----
           Number of Instances:     2     2
Global Cache Load Profile
~~~~~~~~~~~~~~~~~~~~~~~~~                  Per Second       Per Transaction
                                      ---------------       ---------------
  Global Cache blocks received:                 14.52                  0.17
    Global Cache blocks served:                  9.26                  0.11
     GCS/GES messages received:                134.63                  1.60
         GCS/GES messages sent:                136.04                  1.61
            DBWR Fusion writes:                  0.21                  0.00
Estd Interconnect traffic (KB)                243.13

Global Cache Efficiency Percentages (Target local+remote 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer access -  local cache %:   99.97
Buffer access - remote cache %:    0.01
Buffer access -         disk %:    0.02

Global Cache and Enqueue Services - Workload Characteristics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     Avg global enqueue get time (ms):      0.0

          Avg global cache cr block receive time (ms):      0.1
     Avg global cache current block receive time (ms):      0.3

            Avg global cache cr block build time (ms):      0.0
             Avg global cache cr block send time (ms):      0.0
      Global cache log flushes for cr blocks served %:      0.3
            Avg global cache cr block flush time (ms):      0.0

         Avg global cache current block pin time (ms):      0.0
        Avg global cache current block send time (ms):      0.0
Global cache log flushes for current blocks served %:      0.0
       Avg global cache current block flush time (ms):      0.0

Global Cache and Enqueue Services - Messaging Statistics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     Avg message sent queue time (ms):      0.2
             Avg message sent queue time on ksxp (ms):      0.3
                 Avg message received queue time (ms):      0.1
                    Avg GCS message process time (ms):      0.0
                    Avg GES message process time (ms):      0.0

                            % of direct sent messages:    90.53
                          % of indirect sent messages:     9.29
                        % of flow controlled messages:     0.19
          -------------------------------------------------------------
--以上是昨天10:00-11:00 的awr 报表 rac的小部分。注意看 Estd Interconnect traffic (KB) 243.13 ,很小的流量。

--今天把一些大对象让另外的实例掌控。
SYS@xxxx2> oradebug setmypid
Statement processed.
SYS@xxxx2> oradebug lkdebug -m pkey 94701
Statement processed.
SYS@xxxx2> oradebug lkdebug -m pkey 93703
Statement processed.
SYS@xxxx2> oradebug lkdebug -m pkey 97158
Statement processed.

SYS@xxxx2> select * from GV$GCSPFMASTER_INFO where DATA_OBJECT_ID in (94701,93703,97158);
INST_ID    FILE_ID DATA_OBJECT_ID GC_MASTERIN CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT
---------- ---------- -------------- ----------- -------------- --------------- ------------
         1          0          93703 Affinity                 1               0           30
         1          0          94701 Affinity                 1               0           32
         1          0          97158 Affinity                 1               0            5
         2          0          93703 Affinity                 1               0           29
         2          0          94701 Affinity                 1               0           31
         2          0          97158 Affinity                 1               0            5
6 rows selected.

--实际上10:29分,有1个对象有跑回来了。DATA_OBJECT_I=97158
SELECT inst_id
        ,policy_event
        ,data_object_id
        ,target_instance_number
        ,event_date, substr(event_date,12,5) hhmm,to_char(to_date(event_date,'mm/dd/yyyy hh24:mi:ss'),'d') week
    FROM gv$policy_history
   WHERE data_object_id =97158
ORDER BY data_object_id, event_date desc ,inst_id;

   INST_ID POLICY_EVENT         DATA_OBJECT_ID TARGET_INSTANCE_NUMBER EVENT_DATE           HHMM       W
---------- -------------------- -------------- ---------------------- -------------------- ---------- -
         2 push_affinity                 97158                      1 12/03/2015 10:29:42  10:29      5
         1 push_affinity                 97158                      2 12/01/2015 07:46:09  07:46      3
         2 push_affinity                 97158                      1 11/25/2015 17:04:52  17:04      4
...

SYS@xxxx2> select * from GV$GCSPFMASTER_INFO where DATA_OBJECT_ID in (94701,93703,97158);
   INST_ID    FILE_ID DATA_OBJECT_ID GC_MASTERIN CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT
---------- ---------- -------------- ----------- -------------- --------------- ------------
         1          0          93703 Affinity                 1               0           30
         1          0          94701 Affinity                 1               0           32
         1          0          97158 Affinity                 0               1            6
         2          0          93703 Affinity                 1               0           29
         2          0          94701 Affinity                 1               0           31
         2          0          97158 Affinity                 0               1            6

--为了测试准确再次切换过去:        
SYS@xxxx2> oradebug lkdebug -m pkey 97158
Statement processed.

--等11点后看awr报表。
RAC Statistics  DB/Inst: xxxx/xxxx1  Snaps: 9617-9618

                                Begin   End
                                ----- -----
           Number of Instances:     2     2

Global Cache Load Profile
~~~~~~~~~~~~~~~~~~~~~~~~~                  Per Second       Per Transaction
                                      ---------------       ---------------
  Global Cache blocks received:                 31.64                  0.37
    Global Cache blocks served:                  0.78                  0.01
     GCS/GES messages received:                416.42                  4.85
         GCS/GES messages sent:              1,107.51                 12.90
            DBWR Fusion writes:                  0.14                  0.00
Estd Interconnect traffic (KB)                556.99

Global Cache Efficiency Percentages (Target local+remote 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer access -  local cache %:   99.97
Buffer access - remote cache %:    0.01
Buffer access -         disk %:    0.01

Global Cache and Enqueue Services - Workload Characteristics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     Avg global enqueue get time (ms):      0.0

          Avg global cache cr block receive time (ms):      0.3
     Avg global cache current block receive time (ms):      0.1

            Avg global cache cr block build time (ms):      0.0
             Avg global cache cr block send time (ms):      0.0
      Global cache log flushes for cr blocks served %:      0.8
            Avg global cache cr block flush time (ms):      0.0

         Avg global cache current block pin time (ms):  13915.2
        Avg global cache current block send time (ms):      0.0
Global cache log flushes for current blocks served %:      1.5
       Avg global cache current block flush time (ms):   6311.1

Global Cache and Enqueue Services - Messaging Statistics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                     Avg message sent queue time (ms):      2.6
             Avg message sent queue time on ksxp (ms):      2.3
                 Avg message received queue time (ms):      0.1
                    Avg GCS message process time (ms):      0.0
                    Avg GES message process time (ms):      0.0

                            % of direct sent messages:    12.28
                          % of indirect sent messages:    87.68
                        % of flow controlled messages:     0.04
          -------------------------------------------------------------      

--注意Estd Interconnect traffic (KB)=556.99 ,比前面增加1倍。

--对比前面这些指标都存在很大的变化。

GCS/GES messages received:          416.42                  4.85
GCS/GES messages sent:              1,107.51                12.90
Avg global cache current block pin time (ms):  13915.2
Avg global cache current block flush time (ms):   6311.1
% of indirect sent messages:    87.68

--第1次的结果:
GCS/GES messages received:            134.63                  1.60
GCS/GES messages sent:                136.04                  1.61
Avg global cache current block pin time (ms):      0.0
Avg global cache current block flush time (ms):    0.0
% of indirect sent messages:     9.29

--当然这里这点流量不算什么,如果业务分割不好,内联流量就会增加,对系统影响还是很大的。
--收尾工作,把上面的修改切换回来。

SYS@xxxx1> select * from GV$GCSPFMASTER_INFO where DATA_OBJECT_ID in (94701,93703,97158);
   INST_ID    FILE_ID DATA_OBJECT_ID GC_MASTERIN CURRENT_MASTER PREVIOUS_MASTER REMASTER_CNT
---------- ---------- -------------- ----------- -------------- --------------- ------------
         2          0          93703 Affinity                 0               1           30
         2          0          94701 Affinity                 0               1           32
         2          0          97158 Affinity                 0               1            8
         1          0          93703 Affinity                 0               1           31
         1          0          94701 Affinity                 0               1           33
         1          0          97158 Affinity                 0               1            8
6 rows selected.

--补充:Dynamic Remastering Stats部分内容:

Dynamic Remastering Stats                DB/Inst: xxxx/xxxx1  Snaps: 9593-9594
-> times are in seconds
-> Affinity objects - objects mastered due to affinity at begin/end snap

                                                 per    Begin      End
Name                             Total   Remaster Op     Snap     Snap
------------------------- ------------ ------------- -------- --------
remaster ops                         1          1.00                 
remastered objects                   1          1.00                 
replayed locks received         13,765     13,765.00                 
replayed locks sent                  0          0.00                 
resources cleaned                    0          0.00                 
remaster time (s)                  3.9          3.93                 
quiesce time (s)                   1.2          1.19                 
freeze time (s)                    0.2          0.22                 
cleanup time (s)                   0.6          0.59                 
replay time (s)                    0.1          0.12                 
fixwrite time (s)                  1.2          1.17                 
sync time (s)                      0.6          0.64                 
affinity objects                                 N/A      175      176
                          ------------------------------------------------------

Dynamic Remastering Stats                DB/Inst: xxxx/xxxx1  Snaps: 9617-9618
-> times are in seconds
-> Affinity objects - objects mastered due to affinity at begin/end snap

                                                 per    Begin      End
Name                             Total   Remaster Op     Snap     Snap
------------------------- ------------ ------------- -------- --------
remaster ops                         5          1.00                 
remastered objects                   5          1.00                 
replayed locks received      1,112,712    222,542.40                 
replayed locks sent          3,383,681    676,736.20                 
resources cleaned                    0          0.00                 
remaster time (s)                 26.1          5.22                 
quiesce time (s)                   6.9          1.38                 
freeze time (s)                    1.0          0.21                 
cleanup time (s)                   4.3          0.87                 
replay time (s)                    4.2          0.84                 
fixwrite time (s)                  4.5          0.90                 
sync time (s)                      5.1          1.03                 
affinity objects                                 N/A      176      173
                          ------------------------------------------------------

--自己看还是一目了然的。                         

时间: 2024-08-19 01:30:50

[20151203]关于grd对性能影响.txt的相关文章

[20171028]测试大量子光标对性能影响.txt

[20171028]测试大量子光标对性能影响.txt --//做一个测试例子说明存在大量子光标对性能影响. 1.环境: SCOTT@test01p> @ ver1 PORT_STRING                    VERSION        BANNER                                                                               CON_ID ------------------------------

[20171102]测试大量子光标对性能影响2.txt

[20171102]测试大量子光标对性能影响2.txt --//跟开发讲关于绑定变量的问题,总有人讲不是有一个参数cursor_sharing能快捷简单地解决问题,设置cursor_sharing=force, --//实际上合理的使用绑定变量才是王道. --//许多开发人员设置这个参数带来的各种bug,我第一次在8i下使用差点到处服务器cpu资源耗尽,好在我知道我当时的改动,修改回来一些正常. --//我当时还记得设置这个参数报ora-00600错误. --//我想起以前10g下遇到设置cur

盘点 Oracle 11g 中新特性带来的10大性能影响

盘点 Oracle 11g 中新特性带来的10大性能影响 原创 2017-08-02 盖国强 数据和云 Oracle的任何一个新版本,总是会带来大量引人瞩目的新特性,但是往往在这些新特性引入之初,首先引起的是一些麻烦,因为对于新技术的不了解.因为对于旧环境的不适应,从Oracle产品到技术服务运维,总是要走过一个磨合的长期过程. 请注意:我们并不推荐大家盲目的关闭和摒弃Oracle的新特性,我们建议大家在遇到问题时,做出适合自己的调整. 就此盘点一下 Oracle 11g 中,那些新特性带来的新

双通道还是高主频 实测内存对A10-7890K性能影响

  众所周知,双通道.高主频内存对APU性能的发挥有着比较大的影响,尤其是在游戏体验中表现明显.今天我们就来测试一下AMD新款旗舰APU A10-7890K在不同内存频率和通道数量下的性能表现,看看内存对APU性能影响有多大. 关于 A10-7890K 处理器 A10-7890K是AMD今年推出的新款旗舰APU处理器,采用了四核设计,默认主频为4.1GHz,加速可达4.3GHz. 图形方面,A10-7890K内置Radeon R7 GPU,具备512个流处理器,核心频率866MHz,官方内存频率

DX12对CPU要求高吗 CPU对DX12游戏性能影响

  Win10内置的DX12有利于提升游戏体验,不过高版本的DX也对CPU与显卡提出了更高的要求.微软的DirectX一路走来,已经经历了12个版本,无论是硬件还是游戏,也都发生了天翻地覆的变化,先进的技术也给我们带来了更好的游戏体验. DX12对CPU要求高吗?老司机实测CPU对DX12游戏性能影响 早在2014年,微软在GDC上正式发布了新一代的API DirectX12(简称DX12),DX12最重要的变化就是更底层API,具体包括:应用可追踪GPU流水线.控制资源状态转换.控制资源重命名

SqlServer(索引)--创建复合索引时,复合索引列顺序对查询的性能影响[转]

http://www.cnblogs.com/wy123/p/5604400.html SQL Server创建复合索引时,复合索引列顺序对查询的性能影响 说说复合索引 写索引的博客太多了,一直不想动手写,有一下两个原因: 一是觉得有炒剩饭的嫌疑,有兄弟曾说:索引吗,只要在查询条件上建索引就行了,真的可以这么暴力吗? 二来觉得,索引是个非常大的话题,很难概括出所有的情况,你不整出点新意来,倒是有抄袭照搬的嫌疑 既然写了,就写一点稍微不一样的东西出来, 好了,废话打住, /* 20160814备注

MSSQL · 实现分析 · Extend Event实现审计日志对SQL Server性能影响

背景 在上一篇月报分享中,我们介绍了SQL Server实现审计日志功能的四种方法,最终的结论是使用Extend Event(中文叫扩展事件)实现审计日志方法是最优选择,详情参见MSSQL · 实现分析 · SQL Server实现审计日志的方案探索.那么,使用Extend Event实现审计日志的方案会面对如下疑问: Extend Event是否满足可靠性要求 Extend Event是否满足吞吐量要求 Extend Event对SQL Server本身语句查询性能影响到底有多大 这篇文章就是

SQL Server创建复合索引时,复合索引列顺序对查询的性能影响

原文:SQL Server创建复合索引时,复合索引列顺序对查询的性能影响    说说复合索引 写索引的博客太多了,一直不想动手写,有一下两个原因: 一是觉得有炒剩饭的嫌疑,有兄弟曾说:索引吗,只要在查询条件上建索引就行了,真的可以这么暴力吗? 二来觉得,索引是个非常大的话题,很难概括出所有的情况,你不整出点新意来,倒是有抄袭照搬的嫌疑 既然写了,就写一点稍微不一样的东西出来, 好了,废话打住,开搞   搭建测试环境: 创建一张表,模拟实际业务中的一个表,往里面填入数据, 时间字段上,相对按照时间

降低COBOL与其他语言进行交互时产生的性能影响

在本文中,作者会解释让 C++OBOL 与其他语言进行交互所产生的性能影响,并给出一些提示来避免被动受制于不利影响. 几十年前,当我初次开始使用大型机 COBOL 时,我发现它不能与非 COBOL 语言交互.我与一位教授探讨将这作为一个论文题目,主要探讨让 COBOL 与非 COBOL 语言进行交互所产生的性能影响. 为了弄明白可能会有什么性能影响,我基于 "A http://www.aliyun.com/zixun/aggregation/29818.html">Fortran