ORACLE 数据库部署方案设计|江阴雨辰互联

2023年7月11日发(作者：)

ORACLE 数据库部署方案

和安装配置指南

1. 总论

1.1 目的

为加强系统安装维护的规化管理，参考系统的相关文档，进行了深化、细化，力求结合实际的设计、实施工作，建立一套系统设计、实施的标准方案，对设计、实施起到规、指导作用。

文档主要从一个设计者的角度进行编写。首先介绍了产品可实现的部署模式，如何选择部署模式，其次要考虑设计涉及到的因素，有针对性地做好数据库的设计等: 为提高数据库的性能，对程序开发提出了的要求。

文档中参数建议值是对系统设计时的指导，是针对目前系统状况所提出了的经验值，但由于应用系统的复杂性，每个系统有自己的特点，建议按建议值进行系统的初始配置，在压力测试和系统上线后根据实际需要做相应的调整，文档作为系统设计的规和参考。

1. 2 受众

项目设计和实施人员，部分项目组系统设计人员，相关运行维护技术人员。

1. 3关键术语

高可用性群集：High Availability Cluster 简称 HA Cluster:

实时应用集群:Real Application Clusters 简称 RAC:

Dataguard 是ORACLE 推出的一种高可用性的数据库方案, 在软件上对数据库进行设置:

Recovery Time Objective，复原时间目标,是企业可容许服务中断的时间长度，简称 RTO ：

Recovery Point Objective，复原点目标，是指当服务恢复后，恢复得来的数据所对应时的间点，简称RPO： 2. 数据库部署模式

数据库服务器目前的情况：

服务器

IBM P550

IBM DS5100

数量

2台

1台

参数

8CPU 64G存

16*540G/2=3600G

备注

IBM AIX

存储设备

2. 1 单机模式

数据库服务器采用单服务器模式，满足对可用性和性能要求不高的应用，具备以下特点:

1、硬件成本低。单节点，硬件投入较低，满足非重要系统的需求。

2、安装配置简单。由于是单节点、单实例，所以安装配置比较简单。

3、管理维护成本低。单实例，维护成本低。

4、对应用设计的要求较低。由于是单实例，不存在RAC 系统应用设计时需要注意的事项，所以应用设计的要求较低。

5、可用性不高。由于是单服务器、单实例，所以服务器和实例的故障都会导致数据库不可用。

6、扩展性差。无法进行横向扩展，只能进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能进行增加硬件配置等纵向扩展，且扩展性有局限。

此模式要求:

1 硬件配置方面预留扩展量。由于该模式无法进行横向扩展，所以在选择硬件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。

2 充分考虑该模式是否满足应用未来一段时间的需求。需要考虑应用在未来一段时间是否会发生变化，该模式是否满足应用变化的需求。

2. 2 HA 热备模式

数据库服务器采用HA 热备模式，可以满足对可用性有一定要求的应用，

具备以下特点: 1、需要冗余的服务器设备。该模式需要有冗余的服务器硬件，以满足一备一

或者一备多的需求。硬件成本较高。

2、需要出软件的支持。该模式需要配合HA 软件才可以实现。

3、安装配置相对简单。该模式比单节点、单实例的模式配置复杂一些，需要

更多的配置步骤，但相比较RAC、DATAGUARD 等模式要简单。

4、管理维护成本低。单实例，对维护人员的要求较低，维护成本低。

5、对应用设计的要求较低。由于是单实例，不存在RAC 系统应用设计时需要

注意的事项，所以应用设计的要求较低。

6、具备一定的高可用性。由于是多服务器、单实例，所以服务器和实例有故

障时会发生实例在不同服务器上的切换，导致数据库的暂时不可用。无法满足

对可用性有严格要求的应用类型。

7、扩展性差。无法进行横向扩展，只能进行纵向扩展。当应用对性能有更高

的要求时，该模式的数据库服务器无法进行增加节点、实例等横向扩展，只能

进行增加硬件配置等纵向扩展，且扩展性有局限。

此模式要求:

1 硬件配置方面预留扩展量。由于该模式无法进行横向扩展，所以在选择硬

件配置时要为以后的纵向扩展预留扩展量，避免硬件无法满足性能需求的情况。

2 充分考虑该模式是否满足应用未来一段时间的需求。需要考虑应用在未来一段时间是否会发生变化，该模式是否满足应用变化的需求。

2. 3 RAC 模式

数据库服务器采用RAC 模式，满足对高可用性要求高的应用类型，

具备以下特点:

1、需要多个硬件服务器。根据节点的个数，相应的需要多个硬件服务器。硬件成本较高。

2、某些数据库版本需要HA 软件的支持。该模式下，某些数据库版本需要配合相应的HA 软件才可以实现。

3、安装配置复杂。该模式比起单实例模式，安装配置相对复杂，安装配置周期长。

4、管理维护成本高。该模式的管理维护，对管理维护人员的要求较高，管理维护成本较高。

5、对应用设计的要求较高。需要充分考虑业务的逻辑性，以避免在多节点之间的信息交换和全局锁的产生。

6、具备较高的高可用性。由于是多服务器、多实例，单服务器和实例有故障不会影响数据库的可用性。可以满足对可用性有严格要求的应用类型。

7、扩展性好。既可以进行横向扩展，也可以进行纵向扩展。当应用对性能有更高的要求时，该模式的数据库可以通过增加节点的方式进行横向扩展，也可以通过增加硬件配置等纵向扩展，具备良好的扩展性。

此模式要求:

1、硬件配置方面预留扩展量。预留一定的硬件扩展量，可以更灵活的进行扩展。2、在应用设计时，充分考虑业务逻辑，减少多节点间的信息交换量，更好的发挥RAC 的优点。

2. 4 DATAGUARD 模式

数据库服务器采用DATAGUARD 灾备模式，可以满足对可用性有特殊需求的应用，具备以下特点:

1、需要冗余的服务器设备。该模式需要有冗余的服务器硬件。硬件成本较高。

2、需要元余的存储设备。主机和备机都需要同样的存储空间，成本较高。

3、安装配置比较复杂。该模式比单节点、单实例的模式配置复杂一些，需要更多的配置步骤。

4、管理维护成本高。该模式对维护人员的要求较高，维护成本高。

5、具备一定的容灾特性。当主机整个数据库系统不可用并短期无法恢复时，可以把数据库系统切换到备机上，具备容灾的功能。

6、备机可以用作只读查询。备机可以切换到只读状态供报表之类的查询操作，减轻主机的压力。

要求:

1、主机与备机在物理上要分开。为了实现容灾的特性，需要在物理上分割主机和备机。

2、进行合理的设计，充分实现DATAGUARD 的功能。 2. 5 RAC+DATAGUARD 模式

数据库服务器采用RAC+DATAGUARD 模式，可以满足对可用性和容灾都有特定需求的应用，具备以下特点:

1、需要冗余的服务器设备。该模式需要有冗余的服务器硬件。硬件成本较高。

2、需要冗余的存储设备。主机和备机都需要同样的存储空间，成本较高。

3、安装配置比较复杂。该模式既需要配置RAC 又需要配置DATAGUARD ，配置过程比较复杂，配置周期长。

4、管理维护成本高。该模式对维护人员的要求较高，维护成本高。

5、具备很高的可用性和容灾性。该模式既满足高可用性也满足容灾的需求。

6、备机可以用作只读查询。备机可以切换到只读状态供报表之类的查询操作，减轻主机的压力。

要求:

1、主机与备机在物理上要分开。为了实现容灾的特性，需要在物理上分割主机和备机。

2、进行合理的设计，充分实现DATAGUARD 的功能。 2 数据库部署模式选择建议

3. 1 部署模式的选择

在设计数据库时必须考虑系统的可用性、业务连续性要求，针对系统的可用性需求，采用不同的数据库部署模式:

1 对RTO=O、RPO=O 的系统，建议数据库采用RAC 或RAC+DataGuard 模式，数据库单台设备故障时对业务没有影响，并考虑灾备系统的设计。

2 对RTO<=4 小时， RP0<15 分钟的系统，建议数据库采用DataGuard的模式，设备故障时通过HA 技术切换到备用设备，保证系统的可用性，对重要的系统要考虑灾备的设计。

3 对4 小时

4 对8 小时

5 对行非关键系统，测试系统，建议采用PC 服务器、冷备或单机的处理模式。

3.2 应用建议

1、系统的应用建议使用绑定变量，可以重复利用执行计划；

2、对于AIX 系统，建议在操作系统配置文件.profile 中设置export

AIXTHREAD_SCOPE = S，在Aix 4.3 或者 Aix 5.1的环境下，设置该变量可以大幅度的减少进程存的使用量

3、频繁使用的小表要放入库缓存中:

4、频繁使用的index 需要放入库缓存的keep池中:

5、对于表空间，建议使用自动段空间管理(ASSM) ;

7、对于存储频繁更新的数据的表空间或者衰，建议设置较大的pctfree ，以避行迁移或者行；

8、如果使用Raw Device，建议使用AIO;

3.3 操作系统参数建议

2.4.1 AIX

