[Q]问有RAC 实施经验的大虾:不进行应用分布, RAC性能可以超过HA吗?

biti_rainy

最初由 hooman 发布
[B]

试过反向索引和HASH 分区.
但让人困惑的是, 使用反向索引会导致测试结果大幅度波动. 从300-1000/秒的结果都出现过. 百思不得其解. [/B]

hash 分区没有意义的啊，你打散的是 表数据，但是没有解决 索引block


要么，使用 hash + 反向索引

同时打散  索引和表数据看看？

hooman

最初由 biti_rainy 发布
[B]

hash 分区没有意义的啊，你打散的是 表数据，但是没有解决 索引block


要么，使用 hash + 反向索引

同时打散  索引和表数据看看？ [/B]

也试过, 只要使用了反向索引, 就会导致测试结果变得及不稳定.

我以为, 如果使用了LOCAL 索引, HASH 分区(根据索引列进行HASH)也能让索引跟着分散一下呢.

zjxs

reverse key index要求使用cbo，看看参数optimizer_mode，相关表和索引有没有analyze

reverse keyi index只支持equal操作，象<、>、BETWEEN等这样的操作是不能使用reverse key index，检查应用是否存在这样的操作

可以多做几次statspack，看看不同性能的statspack存在那些差异

zjxs

下面这些值都明显偏高了，如果不能调整应用（也包括你的库表、索引等逻辑结构的设计），在os、db参数上的调整对性能的提升可能没有太大意义了。
Ave time to process current block request (ms):           44.1
Ave receive time for current block (ms):                  39.2
Global cache hit ratio:                                    0.9
Ratio of fusion vs physical writes:                        0.2

Ave time to process current block request (ms):           28.3
Ave receive time for current block (ms):                  21.7
Global cache hit ratio:                                   13.4
Ratio of fusion vs physical writes:                        0.4

Ave time to process current block request (ms):           38.2
Ave receive time for current block (ms):                  44.8
Global cache hit ratio:                                   17.8
Ratio of fusion vs physical writes:                        0.3

Ave time to process current block request (ms):           21.0
Ave receive time for current block (ms):                  29.3
Global cache hit ratio:                                    4.4
Ratio of fusion vs physical writes:                        0.6

hooman

最初由 zjxs 发布
[B]下面这些值都明显偏高了，如果不能调整应用（也包括你的库表、索引等逻辑结构的设计），在os、db参数上的调整对性能的提升可能没有太大意义了。
Ave time to process current block request (ms):           44.1
Ave receive time for current block (ms):                  39.2
Global cache hit ratio:                                    0.9
Ratio of fusion vs physical writes:                        0.2

Ave time to process current block request (ms):           28.3
Ave receive time for current block (ms):                  21.7
Global cache hit ratio:                                   13.4
Ratio of fusion vs physical writes:                        0.4

Ave time to process current block request (ms):           38.2
Ave receive time for current block (ms):                  44.8
Global cache hit ratio:                                   17.8
Ratio of fusion vs physical writes:                        0.3

Ave time to process current block request (ms):           21.0
Ave receive time for current block (ms):                  29.3
Global cache hit ratio:                                    4.4
Ratio of fusion vs physical writes:                        0.6 [/B]

不太知道这几个统计项目的意义, 等我研究会儿先.这些值应该在多少之下才算正常呢?

一直在考虑进行有限度的库表, 索引的逻辑/物理结构的设计调整,  但已经找不到方向了(好像只有HASH分区, 反向索引这两大招, 再就是表空间, 数据文件逻辑上分开). 应用程序的工作模式暂时是不可能改的啦.


看起来, 好像好几位老大都不认为在这种应用模式下, 可以用RAC 来实现更大的吞吐量.

zjxs

Ave time to process current block request (ms): 44.1 处理其他instance块请求的平均时间
Ave receive time for current block (ms): 39.2 从其他instance得到块的平均时间
Global cache hit ratio: 0.9 块的global操作占会话逻辑读的比率
Ratio of fusion vs physical writes: 0.2 cache fusion写和物理写的比率

我以前测试的时候，时间都在1ms以内，global cache hit ratio小于1，最后一个没注意，到底达到什么值才是正常的，恐怕也没有一个绝对的限定吧

biti_rainy

我们的正常的数据，仅供参考


Global Cache Service - Workload Characteristics
-----------------------------------------------
Ave global cache get time (ms):                            0.4
Ave global cache convert time (ms):                        0.5

Ave build time for CR block (ms):                          0.0
Ave flush time for CR block (ms):                          0.0
Ave send time for CR block (ms):                           0.1
Ave time to process CR block request (ms):                 0.1
Ave receive time for CR block (ms):                        0.8

Ave pin time for current block (ms):                       0.1
Ave flush time for current block (ms):                     0.0
Ave send time for current block (ms):                      0.1
Ave time to process current block request (ms):            0.2
Ave receive time for current block (ms):                   0.9

Global cache hit ratio:                                    6.5
Ratio of current block defers:                             0.0
% of messages sent for buffer gets:                        6.1
% of remote buffer gets:                                   0.4
Ratio of I/O for coherence:                                1.1
Ratio of local vs remote work:                            15.1
Ratio of fusion vs physical writes:                        0.1

Global Enqueue Service Statistics
---------------------------------
Ave global lock get time (ms):                             0.1
Ave global lock convert time (ms):                         0.6
Ratio of global lock gets vs global lock releases:         1.0

