实际工作规范和案例框架

标签：

菜刀：

1. sql一刀剁了
2. 整个模块丢弃了
3. 调用次数少多了
4. 排序不在需要了
5. 大表砍成小表了
6. 排重操作消失了
7. 插入障碍小多了
8. 迁移事情不做了

手术刀：

1. 大表等于小表了
2. 大表切成小表了
3. 索引变身小表了
4. 删除动作不做了
5. 清表角度表换了
6. 提交次数缩减了
7. 迁移越来越快了
8. sql语句精简了

思路：

1. 诊断
   1. 过程细化
   2. 找出细化项的主要矛盾
2. 改进优化
   1. 理解需求
      1. 表明需求
      2. 隐藏需求
      3. 真正需求
   2. 设计
      1. 尽量不做事，甚至少做事。
      2. 选择相关工具，掌握相关技能
      3. 合理利用资源

规范：

1. 数据库规范
1. 学习规范
   1. 了解自己的职责
   2. 根据职责学习
   3. 提问必须有智慧
   4. 必须有动手试验的习惯
   5. 解决完问题必须总结
   6. 总结后学会分享
2. 求助提问规范
   1. 描述不全不问：
      1. 什么点出故障
      2. 影响面多大
      3. 发生故障的时间点
      4. 产生的故障是否有规律
      5. 故障环境的访问方式
      6. 求助人的联系方式
   2. 用词准确：
      1. 现在运行多长，希望运行多长。
   3. 能搜不问
   4. 问过不问
   5. sql提问要需求最小化
      1. 提供建表语句
      2. 插入部分数据
      3. 告诉我想要展现的结果
3. 作业操作规范
   1. 数据库补丁投放
      1. DML语句和DDL语句不能放在一起
      2. 一次只允许开一个数据库登录界面
      3. PLSQL开发不允许保存密码自动登录
      4. 涉及需更新记录的表必须先备份
      5. 涉及对投放补丁完成时间有预计
   2. 数据库迁移备份
      1. 必须先明确备份迁移方式：
         1. expdp/impdp
         2. exp/imp
         3. rman
         4. others
      2. 明确导入导出表空间及磁盘空间大小
      3. 明确操作的库具体有多大
      4. 明确最大的对象有哪些
      5. 明确需要导出的有多大
      6. 明确需要完成的操作的规定时长
   3. 数据库误删除
      1. 确定被删除的类型
         1. 表被drop
         2. 记录被删除
         3. 表被truncate
      2. 明确误操作的时间点
         1. 当场发现
         2. 事后发现
      3. 对应策略
         1. 表被drop
            1. 用备份恢复
            2. 从回收站恢复
            3. 被多次drop从回收站中根据时间点恢复
         2. 记录被删除
            1. 用备份回鹘
            2. 闪回恢复
            3. 时间长无法闪回，且无备份，考虑手工插入恢复
         3. 表被truncate
            1. 用备份恢复
            2. 如果数据库有闪回，考虑闪回数据库
            3. 都不行的情况下，考虑手工插入记录恢复
4. 诊断流程规范
1. 完善的数据库问题分析步骤
1. 动态
   1. 整体
      1. 主机动态情况检查
      2. 性能视图备份
      3. 获取基线
      4. 观察临时表空间和回滚段表空间情况
   2. 局部
      1. 通过主机进程pid查sql
      2. 观察当前数据库的版本和等待情况，sql基本情况
      3. 检查是否有过分提交的语句
      4. 检查系统的绑定变量
