Chinaunix首页 | 论坛 | 博客
  • 博客访问: 101928284
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928295
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928296
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928297
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928298
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928299
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928300
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928301
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928302
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928303
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928304
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928305
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928306
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928307
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928308
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928299
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928310
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928311
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928312
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928313
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928314
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928315
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928317
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928318
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928319
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928320
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928321
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928322
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928323
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928314
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928325
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928326
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928327
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928328
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928329
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928330
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928331
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928332
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928334
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928335
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928336
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928337
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928338
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928329
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928340
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928341
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928342
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928343
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928344
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928345
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928346
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 5 部分: DB2 实用程序(7)-sdccf-ChinaUnix博客
  • 博客访问: 101928347
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:35:15

为考试作准备

developerWorks



DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24228) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24227) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24226) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24225) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24224) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24223) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24222) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24221) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24220) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24219) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24218) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24217) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24216) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24215) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24214) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24213) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24212) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24211) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24210) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24209) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24208) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24207) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24206) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24205) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24204) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24203) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24202) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24201) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24200) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24199) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24198) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24197) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24196) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24195) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24194) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24193) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24192) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24191) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24190) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24189) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24188) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24187) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24186) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24185) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24184) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24183) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24182) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24181) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24180) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24179) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24178) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~


DB2 维护实用程序

DB2 利用先进的基于成本的优化器来决定如何访问数据。它的决定很大程度上要受到关于数据库表和索引的大小的统计信息的影响。因此,应该使数据库统计信息不断更新,以便于选择有效的数据访问计划。RUNSTATS 实用程序用于更新关于表和相关索引的物理特征的统计信息。这些特征包括记录的数量(基数)、页数、平均记录长度等。

让我们通过一些例子来演示这个实用程序的用法。下面的命令收集关于表 db2user.employee 的统计信息。在计算统计信息的同时,可以对表进行读写访问:

RUNSTATS ON TABLE db2user.employee ALLOW WRITE ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于列 empid 和 empname 的分布统计信息。当这个命令在运行的时候,对这个表只能进行只读访问:

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS 
( empid, empname ) ALLOW READ ACCESS

下面的命令收集关于表 db2user.employee 的统计信息以及关于它的所有索引的详细统计信息:

RUNSTATS ON TABLE db2user.employee AND DETAILED INDEXES ALL

说到收集关于数据库对象的统计信息,您就非常清楚了。可以使用 RUNSTATS 选项的不同组合来收集表统计信息、索引统计信息、分布统计信息、抽样统计信息等。为了简化统计信息的收集,可以将发出 RUNSTATS 命令时指定的选项保存在一个统计信息概要文件中。如果您想重复地收集关于一个表的相同的统计信息,但是又不想重新输入命令选项,那么只需发出:

RUNSTATS ON TABLE db2user.employee USE PROFILE

这个命令使用那个表的统计信息概要文件中记录的选项收集关于 db2user.employee 的统计信息。那么,如何设置统计信息概要文件呢?这和使用 SET PROFILE ONLY 选项一样容易。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION ON COLUMNS ( empid, empname ) 
    SET PROFILE ONLY

注意,该选项只设置概要文件,RUNSTATS 命令不会执行。如果需要修改之前注册的统计信息概要文件,可以使用 UPDATE PROFILE ONLY 选项。类似地,这个选项只更新概要文件,而不会运行 RUNSTATS 命令。如果要同时更新概要文件,则可以使用 UPDATE PROFILE

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UPDATE PROFILE 

RUNSTATS 是一个资源密集型的实用程序。然而,为了维护有效的数据库运行,必须定期收集统计信息。您应该发现数据库活动减少的时间窗口,以便在不影响数据库性能的情况下收集数据库统计信息。在某些环境中,不存在那样的窗口。这时可以考虑使用 RUNSTATS 实用程序的阀门来限制该实用程序所消耗的资源。当数据库活动不频繁时,可以更积极地运行该实用程序。另一方面,当数据库活动增加时,则减少用于执行 RUNSTATS 的资源。下面是指定阀门级别的语法。

RUNSTATS ON TABLE db2user.employee WITH DISTRIBUTION DEFAULT NUM_FREQVALUES 50
 NUM_QUANTILES 50
    UTIL_IMPACT_PRIORITY 30

可接受的优先值范围为 1 到 100。100 表示最高优先级(即无限制),1 表示最低优先级。50 是默认优先级。

