db2 日志维护

合集下载

DB2 日常维护_官方

| August 9, 2005
© 2005 IBM Corporation
数据库监视器堆
命令：db2 get snapshot for dbm 输出：内存池类型 = 数据库监视器堆当前大小（以字节计） = 245760 高水位标记（以字节计） = 327680 已配置的大小（以字节计） = 278528
| August 9, 2005
© 2005 IBM Corporation
数据库编码
关于数据库的编码 db2 get db cfg for sample 数据库地域数据库代码页数据库代码集数据库国家／地区代码 db2set DB2CODEPAGE=1386 = CN = 1386 = GBK = 86
| August 9, 2005
© 2005 IBM Corporation
表空间利用率及状态
命令：db2 list tablespaces show detail 输出：表空间标识 =5 名称 = DMSTBS 类型 = 数据库管理空间内容 = 任何数据状态 = 0x0000 详细解释：正常总计页数 = 1000 可用页数 = 960 已用页数 = 96 可用页数 = 864 高水位标记（页） = 96 页大小（以字节计） = 4096 扩展数据块大小（页） = 32 预取大小（页） = 32 容器数 =1 最小恢复时间 = 2005-06-08-03.13.40.000000
利用率＝当前大小/已配置的大小
| August 9, 2005
© 2005 IBM Corporation
数据库日常维护
常用命令数据库健康状况分析数据维护注意事项 Q&A
| August 9, 2005

DB2最新维护手册

DB2维护手册目录DB2维护手册 (1)一、DB2入门-数据库实例 (5)二、DB2日常维护日操作 (20)1、检查管理服务器是否启动 (21)2、检查DB2实例是否已经启动 (21)3、查看表空间状态是否正常 (21)4、查看表的状态 (22)5、查看磁盘空间 (23)6、检查存储管理软件是否正常 (23)7、检查数据库备份是否正常 (24)8、检查归档日志是否正确归档了 (24)9、查看缓冲池的命中率 (24)10、查看当前运行最频繁的SQL，其命中率是否正常 (24)11、查看当前连接的应用程序，有没有非法连接 (25)12、检查有没有死锁 (25)13、对表和索引进行RUNSTATS (25)14、检查表是否需要重组 (25)15、对需要重组的表进行重组 (26)三、DB2日常维护月操作 (27)1、查看DB2日志 (27)2、检查备份和日志是否都保存好了 (27)四、DB2日常维护季度操作 (27)1、通过快照监控器，查看系统性能如何 (27)2、数据库补丁级别 (28)五、注意事项 (28)1、不要删除活动日志文件 (28)2、注意交易日志存储空间 (28)3、按照系统的实际工作量配置日志空间 (29)4、设置正确数据库代码页 (29)5、检查许可证（L ICENSE）安装情况 (30)6、创建数据库前调整好系统时间 (30)7、不要随便执行CHOWN (CHMOD)–R（UNIX/L INUX） (30)8、在归档日志模式下使用LOAD记得加NONRECOVERABLE参数 (31)六、附：以脱机方式重组表 (31)七、附：索引重组 (32)八、收集和更新统计信息的准则 (35)九、附：使用CLP 捕获数据库运行状况快照 (39)十、IBM DB2 日常维护汇总 (41)十一、DB2常用命令集 (51)一、DB2入门-数据库实例在本文中，我使用DB2 来指代DB2 通用数据库V8.1 for UNIX、Linux 和Windows。

DB2数据库的日志文件管理

DB2数据库的⽇志⽂件管理DB2数据库的⽇志⽂件管理DB2的⽇志模式1.1循环⽇志当循环⽇志⽣效时，事务数据将通过循环的⽅式写⼊主要⽇志⽂件。

当存储于某个⽇志⽂件中的所有记录都不再需要⽤于时，该⽇志⽂件将被重⽤，并且可以在以后再次成为活动⽇志⽂件。

这意味着在循环⽇志模式中，⽇志⽂件的内容最终将被新⽇志条⽬重写。

由于⽇志⽂件的内容被重写覆盖了，因此我们只能将恢复到最后⼀次完整的数据库。

不能使⽤循环⽇志执⾏时间点(point-in-time)恢复。

1.2 归档⽇志在归档⽇志模式中，redo log条⽬将写⼊主要⽇志⽂件。

但是，与循环⽇志不同，这些⽇志⽂件永远都不可重⽤。

当存储于某个⽇志⽂件中的所有记录都不再需要⽤于恢复时，该⽇志⽂件将被标记为⾮活动⽽不是可重⽤。

这意味着它的内容永远都不会被覆盖。

当第⼀个主要⽇志⽂件变满时，系统将分配⼀个新的⽇志⽂件，这样主要⽇志⽂件的配置数量(LOGPRIMARY数据库参数)将⼀直可⽤。

与单个事务相关的所有条⽬必须在活动⽇志空间中保持⼀致。

如果长时间运⾏的事务所需要的⽇志空间⼤于主要⽇志⽂件可以提供的空间，则可能会分配并使⽤次要⽇志⽂件。

