数据库管理规范
一、总则
1.1 目的
为保障公司数据库安全、稳定、高效运行，特制定本规范。
1.2 名词解释
DBA：数据库管理员；
生产环境：本规范指已交付用户使用的应用系统环境；
1.3 适用范围
本规范适用于信息技术部；
二、数据库建设规范
2.1 数据库服务器配置：
? OS与数据库存储空间部署于不同物理磁盘；
? OS 安装在两块物理盘搭建而成的RAID1阵列；
? 数据库存储阵列配置根据业务配置，读多写少配置为RAID5+1，读少写多配置为RAID1；
? 物理内存与数据库大小的比值不小于为1：5；
? CPU平均负载小于50%，峰值小于80%；
2.2数据库配置：
MySQL部分：
? 生产环境和开发测试环境相互独立部署在不同的服务器；
? 一台环境服务器有且仅有一个数据库实例；
? 严禁用超级管理员创建数据库实例；
? 数据库字符集设置UTF8；
? 数据库隔离级别设置为RC级别；
? 关闭数据库自动提交功能；
? 数据库引擎选择innodb；
? MYSQL安装优先选择源码安装；
? MYSQL应选择免费的稳定社区版；
? MySQL标准参数如下：
|
参数 |
设置标准 |
|
storage_engine |
innodb |
|
innodb_buffer_pool_size |
50% OS MEMORY |
|
innodb_log_file_size |
30分钟切换一次 |
|
innodb_log_buffer_size |
10M以内 |
|
innodb_thread_concurrency |
单个CPU的核数 |
|
innodb_flush_log_at_trx_commit |
1 |
|
sync_binlog |
1 |
|
Innodb_file_per_table |
1 |
|
binlog_format |
ROW |
|
slow_query_log |
ON |
|
long_query_time |
10.000000 |
|
log_queries_not_using_indexes |
ON |
|
thread_cache_size |
64M |
Oracle部分：
? 生产环境和开发测试环境相互独立部署在不同的服务器；
? 一台环境服务器有且仅有一个数据库实例；
? 严禁用超级管理员创建数据库实例；
? 数据库字符集设置为AL32UTF8，国家字符集：AL16UTF16
? 控制文件、日志文件、数据文件应部署在不同的磁盘之中；
? 控制文件、日志文件至少保留三个副本；
? 数据库闪回功能应关闭；
? 数据库应置于归档模式运行；
? 数据库应置于专用服务器模式运行；
三、数据库运维规范
3.1 数据库日常运维管理
3.1.1 日常巡检项目包括但不限于：备份是否成功、数据库服务器性能状态、数据库日志是否报错、数据库服务器硬件状态；
3.1.2 每月应出具数据库巡检月报，月报内容包括但不限于3.1.1项所列；
3.1.3 定期编译无效对象并清理无效、或者无用的数据库对象；
3.1.4 定期更新数据库性能统计信息；
3.1.5 应以二进制类型参数文件启动数据库；
3.1.6 定期分析数据库性能分析报告；
3.1.7 可以动态修改的全局参数禁止写入参数文件，但应该记录该参数状态；
3.2 数据库变更管理
3.2.1 数据库变更应由DBA做好备份后再执行变更脚本；
3.2.2 重大数据库数据库变更应一人操作一人监督；
3.2.3 数据库变更流程：
? 业务系统数据库对象变更：
? 数据库参数、版本变更：
四、数据库开发规范
4.1 业务系统对象命名规范
4.1.1 对象名称要求能表达对象用途，尽量采用英文标准翻译；对象名超过数据库长度限制的，可采用英文缩写；
4.1.2 对象名由且仅由字母和下划线 ”_”组成；
4.1.3 历史表以”_HIS” 结尾；
4.1.4 临时表以”_TMP” 结尾；
4.1.5 物化视图以”V_”打头，作为前缀；
4.1.6 索引以”IDX_” 打头；主键索引以”PK_” 打头，作为前缀；
4.1.7 序列以”SEQ_” 打头，作为前缀；
4.1.8 存储过程以”SP_”打头，作为前缀；
4.1.9 函数以”FC_”打头，作为前缀；
4.1.10 触发器以”TR_”打头，作为前缀；
4.2 数据库对象设计和SQL编写规范
4.2.1 数据库禁止使用PROCEDURE、FUNCTION、PACKAGE、TRIGGER、VIEW；
4.2.2 SQL数据库保留字大写，其它部分如表名、字段小写；
4.2.3 SELECT后避免使用”*”,应使用具体的字段名；
4.2.5 INSERT语句之后表名需带字段名称；
4.2.6 批量操作数据时，禁止每INSERT、UPDATE或DELETE一行就COMMIT，应批量提交；
4.2.7 为重用SQL语句，应尽可能使用绑定变量；绑定变量定义数值类型应跟对应字段数据类型匹配；
4.2.8 EXISTS与IN：子查询返回结果集比较小优先使用IN，反之用EXISTS；
4.2.9 业务允许条件下，用union all 代替union；
4.2.10 表字段不应有空值，如有空值，应以默认值填充；
4.2.11 每个表都应该建立主键；
4.2.12 定义字段尽可能使用变长的数据类型，内容长度不固定的字段排在表结构末；
4.2.13表结构字段顺序遵循按查询频率高低来排列；
4.2.14 尽可能把SQL语句简单化；
4.2.15 应把大字段如BLOB，CLOB独立出单表；
4.2.16 SQL语句尽可能不使用复杂计算，应把复杂的计算放在应用服务器；
4.2.17 SQL语句应按结果集数量由少至多顺序执行的子查询；
4.2.18 子查询中避免使用order by，如需要，则必须放在主查询SQL末尾；
4.2.19 SQL语句格式：
? 应适当缩进，体现SQL语句的层级，例如：
SELECT object_name,
object_type,
owner,
status
FROM dba_objects
WHERE owner = 'TFS'
4.2.20 索引列使用约定：
? 避免在索引列上使用NOT、IS NULL、IS NOT NULL;
? 避免在索引列上进行计算;
? 只在适合的列上创建索引，insert、delete、update频繁的表尽可能的减少索引数量；
? 数据量少于5000的表可不建索引；
? DML频繁的表尽可能减少索引数量，单表索引数量少于5个；
? 避免使用函数索引；
4.2.21 数据库设计约定：
1. 每个表应考虑添加以下字段：
|
字段名称 |
数据类型 |
是否唯一 |
是否为空 |
默认值 |
数据格式 |
备注 |
|
ID |
Varchar2(38) |
Y |
N |
|
|
自动生成(兼容老版本GUID),作为表主键 |
|
Creator |
NVARCHAR2(38) |
N |
N |
|
|
创建人ID |
|
Creator_name |
NVARCHAR2(80) |
N |
|
|
Zhang San张三:工号 |
创建人姓名 |
|
Create_time |
Date |
N |
N |
|
2015/5/29 15:40:55 |
创建时间 |
|
modifier |
NVARCHAR2(38) |
N |
N |
|
|
修改人ID |
|
Modifier_name |
NVARCHAR2(80) |
N |
N |
|
Li Si 李四:工号 |
修改人姓名 |
|
Update_time |
Date |
N |
N |
|
2015/5/29 15:48:48 |
修改时间 |
2. 包含以下单词的字段应尽量做如下定义：
|
字段名称 |
数据类型 |
是否唯一 |
是否为空 |
默认值 |
数据格式 |
备注 |
|
Loan_id |
NVARCHAR2(38) |
Y |
N |
|
|
贷款id |
|
*_Remark |
NVARCHAR2(250) |
N |
Y |
|
|
备注 |
|
gender |
NUMBER(1) |
N |
N |
|
|
性别 1男 2女 |
|
*_State |
NUMBER(1) |
N |
N |
|
|
状态 取值0 1 |
|
*_Desc |
NVARCHAR2(250) |
N |
Y |
|
|
描述、说明 |
3. 关联表、字段命名：
如表A字段关联表B的字段col，则表A中的字段命名应为”B_col”
4. 多个表中重名的字段保持字段名和数据类型的一致性
如表A字段名称为A_ID,如B表中也是A_ID,则，A、B两表的这两个字段应有相同的数据类型
5. 每个子系统的表名应以该系统英文简称打头；
6. 字段名称与实际存放的数值应相匹配
如字段名称：
A_DATE 数据类型为时间格式数值，存放的数据格式为’yyyy-mm-dd’
B_TIME数据类型为时间格式数值，存放的数据格式为’yyyy-mm-dd hh24:mi:ss’
7. 存放地址的字段应拆分成addr1,addr2,addr3。Addr1 存：国家-省份-城市；addr2存：区-街道；addr3存：小区-楼栋-门牌号
8. 如字段存放电话号码，则格式如下：0755-88888888与13812345678，不允许为空，如业务实际没有提供，应以默认值填充：0000-00000000
9. 专业名词约定：
还款：Repayment
贷款：loan
利息：Interest
利率：Interest rate
罚息：Penalty
违约：Breach of contract
催收：collection
债权：creditor
合同：contract
申请：apply
费用：fee
信用：credit
审核：audit
风险：risk
准备金：reserve
签约：sign
4.3 数据库设计变更流程
4.3.1 TFS数据库设计开发流程图见如下：
4.3.2 dev库使用者为开发人员，test库使用者为测试组，preprod库使用者为业务部门；
4.3.3 从dev库生成的数据字典与ER图文件为V0版，文件名格式为
”子系统名称_dev_V0_20150610”，从test库生成的数据字典与ER图文件为
”子系统名称_test_V1_20150610”，从生产环境生产的数据字典与ER图文件为
”系统名称_prod_v2_20150610”。数据字典与ER图文件格式为：
4.3.4 设计人员向项目经理、DBA按以下文档格式提交表结构新增或变更文档。
4.3.5 提交数据表设计表格时，注明主外键关系。但在数据库中不添加外键。
4.3.6 两表之间关联的命名原则为：子表名称_REF_父表名称_父表字段。
4.4 数据库变更脚本书写规范
4.3.1 DDL操作脚本和DML操作脚本文件相，如脚本中涉及多个schema，应再按schema分成不同的文件。DDL脚本文件名以”_DDL.txt”结尾，DML脚本文件名互独立以”_DML.txt”结尾；
4.3.2 脚本内容头部中用以下格式注明本脚本内容：
/* 脚本负责人： */
/* 脚本主要用途： */
/* 用户模式/数据库： */
/* 是否存在DELETE、DROP、UPDATE、TRUNCATE操作： */
4.3.3 操作脚本有执行顺序要求的，文件名以序列标识，序列小的文件为先执行，如：
“1_2015_05_01_新增字段_TFSDBUSER_DDL.txt”;
”2_2015_05_01_数据插入_TFSDBUSER_DML.txt”;
文件1较文件2先执行。
5.3.4 操作脚本中应按执行顺序自上而下编写；
五、数据库安全规范
5.1 数据库审计
5.1.1 数据库审计员与数据库管理员应相互独立；
5.1.2 关键数据库表的DML、DDL操作应做审计记录；
5.1.3 数据库的重大操作如失败登陆、起停、表空间变更、参数变更应审计记录；
5.2 数据库账号管理
5.2.1 数据库账号密码长度至少12位，包含大小写字母和数字；
5.2.2 数据库密码应定期修改，频度不低于半年每次；
5.2.3 数据库账号应只有以下四种类型：数据库管理员账号(sys、system)、业务系统管理员账号、业务系统连接数据库账号、数据库备份专用账号（backup）及特殊申请的查询账号，其它账号应锁定；
5.2.4 sys、system、backup账号责任人为DBA；业务系统管理员账号、业务系统连接账号责任人为开发部主管；特殊申请的查询账号责任人为申请人；数据库账号责任人应负责账号密码安全，禁止向非授权人员泄露密码；
5.2.5 账号登陆失败超过10次时应锁定；
5.2.6 sys账号禁止通过客户端电脑连接数据库进行日常管理；
5.2.7 禁止开发人员和用户通过客户端工具连接生产环境数据库服务器；
5.3 数据库权限管理
5.3.1 业务系统管理账号用于存放业务系统数据库对象，可拥有CONNECT，RESOURCE系统权限及本系统对象的DDL、DML权限；
5.3.2 业务系统连接数据库账号用于业务系统访问数据库，可拥有CONNECT系统权限及本系统对象DML权限；
5.3.3 数据库权限以最小权限原则进行授权；
5.4 数据转移管理
5.4.1 数据库备份文件离开公司范围内时应得到主管领导审批；
5.4.2 产品环境数据导入开发测试环境后，应对敏感数据进行处理；
5.5 数据库服务器访问
5.5.1 数据库服务器应对访问IP进行限制，除应用服务器、管理员IP、授信IP可访问，其它IP禁止访问；
六、数据库备份恢复
6.1 数据库备份
6.1.1 数据库备份应异机保留3份副本，且保留期限为1年；
6.1.2 备份数据至少保存3个月，为节省存储空间，应及时删除3月之前的备份数据；金融相关的备份数据应至少保存5年；
6.1.3 每周对数据库进行0级备份，每天进行1级备份；
6.1.4 产品环境数据库应采取逻辑和物理备份两种方式保证数据安全；
6.1.5 非授权人员不能对备份数据进行访问；
6.1.6 因数据库变更需备份生成的备份文件，在确认数据库变更成功后可删除备份文件；
6.2 数据库恢复
6.2.1 应半年对备份数据进行恢复测试，验证备份文件的有效性；
6.2.2 数据丢失后应及时对数据库进行恢复，保证业务系统正常运行；
6.2.3 应定期对数据库进行灾难恢复演练及双机切换演练；