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

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935414
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935416
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935418
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935405
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935407
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935409
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935412
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935413
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935415
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935417
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935409
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935422
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935425
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935427
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935430
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935433
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935437
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935439
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935442
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935445
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935448
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935451
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935454
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935457
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935460
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935463
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935466
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935469
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935473
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935476
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935469
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935482
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935484
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935487
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935490
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935493
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935496
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935499
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935502
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935506
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935499
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935512
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935514
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935518
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935521
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935523
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935527
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935530
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935533
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935536
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks

DB2 9 数据库管理(731考试)认证指南,第 6 部分: 高可用性:备份和恢复(3)-sdccf-ChinaUnix博客
  • 博客访问: 101935529
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-04-13 14:40:10

developerWorks



DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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


DB2 日志

DB2 事务日志对于恢复来说是至关重要的。它们跟踪数据库对象和数据上发生的变化。日志可以存储在文件或原始设备中。对于下面的例子,我们将使用文件。为确保完整性,DB2 使用预写式(write-ahead)日志记录模式,这种模式在将更改写(具体化)到数据库和磁盘之前写日志。下图展示了这种模式。

展示 DB2 Memory、DB2 日志和数据库的交互的图

在这个图中,一共执行了四条 SQL 语句。这些语句被缓存在包缓存中,数据页被从数据库取出到缓冲池中。随着 SQL 语句的执行,更改首先被记录到日志缓冲区中,然后被写到日志文件中。在这例子中,新版本的数据页还没有被具体化到数据库中。这个工作通常是在需要腾出缓冲池空间时执行的,或者是由于性能的原因而异步地执行的。

主日志文件 是在建立第一个数据库连接或者数据库活动时立即分配的。辅助日志文件 是在需要时动态分配的。

下面是与日志记录相关的一些数据库配置参数:

参数 用途
LOGPRIMARY 表明要分配的主日志文件的数量
LOGSECOND 表明可以分配的辅助日志文件的最多数量
LOGFILSIZ 用于指定一个日志文件的大小(4 KB 页的个数)

让我们考虑一个例子。想像一下在数据库配置文件中有以下值:

 Log file size (4 KB)                        (LOGFILSIZ) = 1000
 Number of primary log files                (LOGPRIMARY) = 3
 Number of secondary log files               (LOGSECOND) = 2
 Path to log files                                       = C:\mylogs\

一旦建立到数据库的第一个连接,就会分配三个主日志文件,每个主日志文件由 1000 个 4 KB 的页组成。在 C:\mylogs 目录中可以看到这三个文件:

 Directory of C:\MYLOGS\

06/04/2006  06:17 PM         4,104,192 S0000000.LOG
06/04/2006  06:17 PM         4,104,192 S0000001.LOG
06/04/2006  06:17 PM         4,104,192 S0000002.LOG
               3 File(s)     12,312,576 bytes


现在,假设数据库中没有活动,您决定执行以下事务,该事务将插入一百万条记录:

INSERT INTO TABLE1 VALUES(1);
INSERT INTO TABLE1 VALUES(2);
...
INSERT INTO TABLE1 VALUES(1,000,000);
COMMIT;

前面提到,对数据库的更改被记录在日志中。不必费心计算插入每条记录将占用多少空间,您应该能理解我们要说明什么。DB2 将填充第一个日志文件,然后继续填充第二个日志文件,然后再填充第三个日志文件。当填满第三个日志文件时,就没有主(预分配的)日志文件了,于是 DB2 将动态地分配第一个辅助日志文件,因为 LOGSECOND 是大于 0 的。当这个辅助日志文件被填满时,DB2 将继续分配另一个辅助日志文件,一直重复这个过程,直到分配的辅助日志文件数量达到最大值 LOGSECOND。对于这个例子,当 DB2 尝试分配第三个辅助日志文件时,它将返回一个错误,表明事务已用完日志空间。这时事务将回滚。







本节简要地定义一下不同类型的日志。在下一节中,当我们谈到日志记录的类型时,您将看到这些类型的日志的用法。下面是 DB2 事务日志的三种类型或状态:

活动日志
如果以下两个条件之一得到满足,则一个日志被认为是活动的(active)
  • 它包含关于尚未被提交或回滚的事务的信息。
  • 它包含关于已经被提交但是其更改还没有被写(具体化)到数据库磁盘的事务的信息。
在线归档日志
包含被提交 具体化的事务的信息。这些日志与活动日志放在相同的目录中。
离线归档日志
已经从活动日志目录转移到另一个目录或媒介上的归档日志。这种移动可以手动地完成,也可以由 DB2 自动完成。







有两种类型的日志记录:循环日志记录和归档。

循环日志记录是 DB2 默认的日志记录模式。顾名思义,这种类型的日志记录以循环的模式重用日志。例如,如果有四个主日志,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,Log #1,Log #2,依此类推。

在循环日志记录模式下,只要一个日志只包含关于已提交 被具体化到数据库磁盘上的事务的信息,那么它就可以被重用。换句话说,如果日志仍然是活动日志,那么它就不能被重用。

仍然使用前面循环日志记录的例子,如果有一个长时间运行的事务,这个事务要横跨 5 个日志文件,那么会出现什么情况呢?在这种情况下,DB2 再多分配一个日志文件 —— 即一个辅助日志文件,正如 主日志文件和辅助日志文件 中描述的那样。下图展示了其中的原理。

