Rac 的GES/GCS原理7

Optimizing the Global Cache
In this section, you have seen that the amount of work performed by the cluster in support of the
Global Cache Service is highly dependent on the usage of data blocks within the cluster.

在这个章节中，你已经看到了，在群集内针对全局内存的服务量主要依靠于对群集中数据块
的使用。

 Although most applications will run on RAC without modification, you can reasonably expect to optimize their performance by partitioning them across the nodes.
虽然绝大多数的应用在RAC中可以直接运行而不需要修改，你可以在节点间进行应用分区的方式来优化他们的性能。
 The benefit of application partitioning is that the aggregate size of the buffer cache across all instances is effectively increased, since fewer duplicate data blocks will be stored within it.
应用分区的好处是所有实例间的buffer cache 数量被有效的增加了，因为只有很少的重复数据块被存储在buffer cache中。
The partitioning option, which has been available since Oracle 8.0, allows you to physically
partition tables. The introduction of database services in Oracle 10.1 provides a built-in mechanism
that can be used to implement application partitioning.
在分区的选项里，从ORACLE 8.0就开始有一个策略，这个策略允许使用物理分区表。
从oracle 10.1 开始，已经提供了一种内在的机制，这种机制能够被实施来支持应用分区。

In particular, database services and the
partitioning option can be used together to achieve node affinity for each physical partition. Finally,
the introduction of dynamic resource remastering at object level allows Oracle to optimize the use
of partitioned objects across the cluster by ensuring that they are locally mastered.

而且，数据库服务和分区选项能够组合起来达到每个物理分区的节点亲密性。
最终，在对象层次里进行动态资源重新划分资源属主技术允许oracle能够在群集层次
优化分区对象，保证这些资源可以被本地管理。

The key, therefore, to optimizing the global cache is to design your application in such a way
that you minimize the number of blocks that are shared between instances, which will minimize the
amount of interconnect traffic and the work performed by remote instances.

因此，优化全局内存的关键是设计合理的应用，让尽量少的数据块在实例间被共享访问，
这样可以减少内联心跳的流量以及减少远程节点所需做的工作量。

Other ways to achieve this optimization might include implementing sequences, reverse key indexes, global temporary tables, or smaller block sizes or rebuilding tables with fewer rows per block.
其他可能达到这个优化效果的方法还包括采用序列、做反键索引、使用全局临时表、或采用更小的数据块，或者重建表让每个数据块中有更少的行。

Instance Recovery
In the final section of this chapter, we will briefly describe instance recovery. While it is important
that your cluster can survive an instance failure and that the impact on throughput during instance
recovery is acceptable to your business, understanding the concepts behind instance recovery is
less important than understanding those underlying GCS or GES.

在这章的最后一部分，我们将快速的介绍下实例恢复的概念。因为对于群集来说，从实例失败中
恢复是非常重要的，而且实例恢复时候会有更多的压力，他们对于你的生产应用是可接受的，

懂得在GCS或GES下的恢复的概念比懂得实例恢复的概念要更加重要。

 This is because instance recovery only has a temporary performance impact,

whereas the Global Services can affect your performance at all times.
这是因为实例恢复只会对数据库的表现有临时的影响，而全局服务却可以不断的影响数据库的表现。

In RAC, recovery is performed when an instance fails and another Oracle instance detects the
failure. If more than one node fails at the same time, all instances will be recovered.
在RAC环境下，当一个实例失败了，而另外一个实例发现它的失败，恢复操作将被执行。
如果在同时有超过1个实例失败，所有的实例将被恢复。

The amount of recovery processing required is proportional to the number of failed nodes and
the amount of redo generated on those nodes since the last checkpoint. Following recovery, data
blocks become available immediately.
恢复进程所需要的数据量与上次检查点之前失败节点的个数、这些节点产生的redo数据量是成比例的。

在恢复之后，数据块将立即变得可用。

When an instance detects that another instance has failed, the first phase of the recovery is the
reconfiguration of the GES. Following this, the GCS resources can be reconfigured. During this phase,all GCS resource requests and write requests are suspended, and the GRD is frozen.
当一个实例发现另外一个实例失败了，恢复的第一步是对GES进行重新配置。然后，GCS
资源可以被重新配置。在这个阶段，所有对的GCS资源的读写请求都会被挂起，而GRD目录
被冻结。

 However, instances can continue to modify data blocks as long as these blocks are in the local buffer cache and appropriate enqueues are already held.

然而，实例仍然可以修改数据块，只要这些数据块还在本地的buffer cache中，而对应的
队列仍然被持有。

In the next phase, the redo log file of the failed instance is read to identify all the blocks that
may need to be recovered.
在下一个阶段，失败实例的redo 日志已经提供给实例来识别所有待恢复的数据块。

In parallel, the GCS resources are remastered. This remastering involves
redistributing the blocks in the buffer cache of the remaining instances to new resource masters.

同时，GCS资源属主将被重新定义。这个重新定义包括重新分配剩下实例中的buffer cache
的数据块，把他们分配给新的资源属主。

At the end of this phase, all blocks requiring recovery will have been identified.
In the third phase, buffer space is allocated for recovery and resources are created for all of the
blocks requiring recovery.