以下是建议的网络参数配置:

#/usr/sbin/no -r -0 rfc1323=1

#/usr/sbin/no -r -0 ipqmaxlen=512

#/usr/sbin/no -r -0 sb_ max=4*1048576 4M

#/usr/sbin/no -r -0 udp_sendspace=1048576 1M

#/usr/sbin/no -r -0 udp_recvspace=1048576 1M

打开对文件大小等的限制:

fsize = -1

cpu = -1

data = -1

stack = -1

core = 2097151

rss = -1

nofiles = -1

fsize hard = -1

stack hard = -1

rss hard = -1

nofiles hard = -1 5 数据库设计

4.1 数据库类型特点分析

在创建和规划一个Oracle 数据库之前，首要任务应确定将来投产的数据库属于何种业务类型。目前的应用业务有以下类型:

1、OLTP（Online Transaction Processing)

2、OLAP （Online Analysys Processing)

(联机事务处理〉

OLTP数据库支持某种特定的操作， OLTP系统是一个包含繁重及频繁执行的DML应用，其面向事务的活动主要包括更新，同时也包括一些插入和删除。例如预定系统或在线时时交易系统，网上银行和ATM 自动取款机系统。OLTP系统可以允许有很高的井发性(在这种情况下，高并发性通常表示许多用户可以同时使用一个数据库系统)。

(联机分析处理)

OLAP系统可提供分析服务。这意味着数学、统计学、集合以及大量的计算，一个OLAP系统并不永远适合OLTP或DSS模型，有时它是两者之间的交叉。另外，也可以把OLAP看作是在OLTP系统或DSS之上的一个扩展或一个附加的功能层次。通常，地理信息系统或有关空间的数据库和OLAP数据库相集成，提供图表的映射能力。用于社会统计的人口统计数据库就是一个很好的例子。

4.2 数据库规模

对于数据库的规模，仅从数据量来衡量其规模的大小。因为数据量的规模是反映数据库规模的主要指标。具体如下:

1、数据库业务数据量小于100GB 属小规模数据库

2、数据库业务数据量100GB-600GB 属中等规模数据库

3、数据库业务数据量600GB-1TB 属大规模数据库 4、数据库业务数据量大于lTB 属超大规模数据库

4.3 数据库部署

1 数据库产品选择

Oracle 版本 10g ，版本10.2.0.5。

2 磁盘阵列布局原则

目前磁盘阵列的使用变得越来越普遍，由于磁盘阵列和单个磁盘具有较大的不同，故此在数据库的物理划分上也有较大的不同。对于磁盘阵列系统，由于RAID 的划分，不存在一个个真实的物理盘，对应的是物理卷(PV) ，逻辑卷组(VG) ，逻镜卷(LV) 。在这种情况下Oracle 推荐使用SAME 技术，即全部镜像和条带化(Stripe And Mirror Everything) 。在对磁盘阵列做SAME 处理后，所有的逻辑卷都分布在所有的物理磁盘上，每个逻辑卷的读写都能够利用的到所有的物理磁盘的吞吐能力，同时获得较高的可靠性。同时我们在使用磁盘设备的时候不需要考虑各个不同文件的IO 情况，因为它们都使用同样的全部磁盘的吞吐能力，这进一步简化了数据库系统的文件管理工作，避免一些意外的操作。对较重要、并且效率要求较高的系统推荐使用RAIDO+l 的磁盘配置而不使用RAID5 ，因为RAID5 的校验技术会降低应用数据库系统的效率。但使用RAIDO+1 ，

比RAID5 需要更多物理磁盘。

不同的类型对象，尽量分布在不同的卷组上建议:

1、表对应的数据和索引分别放置在不同的物理磁盘上:

2、控制文件的多个备份分别放置在不同的物理磁盘上:

3、REDO 日志组的多个成员放置在不同的物理磁盘上;

4、建议将Oracle 文件、SYSTEM 表空间、TEMPORARY 表空间、UNDO表空间放置在不同的物理磁盘上;

5 数据库物理结构设计

5.1 软件安装路径及环境变量

建立单独的文件系统来安装数据库软件，且文件系统的mount点不要直接建立在根目录下。

安装路径: / ORACLE_HOME / db/ oracle

各种环境变量设置:

ORACLE_BASE=/ ORACLE_HOME / db/ oracle

CRS_HOME=/ ORACLE_HOME /db/oracle/crs/ora10 ，如

/ home/ db/ oracle/ crs/ l0.2.0

ORACLE_HOME=/home/db/oracle/product/{ 数据库release 版本} ，如

/home/db/oracle/product/10.2.0 。

5.2 数据库实例的命名规则

普通使用模式的Oracle 数据库的服务名和实例名CSID) 是相同的; RAC

模式下的Oracle 数据库的服务名与实例名不同。

数据库服务名的命名格式为: XXXYY db {m}

数据库的SID 的命名格式为: XXXYY db {m}

{n}

说明:

1、其中xxx 表示长度为3 个字符的应用项目缩写。

2、YY: 代表数据库用途， pd 代表生产库， hi 代表历史库， rp 代表报表库，

cf 代表配置库:

3、m 表示数据库序号，从0-9 ，根据项目的数据库数量进行编号。

4、n 表示RAC 节点实例序号1,2, 3…… 。用以区分多节点的RAC 数据库的不同实例。对于普通模式的数据库，该位不指定。 5.3 表空间设计

5.3.1 业务数据量的估算

估算所有业务SCHEMA 下的所有table 的尺寸。

数据量估算的前提:

•

数据库的物理表结构已经确定，并且设计己凝固。

•

用户方提供较为准确的估算依据，例如业务变动的频率、数据需要保存

的周期等。该表是一个示例，可根据业务的不同有所变化。

序号

表名

增长量

年数据量

新上线或扩容，对所申请的存储不得全部一次性挂上,应该预留出30%左右的空间用于追加,以防止出现业务发展和预期不一致时剩余空间多寡不均,调整困难。

操作系统上应该预先做好几个合适大小的lv 备用,包括用于System/sysaux

等表空间的小尺寸的lv 和用于数据表空间、索引表空间的大尺寸1v ,这些lv 要求在HA两边主机都可见,不必单纯因为数据库增加数据文件而需要重新同步HA。

5.3.2 表空间的使用规则

目前多数数据库系统采用数据" 大集中" 原则，对数据库的性能要求较高。这就要求对数据库进行必要的优化配置。表现在表空间的配置上，应遵循以下原则:

1、最小化磁盘I/O 。

2、在不同的物理磁盘设备上,分配数据。

3、尽可能使用本地管理表空间。

多数系统采用RAID1+O 或RA1DO+l,该技术很好的解决了最小化磁盘I/O。

基本不必考虑在不同的物理磁盘设备上，分配数据的原则。 5.3.2.1 表空间的类型

按照表空间所包含的数据文件类型， Oracle 表空间类型有三类:

1、数据表空间(permanence tablespace) -用来保存永久数据，包含永久数据文件。强烈建议在永久表空间创建永久数据文件，不要创建临时数据文件。

2、临时表空间(temporary tablespace) -用来保存临时数据，多用于数据的磁盘排序。强烈建议在临时表空间创建临时数据文件，不要创建永久数据文件。

3、回滚表空间(rollback/undo tablespace) -仅用来保存回退信息。不能在该表空间创建其他类型的段(如表、索引等)。为了更好的管理表空间，同时提高Oracle 数据库系统性能，在上述三类基础上，针对数据的业务功能，进一步对其加以分类。因此Oracle 数据库的表空间划分为基本表空间和应用表空间。如下表:

(1) 基本表空间: 是指Oracle 数据库系统为其自身运行而使用的表空间。

表空间类别

数据表空间

表空间名称

SYSTEM表空间

存储容

Oracle 数据库系统自身生成统数据字典对象

存储SYSAUX数据

说明

存储oracle 数据库系的和使用一基本表空间

Oracle 数据库系统自身生成的和使用一基本表空间

如果UNDO表空间是自动管理，则Oracle 数据库系统自身生成的

数据表空间 SYSAUX

回滚表空间 UNDO表空间容纳回滚数据

生产数据库不应该有如TOOLS、XDB、EXAMPLE 等oracle 默认安装表空间。

(2) 应用表空间:是指业务应用数据保存在此类表空间中。它由DBA 或相关

的数据库规划设计人员创建和规划。

表空间类别

临时表空间

数据表空间

表空间名称

TEMP 表空间

TABLES 表空间

TABLES PARTITION

存储容

容纳排序数据

存储小数据表

存储巨型表数据

说明

数据表空间

INDEXS 表空间

INDEXS PARTITION

LOB 表空间

存储小数据表的索引

存储巨型数据表的索引

存储LOB 的数据

5.3.2.2表空间及其文件的命名规则

数据文件都使用裸设备方式，使用固定大小，不推荐设置为自动扩展。

(1) 基本表空间及其文件命名规

表空间名称

SYSTEM

SYSAUX

UNDOTBSl

TEMP

说明:

• 普通文件名(即创建在文件系统上的文件)

nn 为从01 开始计数的两位整数序号。如: 01, 02, 03 ……… 。

