新書推薦:
《
金托邦:江湖中的沉重正义
》
售價:NT$
275.0
《
易经今解:释疑·解惑·见微
》
售價:NT$
403.0
《
东欧史(全二册)-“中间地带”的困境
》
售價:NT$
1010.0
《
虚拟资本:金融怎样挪用我们的未来
》
售價:NT$
352.0
《
刻意练习不生气
》
售價:NT$
179.0
《
大宋理财:青苗法与王安石的金融帝国(全彩插图本)
》
售價:NT$
500.0
《
安全感是内心长出的盔甲
》
售價:NT$
305.0
《
快人一步:系统性能提高之道
》
售價:NT$
505.0
編輯推薦:
国内专业DB2论坛db2china 鼎力支持
內容簡介:
IBM
DB2作为业界主流的数据库产品,广泛应用于金融、通信、烟草等行业。本书侧重于DB2数据库管理,以实战为主要目标,内容涵盖软件安装配置、数据库环境搭建、存储规划、数据迁移、备份恢复、锁、性能监控调优和常见的问题诊断等。通过循序渐进、深入浅出的讲解,力求让读者亲自动手实验,结合实际案例,快速掌握DB2知识,独立完成日常运维管理工作。本书作者均有IBM原厂的工作经历,实战经验非常丰富,本书将和大家分享他们的DB2数据库管理的最佳实践经验。
關於作者:
徐明伟,网络ID:飞天。毕业于北京航空航天大学,计算机硕士专业。2004年加入IBM中国软件开发中心软件服务部,从事DB2、MDM相关的技术支持和咨询工作。2010年成为DB2咨询顾问,并创立北京普远天成科技有限公司,继续专注于为客户提供DB2咨询、培训和支持工作。
在DB2数据库管理、性能调优和问题诊断方面,徐明伟具备非常丰富的经验。曾经帮助云南移动,海南移动、贵州移动、上海移动、安徽联通、人民银行、农业银行、交通银行、晋商银行、中央国债、中国银联、国家烟草局、南京钢铁、宝钢股份、北京高速路、韩国国税局、马来西亚工业部等备类行业客户进行DB2数据库和相关产品的性能调优和问题诊断工作,获得客户高度认可。
积极推动DB2的推广和使用,组织了多场公开课培训和企业内训,培训的人数超过千人,培训内容注重理论和实战相结合,并分享多个实际性能调优和问题诊断案例,深受客户好评。
王涛,网络ID:wangzhonnew。毕业于加拿大卡尔加里大学,计算机科学专业。于2005年加入JBM加拿大多伦多实验室,从事DB2二线技术支持。2007年升迁到DB2高级技术支持小组,主要负责北美区域客户DB2系统宕机等严重事故处理与高级性能调优支持。2011年进入DB2三线高级问题诊断小组,主要负责全球各地最为复杂与紧急的客户DB2数据库系统故障诊断处理,以及部分模块的研发与优化工作。
王涛在DB2问题诊断和性能优化方面,具有极其丰富的经验,曾经帮助包括花旗银行,汇丰银行、四大投行、可口可乐、波音、美国军方以及政府等不同行业在内的数百家大型企业在第一时间恢复关键数据,为超过近百家企业的关键系统进行DB2性能诊断和优化,获得客户高度认可和赞誉。
王涛是国内几大知名DB2论坛的超级版主,热心帮助国内客户解决生产故障,积极参与社区的问题讨论,为推动DB2在国内的传播做出了突出贡献。
目錄 :
第一部分 DB2概述
第1章 DB2产品介绍
1.1 数据模型
1.2 DB2历史
1.3 DB2版本
1.4 DB2 9主要功能增强
1.5 DB2认证
1.6 DBA的任务和职责
1.7 IBM信息管理产品概述
1.8 小结
1.9 判断题
1.10 参考文献
第2章 DB2体系结构
2.1 DB2体系结构简介
2.2 对象层次关系
2.3 数据访问过程
2.4 数据库工具
2.5 小结
2.6 判断题
2.7 参考文档
第二部分 DB2部置和规划
第3章 安装DB2软件
3.1 软件安装
3.1.1 软件获取
3.1.2 安装前检查
3.1.3 安装
3.1.4 补丁升级
3.1.5 版本升级
3.2 小结
3.3 判断题
3.3 参考文档
第4章 实例管理
4.1 什么是实例
4.2 创建实例
4.2.1 在Windows平台下创建实例
4.2.2 在UNIXLinux平台下创建实例
4.3 启动停止列出实例
4.4 更新实例
4.5 删除实例
4.6 实例参数
4.7 管理服务器(Database Administration Server, DAS)
4.8 小结
4.9 判断题
第5章 数据库创建和存储管理
5.1 数据库结构
5.2 建库、表空间
5.3 表空间维护管理
5.3.1 表空间监控
5.3.2 表空间更改
5.3.3 表空间状态
5.3.4 表空间高水位
5.3.5 深入DMS表空间
5.4 存储设计最佳实践
5.5 小结
5.6 判断题
第6章 数据库连接
6.1 远程连接概述
6.2 节点和数据库编目
6.3 常见的数据库连接问题
6.4 小结
6.5 判断题
第7章 数据库对象
7.1 模式
7.2 表
7.2.1 表约束
7.2.2 表状态
7.2.3 表压缩
7.2.4 表分区
7.3 索引
7.4 视图
7.5 昵称
7.6 序列(Sequence)
7.7 自增字段
7.8 大对象(LOB)
7.9 函数
7.10 触发器
7.11 存储过程
7.12 小结
7.13 判断题
第三部分 DB2运维管理
第8章 数据迁移
8.1 数据迁移概述
8.2 文件格式
8.2.1 DEL格式
8.2.2 ASC格式
8.2.3 PCIXF
8.2.4 Cursor
8.3 export
8.4 import
8.5 load
8.5.1 load步骤及原理
8.5.2 load表状态
8.5.3 load的copy选项
8.5.4 set integrity完整性检查
8.6 12个怎么办
8.6.1 出现了load pending了怎么办
8.6.2 在客户端load问题
8.6.3 要加载的数据是Excel格式怎么办
8.6.4 要导出加载的数据不是逗号双引号分隔怎么办
8.6.5 文件中的列比要导入的表中的字段多怎么办
8.6.6 文件中的列比要导入的表中的字段少怎么办
8.6.7 要导入导出大字段(LOB)怎么办
8.6.8 sequence数据怎么办
8.6.9 导入identity数据怎么办
8.6.10 要加载的数据有换行符怎么办
8.6.11 迁移出现乱码怎么办
8.6.12 表数据从一个表空间迁移到另外一个表空间怎么办
8.7 db2lookdb2move
8.7.1 db2move工具介绍
8.7.2 db2look工具介绍
8.7.3 db2look+db2move迁移案例
8.8 db2dart
8.9 小结
8.10 判断题
第9章 备份恢复
9.1 备份恢复概述
9.2 DB2日志
9.2.1 日志机制和原理
9.2.2 日志参数配置最佳实践
9.2.3 日志监控和维护管理
9.2.4 其他日志相关的考虑
9.2.5 经常遇到的日志问题
9.3 备份
9.3.1 离线备份
9.3.2 在线备份
9.3.3 表空间备份
9.3.4 增量备份
9.3.5 备份介质检查
9.3.6 备份监控
9.4 恢复
9.4.1 崩溃恢复
9.4.2 版本恢复
9.4.3 前滚恢复
9.4.4 删除表恢复(dropped table recovery)
9.5 常见备份恢复场景及遇到的问题
9.5.1 宕机后数据库连接hang的处理
9.5.2 循环日志模式下的离线备份恢复
9.5.3 归档日志模式下的备份恢复
9.5.4 归档日志模式下前滚恢复的几个时间戳
9.5.5 同版本不同实例下的数据库备份恢复(表空间是自动存储管理)
9.5.6 同版本不同实例下的数据库备份恢复(表空间是非自动存储管理)
9.5.7 不同版本不同实例下的数据库恢复
9.5.8 从生产库到测试库恢复的案例分析
9.5.9 历史文件过大造成数据库停止响应案例分析
9.5.10 恢复时解压类包问题
9.5.11 备份失败问题
9.6 小结
9.7 判断题
第10章 DB2日常运维
10.1 日常运维工具概述
10.2 Runstats
10.2.1 Runstats原理
10.2.2 Runstats用法
10.3 Reorg
10.3.1 为什么需要Reorg
10.3.2 Reorg用法
10.3.3 Reorg最佳实践
10.4 Rebind
10.5 获取数据库占用空间的大小
10.6 获取某个表空间占用空间大小
10.7 获取某个表索引占用空间的大小
10.8 小结
10.9 判断题
第11章 锁和并发
11.1 锁和隔离级别概述
11.2 锁的模式和兼容性
11.2.1 表锁模式
11.2.2 行锁模式
11.2.3 表锁和行锁兼容性
11.3 锁的各种问题
11.3.1 锁等
11.3.2 锁超时
11.3.3 死锁
11.3.4 锁升级
11.3.5 锁转换
11.4 锁监控和诊断
11.4.1 锁的分析思路和方法
11.4.2 锁升级lock escalation的诊断分析
11.4.3 锁等(lock wait)的捕获与诊断分析
11.4.4 锁超时(lock timeout)的捕获与诊断分析
11.4.5 死锁(deadlock)的捕获与诊断分析
11.4.6 9.7锁事件监控器
11.5 锁和并发调优
11.6 Currently Committed机制
11.7 小结
11.8 判断题
第四部分 DB2监控和调优
第12章 DB2进程线程模型
12.1 提要
12.2 从操作系统看进程和线程
12.3 DB2 V8V9.1进程模型
12.3.1 代理进程
12.3.2 分区内并行
12.3.3 分区间并行(DPF)
12.3.4 预取进程(prefetcher)
12.3.5 页面清理进程(Page Cleaner)
12.3.6 其他进程
12.3.7 实例 数据库启动步骤
12.4 DB2 9.59.7线程模型
12.5 小结
12.6 判断题
第13章 DB2内存模型
13.1 从操作系统看内存
13.2 DB2 89.1内存模型
13.2.1 实例共享内存段
13.2.2 数据库共享内存
13.2.3 应用程序组共享内存
13.2.4 私有内存
13.3 DB2 9.59.7内存模型
13.3.1 实例内存
13.3.2 应用程序内存
13.3.3 自动内存调节(Self Tuning Memory Management,STMM)
13.4 内存监控
13.4.1 db2mtrk
13.4.2 db2pd -dbptnmem
13.4.3 db2pd -memset db2pd -mempool
13.5 小结
13.6 判断题
第14章 DB2监控工具
14.1 snapshot命令行监控
14.2 snapshot管理视图
14.3 db2pd
14.4 db2top
14.4.1 实时监测
14.4.2 历史信息收集
14.4.3 子窗口
14.5 DB2事件监控器
14.6 小结
14.7 判断题
第15章 性能监控和分析方法
15.1 收集数据
15.1.1 操作系统级别性能监控
15.1.2 数据库级别性能监控
15.1.3 数据收集的频度
15.1.4 小结
15.2 分析数据
15.2.1 瓶颈分类与原理介绍
15.2.2 性能分析思路
15.2.3 性能分析案例
15.2.4 小结
15.3 判断题
第16章 优化器与性能调优
16.1 优化器简介
16.2 性能调优简介
16.2.1 索引
16.2.2 排序
16.3 KPI
16.3.1 缓冲池命中率(bufferpool hit ratio)
16.3.2 有效索引读
16.3.3 包缓存命中率 (package cache hit ratio)
16.3.4 平均结果集大小
16.3.5 同步读取比例
16.3.6 数据、索引页清除
16.3.7 脏页偷取(dirty page steal)
16.3.8 缓冲区读写IO响应时间
16.3.9 Direct IO时间
16.3.10 直接IO读取(写入)的次数
16.3.11 编目缓冲区插入比例
16.3.12 排序指标
16.3.13 基于事务的指标度量
16.3.14 检测索引页扫描
16.3.15 日志写入速度
16.3.16 查询执行速度
16.3.17 实例级性能指标
16.3.18 操作系统级指标
16.4 小结
16.5 判断题
第五部分 DB2问题诊断
第17章 问题诊断
17.1 概述
17.2 日志信息错误
17.3 宕机
17.4 挂起
17.5 错误信息
17.5.1 SQLCODE
17.5.2 db2trc
17.5.3 strace
17.6 分析数据收集工具
17.7 IBM服务支持体系
17.8 小结
17.9 判断题
第18章 数据库安全
18.1 安全概述
18.2 认证机制
18.3 权限控制
18.3.1 管理权限
18.3.2 对象特权
18.3.3 权限设计案例
18.4 审计机制
18.5 DB2安全最佳实践
18.6 其他安全技术增强
18.7 小结
18.8 判断题
18.9 参考文献
內容試閱 :
刚才我们所做的就是将一个服务器系统性能问题细化为数据库服务器或者应用程序服务器的性能问题。如果能够在3个系统中(应用程序服务器、数据库服务器和存储服务器)中至少排除掉一个,都能够为我们性能分析带来很大方便。
但是有时候,很难排除以上任何一种。如果在上周四的数据中,发现上周四大概6个LIOW
Executing,每秒15个查询,CPU占用率5%,那么我们不能够简单地说这个是应用程序服务器的问题。一般来说,正常的系统,性能下降意味着单位时间内的吞吐量减少。可是该例中,正常吞吐量为每秒15个查询,而性能不好的系统中为每秒50个查询,这一点明显有悖于正常行为。
让我们继续分析。通过对CPU使用率的理解,当前CP[J使用率仅有10%,由此可以推断CPU不应该成为瓶颈。那么问题可能出在哪呢?可能是应用层,比如修改了业务逻辑(需要更多的SQL语句),也可能发生在数据库层,比如由于业务量的突然提高,导致更多锁等待,产生系统懒惰。
细化问题有一个前提,就是一定要小心不要走上错误的岔口。在每次回答一个小问题之前,都不要过度依赖某一类的数据。除了CPU使用率、并发数、吞吐量等指标,还包含更多的数据。我们一定要结合关键数据分析现象,千万不要被某几条现象所迷惑。
每一次回答小问题的时候,都要仔细思考一下,有没有其他任何数据能够证明该答案是错误的。注意,“错误”并不是笔误。每次回答问题之前,都要去假设心中的答案是一个错误的答案,然后尝试去找数据证明这一点。如果没有任何数据或者逻辑能够反证你的推论,这个推导才算是合格可用的。
在细化的过程中,有时候我们找不到一个完美的对比数据。比如有的时候当DBA被交予一个陌生的系统时,领导可能拍着桌子吼“这个系统跑了两年都是好好的,可是性能上周突然下降得很厉害,你给我把它搞定”。这个时候,用户可能并没有该系统的历史数据来对比,那么KPI(KeyPer-
formance Indicator,关键性能指标)就是我们最好的朋友。
KPI并不是凭空产生的,而是国内外无数专家在几十年的性能分析中总结出的一套相对适用于大部分系统的性能指标。
除非一个系统被设计得相当诡异,一般来说大部分系统都可以用KPI指标进行评估。当然,如果系统怪异到连最通常的KPI都不适用的情况下,那么这个系统的设计者估计也可以离职了。
最通常的KPI可以说是缓冲池命中率。相信大部分DB2DBA都听说过,就是说有百分之多少的机会,一个逻辑读会发现数据已经存在缓冲池内部。这里我们先不给出具体数值,在下一章中,我们会列举很多常用的KPL以及它们的用法和意义。
数据收集频率很重要,每一次数据收集前,我们都要弄清楚“从这次的收集中我们需要研究什么方向”,以及“为什么在前一次的收集中我们没有收集到相关数据”。我们的目标是尽量减少无效的数据收集次数,但是由于性能问题的特殊性,人们不可能通过一次收集,就把所有可能发生性能问题的相关数据全部拿到。