展示循环日志记录的图

当使用归档日志记录模式时,您要经常归档(保留)日志。在循环日志记录模式下,已提交且被具体化的事务将被覆盖,而在归档日志记录模式下,这些事务将得到保留。例如,如果有 4 个主日志文件,DB2 将按照以下顺序使用它们:Log #1,Log #2,Log #3,Log #4,(如果 Log #1 的所有事务已被提交且具体化,则归档 Log #1),Log #5(如果 Log #2 的所有事务已被提交且具体化,则归档 Log #2),Log #6,依此类推。

正如这个例子演示的那样,DB2 将保持 4 个主日志文件可用,即使一些日志文件中填满了已被提交且具体化的事务,DB2 也不会重用它们。DB2 不会覆盖已经成为归档日志的日志。下图阐释了其中的原理。

展示归档日志记录的图

一个数据库的日志记录的类型是由数据库参数 LOGARCHMETH1 决定的。当 LOGARCHMETH1 为 OFF(默认值)时,归档日志记录被禁用,循环日志记录被启用。

为了启用归档日志记录,可以将 LOGARCHMETH1 设置为以下值中的任何一个值:

LOGRETAIN 日志文件将被保留在活动日志目录中
USEREXIT 日志的归档和检索是由用户提供的用户出口程序自动执行的,这个出口程序必须由 db2uext2 调用。这个程序用于将在线归档日志移动到与活动日志目录不同的一个目录中,或者移动到另一个媒介上。当在 ROLLFORWARD 操作期间需要某些离线归档日志时,这个程序还可以用于将离线归档日志取出到活动日志目录中。在 Windows 下,db2uext2 必须存储在 sqllib\bin 目录中,在 UNIX 下,db2uext2 必须存储在 sqllib/adm 目录中
DISK:directory_name 与 USEREXIT 使用相同的算法。DB2 不调用用户出口程序,而是自动将日志文件从活动日志目录归档到指定的目录
TSM:[management class name] 与 USEREXIT 使用相同的算法。日志被归档到本地 Tivoli Storage Manger (TSM) 服务器上。management class name 参数是可选的。如果没有指定该参数,则使用默认的管理类
VENDOR:library_name 与 USEREXIT 使用相同的算法。日志是使用指定供应商的库来归档的

由于向后兼容的原因,数据库配置文件仍然包含参数 LOGRETAINUSEREXIT。从 8.2 版开始,这两个参数已经被 LOGARCHMETH1 取代。如果更新 USEREXITLOGRETAIN 参数,那么 LOGARCHMETH1 将自动被更新,反之亦然。

无限日志记录
不管是使用循环日志记录还是归档日志记录,日志空间都可能被填满活动日志。如果启用无限日志记录,DB2 就会在一个日志被填满时立即归档这个日志。它不会等到日志中所有的事务都已经被提交且具体化的时候才来归档日志。这样可以保证活动日志目录永远不会被填满。例如,如果有一个长时间运行的事务,在启用无限日志记录模式的情况下,就不会出现日志空间被耗尽的情况。

然而,我们不建议使用无限日志记录,因为它可能延迟紧急事故恢复的时间,这是因为需要从归档站点检索活动日志。无限日志记录是归档日志记录的一个派生物。要启用无限日志记录:

  1. 将 LOGSECOND 数据库配置参数设置为 -1
  2. 启用归档日志记录。







现在您理解了不同类型的日志记录和恢复,但是要注意的一点是,并不是所有日志记录类型都支持所有的恢复类型。循环日志记录只支持紧急事故恢复和版本恢复,而归档日志记录则支持所有类型的恢复:紧急事故恢复、版本恢复和前滚恢复。

可恢复(recoverable)数据库是指可以使用紧急事故恢复、版本恢复或前滚恢复进行恢复的数据库;因此,对于这些数据库,需要启用归档日志记录。不可恢复(nonrecoverable)数据库是指不支持前滚恢复的那些数据库;因此,只需使用循环日志记录。







到目前为之,我们谈到了关于数据库日志和日志记录的一些概念。下图对一些概念作了总结。

展示一些事务和日志记录概念的图

该图展示了一些需要运行一段时间的事务。有些事务是并发运行的;这些事务首先填充日志缓冲区,随后被写到磁盘上的日志文件中。

MINCOMMIT 是一个数据库配置文件参数。
当日志缓冲区被填满时,或者发出第 MINCOMMIT 次提交时,日志缓冲区中的内容将被写到日志文件中。被提交事务对数据页的更改将被具体化(异步地从缓冲池写到数据库磁盘上)。为简单起见,在图中这个过程是在提交时发生的,而实际上通常不是如此。

标有 active 字样的六边形表示日志文件 X 仍然被当作活动日志的时间。您可以看到,这个六边形在表示日志文件 Y 中事务 D 和事务 C 一部分的正方形之上。为什么日志文件 X 在被填满之后仍然被当作活动日志呢?这是因为它包含了还没有被提交和具体化的事务。日志文件 X 包含事务 A、B 和 C。只有事务 A 和事务 B 已经被提交(在这个例子中,它们也随之立即被具体化);而事务 C 仍然在运行,并且被写到日志文件 Y 中。当事务 C 在日志文件 Y 中被提交时(在这个例子中,它也随之立即被具体化),日志文件 X 将不再被当作活动日志,但是它将成为一个在线归档日志。

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