注意,在默认情况下,当数据库被创建时,会启用自动统计信息收集。通过将数据库配置参数 AUTO_RUNSTATS 设为 OFF,可以关闭这个特性。







数据库中添加和删除的数据在物理上可能不是按连续的顺序放置的。在这种情况下,DB2 必须执行附加的读操作来访问数据。这通常意味着需要更多的磁盘 I/O 操作,我们都知道那些操作是开销很大的。在这种情况下,应该考虑在物理上将表重组,使相关的数据存放在相近的位置,以减少 I/O 操作。

REORG 是用于重组表和/或索引中的数据的一个实用程序。虽然数据是在物理上进行重排的,DB2 提供了在线或离线执行该过程的选项。默认情况下,离线 REORG 允许其他用户读这个表。可以通过指定 ALLOW NO ACCESS 选项来限制对表的访问。在线 REORG (也称就地 REORG)不支持对表的读或写访问。由于是在对数据页进行重排,并发的应用程序必须等到 REORG 完成当前页。您可以用适当的选项停止、暂停或恢复这个过程。

下面的例子很清楚地作了演示:

REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE

还可以重组索引。如果像下面一个例子中那样使用了 CLEANUP 子句,那么就会执行清除,而不是重组。

REORG INDEX db2user.idxemp FOR TABLE db2user.employee ALLOW WRITE ACCESS 
REORG INDEX db2user.idxemp FOR TABLE db2user.employee CLEANUP ONLY

REORGCHK 是另一种数据维护实用程序,它可以选择检索当前数据库统计信息或更新数据库统计信息。它还将使用 REORG 指示符生成关于统计信息的报告。通过使用统计信息公式,REORGCHK 将需要 REORG 的表或索引标上星号(*)。

我们来考虑一些例子。下面的命令生成关于运行时授权 ID 拥有的所有表的当前统计信息的一份报告:

REORGCHK CURRENT STATISTICS ON TABLE USER

下面的命令更新统计信息,并生成关于模式 smith 下创建的所有表的一份报告:

REORGCHK UPDATE STATISTICS ON SCHEMA smith

下面是一些 REORGCHK 示例输出:

REORGCHK 示例输出







数据库应用程序或任何 SQL 语句在执行之前,都需要由 DB2 对其进行预编译,并生成一个。包是一种数据库对象,其中包含应用程序源文件中使用的编译后的 SQL 语句。DB2 使用包来访问 SQL 语句中引用的数据。DB2 优化器如何为这些包选择访问计划呢?它依赖于在创建包时的数据库统计信息。

对于静态 SQL 语句,包是在编译时创建和绑定到数据库的。如果对统计信息进行了更新,以反映物理数据库特征,那么也应该更新已有的包。REBIND 实用程序允许重新创建一个包,以便使用当前的数据库统计信息。这个命令非常简单:

REBIND PACKAGE package_name
                

在很多情况下,SQL 语句包含了主机变量、参数占位符和专用寄存器。这些变量的值只有到运行时才是已知的。通过 REBIND 命令中的 REOPT 子句,可以指定是否让 DB2 使用主机变量、参数占位符和专用寄存器的实际值来优化访问路径。有三种 REOPT 选项:

  • NONE —— SQL 语句中使用的主机变量、参数占位符和专用寄存器的实际值将不用于优化访问路径。相反,优化访问路径时使用的是这些变量的默认估计值。
  • ONCE —— 当第一次执行查询时,使用主机变量、参数占位符或专用寄存器的实际值优化给定 SQL 语句的访问路径。
  • ALWAYS —— 总是使用主机变量、参数占位符或专用寄存器的值编译和预优化给定的 SQL 语句的访问路径。
REBIND PACKAGE ACCTPKG REOPT ONCE
					

然而,如果要更改应用程序源,那么需要显式地删除并重新创建已有的相关包。REBIND 实用程序不用于这个目的。这里我们向您提醒这一点,是因为 DBA 经常误解 REBIND 的用途。

对于动态 SQL 语句,它们是在运行时预编译并存储在包缓存中的。如果更新了统计信息,那么可以刷新缓存,以便再次编译动态 SQL 语句,从而将更新后的统计信息考虑进去。命令如下:

FLUSH PACKAGE CACHE DYNAMIC







现在您理解了 RUNSTATSREORGREORGCHKREBINDFLUSH PACKAGE CACHE,让我们回顾一下应该对数据库定期执行的数据库维护过程。下面的图阐释了这个过程:

数据维护过程

阅读(24177) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~