在归档⽇志模式中，通过结合使⽤数据库备份映像和⽇志⽂件，我们可以将数据库恢复到具体的时间点。

有关此流程的详细描述请参见下⽂。

设置了归档模式后，数据库将⽀持前滚恢复。

此时，系统中将会存在三种类型的⽇志⽂件: 活动⽇志:该⽇志包含尚未提交或回滚的事务单元的相关信息，以及已提交但尚未写⼊数据库⽂件的事务的信息。

联机存档⽇志:活动⽇志中所有改动对正常处理已不需要，即该⽇志中所记录的事务都已提交并写⼊数据库⽂件时，该活动⽇志转换为联机存档⽇志。

称之为联机，是由于它们与活动⽇志存放在同⼀个⽬录下。

脱机存档⽇志:将联机存档⽇志从活动⽇志⽬录下Copy到另外的地⽅存档，就称为脱机存档⽇志。

这些⽇志可能在数据库前滚恢复的时候仍然需要。

(所谓联机归档⽇志，就是归档⽇志⽂件和活动⽇志⽂件同在⼀个⽬录下；⽽离线归档⽇志，则是归档⽇志与活动⽇志分开存放)管理数据库⽇志的⼯作可以⼿⼯完成（即将联机存档⽇志⼿⼯拷贝到某个archive⽬录），也可由编写USEREXIT程序⾃动维护。

合理调优提高DB2日志效能

合理调优提高■ 河南刘进京下面重点介绍四个方法来提高日志的效能。

优化配置日志参数与DB2参数有NEWLOGPATH状态，需要做全备份后数据库才能使用。

对于主日志数目（LOGPRIMARY）来说，其空间是预先分配的，用于记录事务的处理。

日志需要的磁盘空间一定的，不管其内容是空的还是写满的。

主日志文件最大数目是256，默认为3。

一般来说，只用主日志就可以满足日常的数据库运行所需。

如果LOGPRIMARY的值设置的过小，就可能会总遇到“log-full”的情况。

如果DB2总是分配辅助日志，就说明主日志大小不够。

对于高负载的OLTP系当分配的日志数达到规定的最大数目，还不能完成当前事务，则前事务会被撤销并返回错误信息。

辅助日志一旦分配，就会一直存在直到数据库去激活。

LOGSECOND 默认值为2，设置范围从0到254。

如果将其设置为-1，表示启用无限日志。

优化日志缓冲区参数对于日志缓冲区LOGBUF Z来说，是关系到日志读写性能的重要参数，其用来定义缓冲区的内存大小，使日志I/O更加高效。

日志缓冲已满是日志写回磁盘的关键OLTP应用调优的合适起点。

执行UPDATEUSING LOGBUFZ可以对其进行调整。

OLAP初始值需小而定。

64 GB的内LOGBUFSZ等。

当然，根据系统的工作符合而定。

不过日志越好，其可能对系统性能造成影响。

来减少日志数据。

如果预计在一个表上大批量操作，可NOT LOGGED INITIALLY。

对于临时表（包含声明的全局临时表和创建来说，一般作为中间数据的中转之用，和删除等上使用MOT使其不记录到数据时，使通过SQL引擎直接写数据页，这样就不且速度很速率高的情况，O次数高。

例如，照和应用程序快照显示提交的数目非常高等。

对应的优化措施是率，如果因为因为日志缓冲区太小导致出现日志磁盘O瓶颈，可的大小，通SNAPDB（数据库快照）LOG_BUFFER_FULL（除）进行监控来确定。

DB2日志归档与备份还原

四、还原数据库
#还原备份
db2 restore db AFCDB2 from /home/db2inst1/db2backup/ taken at 20140212190154 to /backup/log17
#前滚日志
db2 rollforward db AFCDB2 to end of logs and complete
三、备份数据库
#冷备：停止再开启数据库进行冷备
db2 force application all
db2 terminate
db2 backup db AFCDB2 to /home/db2inst1/db2backup/
db2 ARCHIVE LOG FOR DATABASE AFCDB2
#热备
db2 backup db AFCDB2 online to /home/db2inst1/db2backup/
#通过使用 and delete 参数，可以在清理条目的同时删除对应的归档日志文件。
#使用 db2 prune logfile 命令可以清除活动日志目录下的在线归档日志文件，但对离线归档日志文件无效
DB2日志归档与备份还原
一、查看归档是否打开
su - db2inst1
db2 connect to AFCDB2
db2 get db cfg for AFCDB2 |grep ห้องสมุดไป่ตู้i log
二、开启归档日志
#创建一个归档日志专用目录
mkdir /home/db2inst1/db2archlog
#开启归档日志
#查看是否能连接数据库
db2 connect to AFCDB2
附：查看归档日志
#手工归档日志（前提不能有连接）

DB2的日志分为两种模式

DB2的日志分为两种模式，日志循环与归档日志，也就是非归档和归档模式。

下面就具体介绍一下这两种方式以及和备份归档设置的关系。