各表空间根据需求在建库时确定。

(2) 数据文件路径: /home/db/oracle/oradata/{DB_NAME}/

(3) 数据文件的使用方式:

裸设备:适用于RAC 及共享磁盘双机热备数据库架构。创建数据库前，在指定的目录下创建指向裸设备的软连接文件。命令如下:

ln -s / dev/ rxxxxx / home/db/ oracle/oradata/{DB_NAME}/

(2) 应用表空间及其文件命名规:

说明:

• 表空间的命名规则

nn 为从01 开始计数的两位整数序，号，表示表空间的数目。如: 01, 02 ,03 。

• 普通文件名（即创建在文件系统上的文件)

' nn 为从01 开始计数的两位整数，表示数据文件的数目。如: 01, 02,03。

各表空间根据需求在建库时确定。

(2) 数据文件路径: / home/ db/ oracle/ oradata/ {DB_NAME}/

(3) 数据文件的使用方式:

普通文件名

说明

总空间大小设置为2G

总空间大小设置为4G，如果空间非常紧，可设置为2G

总空间不小于8G

总空间不小于4G 裸设备:适用于RAC 及共享磁盘双机热备数据库架构。创建数据库前，在指定的目录下创建指向裸设备的连接文件。命令如下:

ln -s / dev/ rxxx / home/ db/ oracle/ oradata/ {DB_NAME} /r+ 表空间名称_nn_ Slze

其中: xxx 为裸设备的名称。该名规则相关命名规。

5.3.3 表空间的物理使用规则

5.3.3.1 表空间的物理分布

对于小规模数据库，I/O 不是主要的性能瓶颈，可以不考虑物理分布的问题。

对于中规模数据库及大规模数据库，应当考虑:

1、尽可能把应用数据表空间、应用的索引表空间以及相应得分区表空间分布

在独立的物理卷上。

2、其次把UNDO、TEMP、REDOLOG 分布在不同的物理卷上。

5.3.3.2表空间的存储参数的设置

5.3.3.2.1 表空间的参数设置原则

对于数据库的存储空间管理Oracle 有以下的选择:

1 Extent 的管理

对Extent 的管理有两种方式。一般情况下，我们推荐数据库管理员使用本地

管理中的指定大小(Uniform Size) 的方式创建表空间。

1.数据字典，管理(Dictionary Management)

在数据字典的管理方式中，数据库使用数据字典来跟踪数据对象的存储分配，

这样当出现数据对象的存储变化时，数据库需要更新数据字典以保证系统可以跟踪数据库对象的存储变化，这在某种程度上会造成系统性能的下降。

2.本地管理(Local Management)

在本地管理方式中，数据库使用每一个数据文件的前面8 个数据块中的每一位来代表数据块的占用方式。由于这种方式跟踪数据对象的存储分配不需要访问

数据字典，这在一定程度上避免了递归调用的出现，提高了系统存储管理的效率。

对于本地的Extent 管理有两种方式:

(1) 自动分配(Autoallocate)

自动分配的方式指由数据库系统按照数据对象的大小决定该对象的每一个

EXNENT 的大小。一般情况下，由于数据库系统并不能预先的确定该对象的总的大小，数据库总是倾向于在初始的几个Extent 使用较小的值，然后按照8-128-1024-8192 个数据块的方式急剧的增大。这通常会造成系统过多的碎片和较低的存储空间的利用效率。

(2) 指定大小(Uniform Size)

指定大小的方式指由数据库管理员在创建表空间时间指定该表空间的所有的

EXNENT 的大小，这样该表空间的所有的Extent 具有同样的大小。一般情况下，

由于数据库管理员能够预先的估计出该表空间的数据对象的大小，所以数据库管理员通常能够确定合适的UNIFORM SIZE 来创建数据表空间。

通过指定合适的数据表空间，可以避免系统出现过多的碎片和提高存储空间的利用效率。

一般情况下，建议数据库管理员能够使用指定大小的方式来创建表空间，除非明确知道表空间中仅仅存储较小的数据对象，否则不要使用自动的EXTENT 管理方式。

2 Segenmt 的管理

对Segment 的管理可分为两种。我们推荐使用ASSM 方式。

1.手工管理方式(Manual)

手工管理方式是指用户创建表空间时使用手工指定参数Freelist ， Freelist

Group 来控制表空间的段的空闲块。

手工的管理管理可以带来更多的灵活性。

2.自动管理方式(ASSM)

自动的管理方式指数据库系统使用BITMAP 的方式来管理空闲块。在这种情况

下如果多个对象需要分配空间，可能会造成对某一块的竞争。 5.3.4 表的参数设置原则

e_Pctused

存储参数pctfree 和pctused 决定了一个数据块在不同的数据库操作下的可

用性，它与数据对象的操作性质密切相关。

对于主要操作为insert 的数据对象，可以考虑设定较小pctfree 和较大的

pctused ，如pctfree=5 Pctused=60 。对于更新较为频繁的系统,可以设定较大的pctfree 和较小的pctused 来避免行的迁移，如pctfree=20 Pctused=40 。对于数据的保留时间较长，同时数据的删除较少可以考虑设定较小的pctfree 和较大的pctused ，如: Pctfree=10 Pctused=50 。

ns_Maxtrans

存储参数initrans 和maxtrans 决定了数据对象的同一个数据块中能够并发

进行的事务数。

由于目前的数据块由逐步变大的趋势，故此同一个数据块中发生并发事务的几率在上升。

对于db_Block_Size=8192 的OLTP 系统，可以设定initrans = 4 ，Maxtrans=10

5.3.4.1 Undo/temp 表空间的估算

• Undo 设置原则

推荐使用UNDO TABLESPACE ，让系统自动管理回滚段。

须考虑以下几个问题:

系统并发事务数有多少?

系统是否存在大查询或者大是事务?频繁与否?

能提供给系统的回滚段表空间的磁盘空间是多少?

• Temp 设置原则

可创建缺省临时表空间temp ，取数据库的缺省参数。一般情况下，生产数据库系统的临时表空间不是用缺省的。应另外创建临时表空间，以供较大的排序事务使用。可设置每个Transaction 类别用户，对应一个临时表空间。

5.3.5 索引的使用原则

1.基本使用原则

(1) 当查询的行数占整个表总行数的比例<=5%时，建立B树索引效果比较明显。

(普通索引就是B数索引)

(2) 在频繁进行排序或分组(即进行group By 或order By 操作)的列上建立索引。

(3) 在频繁使用distinct关键字进行查询的列上面建立索引。

(4) 进行表连接时，在连接字段上面建立索引。

(5) 对于键值频繁更新的索引，需要定期的进行重建。

2.复合索引的使用原则

一般情况下，对于经常同时使用多个数据项进行查询的对象可以创建复合索

引，使用复合索引时特别要考虑的各个数据项在索引中的相对位置。

一般情况下，我们把最常用的列放在第一位而不太常用的列放在稍后面的位

置。在复合索引创建后，我们要求用户在查询数据的时候也遵循同样的方式来使

用索引。虽然目前能够使用复合索引中的后面的数据项，但是按序使用复合索引可以给我们带来较高的效率。

4.函数索引的使用原则

(1) 在使用函数索引(Function-based INDEX) 时，需要设置初始化参数

QUERY_REWRITE_ENABLED=TRUE ，创建该索引的用户需要有CREATE INDEX 和

QUERY REWRITE 权限。

(2) 对于经常进行运算比较的一些列，可以考虑建立函数索引，但是也可以通过在表中使用原来的列的函数形式来实现

(3) 在OLTP 系统中，一般情况下我们不建议使用函数索引。

5.B 树索引的使用原则

(1)当查询的行数占整个表总行数的比例。5%时，建立B树索引效果比较明显。

否则，就要慎重考虑是否需要建立B索引。

(2) 索引列包含的不同值很多时，应该建立B树索引。使用B树索引时候应该注意的是，它对AND/OR 等条件逻辑组合查询的效率很低。

6.位图索引的使用原则

(1) 索引列包含的不同值很少时，应该建立位图索引。位图索引对AND/OR 等条件逻辑组合查询的效率很高。

(2) 修改表的代价很大，适用于只读性，或更新很少的表。

5.4 文件设计

如果使用裸设备作为数据库设备，则在该目录下建立到相应的裸设备的

文件。如果使用文件作为数据库设备，则根据存储空间的需求，建立独立的文件系统，挂接到该目录下。

5.4.1 RAC 配置文件

Srvconfig-Size

Size 表示了文件/设备的大小，由数字部分和单位部分组成: XU，其中， X 是

一个正整数，取值围从1 --1023 ， U 是单位标识位，是1 位的字符，取值围为k、m、g、t ，分别表示了KByte、MByte、GByte、TByte ， Size 的值应该根据文件/设备的数据大小指定。

5.4.2 参数文件

对于共享磁盘的双机热备的系统，发生失效接管(failover) 时，应使用pfile

参数文件设置:在没有发生失效接管情况下，使用spfile 参数文件。

对于单机或RAC 方式的系统，可使用共享的spfile 参数文件设置。

