数据库运维流程工作流标准20150721

1、数据库运维流程工作流标准文件修订记录表日期作者修订类型修订内容版本2015.7.20新增制定本方案1.0目录数据库运维流程1工作流标准1目录2服务器配置标准3安装标准3监控标准3业务保障标准4慢查询标准4配合开发评估SQL标准5故障处理流程和故障报告标准6备份数据库标准7数据批量处理流程标准7灾备、高可用标准8数据库访问权限管理标准8服务器配置标准根据DBA提出的需求来采购、安装、配置数据库服务器，硬件标准如下：2U机架式；CPU 型号INTEL Xeon系列 2.4GHz或以上；数量 2颗；内存 32GB 或 64GB；硬盘 600GB*6块 10KB SAS硬盘，RAID 10；如果IO存

2、在瓶颈，可以配置PCIe SSD固态硬盘；软件标准如下：CentOS release 6.6 (Final) 2.6.32 x86_64 GNU/Linux安装标准用户名称Oracle数据库用户为：oracleMysql数据库用户为：mysql安装位置：Oracle数据：/oracleMysql软件：/data/womai/mysqlMysql数据：/data内存使用（32GB）Oracle SGA使用 20GBOracle PGA使用 3GBMysql buffer_pool 使用 20GBMysql key_buffer 使用 512MB监控标准1.系统自动收集数据库中告警日志中的错误信息

3、，以邮件形式发送至邮箱，数据库管理员需每日查看该邮件，并及时处理。2.每日查看Nagios数据库告警信息。3.当手机信息、邮件收到Nagios告警信息时，需第一时间告知领导和相关项目人员，并及时进行处理。具体监控项目如下：Check current users logged in；Check load average;Check disk;Check processes;Check net bps;Check cpu utilization;Check memory;Check swap;Check iostat;Check tcp stats;Check ssh login;Check da

4、tabase portCheck database Uptime;Threads;Opens;locksCheck database sessions;业务保障标准根据业务优先级划分如下：一类业务：网站、手机。建议在五分钟内恢复业务；二类业务：CC 。建议数据库故障不要影响接电话，并在十五分钟内恢复业务；三类业务：WMS。建议在十五分钟内恢复业务；四类业务：其他业务建议在六十分钟内恢复业务；慢查询标准Oracle部分慢查询定义，抓取每个类别的top 3，然后进行优化。SQL ordered by Elapsed TimeSQL ordered by CPU TimeSQL ordered by

5、 ExecutionsSQL ordered by Parse CallsMysql部分慢查询定义，抓取每个类别的top 3，然后进行优化。SQL ordered by Record CountSQL ordered by Elapsed TimeSQL ordered by Lock TimeSQL ordered by Fetch Back配合开发评估SQL标准(1) sql语句尽可能简单大的sql想办法拆成小的sql语句(充分利用QUERY CACHE和充分利用多核CPU)(2) 事务要简单，整个事务的时间长度不要太长 (3) 避免使用触发器、函数、存储过程(4) 降低业务耦合度，为sa

6、cle out、sharding留有余地(5) 避免在数据库中进行数学运算(MySQL不擅长数学运算和逻辑判断)(4) 不要用select *，查询哪几个字段就select 这几个字段(5) sql中使用到OR的改写为用 IN() (or的效率没有in的效率高)(6) in里面数字的个数建议控制在1000以内(7) limit分页注意效率。Limit越大，效率越低。可以改写limit，比如例子改写：select id from tlimit 10000, 10; => select id from t where id > 10000 limit10;(9) 使用union all

7、替代union(10) 避免使?大表的JOIN(11) 使用group by 分组、自动排序(12) 对数据的更新要打散后批量更新，不要一次更新太多数据(13) 减少与数据库的交互次数(13) 注意使用性能分析工具Sql explain / showprofile / mysqlsla(14) SQL语句要求所有研发，SQL关键字全部是大写，每个词只允许有一个空格(15) SQL语句不可以出现隐式转换，比如 select id from 表 where id='1'(16) IN条件里面的数据数量要少，我记得应该是500个以内，要学会使用exist代替in，exist在一些场景