一、日志循环这是默认方式，也就是非归档模式，这种模式只支持（backup offline）脱机备份，在备份过程中需要DB2停止服务。

在DB2中查看数据库设置，如发现如下信息$db2 get db cfg for db_name |grep -i log结果如下：Log retain for recovery enabled (LOGRETAIN) = OFFUser exit for logging enabled (USEREXIT) = OFFHADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC First log archive method (LOGARCHMETH1) = OFF 则说明为非归档模式，默认情况下为循环日志在这种模式下进行脱机备份需要注意：1、停止应用对DB2的访问。

可以通过db2 list applications命令查看现有的连接，然后通过db2 force application命令来结束连接。

另外通过db2 deactivate database命令来确保数据库未处于活动状态。

2、通过db2 backup db 数据库名命令来对数据库进行备份。

二、归档日志归档日志不是默认的，需要配置后才会生效，这种模式下的数据库是可恢复的数据库，支持在线备份、前滚恢复和崩溃恢复。

配置DB2归档日志模式主要是要修改Log retain for recovery enabled和First log archive method这两个参数。

修改参数（update更新参数）后，查看数据库是如下设置$db2 get db cfg for db_name |grep -i logLog retain for recovery enabled (LOGRETAIN) = RECOVERYUser exit for logging enabled (USEREXIT) = OFFHADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC First log archive method (LOGARCHMETH1) = LOGRETAIN 注意这里First log archive method的参数LOGRETAIN只表明你开启了归档，还需进一步设置才能正常备份下面需要进一步指定归档目录的路径更改归档目录:$db2 update db cfg for db_name using LOGARCHMETH1"disk:/archive/db_name_db_log"使用归档日志,当日志文件满时，会自动对它进行归档，归档的目的地就是Logarchmeth1设置的位置。

DB2 日志处理

$ db2 connect to <dbname>
$ db2 prune logfile prior to S???????.LOG
注：S???????.LOG为查看到的第一活动日志文件。此命令可以将当前第一活动日志文件之前的归档日志文件全部删除。
9、DB2 日志处理：
DB2日志是以文件的形式存放在文件系统中，分为两种模式：循环日志和归档日志。当创建新数据库时，日志的缺省模式是循环日志。在这种模式下，只能实现数据库的脱机备份和恢复。如果要实现联机备份和恢复，必须设为归档日志模式。目前在综合业务系统中，设置的均是归档日志模式；其它系统（如事后监督、经营决策、中间业务等）一般都设置为循环日志模式。至于采用何种模式，可以通过修改数据库配置参数（LOGRETAIN）来实现：归档日志模式：db2 update db cfg for <dbname> using logretain on 注：改为on后，查看数据库配置参数logretain的值时，实际显示的是recovery。改变此参数后，再次连接数据库会显示数据库处于备份暂挂（BACKUP PENDING）状态。这时，需要做一次对数据库的脱机备份（db2 backup db <dbname>），才能使数据库状态变为正常。循环日志模式：db2 update db cfg for <dbname> using logretain of确的步骤进行操作： 􀁺 要求必须使用DB2命令PRUNE进行清理，不建议使用rm命令删除。 􀁺 删除前应保证应用已停止（即联机已下来）。 􀁺 查看当前使用的日志文件目录及第一活动日志文件 􀂾 用 “db2 get db cfg for <dbname>”命令查看日志文件目录（Path to log files）参数，确定数据库当前使用的日志文件目录。例如：Path to log files = /db2log/，说明DB2日志存放目录是/db2log 􀂾 用 “db2 get db cfg for <dbname>”命令查看第一活动日志文件（First active log file）参数，该参数对应的日志文件之前的日志文件均为归档日志文件，如果确认没有用，可以删除。例如：First active log file = S0015913.LOG，说明当前第一活动日志文件是S0015913.LOG。 􀁺 备份好要删除的归档日志 􀁺 删除归档日志以应用用户（如BTP）登录，执行：

DB2系统管理日志管理

1DB2系统管理1.1 DB2 EE及WORKGROUP版本的区别Workgroup版本和EE的区别主要在于两方面：1、并行性workgroup比较差2、主机连接（即和大型机的连接性能上）比较差3、只能用于4个CPU以下的环境。

1.2 怎样判断DB2实例的版本号和修补级别？用db2level命令。

在DB2 5.2及以上版本中，在安装每个DB2实例时，即会装入db2level程序。

db2level命令的输出提供了有关DB2实例的版本及修补级别的详细信息。

命令输出如下所示：DB21085I Instance "" uses DB2 coderelease "" with level identifier"" and informational tokens "", ""and "".例如：DB21085I Instance "DB2" uses DB2 code release "SQL05020"with level identifier "02070103" and informational tokens"DB2 v5.2.0.30","c990717" and "WR21119".下面解释以下这些信息：= DB2 DB2的实例名= SQL05020 Release号05，Version号02，Module号0= 02070103 内部使用的DB2版本号= DB2 v5.2.0.30 实例的版本信息= c990717 代码的级别信息= WR2119 修补的级别信息注：db2level执行程序不能在不同的系统之间拷贝使用。