5.4.2.1 参数文件命名规则

Oracle 数据库系统在启动时，先读取初始化参数文件，根据该文件的设置，

系统才能启动成功。 Oracle 系统使用spfile 文件和pfile参数文件。数据库系统启动时，首先查找$ORACLE_HOME/dbs/ 目录的spfile 文件，如果无此文件，系统在查找pfile 文件。spfile 文件是二进制文件，而pfile 文件是ASCII 文件。• pfile 初始化参数文件: 该文件是ASCII 码文件，可用文本编辑器编辑(注:在编辑前，一定要先备份)。

文件命名: init {SID}.ora

文件路径: / home/db/{OS_oracle_user} /admin/{DB_NAME}/pfile/以及$ORACLE_Home/dbs/

spfile 初始化参数文件: 该文件是二进制文件，不可以直接编辑。只能通过Oracle SQL 语句进行创建。方法如下(注: 在创建前，一定预先备份spfile及pfile):

spfile 的两种使用方式:

文件系统: spfile {DB_NAME}.ora

裸设备: rspfile {DB_ NAME}_size

保存路径: /home/db/oracl e/oradata/{DB_NAME} / ;

缺省路径: $ORACLE_HOME/dbs/

size 表示了文件/设备的大小，由数字部分和单位部分组成: XU ，其中， X 是

一个正整数，取值围从1-1023 ， U 是单位标识位，是1 位的字符，取值围为k、m、g、t ，分别表示了KByte、MByte、GByte、TByte ， Size 的值应该根据文件/设备的数据大小指定。

5.4.3 控制文件

每个数据库实例应至少有两个控制文件，且每个文件存储在独立的物理磁盘

上。如果有一个磁盘失效而导致控制文件不可用，与其相关的数据库实例必须关闭。一旦失效的磁盘得到修复，可以把保存在另一磁盘上的控制文件复制到该盘上。这样数据库实例可重新启动。并通过非介质恢复操作使数据库得到恢复。

因此，为了使整个系统的高可靠地运行，建议系统设置2-3 个控制文件。

5.4.3.1 控制文件命名规则

(1) 保存路径: /home/db/oracle/oradata/{DB_NAME}/

(2) 控制文件的使用方式:

• 裸设备:创建数据库前，在指定的目录下创建指向裸设备的连接文件。 rcontrol n size

其中: n 为从1 开始计数的整数，表示控制文件序号。如: 1, 2……

size 表示了文件/设备的大小，由数字部分和单位部分组成: XU ，其中， X 是一个正整数，取值围从1~1023 ， U 是单位标识位，是1 位的字符，取值围为k、m、g、t ，分别表示了KByte、MByte、GByte、TByte ，Size 的值应该根据文件/设备的数据大小指定。

•文件系统:

其中: nn 为从01 开始计数的两位整数，表示控制文件序号。如: 01,

(3) 控制文件数量:为2~3 个。如果控制文件所在存储己作镜像，建议2 个控制文件。如果没有做镜像，建议3 个控制文件。

(4) 控制文件大小

• 裸设备:一个物理分区大小，一般为256MB 。

• 文件系统:系统缺省大小。

5.4.4 重做日志文件

重做日志文件的尺寸会对数据库的性能产生重要影响，因为它的尺寸大小决定着数据库的写进程(DBWn) 和日志归档进程(ARCn) 。一般情况下，较大的日志文件提供较好的数据库性能，较小的重做日志文件会增加核查点(checkpo int)的活动，从而导致性能的降低。当然为了防止I/O 争用，还应把各个重做日志文件分布到不同的物理磁盘上。

不可能为重做日志文件提供特定大小的建议，重做日志文件在几百兆字节到几GB 字节都被认为是合理的。欲确定数据库重做日志文件的大小，应根据该系统产生重做日志的数量，并依据最多每二十分钟发生一次日志切换这个大致原则来决定。在系统运行后，我们从alert 文件获取日志的切换时间，并根据切换的问隔来调整重组日志的大小。初始大小建议不低于50M ,小于1G 。

5.4.4.1 日志文件命名规则

归档日志(archivelog )文件，建议放在独立物理磁盘上。 (1) 重做日志保存路径: / home/ db/ oracle/oradata/ {DB_NAME}/

(2) 归档日志保存路径: / home/ db/ oracle/orarch#

#表示实例号， 1, 2, 3, ……

通常要求归档日志备份文件系统大小可以保证容纳2天产生的归档日志。AIX 操作系统还要求该文件系统设置rbrw属性，以避免归档日志被放入操作系统存。

(3) 日志文件的使用方式:

• 裸设备

Rlog#_n_m_size(单机)

Rlog#_n_m_size（RAC)

创建数据库前，在指定的目录下创建指向裸设备的连接文件。

• 文件系统

redon_

#表示实例号， 1, 2, 3, ……

n 表示日志组的编号，取值围为01-06

m 表示日志组成员的编号，取值围为01-02

size 表示了文件/设备的大小，由数字部分和单位部分组成: XU ，其

中， X 是一个正整数，取值围从1--1023 ， U 是单位标识位，是1 位的字

符，取值围为k、m、g、t ，分别表示了KByte、MByte、GByte、TByte ，

Size 的值应该根据文件/设备的数据大小指定。

6 数据库应用

6.1 用户权限控制原则

在投入使用前应该检查用户是否符合如下规则：

1、每个业务用户不得授予DBA用户。

2、取消一些特权。

3、坚持最小化特权原则。 6.1.1 用户及其权限规

根据数据库管理、数据维护、开发、功能等方面分为以下类型用户:

：该类用户拥有DBA 角色，只有数据库管理员能够使用。其他用户不要授予该角色。

OWNER：该类用户拥有数据库业务schema 对象，特别是tables 及其他对象。不对末端用户开放。只有通过对象授权和系统授权， Transaction 类型用户才可防问DATA 0WNER 类型用户;表空间的使用，要通过空间授权阻额，才可访问; CREATE SESSION 特权使用时方可临时授权，使用完毕后，取消授权。

ction：该类型用户拥有数据库最小权限。只有通过明确的系统和对象授权才可访问DATA OWNER 中的对象(如CREATE SESSION, ALTER SESSION 等)。

一般用于末端用户的访问。

r：该类型用户一般用于监控数据库性能，或者是第一方工具使用。

5.其他：作为普通用户使用，使用权限严格限制，并服从DBA 管理。如执行一

般的查询sql 语句等。为非DBA用户使用。

6.1.1.1 用户命名规则

1、DBA 类型命名格式: DBA

注: XXX 为长度为3 个字符的项目英文简称

2、DATA OWNER类型的命名格式: DB

注: X 为长度为2-4 个字符的业务功能简称.

3、Transaction 类型命名格式: T

注: X 为长度为4-8 个字符的业务功能简称

4、Monitor 类型命名

注: 监控软件用户应按照第三方的供应商提供的方式命名。

5、其他类型命名格式: SQL

注: XXX 为长度3 个字符的功能英文简称。 6.1.1.2用户权限分配方式

对于一个数据库项目，在应用系统开发过程中，就开始对数据库用户权限进行严格的控制。即按照该系统未来生产时的方式进行分配，尽管此时数据库还处在开发服务器之中，尽管给开发项目的控制带来更多的工作，但数据库的安全性大大提高了。对数据库用户(user) 的授权，应通过数据库角色(role) 进行分配。而不要把对象特权和系统特权直接授权给数据库用户。

6.1.1.3 各用户类型的角色命名规

1、DATA OWNER 类型用户分配的角色命名规则: R__DB

注: X 为长度为2--4 个字符的业务功能简称。

2、Transaction 类型用户分配的角色命名规则: R__T

注: X 为长度为4-8 个字符的业务功能简称。

3、Moni tor 类型用户分配的角色命名规则:

注: 应按照第三方厂商提供的方式命名。

4、其他类型用户分配的角色命名规则: R__SQL 。

注: XXX 为长度为三个字符的业务功能简称。

6.1.2 数据库用户安全的实现

6.1.2.1 数据库特权

Oracle 数据库是通过"特权" (Privilege) 这个概念来实现数据安全的。所谓特权指用一种指定的方式访问xxx 数据库数据对象的一个许可，如查询一个数据表的许可等。这个特权能够被授予某个实体，因此这个授予实体特权(privilege)

的过程，称之为"授权" (Grant) 。

涉及Oracle 数据库系统安全的实体有两个，分别是系统特权(SystemPrivileges)

和对象特权(Object Privileges) 。

1、系统特权

系统特权是指登录到ORACLE 数据库系统的用户，执行数据库系统级别的某种操作或者是某一数据库对象的创建、修改、删除。在ORACLE 数据库系统中有一系列的系统置预定义特权，系统用这些特权去控制数据的安全。不得授予普通用户额外的全局权限，如select any/delete any/execute any 等，应用有特殊需求的除外。

2、对象特权

对象特权是指登录到ORACLE 数据库系统的用户，有权执行数据库对象级别的某种操作。例如表的INSERT ， DELETE, UPDATE 操作等。同样，在ORACLE数据库系统中有一系列的对象置预定义特权，系统用这些特权去控制数据的安全。

