Maclean Liu(刘相兵 发表于 2012-2-27 22:17:20

RAC Optimized Cache Fusion protocols

Improved performance for read-intensive workloads
improves any read from disk (not cache) whether short random reads or large table scans
Throughput improved up to 70% for internal read-only benchmark

“70%” improvement is best case scenario.    The gain will be dependent on % physical reads vs logical reads.

Fine tuning of Cache Fusion to improve performance of workloads
Read-intensive tables - Readers do not send messages to other nodes
Writers must send messages to every other node
Long running queries  - After checkpoint time on all nodes passes query start time
All blocks relevant to the query are guaranteed to be on disk
Scans of large tables - Sequential scans of large tables will read the table directly from disk, bypassing the need to coordinate with caches on other nodes.  Previously this only worked for table scans run using parallel query slaves.



RAC Other Enhancements
Fine tune performance, scaling, failover, management
Seamless integration with XA and Microsoft Transaction Server
Faster and more robust handling of instance crashes and hangs
Most of this also in 10.2.0.3
Runtime Connection Load Balancing works with OCI Session Pools
Hang Management
Deadlock detection and correction (both single instance and RAC)
Diagnose hangs by detecting  hung process and remove
Status available via views
V$HM_HANGS
V$HM_HUNG_SESSIONS
V$HM_STATS  

Parallel Query slaves will only execute on nodes where the service of the query owner is active.  
No longer have to code instance_groups

Fine tuning of Cache Fusion to improve performance of workloads
Read-intensive tables - Readers do not send messages to other nodes
Writers must send messages to every other node
Long running queries  - After checkpoint time on all nodes passes query start time
All blocks relevant to the query are guaranteed to be on disk
Scans of large tables - Sequential scans of large tables will read the table directly from disk, bypassing the need to coordinate with caches on other nodes.  Previously this only worked for table scans run using parallel query slaves.

Improved monitoring and problem diagnostics with Enterprise Manager
Performance Metrics can be viewed on single summary graph or tiled graphs for each instance
Able to do performance analysis based on Service

Allows the units of work performed across these Oracle RAC instances to share resources and act as a single transaction I.E. tightly coupled
2PC requests can be sent to any node in the cluster
CLUSTERWIDE_DISTRIBUTED_TRANSACTIONS, which is TRUE by default
Note: for performance will probably still want to use DTP services.  

10.2 runtime connection load balancing was JDBC and ODP.NET only
10.2 FCF from all client APIs



oracle_bin 发表于 2012-3-7 22:24:24

CF的机制得好好看看,弄清原理

zhuqibs 发表于 2012-3-15 18:52:24

cache fusion的机制,好像并不在怎么复杂啊

zhuqibs 发表于 2012-3-15 18:59:19

刘老大的资料就是多啊

zhuqibs 发表于 2012-3-15 19:01:48

祝刘老大新婚快乐,给大家共享更多的资料

bjchangxiao 发表于 2017-6-9 15:54:57

好东西,学习一下
页: [1]
查看完整版本: RAC Optimized Cache Fusion protocols