并且此程序只显示正式支持的修补级别信息。

DB2日常操作规范

DB2日常操作规范DB2是一种关系型数据库管理系统，广泛应用于各种企业级系统中，它的日常操作对于数据库的安全性和性能有很大的影响。

下面是DB2日常操作的规范：一、登录和退出1.不使用默认的管理员账户登录系统，而应该创建并使用具有最低权限的用户账户。

2.每次操作前先登录数据库，操作完成后及时退出数据库。

3.对登录账户进行权限管理，只给予必要的权限，不要滥用特权。

二、备份和恢复1.定期进行数据库备份，备份频率根据系统的重要性和数据的更新频率来确定。

2.备份数据时，应该进行完整备份，同时也可以按需进行增量备份或差异备份。

3.保留足够的备份副本，以便在系统出现故障时能够及时恢复。

4.恢复数据时，应该先进行验证和测试，确保数据的完整性和正确性。

三、数据安全1.对于敏感数据，应该进行加密存储，确保数据在存储和传输过程中的安全性。

2.严格控制数据库权限，并定期审查和更新权限。

3.对于不再需要的账户，应该及时删除或禁用，以防止被滥用。

四、性能优化1.定期进行数据库性能监控，及时发现和解决潜在的性能问题。

2.对于频繁访问的数据表，应该创建适当的索引，以提高查询性能。

3.合理设计数据库的结构和关系，避免冗余和重复数据。

4.控制查询的复杂度，避免不必要的关联查询和高开销的操作。

五、日志管理1.启用数据库的日志功能，在出现故障时能够追踪和恢复数据。

2.定期清理日志文件，以避免占用过多的存储空间。

3.对于关键的操作和数据修改，记录日志以便追溯和审计。

六、事务管理1.使用事务来确保数据的一致性和完整性。

2.在事务处理中，避免锁定过多的资源，以免影响系统的并发性能。

3.对于长时间运行的事务，应该设置合适的超时时间，以防止资源被占用过久。

七、版本管理1.对于数据库结构的修改，应该使用合适的版本控制工具进行管理。

2.在进行结构和数据的修改时，应该先备份数据，以便在出现问题时能够还原。

3.记录每次修改的信息和原因，方便后续追溯和管理。

db2日志维护