6.1.2.2 角色

由于ORACLE 数据库系统业务处理的复杂性，对ORACLE 数据库的系统特权和对象特权的分配也就变得十分复杂。因此，为了方便管理系统特权和对象特权，需要引入角色这个基本概念。

所谓角色是指系统特权和对象特权的集合。通过对角色的管理，使得ORACLE 数据库的系统特权和对象特权管理变得更加方便和容易。

基于角色的安全管理主要有以下几点优势:

l、减少授权工作量:可以通过授权给与一组用户相关联的角色，再由该角色授权给该用户组的成员用户。

2、动态特权管理:如果授权给某个xxx用户的特权需要改变，只须修改相关角色的授权，那么与这个角色相关的用户的特权会自动改变，不须修改授权给用户特权。

3、设置特权的可用性: 当某个被授予用户的角色，需要取消，只须对相应的角色设置禁用(DISABLED) 。因此，在任何特定的情况下，都可对用户的授权进行必要的控制。

4、应用程序级的设置可用性: 前台应用程序在试图以某个数据库用户的身份与后台数据库相连接时，可以对角色设置可用性。这种做法可以把非应用程序例如SQL*PLUS或第三方的数据库操作工具等，屏蔽在数据库系统之外，以保证数据库的安全。

角色可以根据业务的需求自由定义，系统特权和对象特权可以授权给角色，角色也可授权给另外的角色，角色也可授权给用户。基于上面描述的角色安全管理的优点和特点， ORACLE 数据库系统选择角色来实施数据库用户的授权管理，并根据ORACLE 的业务需求从不同的角度实现业务的权限分配。

根据需求，设置不同级别的角色，某一级别体现对某一项业务的特权。各角色级别之间或是子集关系，或是交集关系:同一级别的角色之间，或是交集，或是互为独立集合的关系。随着对业务需求的增加或变化，不断增加、完善访问控制的粒度，并坚持最小化特权原则。

1、通过存储过程管理特权(stored procedures)

使用存储过程(stored procedures) 来限制数据库的操作，客户端用户只需有权执行存储过程，并通过存储过程来实现对数据库表的访问。因而就屏蔽了用户直接对数据库表的操作。

2、通过视图(VIEWS) 管理特权

通过视图(VIEWS) 来控制ORACLE 数据库系统的安全。即只分配给用户查询视剧的特权，而对基表〈定义视图的相关的数据表〉则进行屏蔽，禁止对数据表的直接操作。

视图可以实现以下两种安全级别:

1、使用视图可以限制对数据表中的特定的列的访问。

2、使用视图可以限制对数据表中的特定的行的访问。

如: 对于某一基表，要求只显示部分行，则可通过创建实体的WHERE 子句来控

制行的显示。

6.1.2.3 授予权限和角色

6.1.2.3.1 授予系统权限和角色

可以用SQL 语句GRANT 来授予系统权限和角色给其它角色和用户。有GRANT ANY

ROLE 系统权限的任何用户可以授予数据库里的任何角色。

下面的语句授予系统权限CREATE SESSION 和角色ACCTS_PAY 给用户test :

GRANT CREATE SESSION, ACCTS_PAY TO test;

注意: 对象权限不能跟系统权限和角色在同一句GRANT 语句里授予。当一个用户创建一个角色，会把自动这个角色带关键字ADMIN OPTION 地授予

给它的创建者。一个带有关键字ADMIN OPTION 的被授予者有几项扩展性能:

1 被授予者可以对数据库的其它用户或角色进行授予或撤销系统权限或角色的操作。(用户不可以撤销它本身的角色)

2 被授予者可以进一步授予有关键字ADMIN OPTI ON 系统或角色。

3 拥有一个角色的被授予者可以改变或卸载这个角色。

在下面的语句中，安全管理员把NEW-DBA 角色授予给test :

GRANT NEW DBA TO TEST WITH ADMIN OPTION:

用户不但可以使用隐含在角色NEW-DBA 里的所有权限，当有需要时还可以授予，

撤销或卸载NEW-DBA 角色。

只有在对安全管理员进行相关权限和角色授予时，才允许带有关键字ADMIN

OPTION 。

6.1.2.3.2 授予对象权限和角色

同样可以使用GRANT 语句来授予对象权限给角色和用户。要授予对象权限，

必须要具备下面任意一个条件:

1 拥有被授予的对象

2 被授予过有关键字GRANT OPTION 的对象权限。

注意: 系统权限和角色不能和对象权限在同一句GRANT 语句中授予。

下面的语句授予了对应EMP 表所有列的SELECT ， INSERT 和DELETE 的对象权

限给用户Test1 和Test2:

GRANT SELECT, INSERT, DELETE ON EMP TO Test1, Test2;

要授予只对应EMP 表的JOB 列的INSERT 的对象权限给用户Test1 和Test2 ，声明下面的句子:

GRANT INSERT (JOB) ON EMP TO Test1, Test2 ;

要把对应于SALARY 视图的所有对象权限给用户JFEE ，要使用ALL 关键字，正

如下面的例子所示:

GRANT ALL ON SALARY TO JFEE ;

拥有对象的用户会自动授予所有相关的有关键字GRANT OPTION 的对象权限。这几个权限让被授予者有以下几个扩展权限:

1 被授予者可以授予有或没有关键字GRANT OPTION 的对象权限给数据库里的任何用户或者任何角色。

2 如果在带有关键字GRANT OPTION 情况下授予，被授予者得到一个表的对

象权限，并且被授予者有CREATE VIEW 或CREATE ANY VIEW 的系统权限，那么被授予者就可以在这个表上建视图和把这个视图相应的权限授予给数据库的任何用户或角色。

3 当把一个对象权限授予给一个角色时，关键字GRANT OPTION 是不起作用的。Oracle 防止通过角色来传播对象权限，因此有某角色的被授予者不能通过角色来传播拥有的对象权限。

6.1.2.3.3 授予列的权限

可以授予对应于表里单独一列的INSERT ， UPDATE 或REFERENCES 的权限。

警告:在授予对应列的INSERT 权限之前，观察这个表是否有许多定义了NOT

NULL 约束的列，如果是就终止授予。选择性的把插入特性授予给那些没有NOT

Nl几L特性的列，防止了用户插入任何列到表里。要避免这种情形，就要确定每一个NOT NULL 的列既可以插入又有非空的默认值。否则，被授予者插入记录就会不成功并出现错误。

6.1.2.4 数据库默认用户

除了sys、system、rman 用户，其他oracle 默认用户都应该置为expire 或

lock 状态，除非有特殊需求;

6.1.2.5 数据库用户密码

数据库所有活动状态用户的密码不得设置为己知的默认密码(如: sys 用户密码也不能设置为manager) ;

数据库用户的密码应该定期修改 6.2 数据库分区

6.2.1 数据库分区介绍

分区技术是为解决数据库中巨大的表或索引读写速度过慢而提出的解决方案。分区技术是利用物理上和逻堤上对数据进行分割来提高处理速度的。同时，合理的分区也提高了数据库数据的可管理性。

Partition 表和索引考虑使用分区的条件:

1、数据损坏的故障隔离

2、支持在线增加、删除

3、特定分区上的批处理

4、按分区备份

5、维护时可访问正常分区

6、恢复最关键的数据分区

6.2.2 逻辑分割

根据分区策略，一表的数据可以逻辑上分布于多个分区、子分区中，对数据的查询如果利用分区策略就可以缩小访问的围，在一定量级上提高查询速度。同样，对于索引分区也是一样的，从逻辑上分割表，缩小处理中的围，能够极提高Oracle 本身的处理速度。

6.2.3 物理分割

对于逻辑分割后的分区，可以通过策略分布到不同的表空间中，从而分布到不同的数据文件中，而数据文件又可以分配到不同的存储介质空间中，这样就可以充分利用操作系统的并行访问，同时也利用存储介质的并行访问，极同时提高写入和读取速度。

同样，对于索引分区也是一样的机制。 6.2.4 分区的好处

1、分区允许数据库管理员进行数据管理操作: 数据装载，索引的创建和重建，在分区级别的备份与恢复。因此可节省数据库管理员大量的操作时间。

2、分区可大幅度减少因维护引起的看机时间。分区的独立性使数据库管理员

对同一表或索引的各个分区进行并发的维护管理操作;也可对分区表并行的执

行SELECT 和DML 操作。

3、分区可增加数据库的可用性。减少维护窗口，恢复次数以及系统失效的影

响。

4、分区不要求修改任何应用程序。如数据库管理员可把非分区表转换为分区表，

而不必修改或重写SELECT 语句或DML 语句。同时也不必重写前端的应用程序代码。

6.2.5 分区的缺点

当然，任何事物都具两面性，分区带来了数据库创建方面的复杂度。即维护操作原来是面向一个表或索引对象，现在则要面向几十至上百个分区。但后台工作复杂度的加大换来了前台数据操作的效率提高，也是值得的。

6.2.6 Oracl e 分区技术

Oracle 提供以下五种分区技术:

1、围分区

围分区是对某个可度量的字段在可以预见的围进行划分的分区方式，例如: 日期字段。

2、枚举值分区

枚举值分区是对某个可列举确定值的字段按照不同值进行划分的分区方式，例如: 区县代码字段。

3、散列分区

散列分区是对某个离散性很大的字段按照根据散列算法计算出的散列值进行分区，例如:证件。 4、组合围-散列分区

组合围-枚举值分区是按照围做主分区，在主分区的基础上再次进行按照枚举值分区的组合分区。例如: 日期-区县。

5、组合枚举-散列分区

组合围-散列分区是按照围做主分区，在主分区的基础上再次进行按照散列分区的组合分区。例如: 日期-证件。

6.2.7 分区使用选择

如果数据按照某个(某些)值分区，那么range 分区就最合适，比如按照"年度"、"月份"等等，在这种情况下， range 分区可以利用分区消除，这包括应用中使用”=”、”>"、" < " 等作为条件。

如果不能找到其他合适的自然条件进行分区，那么HASH 分区就比较合适，这

是我们建议选择唯一列或者几乎唯一的列作为分区键值。这种情况下，分区数据是均匀的，使用分区键值”=” 或者in(valuel ， value2 …)时， hash 分区可以利用分区消除，但是使用其他条件时， hash 无法利用分区消除。

如果分区后，每个分区的数据量还是很大，建议使用组合分区，例如，首先按照自然条件做range 分区之后，对分区再进行分区。

6.2.8 分区索引

6.2.8.1 全局索引(GLOBAL index )

1、指向任何一个分区中的记录

2、索引可以被分区或不分区

3、表可以被分区或不分区

4、分区键值可以是有前缀后没有前缀

6.2.8.2 本地索引(LOCAL index)

1、每个本地索引分区只包含本分区的记录 2、二种类型的本地索引

前缀(prefixed ) : 唯一或非唯一列，可有效的使用分区消除，适于索引并行查询，适用于OLTP

非前缀(non-prefixed) : 适合于索引并行查询，可有效的使用分区消除，唯一索引受限，适用于DSS

3、分区键值可以与索引键值不同

1.本地分区索引: 每个表分区都有一个索引分区，而且只索引该表分区的数据。一个给定索引分区中的所有条目都指向一个表分区，表分区中的所有行都表示在一个索引分区中。

优点:容易维护;适合并行索引扫描

缺点:对少量记录查询相对效率不高

2.全局非分区索引:一个索引可以指向多个分区的数据

优点:对单个或少量记录的访问比较有效

缺点:管理维护上有额外成本

3.全局分区索引: 索引有独立的分区键值，每个索引分区可能指向多个不同的表分区数据

优点:可用性和管理性

缺点:对新数据的导入不会太有效

6.3 数据库实例配置

对于Oracle各个版本的参数优化，随版本的区别而有所不同。但万变不离其

宗，大部分的参数设置原理是相同的。

6.3.1 数据库字符集

数据库字符集的确定非常重要，如果选择不当，会给业务数据的保存带来麻烦。如在现实中，有的汉字保存到数据库时发生乱码，从而使客户的信息不能正常保存和显示。数据库字符集在系统设计开发阶段就应当确定。在数据库系统上线后，再更改数据库字符集，代价会非常大。因为不同的字符集设置之间，存在转换操作，如果不兼容，只能逐条转换。一般选择原则是要适中，满足当前和未来业务数据的保存。既不要选择太大，也不要过小。现有支持汉字的字符集包括:

ZHS16CGB231280 : 此字符集较小，不建议使用

ZHS16GBK: r 此字符包含了大部需要的汉字字符，由于目前已经有了新的国标GB18030-2005 ，而GB18030不是GBK的严格超集，部分字符编码有改动，如果要升级到GB18030只能是将库导出导入重建，因此不建议使用该字符集。ZHS32GB18030: 此字符集是最新国家标准字符集，包含字符较全，如果系统将来不会有其他国家字符被使用，可以使用此字符集。注意10g 的DBCA工具建库时，选不到该字符集，要使用该字符集只能手工建库。

AL32UTF8 : 此字符集是oracle推荐使用的字符集，对汉字支持也较好。如果系统可能会有其他国家字符录入，建议选用此字符集。

6.3.2 数据库版本和补丁集

开放平台管理部每季度会推出oracle 版本建议，包括使用的oracle 版本和补丁集建议，新上线系统安装时应该按最新的版本建议安装。

6.4 数据库参数设置

数据库参数的设置与业务应用密不可分。不同的业务类型，决定着关键参数的值，同时合理参数值也就决定着数据库系统的性能优劣。不仅如此，业务数据的需求也决定着数据库系统的设置。对于实例创建成功而不可更改的或者修改代价比较大的参数，必须慎重考虑，在充分调研各个方面的需求后，方可确定参数值，以满足业务的正常健康的运行。

6.4.1 必须修改的初始化参数

6.4.1.1 DB_CACHE_SIZE

数据库缓冲高速缓存用来存储最近使用的数据。处理查询时，服务器进程在数据库缓冲高速缓存中查找任何所需的块。如果未在数据库缓冲高速缓存中找到这个块，服务器进程就从数据文件读取这个块并且在数据库缓冲高速缓存中放置一个副本。由于对同一个块的后续请求可能在存中找到这个块，因此这些后续请求可以不需要再次进行物理读取。

Oracle 使用最近最少使用算法来释放近期未被访问的缓冲区，以便在缓冲高速缓存中为新块腾出空间。

衡量一个系统的的数据缓冲区设定效果的的一个重要指标是数据的缓存命中率。

对于OLAP 系统，由于大量的数据访问使用全表扫描的方式来运行，回答的是一些统计结果和"如果" " 那么" 之类的分析和预测，其数据缓存的利用率较低，

此时主要应该考虑的是规划系统的I/O分布以提高系统I/O效率，而不是提高系统缓存的命中率。

对于OLTP 系统，由于每次处理的数据量较小而且大量的数据是可以重复使用的，所以数据的共享对提高系统的效率非常重要。下面的说明是针对OLTP 应用系统的。

对于一个设计良好的应用系统，其数据库的缓存命中率应该在85% 以上。对于DB_CACHE_SIZE 的最终确定，需要依靠对实际系统的运行分析。

建议值: 该参数一般取物理存的30%-50%左右。

本系统：20G-32G

以后根据运行分析，再作调整。

6.4.1.2 SHARED_POOL_SIZE

共享池是用来存放可供全局共享的对象，比如可重用的SQL 语句执行计划，PL/SQL 包、存储过程、函数和游标等信息。

共享池的大小是由SHARED_POOL_SIZE 参数决定的，而且可以使用ALTER SYSTEM

SET 语句来动态改变，但总的SGA 区大小不能超过SGA_MAX_SIZE 。设置的一般性原则

一般情况下，共享池大小的设定与应用的类型和并发用户的数量有关系。其实际设定值与系统的可用存相关。

对于复杂的应用系统，指每个功能拥有较多的SQL 语句同时每个SQL 语旬的执行计划又比较复杂的情况下，可以适当的增加SHARED_POOL_SIZE的值，随着并发用户的增加应当适当的调整SHARED_POOL_SIZE 的值。对于较小的应用系统，共享池的大小和数据缓冲区的比例可以为1 : 2 ，随着存的增加，该比例可以进一步的减小，一般共享池不必超过6GB。对于一个正常的OLTP 系统SQL 语句的缓存命中率在95%就是一个比较好的系统了，对于OLAP 系统80%的缓存命中率也是可以接受的。

对于一个具有4GB 物理存300 个并发用户的应用体系的OLTP 应用系统可以设定SHARED_POOL_SIZE=800M，而对于一个具有8GB 物理存600个并发用户的C/S 应用体系的OLTP 应用系统则可以设定

SHARED_POOL_ SIZE= 1200M 。

建议值: 建议此参数设置为512M，至少在200M-4G 之间。

本系统：5G-8G

对于SHARED_POOL_SIZE 的最终确定，需要依靠对实际系统的运行分析。

6.4.1.3 LARGE_POOL_SIZE

大池用来存储和SQL 语句处理无直接关系的大存结构。如在备份和恢复过程中复制的数据块。大池是SGA 区的可选选项，目的为了减轻共享池的压力。大池不使用最近最少使用( LRU) 算法来进行管理。

大池的大小由参数文件中的LARGE_POOL_SIZE 设置。能被ALTER SYSTEM 语句动态改变。

设置的一般性原则

大池一般用来存放并行查询的相关信息和RMAN 的磁盘I/O缓冲区。对于为RMAN

所分配的大池，其设定与RMAN 分配的通道数有关:

公式为:通道数* (16 MB + ( 4 * size_of_tape_buffer))

硬盘备份时， size_of_tape_buffer 为0

磁带备份时，该值默认为256k

建议值: OLTP:100M OLAP: 256M

本系统：100M 6.4.1.4 DB_BLOCK_SIZE

DB_BLOCK_SIZE 参数决定数据库系统的性能和使用。

数据库参数DB_BLOCK_SIZE 的设置与原则:

