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日志是以文件的形式存放在文件系统中，分为两种模式：循环日志和归档日志。

当创建新数据库时，日志的缺省模式是循环日志。

在这种模式下，只能实现数据库的脱机备份和恢复。

如果要实现联机备份和恢复，必须设为归档日志模式。

在DB2 UDB 中，脱机备份也是最简单的备份。

脱机备份要求采取完全数据库备份，显然，在备份的过程中，数据库是脱机的。

换言之，当执行脱机备份时，用户无法访问数据库。

如果您正在使用循环日志记录，脱机备份是惟一受支持的备份类型。

当首先创建一个数据库的时候，这是默认的日志记录方法。

对于循环日志记录，log retain for recovery status 和user exit for logging status 都被设为 NO。

LOGRETAIN 和 USEREXIT 两个参数都被设为 OFF。

Log retain for recovery status = NOUser exit for logging status = YESLog retain for recovery enabled (LOGRETAIN) = OFFUser exit for logging enabled (USEREXIT) = OFF目前在综合业务系统中，设置的均是归档日志模式；其它系统（如事后监督、经营决策、中间业务等）一般都设置为循环日志模式。

至于采用何种模式，可以通过修改数据库配置参数（LOGRETAIN）来实现：归档日志模式：db2 update db cfg for using logretain on注：改为on后，查看数据库配置参数logretain的值时，实际显示的是recovery。

改变此参数后，再次连接数据库会显示数据库处于备份暂挂（BACKUP PENDING）状态。

这时，需要做一次对数据库的脱机备份（db2 backup db ），才能使数据库状态变为正常。

案例描述：近日湖北运维反应湖北数据库归档日志生成过快,导致磁盘空间占满，引起数据库宕机。

问题看起来很简单，只要清理下归档日志然后重启就能解决，但这只是治标不治本的方法，显然是要找到归档日志增长异常频繁的原因。

最后通过LogMiner分析归档日志发现是运维部署了频繁update的语句，停了后归档日志变为正常.下面是详细步骤1.通过v$archived_log视图查看最近归档日志状态select to_char(COMPLETION_TIME，’yyyymmdd')， count（*)from v＄archived_log twhere t。

COMPLETION_TIME 〉sysdate — 20group by to_char（COMPLETION_TIME，’yyyymmdd')order by to_char(COMPLETION_TIME, ’yyyymmdd');2.查看今天的归档日志情况，看到8点左右归档日志增长最大select to_char(FIRST_TIME，'yyyymmddhh24')， count（＊)from sys。

v_$archived_log twhere t。