db2⽇志维护1、查看数据库配置get db cfg for hdxtdb 查看数据库参数db2 => get db cfg for hdxtdbDatabase Configuration for Database hdxtdb数据库 hdxtdb的数据库配置Database configuration release level数据库配置发⾏版级别= 0x0a00Database release level 数据库发⾏版级别 = 0x0a00Database territory 数据库地域 = cnDatabase code page 数据库代码页 = 1386Database code set 数据库代码集 = gbkDatabase country/region code 数据库国家／地区代码 = 86Database collating sequence 数据库整理顺序 = UNIQUEAlternate collating sequence (ALT_COLLATE) =备⽤整理顺序Dynamic SQL Query management (DYN_QUERY_MGMT) = DISABLE动态 SQL 查询管理Discovery support for this database (DISCOVER_DB) = ENABLE对此数据库的发现⽀持 (DISCOVER_DB)Default query optimization class (DFT_QUERYOPT) = 5缺省查询优化类 (DFT_QUERYOPT)Degree of parallelism 并⾏度 (DFT_DEGREE) = 1Continue upon arithmetic exceptions (DFT_SQLMATHWARN) = NO 在算术异常时继续 Default refresh age (DFT_REFRESH_AGE) = 0 缺省刷新有效期Default maintained table types for opt (DFT_MTTB_TYPES) = SYSTEM缺省维护的选项（DFT_MTTB_TYPES）的表类型Number of frequent values retained (NUM_FREQVALUES) = 10保留的⾼频值的数⽬ Number of quantiles retained (NUM_QUANTILES) = 20保留的分位点数⽬Backup pending = NO备份暂挂Database is consistent = NO数据库是⼀致的Rollforward pending = NO前滚暂挂Restore pending = NO复原暂挂Multi-page file allocation enabled = YES启⽤的多页⽂件分配Log retain for recovery status 恢复状态的⽇志保留 = NOUser exit for logging status = NO⽇志记录状态的⽤户出⼝Data Links Token Expiry Interval (sec) (DL_EXPINT) = 60Data Links 标记到期时间间隔（秒）Data Links Write Token Init Expiry Intvl(DL_WT_IEXPINT) = 60Data Links 写标记初始时间间隔Data Links Number of Copies (DL_NUM_COPIES) = 1副本的 Data Links 数⽬Data Links Time after Drop (days) (DL_TIME_DROP) = 1删除后的 Data Links 时间（天数）Data Links Token in Uppercase (DL_UPPER) = NO⼤写的 Data Links 标记Data Links Token Algorithm (DL_TOKEN) = MAC0Data Links 标记算法Database heap (4KB) 数据库堆（4KB (DBHEAP) = 1200Size of database shared memory (4KB) (DATABASE_MEMORY) = AUTOMATIC数据库共享内存⼤⼩（4KB）Catalog cache size (4KB) (CATALOGCACHE_SZ) = (MAXAPPLS*4) ⽬录⾼速缓存⼤⼩（4KB）Log buffer size (4KB) (LOGBUFSZ) = 512⽇志缓冲区⼤⼩（4KB）Utilities heap size (4KB) (UTIL_HEAP_SZ) = 5000实⽤程序堆⼤⼩（4KB）Buffer pool size (pages) (BUFFPAGE) = 1000缓冲池⼤⼩（页）Extended storage segments size (4KB) (ESTORE_SEG_SZ) = 16000扩充存储段⼤⼩（4KB）Number of extended storage segments (NUM_ESTORE_SEGS) = 0扩充存储段的数⽬Max storage for lock list (4KB) (LOCKLIST) = 40960锁定列表的最⼤存储量（4KBMax size of appl. group mem set (4KB) (APPGROUP_MEM_SZ) = 30000应⽤程序组内存集的最⼤⼤⼩（4KB）Percent of mem for appl. group heap (GROUPHEAP_RATIO) = 70应⽤程序组堆的内存百分⽐Max appl. control heap size (4KB) (APP_CTL_HEAP_SZ) = 128最⼤应⽤程序控制堆⼤⼩（4KB）Sort heap thres for shared sorts (4KB) (SHEAPTHRES_SHR) = (SHEAPTHRES) 共享排序的排序堆域值（4KB）Sort list heap (4KB) (SORTHEAP) = 4096排序列表堆（4KB）SQL statement heap (4KB) SQL 语句堆（4KB） (STMTHEAP) = 2048Default application heap (4KB) (APPLHEAPSZ) = 4096缺省应⽤程序堆（4KB）Package cache size (4KB) (PCKCACHESZ) = (MAXAPPLS*8) 程序包⾼速缓存⼤⼩（4KB）Statistics heap size (4KB) (STAT_HEAP_SZ) = 4384统计信息堆⼤⼩（4KB）Interval for checking deadlock (ms) (DLCHKTIME) = 10000检查死锁的时间间隔（毫秒）Percent. of lock lists per application (MAXLOCKS) = 30每个应⽤程序的锁定百分⽐列表Lock timeout (sec) (LOCKTIMEOUT) = 60锁定超时（秒）Changed pages threshold (CHNGPGS_THRESH) = 60更改的页阈值Number of asynchronous page cleaners (NUM_IOCLEANERS) = 2异步页清除程序的数⽬Number of I/O servers (NUM_IOSERVERS) = 7I/O 服务器的数⽬Index sort flag (INDEXSORT) = YES索引排序标志Sequential detect flag (SEQDETECT) = YES顺序检测标志Default prefetch size (pages) (DFT_PREFETCH_SZ) = AUTOMATIC缺省预取⼤⼩（页）Track modified pages (TRACKMOD) = OFF跟踪修改的页数Default number of containers = 1容器的缺省数⽬Default tablespace extentsize (pages) (DFT_EXTENT_SZ) = 32缺省表空间扩展数据块⼤⼩(页)Max number of active applications (MAXAPPLS) = AUTOMATIC 活动应⽤程序的最⼤数⽬Average number of active applications (AVG_APPLS) = 1活动应⽤程序的平均数⽬Max DB files open per application (MAXFILOP) = 64每个应⽤程序的最⼤打开数据库⽂件数Log file size (4KB) (LOGFILSIZ) = 20000⽇志⽂件⼤⼩（4KB）Number of primary log files (LOGPRIMARY) = 30主⽇志⽂件的数⽬Number of secondary log files (LOGSECOND) = 20辅助⽇志⽂件的数⽬Changed path to log files (NEWLOGPATH) =已更改的⾄⽇志⽂件的路径Path to log files ⽇志⽂件路径 = /home/hdxtdb/db2inst1/NODE0000/SQL00001/SQLOGDIR/Overflow log path (OVERFLOWLOGPATH) =溢出⽇志路径Mirror log path (MIRRORLOGPATH) =镜像⽇志路径First active log file =⾸个活动⽇志⽂件Block log on disk full (BLK_LOG_DSK_FUL) = NO磁盘上已满的块⽇志Percent of max active log space by transaction(MAX_LOG) = 0事务使⽤的最⼤活动⽇志空间的百分⽐Num. of active log files for 1 active UOW(NUM_LOG_SPAN) = 0 1 个活动 UOW 的活动⽇志⽂件的数⽬Group commit count (MINCOMMIT) = 1组落实计数Percent log file reclaimed before soft chckpt (SOFTMAX) = 100软检查点前回收的⽇志⽂件的百分⽐Log retain for recovery enabled (LOGRETAIN) = OFF启⽤的恢复的⽇志保留User exit for logging enabled (USEREXIT) = OFF启⽤的⽇志记录的⽤户出⼝HADR database role = STANDARD HADR 数据库⾓⾊HADR local host name (HADR_LOCAL_HOST) =HADR 本地主机名HADR local service name (HADR_LOCAL_SVC) =HADR 本地服务名称HADR remote host name (HADR_REMOTE_HOST) =HADR 远程主机名HADR remote service name (HADR_REMOTE_SVC) =HADR 远程服务名称HADR instance name of remote server (HADR_REMOTE_INST) =远程服务器的 HADR 实例名HADR timeout value (HADR_TIMEOUT) = 120 HADR 超时值 (HADR_TIMEOUT)HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC HADR ⽇志写同步⽅式 (HADR_SYNCMODE) First log archive method (LOGARCHMETH1) = OFF第⼀个⽇志归档⽅法Options for logarchmeth1 (LOGARCHOPT1) = logarchmeth1 的选项Second log archive method (LOGARCHMETH2) = OFF第⼆个⽇志归档⽅法Options for logarchmeth2 (LOGARCHOPT2) = Logarchmeth2 的选项Failover log archive path (FAILARCHPATH) =故障转移⽇志归档路径Number of log archive retries on error (NUMARCHRETRY) = 5错误时重试⽇志归档次数Log archive retry Delay (secs) (ARCHRETRYDELAY) = 20⽇志归档重试延迟（秒）Vendor options (VENDOROPT) =供应商选项 (VENDOROPT)Auto restart enabled (AUTORESTART) = ON启⽤的⾃动重新启动Index re-creation time and redo index build (INDEXREC) = SYSTEM (RESTART) 索引重新创建时间和重做索引构建Log pages during index build (LOGINDEXBUILD) = OFF在索引构建期间记录页Default number of loadrec sessions (DFT_LOADREC_SES) = 1loadrec 会话的缺省数⽬Number of database backups to retain (NUM_DB_BACKUPS) = 12要保留的数据库备份的数⽬Recovery history retention (days) (REC_HIS_RETENTN) = 366恢复历史保留时间（天数）TSM management class TSM 管理类 (TSM_MGMTCLASS) =TSM node name TSM 节点名 (TSM_NODENAME) =TSM owner TSM 所有者 (TSM_OWNER) =TSM password TSM 密码 (TSM_PASSWORD) =Automatic maintenance ⾃动维护 (AUTO_MAINT) = OFFAutomatic database backup (AUTO_DB_BACKUP) = OFF⾃动数据库备份Automatic table maintenance (AUTO_TBL_MAINT) = OFF⾃动表维护Automatic runstats (AUTO_RUNSTATS) = OFF⾃动 runstatsAutomatic statistics profiling (AUTO_STATS_PROF) = OFF⾃动统计信息概要分析Automatic profile updates (AUTO_PROF_UPD) = OFF⾃动概要⽂件更新Automatic reorganization (AUTO_REORG) = OFF⾃动重组db2 =>修改对应的参数，使⽤命令：update db cfg [fordbname] using <参数名> <参数值>db2 => update db cfg using logretain onDB20000I UPDATE DATABASE CONFIGURATION命令成功完成。