在这个阶段的最后部分，所有需要恢复的数据块将被重新识别。在第三阶段，buffer 空间
将被分配以供恢复使用，同时所有需要恢复数据块的资源将被创建。

 The buffer caches of all remaining instances are searched for past images
of blocks that may have been in the buffer cache of the failed instance at the time of failure.
剩下实例的buffer cache 将被搜索，寻找数据块的过去时间点镜像，这些数据块可能在实例
失败的时候存在于失败实例的buffer cache中。

 If a PI buffer exists for any block, then this buffer is used as a starting point for the recovery of that block. At this point, all resources and enqueues that will be required for the recovery process have
been acquired.

如果某个数据块存在一个时间点镜像，那么这个buffer数据块将被作为恢复那个数据块的
起点。在这个起点上，所有被恢复进程所需要的资源和队列都将被获取。

Therefore, the GRD can be unfrozen, allowing any data blocks that are not involved
in the recovery process to be accessed. The system is now partially available.
因此，GRD目录可以被解冻，以方面恢复进程来访问里面的资源。这个系统现在是部分可靠地。

In the next phase, each block that has been identified as needing recovery is reconstructed
from a combination of the original block on disk, the most recent past image available, and the
contents of the redo log of the failed instance. The recovered block is written back to disk, immediately after which the recovery resources are released, so that the block becomes available again.
在下一个阶段，每个被识别为需要恢复的数据块将被重建，从磁盘上的原始块，最近的可用的过去镜像，以及失败实例的redo 日志。一旦恢复的资源被释放，被恢复的数据块将被写回磁盘。这个数据库变得又可以访问了。

When all blocks have been recovered, the system is fully available again.
A block may be modified by the failed instance but not exist as a past image or a current block
in any of the remaining instances. In this case, Oracle uses the redo log files of the failed instance to
reconstruct the changes made to the block since the block was last written to disk.
当所有的数据块已经被恢复，系统将再次完全可用。
某些被修改的数据块存在于失败的实例上，但是在所有可用实例上并不存在它的过去时间点
镜像。这种情况下，ORACLE将使用失败节点产生的redo日志来重现自从上次该数据块写入
磁盘以来所有对该数据块的改变。

The buffer cache is flushed to disk by the database writer process when free buffers are required for new blocks. It is also flushed to disk whenever there is a database checkpoint, which occurs whenever there is a log file switch.

当实例要求读入更多的数据块，它会要求空闲的buffer，此时数据库写进程将把buffer cache
写入磁盘。每次发生log file switch 的时候都会发生数据库级别的checkpoint,当发生数据库级别的checkpoint时，buffer cache的内容也会被写入磁盘，

Therefore, you only need to recover redo generated since the last log file switch. Consequently,
the amount of redo and the amount of time required to apply the redo will be proportional
to the size of the redo log file.
因此，你只需要恢复从上一次日志切换以来的所有 redo 日志。因此，恢复redo的量以及
时间和redo 日志的大小是成比例的。

You can reduce the amount of time required for recovery by adjusting the mean time to recovery
using the FAST_START_MTTR_TARGET parameter, which allows you to specify the maximum amount of
time, in seconds, in which you wish the database to perform crash recovery.
你可以通过使用参数 FAST_START_MTTR_TARGET 来减少恢复所需的时间，这将允许你指定
最多在这段时间内你的数据库能够完成失败恢复。

The FAST_START_MTTR_TARGET adjusts the frequency of checkpoints to limit potential recovery time. This parameter was introduced in Oracle 9.0.1 and replaces the FAST_START_IO_TARGET parameter, which specifies the target number of database blocks to be written in the event of a recovery, and the LOG_CHECKPOINT_INTERVAL parameter, which specifies the frequency of checkpoints in terms of 512-byte redo log blocks.
FAST_START_MTTR_TARGET参数将调解checkpoint的频率，并减少潜在的恢复时间。这个参数
在ORACLE 9.0.1的时候被引进，并代替了参数FAST_START_IO_TARGET。FAST_START_IO_TARGET参数指定在恢复时候，目标数据库数据块的个数。而LOG_CHECKPOINT_INTERVAL 参数可以指定checkpoint 的频率，
依据redo 数据块大小512字节算。

Summary
This chapter described some of the internal algorithms that are used within a RAC database. While
understanding the exact implementation of each algorithm is not essential, having an appreciation
of them when designing new systems is highly beneficial.

总结：
这个章节描述了某些RAC数据库的内部算法。虽然我们并不需要懂得每个算法的实际执行，
但对这些算法有所了解对于我们设计新的系统是大有裨益的。

As you have seen, much of the performance of an Oracle RAC database depends on the application.
Therefore, testing and benchmarking your application prior to going into production are
vital to determine its effect on GCS and GES. By aiming to minimize the amount of interconnect
traffic your application generates, you will maximize both performance and scalability.
正如你看到的，绝大多数的ORACLE RAC性能问题要依靠应用来解决。
因此，在进入生产系统之前，测试和校准你的应用，确定他们对GCS/GES的影响，
是非常关键的。为了减少你的应用数据的内联的通信，你需要最大化你的数据库性能和
可扩展性。