交易系统和查询统计系统的差异分析.pptVIP

Oracle 性能调整 交易系统和查询统计系统的差异分析 OLTP 系统 主要特征 高吞吐量, 大量的插入和修改 可用性优先级最高，反应速度要求极高 大的, 连续增加的数据 大量用户的并发访问 Cursor问题/Bind变量问题 单笔事务的资源消耗少 OLTP系统 优化目标 高可用性 响应速度 高并发性 可恢复性 OLTP系统 典型应用 小规模增值税申报开票 电器零售业务 火车票销售系统 … … OLTP系统 主要适用技术 普通B*树索引 访问方式主要是按索引进行操作 索引不要太多 为Sequence字段设计Reverse key 定期重建索引 多表连接主要采用NL loop 为固定进行join操作的表使用cluster技术 IOT表的应用 OLTP系统 主要适用技术 预先分配空间(使用uniform 而不是autoallocation) 尽量使用bind变量，规范语句书写，提高语句的共享性 Cursor_sharing 参数设置为similar/force ,9204前有bug 不采用并行技术 分区技术 物化视图技术 … … 主要特征 对大量数据的查询 单笔事务的资源消耗大 并发量不高 后台操作 要求速度高 有一定的周期性 对数据仓库应使用并行查询的特性. 决策支持系统 Data 决策支持系统 典型应用 大批量数据装载、转换和装载 联机在线分析（OLAP) 历史数据迁移 会计记帐 生成汇总报表 … … 决策支持系统 主要适用技术 索引多，除B*树索引外，还有Bitmap索引 合理设置db_block_size和db_file_multiblock_read_count 保证extent大小是MTBC的整数倍 多表连接主要采用Hash Join和SMJoin 定期进行统计信息的采集 采用并行技术 分区技术 物化视图技术 …… 数据仓库需求 评估索引的使用: 尽可能使用位图索引. 对于按照主键执行的范围查询,使用索引组织表. 对非均匀分布的索引列生成柱状图. 簇表: 使用散列簇. 数据仓库应用的问题 分析时间不是很重要了. 执行计划必须被优化: 使用并行查询特性. 仔细的调优, 如果有可能使用提示. 测试实际的数据. 有些功能尽量使用pl/sql程序而不是用应用程序语言来实现 绑定变量可能会出问题. 全表扫描不再是主要问题 全表扫描？ 什么是全表扫描(FTS) 全表扫描的危害－大量的IO资源 全表扫描语句 非全表扫描语句 响应速度 00:06:10.07 00:00:07.06 内存消耗 3,917M 0.9m I/O消耗 4,411M 2.5M 全表扫描的原因1：缺乏索引 最简单原因：缺乏相关约束条件字段的索引 解决步骤： 按消耗资源的高低定位有问题的SQL语句 在这些SQL语句的执行路径中，分析全表扫描的表 在SQL语句中分析该表的约束条件字段 检查各个约束条件字段的索引是否存在 选择可选性最高的字段建立索引 评估效果 全表扫描的原因2：索引被抑制 在字段前增加了函数 To_char(fmt_jfrq,’yyyymmdd’) 修改为： Fmt_jfrqto_date(,’yyyymmdd’) 字段嵌入表达式 Fmt_bg_ysrq+14sysdate 修改为： Fmt_bg_ysrqsysdate-14 全表扫描的原因3：索引没有启动 原因分析 统计信息没有及时更新，导致基于成本的Oracle优化器没有选择合适的按索引访问数据的执行路径 Oracle老版本的优化器存在不足 解决办法 及时更新统计信息 通过hint，强制使用索引 通过dbms_stats指定索引统计数据 升级Oracle版本 * * Typical OLTP Applications Airline reservation systems Large order-entry applications Banking applications Requirements High availability (7 day/24 hour) High speed High concurrency Reduced time recovery * * * * * Characteristics of Decision Systems Decision support applications distill large amounts of information into understandable reports. They gather data from OLTP systems and use summaries and aggregates in retrieving it. They make he