db2日常维护

本文主要介绍数据库管理员（DBA）在日常维护中如何形成自己的维护规范，一个完整的日常维护规范可以帮助DBA 理顺每天需要的操作，以便更好的监控和维护数据库，保证数据库的正常、安全、高效运行，防止一些错误重复发生。

“ DB2 日常维护指南, 第1 部分”具体包括检查管理服务器（DAS）是否启动、检查DB2 实例是否启动、查看表空间的状态是否正常、检查表的状态是否正常、查看磁盘空间是否有异常、查看存储管理软件、数据库备份、日志归档是否正常等。

通过明确日常中的每一天该做什么，形成完善的日常管理维护规范，从而更好对数据库进行维护。

检查管理服务器是否启动DB2 管理服务器（DAS ）是用于辅助DB2 实例上任务的一个控制点，如果想使用DB2 提供的图形化工具（如“控制中心”、“配置顾问程序”等）、工具目录数据库（ToolsCatalog ）、数据库发现等功能，则必须有一个正在运行的DAS 。

DAS 主要有以下功能：1.企业DB2 数据库实例的远程管理。

2.提供用于作业管理的工具，包括调度DB2 数据库管理器和操作系统命令脚本运行的能力，这些命令脚本是用户定义的。

3.使用“任务中心”来对DAS 的远程或本地做到定义作业的安排，查看已完成作业的结果以及执行其他管理任务。

4.与DB2 发现实用程序一起提供一种查找关于DB2 实例、数据库以及其他DB2 管理服务器配置信息的方法。

“配置助手”和“控制中心”使用此信息来简化和自动执行客户机与DB2 数据库的连接配置。

一个数据库物理服务器包括一个管理服务器（Admin Server ）以及一个或多个实例，每个实例( 数据库管理器database manager) 是一个逻辑服务器，可以拥有一个到多个数据库。

每个数据库服务器有且只能有一个DAS ，如果没有DAS ，需要发出dascrt 命令（这个命令只是在UNIX 平台有效，在Windows 平台需要使用“ db2admin create ”命令）或者db2admin create 命令（在windows 和UNIX 平台都可以使用）来创建一个DAS 。