8、查询会比in快(17) 能不用NOT IN就不用NOTIN，坑太多了。会把空和NULL给查出来(18) 在SQL语句中，禁止使用前缀是%的like(19) 不使用负向查询，如not in/like(19) 关于分页查询：程序里建议合理使用分页来提高效率limit，offset较大要配合子查询使用(20) 禁止在数据库中跑大查询(21) 使用预编译语句，只传参数，比传递SQL语句更高效；一次解析，多次使用；降低SQL注入概率(22) 禁止使用order by rand()(23) 禁止单条SQL语句同时更新多个表故障处理流程和故障报告标准数据库负责人职责梳理：1、 数据库出现故障后，由相关责任人

9、进行处理。2、 第一责任人负责准备切换文档，并登录远程服务器，执行切换任务；3、 第二责任人登录远程管理卡，检查硬件和服务器的状态，记录或截图后重启服务器，并配合第一责任人切换。数据库切换流程梳理：1、收到告警，登录后发现数据库故障，且影响业务。或者无法登录主机，无法登录远程管理卡，或发现远程管理卡有故障日志导致服务器故障。总之业务停掉了。2、第一时间通知宋经理和项目人员3、数据库主机无法恢复后，向宋哥确认切换主机4、登陆备机机开始切换（根据实际情况，首选switchover）附件为CC (oracle) 项目和CMS (mysql) 项目的切换文档。撰写故障报告，每月为一个文档，文档名称为数

10、据库组故障报告表YYYYMM.xlsx 。 打开故障文档，首页为索引，记录每次故障的编号，所属项目，状态，时间，相关人员。后面每个表单记录一次具体故障，这里会详细记录故障表现和处理方法等。附件为2015年4月的故障报告。备份数据库标准1.每周一至周六进行增量备份，周日进行全量备份。2.备份统一由远程备份至备份存储机器。3.备份由凌晨十二点开始，分项目分时段备份，不得重叠备份。4.备份集需保留2周数据。两周后由脚本自动删除。5.每季度将数据保存至移动存储介质做永久保存。数据批量处理流程标准大批量操作（增、删、改）数据流程：为避免数据库大批量操作数据时产生长时间的锁、等待、数据不一致、数据库压力太

11、大、数据库容灾备库日志恢复缓慢等现象，特制订本流程望各位遵守。1.所有大批量操作数据时，需要提前告知数据库管理员，数据库管理员会同时间跟踪该数据库及灾备数据库状况。2.在删除操作时，为减小对线上生产造成的压力，删除工作时间段尽量选择在夜里业务清闲时做（可执行数据库job）。3.删除大批量数据时，需将大事务缩减为小事务，分批提交，每1000条提交一次。减少对数据库的压力。DECLARE CURSOR MYCURSOR IS SELECT ROWID FROM table_name WHERE xxx = 'xxx' ORDER BY ROWID; -按ROWID排序的CURSOR

12、，删除条件是XXX=XXXX，根据实际情况写 TYPE ROWID_TABLE_TYPE IS TABLE OF ROWID INDEX BY PLS_INTEGER; V_ROWID ROWID_TABLE_TYPE; BEGIN OPEN MYCURSOR; LOOP FETCH MYCURSOR BULK COLLECT INTO V_ROWID LIMIT 1000; -每次处理1000行，也就是每1000行一提交 EXIT WHEN V_ROWID.COUNT=0; FORALL I IN V_ROWID.FIRST.V_ROWID.LAST DELETE FROM table_name WHERE ROWID=V_ROWID(I); COMMIT; END LOOP; CLOSE MYCURSOR; END; /灾备、高可用标准1.所有数据库必须排除单点，实行主、备（从）机制。2.备库与主库实现实时同步机制，将提交数据同时在备库执行恢复，保证主备库数据一直。3.每周检查主备库同步情况。4.备库服务器环境尽量保持与主库一直，巡检时关注备库压力，并预测备库是否可以支撑业务压力。5.数据库出现压力过大时，需实现读写分离架构。将报表、执行效率低下SQL等与主库分离。6.数据库使用keepa