GCS and GES Messaging statistics
--------------------------------
Ave message sent queue time (ms):                          0.0
Ave message sent queue time on ksxp (ms):                  0.6
Ave message received queue time (ms):                      0.0
Ave GCS message process time (ms):                         0.0
Ave GES message process time (ms):                         0.0
% of direct sent messages:                                53.7
% of indirect sent messages:                              45.2
% of flow controlled messages:                             1.1
          -------------------------------------------------------------
GES Statistics for DB: OCN  Instance: ocn2  Snaps: 13174 -13175

Statistic                                    Total   per Second    per Trans
--------------------------------- ---------------- ------------ ------------
dynamically allocated gcs resourc                0          0.0          0.0
dynamically allocated gcs shadows                0          0.0          0.0
flow control messages received                   0          0.0          0.0
flow control messages sent                       0          0.0          0.0
gcs ast xid                                      0          0.0          0.0
gcs blocked converts                        13,912          3.9          0.2
gcs blocked cr converts                     31,317          8.7          0.4
gcs compatible basts                             1          0.0          0.0
gcs compatible cr basts (global)             2,777          0.8          0.0
gcs compatible cr basts (local)              7,934          2.2          0.1
gcs cr basts to PIs                              0          0.0          0.0
gcs cr serve without current lock                0          0.0          0.0
gcs error msgs                                   0          0.0          0.0
gcs flush pi msgs                            4,130          1.1          0.0
gcs forward cr to pinged instance                0          0.0          0.0
gcs immediate (compatible) conver           31,404          8.7          0.4
gcs immediate (null) converts               24,680          6.9          0.3
gcs immediate cr (compatible) con           27,079          7.5          0.3
gcs immediate cr (null) converts           416,525        115.7          4.7
gcs msgs process time(ms)                   22,730          6.3          0.3
gcs msgs received                          597,739        166.0          6.8
gcs out-of-order msgs                            0          0.0          0.0
gcs pings refused                                5          0.0          0.0
gcs queued converts                              0          0.0          0.0
gcs recovery claim msgs                          0          0.0          0.0
gcs refuse xid                                   0          0.0          0.0
gcs retry convert request                        0          0.0          0.0
gcs side channel msgs actual                 2,590          0.7          0.0
gcs side channel msgs logical              259,000         71.9          2.9
gcs write notification msgs                     22          0.0          0.0
gcs write request msgs                       5,092          1.4          0.1
gcs writes refused                               0          0.0          0.0
ges msgs process time(ms)                      410          0.1          0.0
ges msgs received                           11,231          3.1          0.1
global posts dropped                             0          0.0          0.0
global posts queue time                          0          0.0          0.0
global posts queued                              0          0.0          0.0
global posts requested                           0          0.0          0.0
global posts sent                                0          0.0          0.0
implicit batch messages received            53,173         14.8          0.6
implicit batch messages sent                46,747         13.0          0.5
lmd msg send time(ms)                           39          0.0          0.0
lms(s) msg send time(ms)                         4          0.0          0.0
messages flow controlled                     6,018          1.7          0.1
messages received actual                   481,891        133.9          5.5
messages received logical                  608,845        169.1          6.9
messages sent directly                     281,043         78.1          3.2
messages sent indirectly                   236,629         65.7          2.7
msgs causing lmd to send msgs                1,638          0.5          0.0
msgs causing lms(s) to send msgs             9,101          2.5          0.1
msgs received queue time (ms)               16,402          4.6          0.2
msgs received queued                       608,921        169.1          6.9
msgs sent queue time (ms)                   11,256          3.1          0.1
msgs sent queue time on ksxp (ms)          239,530         66.5          2.7
msgs sent queued                           236,656         65.7          2.7
msgs sent queued on ksxp                   421,799        117.2          4.8
GES Statistics for DB: OCN  Instance: ocn2  Snaps: 13174 -13175

Statistic                                    Total   per Second    per Trans
--------------------------------- ---------------- ------------ ------------
process batch messages received              1,804          0.5          0.0
process batch messages sent                  1,398          0.4          0.0
          -------------------------------------------------------------

Yong Huang

最初由 hooman 发布
[B]

没错, 正是在INDEX 发现了大量的冲突, 目前还不知道是不是根本原因, 咋解决呢.

附件是STATSPACK. [/B]

How did you know it's contention on indexes? Anything special in statspack?

I have a wild idea open to everybody's critique. If you have heavy GCS related waits and they happen mostly during batch load, how about shut down all other instances except the one for batch load, or somehow restrict all users' access to only one instance, effectively changing the database to a non-RAC one during that period?

Yong Huang

hooman

最初由 Yong Huang 发布
[B]

How did you know it's contention on indexes? Anything special in statspack?

We checked the v$session_wait and found it.

[B]
I have a wild idea open to everybody's critique. If you have heavy GCS related waits and they happen mostly during batch load, how about shut down all other instances except the one for batch load, or somehow restrict all users' access to only one instance, effectively changing the database to a non-RAC one during that period?

Yong Huang [/B]

So your point is RAC is not better than HA in this case?

hooman

按照我们的应用模式, INSERT 操作时同一时刻, 不同SESSION 访问同一个数据块的概率有多大呢?

如果是表所对应的数据块可以用下式计算两个SESSION 同时访问一个数据块的概率:
N 是 HASH 分区的数目
n  是SESSION 数目

因为每个INSERT 肯定不会把最后一个BLOCK 写满, 而另一个INSERT 操作必定会企图也从这个BLOCK 开始写数据.