FIRST_TIME 〉 trunc(sysdate）group by to_char（FIRST_TIME，’yyyymmddhh24')order by to_char(FIRST_TIME，'yyyymmddhh24’)3.查看今天八点的归档日志的路径select name， COMPLETION_TIME， t.FIRST_TIME, t.RESETLOGS_TIME from sys.v_＄archived_log twhere to_char(FIRST_TIME，’yyyymmddhh24'） = 2015081108order by t.FIRST_TIME desc；4.打开toad，连接数据库，打开日志分析工具logminer(database→diagnose→logminer)5．点击next6.把第三步得到的归档日志的路径输入file to mine7。

关于DB2常见性能问题的解决参考最近一个项目在做性能测试时，在并发达到一定数后，DB2数据库资源占用很大，必须对数据库和应用进行优化。

该项目要求性能指标（CPU<70%，内存占用<70%，IO<60），按照网友介绍的经验，分别针对CPU、内存、IO进行问题排查和分析。

现将过程总结如下：一、CPU分析通过资源监视器查看一个或多个CPU 的使用率，确定确实存在CPU使用率一直居高不下的情况。

1、首先排除掉存在死循环的情况。

（并发下来后，CPU使用率会降下来）。

2、DB2占用CPU的主要行为有：语句编译、大量排序、DB2实用工具运行。

3、先查看是否有大量的语句编译：通过DB2的表函数MON_GET_WORKLOAD，可以查看到：select varchar(workload_name,30) as workload_name,sum(total_cpu_time),sum(total_compile_proc_time),sum(act_rqsts_total),um(total_compilations),sum(total_act_time), sum(pkg_cache_inserts), sum(pkg_cache_lookups) from TABLE(MON_GET_WORKLOAD('',-2)) as T group by workload_name如果compile_proc_time 高于5-10% 的total_cpu_time，并且pkg_cache_inserts/pkg_cache_lookups 高于4-5%，则数据库在语句编译上花费了太多的时间。

必须调大语句集中器STMT_CONC的大小。

采用逐步调大的方式来跟踪效果。

4、查看是否存在大量的SORT首先通过db2的快照，看是否存在大量的sort溢出✓Sort overflows/Total sorts * 100% 表示排序溢出百分比，通常情况下，该值应该小于3。

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 命令成功完成。

1、l‎o ad 方‎法装入数据‎：ex‎p ort ‎t o te‎m pfil‎e of ‎d el s‎e lect‎* fr‎o m ta‎b lena‎m e wh‎e re n‎o t 清理‎条件；‎l oad ‎f rom ‎t empf‎i le o‎f del‎modi‎f ied ‎b y de‎l prio‎r ityc‎h ar r‎e plac‎e int‎o tab‎l enam‎enon‎r ecov‎e rabl‎e；说‎明：‎在不相关的‎数据表ex‎p ort数‎据时，可以‎采取并发的‎形式，以提‎高效率；‎tabl‎e name‎指待清理t‎a ble的‎名称；‎m odif‎i ed b‎y del‎p rior‎i tych‎a r防止数‎据库记录中‎存在换行符‎,导致数据‎无法装入的‎情况; ‎r epla‎c e in‎t o对现数‎据库中的内‎容进行替换‎，即将现行‎的数据记录‎清理，替换‎为数据文件‎内容；‎n onre‎c over‎a ble无‎日志方式装‎入；2‎、查找当前‎的应用：d‎b2 li‎s t ap‎p lica‎t ion ‎g rep ‎b tpdb‎s;3‎、删除当前‎正在使用的‎a ppli‎c atio‎n:d‎b2 "f‎o rce ‎a ppli‎c atio‎n (id‎1,id2‎,id3)‎"id‎1,id2‎,id3 ‎是list‎显示的应用‎号；4‎、查看当前‎应用号的执‎行状态：‎db2 ‎g et s‎n apsh‎o t fo‎r app‎l icat‎i on a‎g enti‎d 299‎grep‎row‎5、查看‎数据库参数‎：db‎2 get‎db c‎f g fo‎r //当‎前数据库可‎以省略‎6、修改数‎据库的lo‎g数据：‎db2 ‎u pdat‎e db ‎c fg u‎s ing ‎<参数名>‎<参数值‎>7、‎d b2st‎o p fo‎r ce的用‎法：在‎进行bin‎d的时候出‎现如下错误‎：sq‎l0082‎c an e‎r ror ‎h as o‎c curr‎e d wh‎i ch h‎a s te‎r mina‎t ed p‎r oces‎s ing.‎sql‎0092n‎n o pa‎c kage‎was ‎c reat‎e d be‎c ause‎of p‎r evio‎u s er‎r ors.‎sql‎0091n‎b indi‎n g wa‎s end‎e d wi‎t h "3‎" err‎o rs a‎n d "0‎" war‎n ings‎.主要‎是表文件被‎加锁，不能‎继续使用；‎在进行‎s top的‎时候报错：‎d b2st‎o p8‎/03/2‎005 2‎1:46:‎530 0‎sql1‎025nt‎h e da‎t abas‎e man‎a ger ‎w as n‎o t st‎o pped‎beca‎u se d‎a taba‎s es a‎r e st‎i ll a‎c tive‎.sq‎l1025‎n the ‎d atab‎a se m‎a nage‎r was‎not ‎s topp‎e d be‎c ause‎data‎b ases‎are ‎s till‎acti‎v e.‎需要使用如‎下命令可以‎解决这个问‎题： db‎2stop‎forc‎e08‎/03/2‎005 2‎1:47:‎49 0 ‎0 sql‎1064n‎d b2st‎o p pr‎o cess‎i ng w‎a s su‎c cess‎f ul.‎sql1‎064nd‎b2sto‎p pro‎c essi‎n g wa‎s suc‎c essf‎u l.‎然后启动数‎据库db2‎s tart‎,连接数据‎库db2s‎后，重新进‎行bind‎即可。

归档日志满的解决办法
1、适当增大日志目录大小：在文件系统范围内扩容，增加虚拟内存空间；
2、定期删除过期存档：删除归档了一段时间的日志文件。

很多时候，由于不知道日志文件的实际用处，往往采用保守策略，定期删除较早的，周期性的删除；
3、采用刷新覆盖的方式：日志文件非常庞大时可以采用这种方式；
4、采用日志归档工具：比如ELK（Elasticsearch、Logstash、Kibana）等日志归档工具，也可以方便，快捷的实现日志收集整理上报；
5、采用云服务进行日志管理：在云环境上直接安装日志管理工具，可以免去很多日志文件定期清理等负担，让日志收集、整理和分析更加高效便捷。

处理归档日志增加过快一例(2010-08-25 20:03:47)转载▼标签：分类：原创文章oracle归档日志增加过快处理归档日志增加过快一例摘要本文介绍了不久前作者是如何彻底解决一家医院数据库由于归档日志增长过快,导致磁盘剩余空间占满，引起宕机全过程。

通过本案例的描述,我们可以了解到当遇到数据库宕机问题时，应该如何分析现象、找到问题关键、最终彻底解决该问题的一个总体思路，最后还应该深入思考该问题产生的原因，总结出避免以后再出现该问题的建议。

关键字: ORACLE、归档日志、宕机、DML语句初步了解早上一来到公司，XZH就告诉我接到CQ公司的有一个技术申请，大致情况为一家三甲医院，采用Rac+Linux环境，启用了归档模式，但是由于日志增长过快，我们的技术人员设虽然置自动删除归档的任务，但是还是没有避免磁盘空间被占满，已经引起医院2次全院无法使用，虽然CQ公司也安排多名技术人员去现场处理，但是医院认为一直没有解决彻底，因此信息主管对此意见较大，希望公司安排技术支持部现场彻底解决该问题。

通过申请描述，我大致了解到以下几个关键点：1.医院启用了归档，也做了定期自动删除归档日志的任务。

2.由于归档日志增加过快，已经导致医院2号节点宕机。

3.我们的技术人员去了几次，都未彻底解决，用户已经意见很大了。

这只是个初步情况，往往只能了解问题的大概，具体的问题产生的原因还是得到用户那里去才能真正了解，于是立即出发，前往用户处处理问题。

现场分析问题到达医院，同系统管理员互相寒暄了几句，了解大体情况是医院昨天凌晨部分科室反映不能登录导航台，于是系统管理员深夜被叫到医院，查看服务器发现数据库已经宕机，检查磁盘空间，发现其中一个节点的剩余空间为0，于是立即删除部分过去的归档日志，重新启动服务器，下面科室才能够正常登录，谈话间不断听见系统管理员抱怨深夜到医院是如何如何不情愿，看来意见是比较大。

而且同样的问题不久前才出现过一次，当时是中午，询问同去的同事，了解到确实不久前也出现过一次同样的情况，当时认为是归档日志的定期删除保留的日志时间太长，当时保留的是30天的日志，后来改为保留5天的日志，心想不会再出现该问题，没想到还是无法避免。

统计并轨二期部署完成后，数据下行数据量较大，数据库日志增长较快，因此近期需要经常对数据库做日志归档操作，以省局数据库为例步骤如下：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。