1、OLTP 类型的业务应用数据库系统，则DB_BLOCK_SIZE=4k或者8k ;

2、DSS 类型的业务应用数据库系统，则DB_BLOCK_SIZE=16k或者32k ;

可以建立不同block size 的表空间，根据不同的业务特性将不同的表放置于不同block size 的表空间中，这个特性对于系统会有性能的提升。针对不同业务类型的数据库系统，以上设置方式，不是绝对的，要取决于业务具体情况。

6.4.1.5 SP_FILE

参数设置文件的绝对路径。

默认值: ORACLE_HOME/dbs/

建议值:根据命名规命名，文件文件应该放入存储，特别是在HA 环境中。

6.4.1.6 PGA_AGGREGATE_TARGET

使用该参数的前提是，必须WORKAREA_SIZE_POLICY=AUTO ，并且数据库运行方式是Dedicate sever 和连接时Dedicate 方式时，这个参数才可生效。此时参数SORT_AREA_SIZE， HASH_AREA_SIZE， BITMAP_AREA_SIZE 会被忽略失效。但如果使用MTS 和SHARE SERVER 连接方式时，则PGA_AGGREGATE_TARGET会被忽略失效，此时*_AREA_SIZE 就会生效。PGA-AGGREGATE-TARGET 是系统自动管理*_AREA_SIZE 的大小，因此推荐使用这个参数。其设置原则为:

1、OLTP: PGA_AGGREGATE_TARGET = (total_mem * 80%) * 20%

2、DSS: PGA_AGGREGATE_TARGET = (total_mem * 80%) * 50%

其中: total_mem 为系统的物理存。该原则是经验值，对于实际运行系统可视情况适当浮动调整。

本系统：1G 6.4.1.7 PROCESSES

根据实际连接数据库的连接数的1.2- 1.4 倍进行设置，不得低于500 。

6.4.1.8 OPEN_CURSORS

该参数设定了一个会话一次可以打开的游标的最大数量，并且限制使用的PLlSQL 游标高速缓存的大小，以避免用户再次执行语句时重新进行语法分析。如果初始化参数CURSOR_SPACE_ FOR_ TIME 设为TRUE，则OPEN_ CURSORS 也需要相应的增大。

1) 值围: 1 - 4GB

2) 默认值: 50

3) 推荐值:该值与应用类型相关，设置值不得低于200

6.4.1.9 MAX_DUMP_FILE_SIZE

建议不要使用默认值(UNLIMITED ) ，最大设置100M。以避免数据库多次dump 出trc 文件时迅速撑满整个文件系统。

6.4.1.10 RECOVERY_PARALLELISM

参与实例恢复( RECOVERY) 的进程数量， 0 或1 意味着串行。

默认值:操作系统相关，通常为0

取值围:操作系统相关，不超过PMALLEL_MAX_SERVER 设置值

推荐值: 物理CPU个数-1

6.4.1.11 PARALLEL_EXECUTION_MESSAGE_SIZE

并行操作(并行查询，并行DML ，并行恢复、复制)时消息的大小，设置较大值对并行查询时有并行进程间大量数据传输时比较有利。

默认值: 2148

取值围: 2148 - 65535 推荐值: 8192或者更大

6.4.1.12 INSTANCE_GROUPS (RAC)

描述当前实例所属的资源组， RAC 中并行操作模式时用到，和下面的PARALLEL_INSTANCE_GROUPS 共同使用，可以限制并行操作使用的实例资源。

默认值: 无

取值围:无

推荐值: 数据中心通常只使用两节点的RAC ，因此只有两个设置值， RAC两个节点各使用一个(和两个实例的instance-name 中的顺序保持一致) :

node_0l, node_both

node_02, node_both

6.4.1.13 PARALLEL_INSTANCE_GROUP (RAC)

描述当前实例并行操作时可使用的资源组， RAC 中并行操作模式时用到，和上面的INSTANCE_GROUPS 共同使用，可以限制并行操作使用的实例资源。

默认值:无

取值围:其设置名称必须在RAC 节点的INSTANCE_GROUPS 中曾出现。

推荐值:数据中心通常只使用两节点的RAC ，需要保证日常并行仅在本节点进行，避免同时耗尽两台实例的所有资源。设置时应根据INSTANCE_GROUPS 来设置:

INSTANCE_GROUPS 设置为node_Ol， node_both 则PARALLEL INSTANCE_GROUPS设置为node_Ol

INST州CE-GROUPS 设置为node_02， node_both 则PARALLEL INSTANCE_GROUPS设置为node_02 。

node-both 在通常情况下不会被使用，除非应用有非常大的并行操作需要

同时使用两个节点上的资源，

此时需要在应用中显式调用

alter session set PARALLEL INSTANCE_GROUPS== 'node both' 6.4.1.14 与DRM 有关的隐藏参数( RAC )

10g 的RAC 中引入的DRM (Dynamic Resource Mastering) 的概念，在RAC的不同节点间根据资源使用情况决定master 节点。由于该功能并不十分完善，常常造成节点问master 节点不断转换，触发bug ，而且数据中心中所有的RAC 都是两.点的，使用该功能意义不大，因此可以屏蔽该功能。

屏蔽时需要配置如下两个默认参数:

_gc_undo_affinity=FALSE

_gc_affinity_time=0

6.4.2 建议修改的初始化参数

6.4.2.1 SESSION_CACHED_CURSORS

设置该参数有助于减少系统parse SQL 的时间，提高系统效率。10g 中该参数的默认值为20 。

建议设置session_cached_cursors==50 ，对于实际运行系统可视情况适当浮动调整。

6.4.2.2 BACKUP_TAPE_IO_SLAVES

该参数指定了'恢复管理器(Recovery Manager) 所使用的从属进程的数目，这些从属进程被用来备份，拷贝或恢复数据到磁带上。当此参数为TRUE时，一个I/O

从属进程被用来从磁带设备读取或写入数据。如果此参数为FALSE (默认情况下) ，在备份中不会使用I/O从属进程，而是由备份的阴影进程(shadow

process) 来存取磁带设备。该参数设置为true 后，通过模拟IO 的行为，主进程可以不必等待磁带写完成后就能继续处理其他数据块，会启动子进程来等待，从而加快了备份速度。

建议值: 备份到磁带上的系统，设置该参数为true 以加快速度。 6.4.2.3 JAVA_POOL_SIZE

参数JAVA_POOL 设定了数据库用来存放JAVA 代码的缓冲池的大小。

建议:

对于没有使用数据库中的]AVA 的应用，不设置，使用系统默认值。

对于使用了数据库中的JAVA 的应用， JAVA_POOL_SIZE 的大小由应用的类型和数量确定。

6.4.2.4 OPTIMIZER_INDEX_COST_ADJ

控制优化器是否会更倾向于使用索引。

默认值: 100,

推荐值: OLTP: 50，即优化器评估时将走索引的代价评估为标准状况下

(默认值100 时)走索引代价的50% 。

OLAP: 不设置，使用默认值

6.4.3 不修改的初始化参数

6.4.3.1 SGA_TARGET

该参数的作用是通过设置一个总值，让数据库根据实际需要，动态调整各块缓存区的大小，且每块缓存区的大小不会小于手动设置的参数值。但在实际使用过程中，如果只是设置SGA TARGET，而不手动设置各种缓存区的参数值，在系统繁忙时由于动态调整不同区域存占用将将有可能会引发Oracle 部的一些bug。因此，建议SGA 区存管理通过手工设置，不设置该参数，维持默认值0 。

6.4.3.4 SGA_MAX_ SIZE

SGA MAX SIZE 为SGA 的最大允许设置值，系统会动态修改以上参数设置值时，以上参数设置值的总和不得超过本参数指定值。

设置该值大于以上pool 的总和或SGA TARGET 的设置值，会造成多余值无法被自动利用而造成浪费。应该尽量通过测试确实合适的pool 设置值，避免系统自动扩展或临时扩展。

6.4.4 建议不修改的初始化参数

6.4.4.1 UNDO_RETENTION

以秒为单位设置UNDO 争用值的下限。对自动扩展的UNDO 表空间有价值，对固定大小的UNDO 表空间(数据中心推荐做法) ，系统根据UNDO 使用情况、UNDO

表空间大小自动确定该值，除非启用了retention guarantee 。

默认值: 900,

6.4.4.2 SESSIONS

指定用户会话和系统会话的总量。默认数量大于PROCESSES ，以允许递归会话。

1) 值围: 任何整数值。

2) 默认值: 派生(1.1* ROCESSES + 5)

3) 建议值:该值无需特意指定，建议在指定PROCESS 后使用系统计算值。

6.4.4.3 TRANSACTIONS

指定并行事务处理的最大数量。如果将该值设置得较大，将增加SGA 区的大小，

并可增加实例启动过程中分配的凹滚段的数量。默认值大于SESSIONS, 以实现递归事务处理。

对于连接到Oracle 数据库的应用，根据其连接方式可以分为:

1.直接连接到数据库应用。如:客户前台直接通过SQL*NET ,JDBC 连接到数据库应用，这类应用中由于用户的操作关系，一般的并发事务数较小，远远的小于连接到数据库的会话数:

2.用户前台并不直接与数据库相连而是通过中间件与数据库相连，这类应用中连接到数据库的会话数等于中间件的服务器的数量。由于应用服务器的集中作用，

这时每个连接到数据库的会话为多个最终客户服务，会话的负荷较重，事务较多，极限情况下每个会话都可能出现由活动事务的情况，考虑到系统的递规调用的情况，最大值可能为1.1倍的会话数。

1) 值围: 4 到4G

2) 默认值:派生(1.1 * SESSIONS)

第一类应用， TRANSACTIONS 最好为1 /10 到1 /5 的PROCES S 的值;

第二类应用， TRANSACTIONS 最好为1.1 倍的PROCESS 的值

不建议修改默认值，由ORACLE 根据SESSION/PROCESS 的设的设置自动计算。

6.4.4.4 DB_KEEP_CACHE_SIZE

建议对频繁使用的较小的字典表将其放入到KEEP池中。通常情况下，系统新上线时如果开发部门没有明确要求，不进行设置。运维过程中觉得有必要设置时，

可以进行修改。

6.4.4.5 LOCK_SGA

决定设置数据库参数lock_sga 将目前数据库SGA 索住在物理存中。同时，对于AIX ，上述从操作还需要修改操作系统参数v_pinshm 从缺省的0 设置为1 ;平时不会被交换至硬盘，可以不设置。

6.4.4.6 DB_FILES

该参数定义了数据库可以打开的数据文件的数目，此参数默认值为200 ，在创建实例的时指定，在RAC、DATAGURD 等环境要求各实例保持一致，修改时要求重启实例。

从实践来看，通常数据文件都不会超过150 个，设置过大的值会浪费一定存，因此不必过早设置过大数值。

6.4.4.7 DB_FILE_MULTIBLOCK_ READ_COUNT

该参数指定了在涉及一个全表连续扫描的一次I/O 操作过程中读取的数据块(其大小由数据库初始化参数DB-BLOCK-SIE 决定)的最大数量。只有在系统对数据库的一个表进行全表扫描时( db file scattered read) 该参数才起作用。

一般的情况下，该参数的设定与系统的应用类型相关，对于做大量数据查询的OLAP 系统可以设定较大的值，如32 ，对于一般的OLTP 系统设定为8 或16 是一个较好的选择。

默认值: 对OLAP 系统推荐使用32 ，对OLTP 系统推荐使用16

6.4.4.8 LOG_BUFFER

重做日志文件跟踪服务器进程和后台进程对数据库进行的更改。该缓冲区是循环使用的，包含对数据文件所做的各种修改动作的信息，例如: INSERT ,UPDATE,

DELETE, CREATE, ALTER 和DROP 等操作。重做日志缓冲区大小由参数文件中的LOG_BUFFER 设置。较大的日志缓冲区有助于降低日志文件的读写频率，提高系统的效率。

设置的一般性原则

由于系统的写日志进程(LGWR) 在日志缓冲区中的重做条目(redo entry) 达到1岖的时候，会把日志缓冲区的数据写入日志文件，同时当日志缓冲区1/3 满的时候也会写日志文件，所以过大的日志缓冲区是没有意义的。

该参数的值一般接近SGA 设置值决定的粒度值(通常为16M) ，不必专门设置增大。

6.5 数据库连接服务

6.5.1 专用服务器连接

在专用服务器模式下，客户连接和服务器进程(或者有可能是线程)之间会有一个一对一的映射。如果一台UNIX 主机上有100 条专用服务器连接，就会有相应的100 个进程在执行。

6.5.2 共享服务器连接

共享服务器连接强制要求必须使用Oracle Net ，即使客户和服务器都在同一台

机器上也不例外。如果不使用Oracle TNS 监听器，就无法使用共享服务器。如前所述，客户应用会连接到Oracle TNS 监昕器，并重定向或转交给一个调度器。调度器充当客户应用和共享服务器进程之间的" 导管"。

6.5.3 连接服务建议

6.3.1 专用服务器连接

服务器只要有足够的资源(CPU 和RAM) 就使用专用服务器连接

6.5.3.2 共享服务器连接

共享服务器只适用于OLTP 系统,只在资源(CPU 和RAM) 不足的情况下使用

其他高级连接特性需要使用共享服务器连接

6.6 数据库安全建议

6.6.1最小安装

随着Oracle 数据库版本的不断升级， Oracle 的功能也越来越多，因此安全检查点也越来越多。因此最好根据需求只安装所需容。如: 不需要web 功能，就不要安装相应组件。

6.6.2 安装时的安全

Oracle 软件的安装目录要和系统盘分开。在Unix 下， Oracle 数据库系统的和组的权限也要作相应设置。创建数据库管理员组(DBA) 并分配root 和Oracle 软件拥有者的用户ID 给这个组。DBA 能执行的程序只有"7 1 0" 权限。在安装过程中SQL*DBA 系统权限命令被自动分配给DBA组。

6.6.2.1 删除或修改默认的用户名和密码

Oracle 的默认安装会建立很多缺省的用户名和密码，而大部分的数据库管理员都不清楚到底有多少数据库用户，从而留下了很大的安全隐患。因此数据库软件应以定制方式安装。

6.6.2.2 安装最新的安全补丁

保证ORACLE 数据库安全性的一个比较好的办法是及时安装安全补丁。

6.7 数据库备份和恢复

6.7.1 RMAN 备份

该类备份是最为完善的备份恢复解决方案。对于从几百M至TB级的数据库，都可选择其作为备份方案。正因其完善，相关的备份架构相对复杂，维护操作也复杂。对于小型数据库(如几十M) 来说，硬件和软件成本以及维护代价过高。

6.7.2 Export/import 备份

该类备份是用于小型数据库备份作为合适。硬件和软件成本以及维护代价比较低。因其备份方式灵活，可以进行表级、模式级备份，常作为rman备份方案的补充。另外，对于跨操作系统平台迁移数据库，也经常使用其作为首选方案。

6.7.3 存储级备份一虚拟带库

虚拟磁带库相对其它备份设备具备了显著优势:

1 性能大幅提高----可支持接近磁盘阵列极限的备份/恢复速度。

2 免疫病毒----应用安全性等同物理磁带库。

3 去除磁盘碎片----保障性能持续性及磁盘效率。

4 无转译数据传输----良好的对数据结构损坏的承受力。

通用于主机软硬件环境----免除适配、维护和管理风险。 6.7.4 数据库恢复

6.7.4.1 实例故障的一致性恢复

当实例意外地(如掉电、后台进程故障等)或预料地(发出SHUTDOUM ABORT语句)中止时出现实例故障，此时需要实例恢复。实例恢复将数据库恢复到故障之前的事务一致状态。如果在在线后备发现实例故障，则需介质恢复。在其它情况Oracle 在下次数据库起动时(对新实例装配和打开) ，自动地执行实例恢复。如果需要，从装配状态变为打开状态，自动地激发实例恢复，由下列处理:

1、为了解恢复数据文件中没有记录的数据，进行向前滚。该数据记录在在线日志，包括对回滚段的容恢复。

2、回滚未提交的事务，按步1重新生成回滚段所指定的操作。

3、释放在故障时正在处理事务所持有的资源。

4、解决在故障时正经历一阶段提交的任何悬而未决的分布事务。

6.7.4.2 介质故障或文件错误的不一致恢复

介质故障是当一个文件、一个文件的部分或磁盘不能读或不能写时出现的故障。文件错误一般指意外的错误导致文件被删除或意外事故导致文件的不一致。这种状态下的数据库都是不一致的，需要DBA 手工来进行数据库的恢复，这种恢复有两种形式，决定于数据库运行的归档方式和备份方式。

1、完全介质恢复可恢复全部丢失的修改。一般情况下需要有数据库的备份且数据库运行在归档状态下并且有可用归档日志时才可能。对于不同类型的错误，有不同类型的完全恢复可使用，其决定于毁坏文件和数据库的可用性。

2、不完全介质恢复是在完全介质恢复不可能或不要求时进行的介质恢复。重构受损的数据库，使其恢复介质故障前或用户出错之前的一个事务一致性状态。不完全介质恢复有不同类型的使用，决定于需要不完全介质恢复的情况，有下列类型: 基于撤消、基于时间和基于修改的不完全恢复。

1 基于撤消(CANCEL)恢复:在某种情况，不完全介质恢复必须被控制，可撤消在指定点的操作。基于撤消的恢复地在一个或多个日志组(在线的或归档的〉己被介质故障所破坏，不能用于恢复过程时使用，所以介质恢复必须控制，以致在使用最近的、未损的日志组于数据文件后中止恢复操作。

2 基于时间(TIME)和基于修改(SCN) 的恢复:如果希望恢复到过去的某个指定点，是一种理想的不完全介质恢复，一般发生在恢复到某个特定操作之前，恢复到如意外删除某个数据表之前。

6.8 ORACLE NETWORK 配置

6.8.1 监昕器的使用配置原则