第四章数据库性能配置

初始化参数
建库后不应随便更改
open_cursors是每个会话开启的最大游标数量，推荐值为500

关于undo段：v$undostat视图中存储着回滚段的监控和调整数据。
v$rollstat视图包含着回滚段的行为信息

重做日志文件的大小设置
重做日志文件的大小影响着性能，dbwr、arch进程依赖于重做日志文件的大小。
通常来说大一些比较保险
重做日志文件大小影响着数据库写进程和检查点行为。而检查点的频率由多个因素决定，包括日志文件大小和fast_start_mttr_target参数。
如果fast_start_mttr_target设置为限制实例恢复时间，oracle将频繁产生检查点。
这种情况下，日志文件应该足够大，以避免检查点产生时由于日志写入未完成而等待。
优化的参数可以从v$instance_recovery的optimal_logfile_size列得到（可能为空）

重做日志文件的大小没有一个固定的说法，但通常从100MB到几个GB不等。保证日志文件最多每20分钟切换一次。

表空间的说明：
除了system、sysaux，还需要一个临时表空间、一个撤销表空间、至少一个应用相关的表空间。
对于永久表空间，本地管理和全局管理很大程度上影响着性能。
一般来说，增删改相对查询更多的系统选择本地管理。

对于永久表空间，oracle推荐自动段空间管理。

临时表空间既可以是本地管理也可以是数据字典管理。推荐本地管理临时表空间，统一区大小设置为1MB。

如果有多个用户同时使用临时表，区的大小应该再小一点，如256K。因为每次调用都需要至少一个区。

创建表和索引时需要注意：
指定自动段空间管理表空间 以便最大性能
仔细设置存储参数  包括pctfree等（自动段空间管理不需要设置）

表压缩
根据业务需要，可以将堆表设置为压缩格式。
块还可以在buffer cache中压缩。
表压缩不仅节约空间，还节省内存，即buffer cache的需求。
调优就是减少不必要的i/o，增加可能的buffer cache hits。

在大表压缩前，需要评估压缩特性。经验上来讲，1000个数据块可以提供非常精确的压缩特性了。提供的sampling越多，压缩越精确。

未用空间的回收：
If an object does have space available for reclamation, then you can compact and shrink segments or deallocate unused space at the end of a segment.

视图v$dispatcher中包含调度器进程的信息
v$dispatcher_rate：调度器具体数据

To assess dispatcher performance, query the V$DISPATCHER_RATE view and compare the current values with the maximums. If your present system throughput provides adequate response time and current values from this view are near the average and less than the maximum, then you likely have an optimally tuned shared server environment.

If the current and average rates are significantly less than the maximums, then consider reducing the number of dispatchers. Conversely, if current and average rates are close to the maximums, then you might need to add more dispatchers.

我们应该避免dispatcher进程 的争用。方法有：
1.增加dispatcher
dispatcher的个数由初始化参数max_dispatchers决定
2.使用连接池
3.允许多会话

如果系统中存在排队现象，可以使用如下语句查看消息队列：
SELECT DECODE(TOTALQ, 0, 'No Requests',
WAIT/TOTALQ || ' HUNDREDTHS OF SECONDS') "AVERAGE WAIT TIME PER REQUESTS"
FROM V$QUEUE
WHERE TYPE = 'COMMON';

通过以下语句查看到当前有多少共享服务器：
SELECT COUNT(*) "Shared Server Processes"
FROM V$SHARED_SERVER
WHERE STATUS != 'QUIT';

如果发现共享服务器争用现象，首先通过检验共享池和大池确认这不是内存的争用。如果性能依然很差，可以分配更多的资源来减少共享服务器的争用。
方法是修改如下参数：
max_dispatchers
max_shared_servers
dispatchers
shared_servers