oracle大数据库安装及配置要求规范v10.docx
《oracle大数据库安装及配置要求规范v10.docx》由会员分享，可在线阅读，更多相关《oracle大数据库安装及配置要求规范v10.docx（28页珍藏版）》请在冰豆网上搜索。
oracle大数据库安装及配置要求规范v10
Oracle数据库系统安装
及配置规范
2015-10
1.数据库物理设计原则
1.1.数据库环境配置原则
1.1.1.操作系统环境
对于中小型数据库系统，采用linux操作系统比较合适，对于数据库冗余要求负载均衡能力要求较高的系统，可以采用Oracle10gRAC的集群数据库的方法，集群节点数范围在2—64个。
对于大型数据库系统，可以采用SunSolarisSPARC64位小型机系统或HP9000系列小型机系统。
RAD5适合只读操作的数据库，RAD1适合OLTP数据库。
1.1.2.内存要求
对于linux操作系统下的数据库,由于在正常情况下Oracle对SGA的管理能力不超过1.7G。
所以总的物理内存在4G以下。
SGA的大小为物理内存的50%—75%。
对于64位的小型系统，Oracle数据库对SGA的管理超过2G的限制，SGA设计在一个合适的范围内：
物理内存的50%—70%，当SGA过大的时候会导致内存分页，影响系统性能。
1.1.3.交换区设计
当物理内存在2G以下的情况下，交换分区swap为物理内存的3倍，当物理内存>2G的情况下，swap大小为物理内存的1—2倍。
1.1.4.其他
其他环境变量参考Oracle相关的安装文档和随机文档。
1.2.数据库设计原则
1.2.1.数据库SID
数据库SID是唯一标志数据库的符号，命名长度不能超过5个字符。
对于单节点数据库，以字符开头的5个长度以内字串作为SID的命名。
对于集群数据库，当命名SID后，各节点SID自动命名为SIDnn，其中nn为节点号：
1，2，…,64。
例如rac1、rac2、rac24。
1.2.2.数据库全局名
数据库全局名称：
.domain
1.2.3.数据库类型选择
对于海量数据库系统，采用datawarehouse的类型。
对于小型数据库或OLTP类型的数据库，采用TransactionProcessing类型。
1.2.4.数据库连接类型选择
Oracle数据库有专用服务器连接类型和多线程服务器MTS连接类型。
对于批处理服务，需要专用服务器连接方式，而对于OLTP服务则MTS的连接方式比较合适。
由于采用MTS后，可以通过配置网络服务实现某些特定批处理服务采用专用服务器连接方式，所以数据库设计时一般采用MTS类型。
1.2.5.数据库SGA配置
数据库SGA可以采用手工配置或按物理内存比例配置，在数据库初始设计阶段采用按比例配置方式，在实际应用中按系统调优方式修改SGA。
1.2.6.数据库字符集选择
为了使数据库能够正确支持多国语言，必须配置合适的数据库字符集，采用UTF8字符集。
注意：
如果没有大对象，在使用过程中进行语言转换没有什么影响，具体过程如下（切记设定的字符集必须是ORACLE支持，不然不能start）
SQL>shutdownimmediate;
SQL>startupmount;
SQL>altersystemenablerestrictedsession;
SQL>altersystemsetjob_queue_processes=0;
SQL>alterdatabaseopen;
SQL>alterdatabasecharactersetinternal_usewe8iso8859p1;
SQL>shutdownimmediate;
SQL>startup
1.2.7.数据库其他参数配置
1.2.7.1.DB_FILES
Db_files是数据库能够同时打开的文件数量，默认值是200个。
当数据库规划时文件数量FILES接近或超过200个时候，按以下估计值配置：
DB_FILES=FILES*1.5
1.2.7.2.Db_block_size
一个extent要是5个blocks的倍数为好，如：
一个blocks是4096字节，那一个extent就是2M、4M或8M为好。
Db_block_size是数据库最小物理单元，一旦数据库创建完成，该参数无法修改，db_block_size按以下规则调整：
数据仓库类型：
db_block_size尽可能大，采用8192或16384
OLTP类型：
db_block_size用比较小的取值范围：
2048或4096
Blocks推荐是系统操作的块倍数（裸设备块大小是512字节，NTFS是4K，使用8K的方式在大部分系统上通用）。
1.2.8.数据库控制文件配置
1.2.8.1.控制文件镜象
多个控制文件存放在不同的物理位置。
1.2.8.2.控制文件配置
控制文件中参数设置，最大的数据文件数量不能小于数据库参数db_files。
1.2.9.数据库日志文件配置
1.2.9.1.日志文件大小
日志文件的大小由数据库事务处理量决定，在设计过程中，确保每20分钟切换一个日志文件。
所以对于批处理系统，日志文件大小为几百M到几G的大小。
对于OLTP系统，日志文件大小为几百M以内。
1.2.9.2.日志文件组数量
对于批处理系统，日志文件组为5—10组；对于OLTP系统，日志文件组为3—5组，每组日志大小保持一致；对于集群数据库系统，每节点有各自独立的日志组。
1.2.9.3.日志成员数量
为了确保日志能够镜象作用，每日志组的成员为2个。
1.2.10.数据库回滚段配置
在Oracle9i数据库中，设计Undo表空间取代以前版本的回滚段表空间。
Undo表空间大小的设计规范由以下公式计算：
Undospace=UR*UPS*db_block_size+冗余量
UR：
表示在undo中保持的最长时间数（秒），由数据库参数UNDO_RETENTION值决定。
UPS：
表示在undo中，每秒产生的数据库块数量。
例如：
在数据库中保留2小时的回退数据，假定每小时产生200个数据库块。
则Undospace=2*3600*200*4K=5.8G。
1.2.11.数据库临时段表空间配置
数据库临时段表空间根据实际生产环境情况调整其大小，表空间属性为自动扩展。
1.2.12.数据库系统表空间配置
系统表空间大小1G左右，除了存放数据库数据字典的数据外，其他数据不得存储在系统表空间。
1.3.数据库表空间设计原则
1.3.1.表空间大小定义原则
当表空间大小小于操作系统对最大文件限制时，表空间由一个文件组成。
如果表空间大小大于操作系统对最大文件限制时，该表空间由多个数据文件组成，表空间的总大小为估算为：
Tablespace+sum（数据段+索引段）*150%。
1.3.2.表空间扩展性设计原则
表空间数据文件采用自动扩展的方式，扩展容量快大小按2的整数倍（1M、2M、4M、8M、16M、32M、64M）进行扩展，创建表空间时尽量采用nologing选项。
表空间的最大限制一般采用unlimited，除非确切知道表空间数据文件的最大使用范围。
（一般windows３２位系统的文件最大２Ｇ，６４位的unix系统系统文件最大１２８G,但也要注意文件格式设定的文件大小）,建议最大为2G。
表空间采用local管理方式，例如：
CREATETABLESPACETBS_USERINFO
DATAFILE
‘/oradata/tbs_userinfo.dbf’
SIZE8M
REUSE
AUTOEXTENDON
NEXT2M
MAXSIZEUNLIMITED
NOLOGGING
EXTENTMANAGEMENT
LOCAL
AUTOALLOCATE
SEGMENTSPACEMANAGEMENTAUTO;
CNOUG博客首页cl5|
N%H$uJ@
1.4.裸设备的使用
一个scsi设备可以14个分区，unix操作系统256个分区,性能比文件系统方式高15％左右，空间大于要小于（实际分区大小减两个ORACLE的数据块），比如100M，大于为100000K，推荐在unix使用软连接（ln）方式把裸设备形成文件，用加入表空间时加resue选项，当然也可只接把设备加入表空间，移动裸设备使用dd命令。
对于windows平台，oracle提供软连接工具，实现裸设备的使用，计算一条记录的长度。
2.数据库逻辑设计原则
2.1.命名规范
2.1.1.表属性规范
2.1.1.1.表名
前缀为Tbl_。
数据表名称必须以有特征含义的单词或缩写组成，中间可以用“_”分割，例如：
tbl_pstn_detail。
表名称不能用双引号包含。
2.1.1.2.表分区名
前缀为p。
分区名必须有特定含义的单词或字串。
例如：
tbl_pstn_detail的分区p2*******01表示该分区存储2004100101时段的数据。
2.1.1.3.字段名
字段名称必须用字母开头，采用有特征含义的单词或缩写，不能用双引号包含。
2.1.1.4.主键名
前缀为PK_。
主键名称应是前缀+表名+构成的字段名。
如果复合主键的构成字段较多，则只包含第一个字段。
表名可以去掉前缀。
2.1.1.5.外键名
前缀为FK_。
外键名称应是前缀+外键表名+主键表名+外键表构成的字段名。
表名可以去掉前缀。
2.1.2.索引
2.1.2.1.普通索引
前缀为IDX_。
索引名称应是前缀+表名+构成的字段名。
如果复合索引的构成字段较多，则只包含第一个字段，并添加序号。
表名可以去掉前缀。
2.1.2.2.主键索引
前缀为IDX_PK_。
索引名称应是前缀+表名+构成的主键字段名，在创建表时候用usingindex指定主键索引属性。
2.1.2.3.唯一索引
前缀为IDX_UK_。
索引名称应是前缀+表名+构成的字段名。
2.1.2.4.外键索引
前缀为IDX_FK_。
索引名称应是前缀+表名+构成的外键字段名。
2.1.2.5.函数索引
前缀为IDX_func_。
索引名称应是前缀+表名+构成的特征表达字符。
2.1.2.6.蔟索引
前缀为IDX_clu_。
索引名称应是前缀+表名+构成的簇字段。
2.1.3.视图
前缀为V_。
按业务操作命名视图。
2.1.4.实体化视图
前缀为MV_。
按业务操作命名实体化视图。
2.1.5.存储过程
前缀为Proc_。
按业务操作命名存储过程。
2.1.6.触发器
前缀为Trig_。
触发器名应是前缀+表名+触发器名。
2.1.7.函数
前缀为Func_。
按业务操作命名函数。
2.1.8.数据包
前缀为Pkg_。
按业务操作集合命名数据包。
2.1.9.序列
前缀为Seq_。
按业务属性命名。
2.1.10.表空间
2.1.10.1.公用表空间
前缀为Tbs_。
根据存储的特性命名，例如：
tbs_parameter。
2.1.10.2.专用表空间
Tbs_<表名称>_nn。
该表空间专门存储指定的某一个表，或某一表的若干个分区的数据。
2.1.11.数据文件
<表空间名>nn.dbf。
nn=1，2，3，4，…等。
2.1.12.普通变量
前缀为Var_。
存放字符、数字、日期型变量。
2.1.13.游标变量
前缀为Cur_。
存放游标记录集。
2.1.14.记录型变量
前缀为Rec_。
存放记录型数据。
2.1.15.表类型变量
前缀为Tab_。
存放表类型数据。
2.1.16.数据库链
前缀为dbl_。
表示分布式数据库外部链接关系。
2.2.命名
2.2.1.语言
命名应该使用英文单词，避免使用拼音，特别不应该使用拼音简写。
命名不允许使用中文或者特殊字符。
英文单词使用用对象本身意义相对或相近的单词。
选择最简单或最通用的单词。
不能使用毫不相干的单词来命名。
当一个单词不能表达对象含义时，用词组组合，如果组合太长时，采用用简或缩写，缩写要基本能表达原单词的意义。
当出现对象名重名时，是不同类型对象时，加类型前缀或后缀以示区别。
2.2.2.大小写
名称一律大写，以方便不同数据库移植，以及避免程序调用问题。
2.2.3.单词分隔
命名的各单词之间可以使用下划线进行分隔。
2.2.4.保留字
命名不允许使用SQL保留字。
2.2.5.命名长度
表名、字段名、视图名长度应限制在20个字符内（含前缀）。
2.2.6.字段名称
同一个字段名在一个数据库中只能代表一个意思。
比如telephone在一个表中代表“电话号码”的意思，在另外一个表中就不能代表“手机号码”的意思。
不同的表用于相同内容的字段应该采用同样的名称，字段类型定义。
2.3.数据类型
2.3.1.字符型
固定长度的字串类型采用char，长度不固定的字串类型采用varchar。
避免在长度不固定的情况下采用char类型。
如果在数据迁移等出现以上情况，则必须使用trim（）函数截去字串后的空格。
2.3.2.数字型
数字型字段尽量采用number类型，要注意精度。
2.3.3.日期和时间
2.3.3.1.系统时间
由数据库产生的系统时间首选数据库的日期型，如DATE类型。
2.3.3.2.外部时间
由数据导入或外部应用程序产生的日期时间类型采用varchar类型，数据格式采用：
YYYYMMDDHH24MISS。
2.3.4.大字段
如无特别需要，避免使用大字段（blob，clob，long，text，image等）。
2.3.5.唯一键
对于数字型唯一键值，尽可能用系列sequence产生。
2.4.设计
2.4.1.范式
如无性能上的必须原因，应该使用关系数据库理论，达到较高的范式，避免数据冗余,但是如果在数据量上与性能上无特别要求，考虑到实现的方便性可以有适当的数据冗余，但基本上要达到3NF.如非确实必要，避免一个字段中存储多个标志的做法。
如11101表示5个标志的一种取值。
这往往是增加复杂度，降低性能的地方。
2.4.2.表设计
2.4.2.1.逻辑段设计原则
2.4.2.1.1.Tablespace
每个表在创建时候，必须指定所在的表空间，不要采用默认表空间以防止表建立在系统表空间上导致性能问题。
对于事务比较繁忙的数据表，必须存放在该表的专用表空间中。
2.4.2.1.2.Pctused
默认pctused导致数据库物理空间利用率非常低40%左右；对于update比较少或update不导致行增大的表，pctused可设置在60—85之间；对于update能够导致行增大的表，update设置在40—70之间。
2.4.2.1.3.Initrans
对于需要并行查询或者在RAC数据库中需要并行处理的表，initrans设置为2的倍数，否则，不设该值。
2.4.2.1.4.Storage
1）Initial
尽量减少表数据段的extents数量，initial的大小尽量接近数据段的大小64K，128K，…，1M，2M，4M，8M，16M，…，等按2的倍数进行圆整。
例如表或分区数据段大小为28M，则initial取32M。
2）Next
表或分区扩展extents的大小，按上述方法进行圆整。
当表或分区数据段无法按Initial接近值进行圆整的情况下，其大小可以按Initial+Next进行圆整。
此时，必须设置Minextents=2。
例如：
表或分区数据段大小为150M，则Initial=128M；Next=32M，Minextents=2。
3）Minextents
该参数表示表创建时候Extents的初始数量，一般取1—2。
4）Pctincrease
表示每个扩展Extents的增长率，设置pctincrease=0能够获得较好的存储性能。
2.4.2.2.特殊表设计原则
2.4.2.2.1.分区表
对于数据量比较大的表，根据表数据的属性进行分区，以得到较好的性能。
如果表按某些字段进行增长，则采用按字段值范围进行范围分区；如果表按某个字段的几个关键值进行分布，则采用列表分区；对于静态表，则采用hash分区或列表分区；在范围分区中，如果数据按某关键字段均衡分布，则采用子分区的复合分区方法。
2.4.2.2.2.聚蔟表
如果某几个静态表关系比较密切，则可以采用聚蔟表的方法。
2.4.2.3.完整性设计原则
2.4.2.3.1.主键约束
关联表的父表要求有主健，主健字段或组合字段必须满足非空属性和唯一性要求。
对于数据量比较大的父表，要求指定索引段。
2.4.2.3.2.外键关联
对于关联两个表的字段，一般应该分别建立主键、外键。
实际是否建立外键，根据对数据完整性的要求决定。
为了提高性能，对于数据量比较大的标要求对外健建立索引。
对于有要求级联删除属性的外键，必须指定ondeletecascade。
2.4.2.3.3.NULL值
对于字段能否null，应该在sql建表脚本中明确指明，不应使用缺省。
由于NULL值在参加任何运算中，结果均为NULL。
所以在应用程序中必须利用nvl（）函数把可能为NULL值得字段或变量转换为非NULL的默认值。
例如：
NVL（sale,0）。
2.4.2.3.4.Check条件
对于字段有检查性约束，要求指定check规则。
2.4.2.3.5.触发器
触发器是一种特殊的存储过程，通过数据表的DML操作而触发执行，起作用是为确保数据的完整性和一致性不被破坏而创建，实现数据的完整约束。
触发器的before或after事务属性的选择时候，对表操作的事务属性必须与应用程序事务属性保持一致，以避免死锁发生。
在大型导入表中，尽量避免使用触发器。
2.4.2.4.注释
表、字段等应该有中文名称注释，以及需要说明的内容。
2.4.3.索引设计
对于查询中需要作为查询条件的字段，可以考虑建立索引。
最终根据性能的需要决定是否建立索引。
对于复合索引，索引字段顺序比较关键，把查询频率比较高的字段排在索引组合的最前面。
在分区表中，尽量采用local分区索引以方便分区维护。
除非时分区local索引，否则在创建索引段时候必须指定指定索引段的tablespace、storage属性，具体参考2.4.2.1内容。
2.4.4.视图设计
视图是虚拟的数据库表，在使用时要遵循以下原则：
1）从一个或多个库表中查询部分数据项；
2）为简化查询，将复杂的检索或字查询通过视图实现；
3）提高数据的安全性，只将需要查看的数据信息显示给权限有限的人员；
4）视图中如果嵌套使用视图，级数不得超过3级；
5）由于视图中只能固定条件或没有条件，所以对于数据量较大或随时间的推移逐渐增多的库表，不宜使用视图；可以采用实体化视图代替；
6）除特殊需要，避免类似Select*from[TableName]而没有检索条件的视图；
7）视图中尽量避免出现数据排序的SQL语句。
2.4.5.包设计
存储过程、函数、外部游标必须在指定的数据包对象PACKAGE中实现。
存储过程、函数的建立如同其它语言形式的编程过程，适合采用模块化设计方法；当具体算法改变时，只需要修改需要存储过程即可，不需要修改其它语言的源程序。
当和数据库频繁交换数据是通过存储过程可以提高运行速度，由于只有被授权的用户才能执行存储过程，所以存储过程有利于提高系统的安全性。
存储过程、函数必须检索数据库表记录或数据库其他对象，甚至修改（执行Insert、Delete、Update、Drop、Create等操作）数据库信息。
如果某项功能不需要和数据库打交道，则不得通过数据库存储过程或函数的方式实现。
在函数中避免采用DML或DDL语句。
在数据包采用存储过程、函数重载的方法，简化数据包设计，提高代码效率。
存储过程、函数必须有相应的出错处理功能。
2.4.6.安全性设计
2.4.6.1.管理默认用户
在生产环境中，必须严格管理sys和system用户，必须修改其默认密码，禁止用该用户建立数据库应用对象。
删除或锁定数据库测试用户scott。
2.4.6.2.数据库级用户权限设计
必须按照应用需求，设计不同的用户访问权限。
包括应用系统管理用户，普通用户等，按照业务需求建立不同的应用角色。
用户访问另外的用户对象时，应该通过创建同义词对象synonym进行访问。
2.4.6.3.角色与权限
确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。
每个角色拥有刚好能够完成任务的权限，不多也不少。
在应用时再为用户分配角色，则每个用户的权限等于他所兼角色的权限之和。
2.4.6.4.应用级用户设计
应用级的用户帐号密码不能与数据库相同，防止用户直接操作数据库。
用户只能用帐号登陆到应用软件，通过应用软件访问数据库，而没有其它途径操作数据库。
2.4.6.5.用户密码管理
用户帐号的密码必须进行加密处理，确保在任何地方的查询都不会出现密码的明文。
2.5.SQL编写
2.5.1.字符类型数据
SQL中的字符类型数据应该统一使用单引号。
特别对纯数字的字串，必须用单引号，否则会导致内部转换而引起性能问题或索引失效问题。
利用trim（）,lower（）等函数格式化匹配条件。
2.5.2.复杂sql
对于非常复杂的sql（特别是有多层嵌套，带子句或相关查询的），应该先考虑是否设计不当引起的。
对于一些复杂SQL可以考虑使用程序实现。
USER_TAB_COMMENTS数据字典
Commenton可加注解
2.5.3.高效性
2.5.3.1.避免In子句
使用In或notIn子句时，特别是当子句中有多个值时，且查询数据表数据较多时，速度会明显下降。
可以采用连接查询或外连接查询来提高性能。
Char比varchar查询时高效。
在进行查询及建立索引时，char比varchar的效率要高，当然varchar在存储上比char要好。
2.5.3.2.避免嵌套的Select子句
这个实际上是In子句的特例。
2.5.3.3.避免使用Select*语句
如果不是必要取出所有数据，不要用*来代替，应给出字段列表，注：
不含selectcount（*）。
2.5.3.4.避免不必要的排序
不必要的数据排序大大的降低系统性能。
2.5.4.健壮性
2.5.4.1.Insert语句
使用Insert语句一定要给出要插入值的字段列表，这样即使更改了表结构加了字段也不会影响现有系统的运行。
2.5.4.2.Count（*）、Count（id）、count（distinctid）的区别
Selectcount（*）fromtesttab
得到表testtab的记录数
selectcount（id）fromtesttab
得到表testtabid字段非空记录数
selectcount（distinctid）fromtesttab
得到表testtabid字段值非相同记录数
2.5.4.3.Notnull为字段类型性质的约束
本约束功能在后期无语法使期失效，可使用修改字段类型方式。
altertablemodify字段名类型notnull
altertablemod
升级会员 