2. 静态
1. 整体
1. 主机的静态情况检查
2. 记录oracle所有的参数设置情况，并且检查是否归档
3. 检查数据库表和索引是否存在并行度设置
4. 检查是否有实效的索引
5. 检查是否有显著未释放的高水平位的表
6. 检查统计信息
1. 自动统计信息收集情况
2. 全局临时表的情况
7. awr/addm/ash/awrddrpt/awrsqrpt等方式观察数据库
8. 获取数据库警告和监听日志
9. 检查日志大小设置情况
10. 检查最大的对象是哪些，表空间使用情况和回收站情况
2. 局部
1. 检查有哪些函数索引和位图索引
2. 检查CACHE小于20的序列
3. 分析需要跟踪的表和索引
1. 查看表的大小情况
1. 记录的大小
2. 物理的大小
2. 检查表结构的情况
1. 查看表的信息
2. 看分区表相关信息
3. 查看索引情况
1. 每张表对应多少索引
2. 结构情况
3. 查看索引列的信息
4. 以下查出的都是分区索引
5. 高效开发规范
1. SQL编写规范
1. 单条sql不要超过100行
2. sql子查询嵌套不要超过3层
3. sql表关联需要考虑连接条件和限制条件的索引
4. 尽量避免hint在代码中出现
5. 同一个sql模块避免出现大量相似之处
6. 用到并行需谨慎
7. 尽量避免对列的运算
2. PLSQL编写规范
1. 注释不少于代码的1/10
2. 代码必须提供最小化测试案例与注释中
3. 绑定变量
4. 尽量使用批量提交
5. 同一过程包中出现重复逻辑块需封装，统一调用
6. 生产环境尽量使用包来封装过程和函数
7. 动态SQL编写需记录真实SQL记录表中
6. 合理设计规范
1. 表规范
1. 范式
1. 绝大部分要求第三范式
2. 适当考虑反范式
2. 不同类表的差异
1. 小表
1. 一般要有主键
2. 一般要有约束
3. 尽量规划在同一个表空间
2. 大表
1. 尺寸超过10g需要考虑建分区
2. 分区表中分区超过100要注意
3. 大表尽量要有明确的数据保留策略
1. 体现在设计文档
2. 实现步骤体现在维护脚本中
3. 体现在表注释中
4. 大表坚决不允许有触发器
5. 日志大表一般不设主键
3. 中间表
1. 内存表
2. 全局临时表
3. 表结构
1. 注释
1. 表必须要有注释
2. 列尽量要有注释
2. 列类型
1. 避免使用LOGN字段
2. 避免用CHA字段
3. 列类型和值尽量匹配
1. 时间取值放入date列
2. 数据取值放入number列
3. 字符串放入varchar2列
2. 索引规范
1. 用不上分区条件的局部索引不宜建
2. 函数索引大多用于列运算，一般需要避免
3. 位图索引遇到更新是噩梦，需要避免
4. 外键未建索引将引发死锁，及影响表连接的性能
5. 建联合索引需谨慎
1. 要结合单列查询决定前缀
2. 超过四个字段的联合索引要引起注意
3. 范围查询影响组合索引
4. 需要考虑回表因素
6. 单表索引个数需要控制
1. 索引超过5个以上
2. 建后2个月内没有使用的
7. 单表无任何索引需要重视
8. 需要注意索引的实效情况
1. 导致索引失效的因素
1. 表移动表空间
2. 分区表系列动作未加update global indexes
2. 当前哪些索引实效
3. 如何让索引生效
3. 环境参数规范
1. 数据库参数
1. SGA和PGA参数
1. OLTP应用是主机内存的80%分配数据库，其中SGA80%，PGA20%
2. OLAP应用是主机内存的80%分配数据库，其中SGA50%，PGA50%
2. Process和Session
3. Open_cursor
4. 日志参数
1. 日志文件个数
2. 日志文件大小
5. 是否归档
2. 表空间规划
1. 回滚表空间
1. 自动管理
2. 避免自动扩展
3. 尽可能规划大
2. 临时表空间
1. 避免自动扩展
2. 尽可能大
3. 尽可能使用临时表空间组
3. 业务表空间
1. 控制个数，不超过6个为宜
2. 尽量避免自动扩展，超阀值由监控来检查
3. 根据自己的业务，固定表空间名
4. 表空间需良好分类
1. 参数配置表
2. 业务数据表
3. 历史记录表
5. 表空间需合理命名
3. RAC系统
1. 考虑通过TNS设置，将不同的业务代码部署在不同节点
2. 不同节点用不同的回滚段和临时段
4. 命名规范
1. 表t_
2. 视图v_
3. 同义词s_
4. 簇表c_
5. 序列seq_
6. 存储过程p_
7. 函数f_
8. 包pkg_
9. 类typ_
10. 外键fk_
11. 主键pk_
12. 唯一索引ux_
13. 普通索引idx_
14. 位图索引bx_
15. 函数索引fx_

实际工作规范和案例框架

标签：

原文地址：http://www.cnblogs.com/alexweng/p/4445771.html