db2数据库日志清理(日志归档)

统计并轨二期部署完成后，数据下行数据量较大，数据库日志增长较快，因此近期需要经常对数据库做日志归档操作，以省局数据库为例步骤如下：1. 以root用户登录数据库服务器（DB2Server）2. 日志归档操作，此操作只能在备份数据库成功之后执行。

如备份不成功，则此部分不能执行。

stma数据库su – db2admindb2 connect to stma user db2admin using db2admindb2 get db cfg | grep -E 'First active log file'记录下首活动日志名S00*****.LOG，之后db2 prune logfile prior to S00*****.LOGdb2 connect resetrone数据库db2 connect to rone user db2admin using db2admindb2 get db cfg | grep -E 'First active log file'记录下首活动日志名S00*****.LOG，之后db2 prune logfile prior to S00*****.LOGdb2 connect resetroeee数据库db2 connect to roeee user db2admin using db2admindb2 get db cfg | grep -E 'First active log file'记录下首活动日志名S00*****.LOG，之后db2 prune logfile prior to S00*****.LOGdb2 connect resetdatacdb数据库db2 connect to datacdb user db2admin using db2admindb2 get db cfg | grep -E 'First active log file'记录下首活动日志名S00*****.LOG，之后db2 prune logfile prior to S00*****.LOGdb2 connect resetstmadc数据库db2 connect to stmadc user db2admin using db2admin db2 get db cfg | grep -E 'First active log file'记录下首活动日志名S00*****.LOG，之后db2 prune logfile prior to S00*****.LOGdb2 connect resetdceii数据库db2 connect to dceii user db2admin using db2admindb2 get db cfg | grep -E 'First active log file'记录下首活动日志名S00*****.LOG，之后db2 prune logfile prior to S00*****.LOGdb2 connect resetdatactr数据库db2 connect to datactr user db2admin using db2admin db2 get db cfg | grep -E 'First active log file'记录下首活动日志名S00*****.LOG，之后db2 prune logfile prior to S00*****.LOGdb2 connect resetdataprov数据库db2 connect to dataprov user db2admin using db2admin db2 get db cfg | grep -E 'First active log file'记录下首活动日志名S00*****.LOG，之后db2 prune logfile prior to S00*****.LOGdb2 connect resetsccmprov数据库(地市为sccmcity)db2 connect to sccmprov user scuser using scuserdb2 get db cfg | grep -E 'First active log file'记录下首活动日志名S00*****.LOG，之后db2 prune logfile prior to S00*****.LOGdb2 connect reset。

db2日志说明

db2日志说明db2日志记录1. 日志的意义：主要在于数据恢复。

Db2实施了提前写日志存档模式，当发出删除、插入或更新数据库中某一数据的SQL调用时，所作出的数据变更首先要写到日志中去。

当发出一条SQL提交确认命令时，DB2首先要把redo所需要的日志写入磁盘。

如果断电的话，所有被提交的事务都会重新做一遍，而未提交的则会rollback。

事务：为了保证数据的可恢复性和一致性引入的概念。

比如执行了两条sql语句，但是他们是为了完成同一件事，因此他们会被当做一个整体。

当发生意外情况时，如果已经commit，但是未写到磁盘，就要执行redo重新执行一遍。

如果还没有commit，就要全部回滚。

日志作用：比如昨天晚上进行了数据库备份，但是今天中午数据库出现了问题（如存储介质损坏）需要恢复，那么只能恢复到昨天晚上的状态，今天上午的数据都没法恢复，这时如果数据库日志没有损坏，就可以通过日记把这段时间的操作重新执行一遍。

2. 日志分为循环日志和归档日志：日志中只记录DML操作（insert，update和delete操作），当我们前台执行了一条insert，update或delete语句，日志中就会相应的记录这条SQL语句的redo操作和undo操作几种操作类型：DDL（Data Definition Language 数据定义语言），用于操作对象和对象的属性（数据库，表，视图等）。

具体表现在Create，Drop 和Alter操作上。

不会对具体的数据进行操作，而是对对象进行操作。

像主键约束、唯一约束、非空约束、外键约束、核查约束和缺省约束这些操作都是使表具有某些特性，所以在这里我认为他们都是表的属性，也属于DDL操作。

DML（Data Manipulation Language 数据操控语言）用于操作数据库对象中包含的数据，也就是说操作的单位是记录。

主要表现在Insert，Delete和Update等操作上。

DB2报“数据库日志已满”问题解决

DB2报“数据库日志已满”问题解决用控制中心直接改会比较容易一点，在数据库名称上点右键-->配置-->日志-->日志文件大小、主日志文件数、辅助日志文件数改大一点。

也可用命令行db2cmddb2 update db cfg for mymakro using LOGFILSIZ 512 --日志文件大小db2 update db cfg for mymakro using LOGPRIMARY 20 --主日志db2 update db cfg for mymakro using LOGSECOND5 10 --辅助日志要将与此数据库的所有连接断开后才会生效。

执行批处理时,DB2 报数据库的事务日志已满的错误,解决办法辅助日志文件的数目(LOGSECOND) = 25已更改的至日志文件的路径(NEWLOGPATH) =日志文件路径= D:\DB2\NODE0000\SQL00003\SQLOGDIR\溢出日志路径(OVERFLOWLOGPATH) =镜像日志路径(MIRRORLOGPATH) =首个活动日志文件= S0000005.LOG磁盘上已满的块日志(BLK_LOG_DSK_FUL) = NO事务使用的最大活动日志空间的百分比(MAX_LOG) = 01 个活动UOW 的活动日志文件的数目(NUM_LOG_SPAN) = 0组落实计数(MINCOMMIT) = 1软检查点前回收的日志文件的百分比(SOFTMAX) = 100启用的恢复的日志保留(LOGRETAIN) = RECOVERY启用的日志记录的用户出口(USEREXIT) = OFFHADR 数据库角色= STANDARDHADR 本地主机名(HADR_LOCAL_HOST) =HADR 本地服务名称(HADR_LOCAL_SVC) =HADR 远程主机名(HADR_REMOTE_HOST) =HADR 远程服务名称(HADR_REMOTE_SVC) =远程服务器的HADR 实例名(HADR_REMOTE_INST) =HADR 超时值(HADR_TIMEOUT) = 120HADR 日志写同步方式(HADR_SYNCMODE) = NEARSYNC第一个日志归档方法(LOGARCHMETH1) = LOGRETAIN logarchmeth1 的选项(LOGARCHOPT1) =第二个日志归档方法(LOGARCHMETH2) = OFFlogarchmeth2 的选项(LOGARCHOPT2) =故障转移日志归档路径(FAILARCHPATH) =错误时重试日志归档次数(NUMARCHRETRY) = 5日志归档重试延迟（秒）(ARCHRETRYDELAY) = 20供应商选项(VENDOROPT) =启用的自动重新启动(AUTORESTART) = ON索引重新创建时间和重做索引构建(INDEXREC) = SYSTEM (RESTART) 在索引构建期间记录页(LOGINDEXBUILD) = OFFloadrec 会话的缺省数目(DFT_LOADREC_SES) = 1要保留的数据库备份的数目(NUM_DB_BACKUPS) = 12恢复历史保留时间（天数）(REC_HIS_RETENTN) = 366TSM 管理类(TSM_MGMTCLASS) =TSM 节点名(TSM_NODENAME) =TSM 所有者(TSM_OWNER) =TSM 密码(TSM_PASSWORD) =自动维护(AUTO_MAINT) = OFF自动数据库备份(AUTO_DB_BACKUP) = OFF自动表维护(AUTO_TBL_MAINT) = OFF自动runstats (AUTO_RUNSTATS) = OFF自动统计信息概要分析(AUTO_STATS_PROF) = OFF自动概要文件更新(AUTO_PROF_UPD) = OFF自动重组(AUTO_REORG) = OFFdb2 => quitDB20000I QUIT 命令成功完成。

DB2事务日志使用详解

DB2事务日志使用详解摘要：我们经常接到客户的电话说数据库日志满了，需要快速清除。

对于一些初入门的DB2使用者去维护一个大数据量的系统，这几乎是他们必然会碰到的一个问题。

碰到这样的问题，我们可以不厌其烦的一遍遍向客户解释这个问题的原因，也可以给出非常明确的解决方案，但是对于很多客户看来，这似乎是一个比较无奈的解决方案，他们只能承担着这种操作带来的系统中断。

因此，对于数据库的设计人员，开发人员和维护人员来讲，非常清楚的了解数据库的日志原理与合理的规划一些操作以避免发生这样的情况是非常重要的！下面，我们就对数据库的日志原理和使用..我们经常接到客户的电话，我的数据库日志满了，有没有什么好办法快速清除?尤其对于一些初入门的DB2使用者去维护一个大数据量的系统，这几乎是他们必然会碰到的一个问题。

我们也经常接到客户更紧急的电话，我的数据库不能使用了，因为日志占用太多空间，文件系统满了，就把日志删除了，现在数据库无法使用，这个是生产系统，需要尽快恢复，有什么办法可以让数据库立刻使用?碰到这样的问题，我们可以不厌其烦的一遍遍向客户解释这个问题的原因，也可以给出非常明确的解决方案，但是对于很多客户看来，这似乎是一个比较无奈的解决方案，他们只能承担着这种操作带来的系统中断。

因此，对于数据库的设计人员，开发人员和维护人员来讲，非常清楚的了解数据库的日志原理与合理的规划一些操作以避免发生这样的情况是非常重要的！下面，我们就对数据库的日志原理和使用中经常遇到的问题以及其解决方法跟大家分享下。

1、DB2数据库的日志原理事务日志记录数据库中所有对象和数据的改变，在早前版本中最大可达256G，其大小为( logprimary + logsecond ) * logfilsiz，其中logprimary + logsecond的值小于或等于256，logfilsiz的最大为262144，在9.5版本中，日志最大已经可以达到512G，其中logfilsz的大小更改为524286。