posts - 105,&
comments - 18,&
trackbacks - 0
1、DB2数据库的日志原理
事务日志记录数据库中所有对象和数据的改变，在早前版本中最大可达256G，其大小为( logprimary + logsecond ) * logfilsiz，其中logprimary + logsecond的值小于或等于256，logfilsiz的最大为262144，在9.5版本中，日志最大已经可以达到512G，其中logfilsz的大小更改为524286。
DB2数据库的日志分为主日志和辅助日志，其中主日志在第一个连接到达数据库或者数据库被激活后立即分配，而辅助日志在主日志大小不够的时候动态分配。所以需要注意一点，日志所在的文件系统的大小必须大于主日志文件与辅助日志文件的大小之和。
DB2数据库有2种日志配置方式，循环日志与归档日志。
循环日志：这是数据库默认的日志使用方式，主日志用来记录所有的更改，当事务提交后，日志文件会被重用。当主日志文件达到限制时，辅助日志文件将被使用。这种日志方式可以进行崩溃恢复和版本恢复，不能进行前滚恢复，不支持在线备份。
当活动事务的使用空间超过主日志和辅助日志的限制或者日志空间超过磁盘可使用空间，将会得到日志满的错误。
归档日志：启用logarchmetd1、logarchmetd2或打开logretain参数，注意，在9.5版本中，不推荐使用logretain参数，其所有的设置值将被忽略。在数据库归档日志规划时，建议不再使用logretain的方法。日志文件将不会被删除-保持在线或者离线状态。支持前滚恢复和在线备份。
疑问：归档日志下，日志一直保留，持续生成新日志，为什么还会出现日志满的错误?
归档日志下，其可用的活动日志大小依然受到主日志与辅助日志大小之和的限制，所以，即使在归档日志下，日志满的场景与活动日志下是完全一样的。
2、日志使用中的问题与解决方法
在日常使用中，我们遇到最多的问题就是日志满，现在用几个实际的例子来看如何分析和解决日志满的问题，一般的，日志满可以分以下几个场景：
A、 环境准备，并介绍数据库日志使用大小评估方法：
　　数据库参数设置如下：
　　日志文件大小(4KB) (LOGFILSIZ) = 10000
　　主日志文件的数目 (LOGPRIMARY) = 3
　　辅助日志文件的数目 (LOGSECOND) = 2
　　日志总大小为200M.
　　创建测试用表：　
　　C:Documents and Settingsadministrator&db2 "create table test_log(col int, col2 char(10)
　　,col3 timestamp,col4 varchar(100),col5 varchar(100),col6 varchar(100),col7 varch
　　ar(100),col8 varchar(100))"
　　DB20000I SQL命令成功完成。
　　创建插入数据的存储过程：　
双击代码全选
　　C:Documents and Settingsadministrator&db2 -td@ -vf proc_testlog.sql
　　create procedure proc_testlog(v1 int)
　　declare time int default 0;
　　while (time & v1)
　　insert into test_log values(1,'testlog',current timestamp,'testlogtestlogte
　　stlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestl
　　og','testlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestl
　　ogtestlogtestlogtestlog','testlogtestlogtestlogtestlogtestlogtestlogtestlogtestl
　　ogtestlogtestlogtestlogtestlogtestlogtestlog','testlogtestlogtestlogtestlogtestl
　　ogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlog','testlogtestl
　　ogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogt
　　estlog');
　　set time = time + 1;
　DB20000I SQL命令成功完成。
我们来评估下插入使用日志的情况，以便构造日志满的场景，使用db2pd来查看事务日志的使用。
分别打开2个db2cmd会话窗口，在窗口1中我们执行：
　　C:Documents and Settingsadministrator&db2 +c call proc_testlog(1)
　　返回状态 = 0
　　会话2中执行:　
双击代码全选
　　C:Documents and Settingsadministrator&db2pd -db sample -transactions
　　Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:29:20
　　Transactions:
　　Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2
　　Firstlsn Lastlsn LogSpace SpaceReserved TID
　　AxRegCnt GXID
　　0x7FC21A80 7 [000-0 WRITE 0xx00000
　　000 0x 0x 110 700 0x
可以看到这个写操作占用的日志大约为700个字节，在回话1中再重复执行上面的命令，会话2中在看db2pd的输出：　
双击代码全选
　　C:Documents and Settingsadministrator&db2pd -db sample -transactions
　　Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:45:55
　　Transactions:
　　Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2
　　Firstlsn Lastlsn LogSpace SpaceReserved TID
　　AxRegCnt GXID
　　0x7FC21A80 7 [000-0 WRITE 0xx00000
　　000 0xB8 0x06 154
，我们可以这样评估，单个事务每执行一次表插入，插入一行占用的日志约为700字节，在一个事务中，插入多条记录，插入一行记录占用的日志约为634字节，当然，实际上当插入多行时，日志的大小会比计算值略大。
使用这个方法可以根据业务运行情况来评估需要数据库应该配置的日志大小，也可以评估单个大事务需要的日志空间。
根据估算，200M总日志大小，200*5=330781。因此可以一次插入大约33W记录来构造日志满的场景。
B、 事务日志满场景一：当前未提交的事务太大，超过日志的限制。
在会话1中执行：
C:Documents and Settingsadministrator&db2 commit
DB20000I SQL命令成功完成。
提交前面未提交的事务。
C:Documents and Settingsadministrator&db2 +c call proc_testlog(330000)
SQL0964C 数据库的事务日志已满。 SQLSTATE=57011
这时候我打开另外一个session，执行一个不相关的插入操作。
C:Documents and Settingsadministrator&db2 "insert into test values(1112,1,&sdfsdfsdfsdf&,&sdfsdfsdfsdfsdf&,&sdfsdfsdffsdfsd&)
DB21034E 该命令被当作 SQL 语句来处理，因为它是无效的&命令行处理器&命令。在
SQL 处理期间，它返回：SQL0964C 数据库的事务日志已满。 SQLSTATE=57011
可以看到，当日志满的时候其他的任何记日志的操作都将不能进行，所以整个系统基本处于不可用的状态，除非等事务回滚结束。
OK，事务日志满的情况出现，现在我们就根据日志满的日志，来逆向分析是哪个操作导致的该问题，分析步骤如下：
首先，确定哪个应用的事务占用了大量的日志空间：
在回话2中执行：　
双击代码全选
　　C:Documents and Settingsadministrator&db2pd -db sample -transactions
　　Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:02:27
　　Transactions:
　　Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2
　　Firstlsn Lastlsn LogSpace SpaceReserved TID
　　AxRegCnt GXID
　　0x7FC21A80 7 [000-0 WRITE 0xx00000
　　000 0xC 0xFCD0 x
可以看到上面红色部分， AppHandl为7的应用的一个事务占用了大量的日志。如果有多个应用占用了大量的日志，我们可以按照下面的方法逐个分析，看每个应用是执行了什么sql导致的占用如此大的日志。
然后使用db2pd确定这个日志执行了什么语句导致占用了大量的日志：　
双击代码全选
　　C:Documents and Settingsadministrator&db2pd -db sample -applications
　　Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:02:36
　　Applications:
　　Address AppHandl [nod-index] NumAgents CoorEDUID Status C-
　　AnchID C-StmtUID L-AnchID L-StmtUID Appid
　　WorkloadID WorkloadOccID
　　0x7AED0-02 UOW-Waiting 0
　　0 185 1 *LOCAL.DB2.
Application handle为7的应用，对应的L-AnchID为185，L-StmtUID为1。在回话2中继续使用db2pd找到对应的sql语句：
双击代码全选
　　db2pd -db sample -dynamic
　　Dynamic SQL Statements:
　　Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text
　　0x7EA7D540 185 1 1 1 1 1 CALL proc_testlog(?)
对应AnchID为185, StmtUID为1的语句，是CALL proc_testlog(?)，通过上面的分析，我们可以找到，是调用存储过程proc_testlog导致占用了大量的日志，从而找出导致日志满的罪魁祸首。
解决方案：
首先，尽量规避超大事务的操作，对于必须执行的这种大操作，可以考虑是否可以分解成几个事务进行，如果可以，尽量分解为小事务的方式进行;如果业务上不可以分解，是否可以考虑采用不记日志的方式?比如，load代替insert?表针对这个操作，暂时改为不记日志的方式等等。
注意：当进行不记日志的操作时，必须非常清楚这样的操作的影响，比如，归档日志下数据库前滚的影响，hadr与复制的数据同步影响，操作失败结果如何等等。
其次，总有些我们无法预料的操作发生，可能某个维护人员某天发出一个不适当的命令，删除了大量的数据，导致日志满，整个系统无法运行，如何规避这样的操作带来的系统运行影响呢?可以设置参数：max_log和DB2_FORCE_APP_ON_MAX_LOG注册变量。
max_log此参数指示一个事务可以消耗的主日志空间的百分比。该值是为 logprimary 配置参数指定的值的百分比。如果该值设置为 0，那么对一个事务可以消耗的总的主日志空间的百分比没有限制。我们可以配合设置DB2_FORCE_APP_ON_MAX_LOG注册变量来规定如果应用程序违反了 max_log 配置，我们对该应用如何处理，DB2_FORCE_APP_ON_MAX_LOG设置为true，则超过max_log的应用回被强制与数据库断开连接，事务将被回滚，并且将返回错误 SQL1224N。如果 DB2_FORCE_APP_ON_MAX_LOG 注册表变量设置为 FALSE，则违反了max_log设置的的事务将失败，并返回错误 SQL0964N。该应用程序仍然可以提交在工作单元中由先前语句完成的工作，它也可以回滚已完成的工作以撤销该工作单元。
通过次设置我们可以保证即使有大事务操作，总有(1-max_log/100)*log_primary+log_second的日志可以用来处理日常交易，从而避免系统中断。
注意： 由 max_log 配置参数施加的限制不适用于下列 DB2 命令：ARCHIVE LOG、BACKUP DATABASE、LOAD、REORG TABLE(联机)、RESTORE DATABASE 和 ROLLFORWARD DATABASE。
C、 事务日志满场景二：某个事务一直未提交，占用的日志不能被重用，导致日志满
现在看另外一个场景，我在一个会话中执行了如下命令：
　　C:Documents and Settingsadministrator&db2 +c call proc_testlog(3)
　　SQL0964C 数据库的事务日志已满。 SQLSTATE=57011
显然，数据库日志已满，于是，根据上面的方法，我找是哪个事务占用了日志。
双击代码全选
　　C:Documents and Settingsadministrator&db2pd -db sample -transactions
　　Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:10:12
　　Transactions:
　　Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2
　　Firstlsn Lastlsn LogSpace SpaceReserved TID
　　AxRegCnt GXID
　　0x7FC21A80 12 [000-0 READ 0xx00000
　　000 0x 0x 0 0 0xA9
　　0x7FC0-0 READ 0xx00000
　　000 0x 0x 0 0 0xF
　　0x7FC0-0 READ 0xx00000
　　000 0x 0x 0 0 0xBE
　　0x7FC0-0 READ 0xx00000
　　000 0x 0x 0 0 0x
　　0x7FC24E80 16 [000-0 READ 0xx00000
　　000 0x 0x 0 0 0x
　　0x7FC25B80 17 [000-0 WRITE 0xx00000
　　000 0xB7 0x5 184 408 0xA
很奇怪，从结果显示，我没有发现任何一个占用大量日志的应用程序，日志的使用显然都非常的小，那为什么日志还会满呢?我们再注意下占用日志的应用，查看下各自使用的日志文件。
双击代码全选
　　C:Documents and Settingsadministrator&db2pd -db sample -logs
　　Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:12:34
　　Current Log Number 4
　　Pages Written 9498
　　Method 1 Archive Status n/a
　　Method 1 Next Log to Archive n/a
　　Method 1 First Failure n/a
　　Method 2 Archive Status n/a
　　Method 2 Next Log to Archive n/a
　　Method 2 First Failure n/a
　　Address StartLSN State Size Pages Filename
　　0x7FBECBD4 0x0 0x00 10.LOG
　　0x7FBECC74 0x00 0x00 11.LOG
　　0x7FBECD14 0x 0x00 12.LOG
　　0x7EABB2F4 0x0 0x00 13.LOG
　　0x7EABB394 0x 0x00 14.LOG
分析发现，这个占用日志的应用的日志开始lsn为0xB7，结束lsn为0x5，正好落在第一日志文件中，因为这个事务一直没有被提交，所以S0000000.LOG一直不能被重用，这样业务在将主日志和辅助日志用完后，无法重新开始使用日志文件，导致出现日志满的错误。同样，使用上面的方法，我们可以查找出这个Applications handle为7的一直没有提交的小事务执行的是什么操作。
　　上面的情况模拟方法：
　　在一个回话中执行一个小事物，比如
　　C:\Documents and Settings\administrator&db2 +c "insert into test values ( 1112,1, &sdfsdfsdfsdf& , &sdfsdfsdfsdfsdf& , &sdfsdfsdffsdfsd& )
　　在另外一个回话中执行占用事务比较大的操作，比如：db2 call proc_testlog(300000)，在这个回话中的操作都及时提交，直到配置的日志文件被使用完，再执行小操作db2 call proc_testlog(3)，就可以出现上面的日志满的情况。
　　解决方案：
　　可以看出，不是日志满的问题一定是由于应用占用大量的日志导致的，一个被忽略的未提交的操作也可能导致系统的日志无法被重用而导致日志满，在应用中，这是我们应该尽量避免的。但是总是如果无法保证所有的操作都及时的提交，我们可以设置num_log_span参数来规避这个问题，参数指定是否对一个事务可以跨越多少个日志文件具有限制以及该限制是多少，当设置这个参数后，未提交的事务所在的日志与当前日志跨越的个数超过这个值，将被中断，从而避免事务长时间存在导致系统日志满。另外大事务可以跨越的日志也不能超过这个限制，所以当设置max_log和num_log_span后，一个事务所可以使用的事务日志将取2者中比较小的值。
　　当启用了无限活动日志空间时，max_log和 num_log_span 配置参数非常有用。如果打开了无限记录(即，logsecondary 为 -1)，那么事务数不受日志文件数的上限(logprimary + logsecond)限制。当到达 logprimary 的值时，DB2 将开始归档活动日志，而不是使事务失败。这样可能会导致问题，例如，有一个长期运行的事务，但一直未落实它(可能是由于应用程序不正确导致的)。如果出现这种情况，那么活动日志空间会不断增长，从而可能使得崩溃恢复性能很差。为了防止这样，可以为 max_log 和/或 num_log_span 配置参数指定值。
　　注意：系统临时表的使用，系统临时表的数据操作是不记日志的，但是表的定义是有少量日志记录的，所以，临时表定义了一直没操作，不提交也可能会引起部分小日志的一直被占用。
阅读(...) 评论()温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
自信、激情、真诚
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
1.日志文件不够& & &总共日志大小为：（ LOGPRIMARY + LOGSECOND ）* LOGFILSIZ * 4KB&，其中4KB为数据页，不同数据库设置的数据页可能不一样。& & &对一个表进行全表update时候，占用的最大事务空间约为表大小的2倍。这主要是事务日志记录了两种方式，do和redo。例如一张task表大小为160M，全表update时候所用到的最大日志空间约为320M。& & &如果觉得日志空间不够，可以用 db2&update db cfg for &dbname& using &p& &v&。例如要更改主日志大小：db2 update db cfg for &dbname& using logprimary 30.2.应用程序占用很大事务日志并且没有提交，造成后续操作不能重用日志。& &针对这样相似的问题，我们通常先找到应用程序的ID,然后将应用程序停掉。2.1用快照方式获取应用程序使用日志情况。&例如：&(1).打开监控开关:db2 update monitor switches using statement on uow on&(2).获取数据库快照:db2 get snapshot for database on& &dbname&。找到快照中日志空间使用部分：Log space available to the database (Bytes)= Log space used by the database (Bytes) & & = 5061Maximum secondary log space used (Bytes) & = 0Maximum total log space used (Bytes) & & & = 12255Secondary logs allocated currently & & & & = 0Log pages read & & & & & & & & & & & & & & = 0Log read time (sec.ns) & & & & & & & & & & = 0.Log pages written & & & & & & & & & & & & &= 6Log write time (sec.ns) & & & & & & & & & &= 0.Number write log IOs & & & & & & & & & & & = 6Number read log IOs & & & & & & & & & & & &= 0Number partial page log IOs & & & & & & & &= 5Number log buffer full & & & & & & & & & & = 0Log data found in buffer & & & & & & & & & = 0Appl id holding the oldest transaction & & = 136Log to be redone for recovery (Bytes) & & &= 4923Log accounted for by dirty pages (Bytes) & = 4923File number of first active log & & & & & &= 0File number of last active log & & & & & & = 2File number of current active log & & & & &= 0File number of log being archived & & & & &= Not applicable&从快照信息中我们可以看到最后使用日志的应用程序的ID，如上图红色部分所示，即最后的应用程序的ID为136.&(3).获取应用程序的使用日志的详细信息。& db2 list applications& uth Id &Application & &Appl. & & &Application IdDB & & & # of& & & & &Name & & & & & HandleName & &Agents-------- -------------- ------------------------------------------------------------------------ -------------E91Q3A & db2bp & & & & &136 & & & &*LOCAL.e91q3a.db2 " get snapshot for application&applid *LOCAL.e91q3a."&& & & & & & & & & & & & & & & & & & Application SnapshotUOW log space used (Bytes) & & & & & & & & = 270Previous UOW completion timestamp & & & & &= 04/09/:57.581923Elapsed time of last completed uow (sec.ms)= 0.465833UOW start timestamp & & & & & & & & & & & &= 04/09/:25.545220UOW stop timestamp & & & & & & & & & & & & =UOW completion status & & & & & & & & & & &=(4)停止没有提交的应用程序。db2 "force application(136)"就这四步搞定，呵呵！2.1使用db2pd来分析事务(1).db2pd -db sampe &-transactions/applications(2).db2pd -db sample -dynamic查看是哪个SQL占据了大量的日志。
阅读(5362)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
在LOFTER的更多文章
loftPermalink:'',
id:'fks_',
blogTitle:'解决DB2数据库事务日志已满问题',
blogAbstract:'& & & 在使用DB2进行大量的update,insert,import的操作时候，事务日志可能会用光,即日志文件不够，还有一种情况是应用程序占用了很大的事务并且没有提交，造成后续应用不能重用日志，导致日志满。针对上面两个问题，给出的解决方案如下:1.日志文件不够& & &总共日志大小为：（ LOGPRIMARY + LOGSECOND ）* LOGFILSIZ * 4KB',
blogTag:'db2事务日志已满,db2报错sqlstate57011,db2事务日志满,db2日志满解决办法',
blogUrl:'blog/static/',
isPublished:1,
istop:false,
modifyTime:0,
publishTime:6,
permalink:'blog/static/',
commentCount:1,
mainCommentCount:1,
recommendCount:0,
bsrk:-100,
publisherId:0,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:false,
hostIntro:'自信、激情、真诚',
hmcon:'1',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}db2 delete 大表不写日志方法_数据库技术_Linux公社-Linux系统门户网站
你好，游客
db2 delete 大表不写日志方法
来源：Linux社区&
作者：warden2010
最近由于项目需要，用shell程序批量删除业务表数据，但还需要按业务需求保留业务历史数据，由于项目中用的是db2,db2在删除数据时会产生大量的日志，会把日志文件充满，会报57011错误.通过在网上查找一些资料，最终在不改变原表结构参数的基础上，减少其他们人员的工作量的基础上动态调整参数。
以下为具体操作步骤：
-- db2 delete 大表不写日志操作1.update command options using c off& -- //关闭自动提交 2.alter table MARPT.RPT_DIM_U_ORG_INX_M_CURR_CUS_PRO_TBK& activate not logged initially //设置不记日志 3.delete from MARPT.RPT_DIM_U_ORG_INX_M_CURR_CUS_PRO_TBK -- 删除数据<mit//手动提交 5.update command options using c on//打开自动提交
相关操作说明;
1.alter table testdeletetab ACTIVATE& NOT& LOGGED& INITIALLY，设置表操作不记日志，这条命令只在一个事务里有效，遇到commit之后就失效了，这个很需要关注，因为有的时候我们的连接都是设置的自动提交，所以虽然设置了不记日志，但是并没有起到作用。
2.可以通过相关的命令查看当前命令参数
db2 list command options
下边为相应的shell脚本，可以参照一下
. /home/odr1/.profile#ODS RUN ALL GDBMA JOBS#GDBMA##删除表参数WORK_DATE=$2TAB_NAME=$1#SYSNAME=GDBMAif [ "$TAB_NAME#" -eq "#" ]then echo "the job do not delete the table data!! "else MADS_HOME=/home/odsuser1/gdbma/etl#DS ConfigDSConfigFile=$MADS_HOME/dsconfig_gdbma#MARPT ETL2数据库#DBDBNAME=`awk 'FS="=" {if ($0~/^MARPTDBName/) print $2}' $DSConfigFile`DBUSR=`awk 'FS="=" {if ($0~/^MARPTDBUser/) print $2}' $DSConfigFile`DBPWD=`awk 'FS="=" {if ($0~/^MARPTDBPassword/) print $2}' $DSConfigFile`DBSCHEMA=`awk 'FS="=" {if ($0~/^MARPTDBSchema/) print $2}' $DSConfigFile`
DBPWD=`$MADS_HOME/Encrypt/discrypt.sh $DBPWD`
dbname=$DBNAMEuser=$DBUSRpasswd=$DBPWD#连接数据库db2 connect to $DBNAME user $DBUSR using $DBPWD &/dev/nulldb2 set schema=$DBSCHEMA;ssql="SELECT SCHEDULE,KEEP_DATE,SCH_NAME,TAB_DATE,NO_LOG& from "$DBSCHEMA".S_TAB_INFO where tab_name='"$TAB_NAME"' "SDATA=`db2 -t "$ssql"`if [ $? -eq 0 ]thenecho " the job drop data start!"elseecho "this query false!!!"fiecho "$SDATA"& | sed -e '4,/^$/!d;/^$/d'|#循环读取job，然后调度while read SCHEDULE KEEP_DATE SCH_NAME TAB_DATE NO_LOGdoecho "$NO_LOG"if [ "$NO_LOG" = 'Y' ] &&&&& then &&&&&&&&& #参数调整(取消自动提交）&&&&&&&&& COMMIT_OFF=`db2 -a "update command options using c off"`& &&&&&&&&& #激活不写日志&&&&&&&&& LOG_OFF=`db2 -a "alter table "$DBSCHEMA"."$TAB_NAME"& activate not logged initially"`& &&& # 清数据开始&&& if [ "$SCHEDULE" = 'M' ]&&&&&&& then &&&&&&& if [ "$KEEP_DATE" = 1 ]&&&&&&&&&&& then &&&&&&&&&&& delete_table="delete from "$DBSCHEMA"."$TAB_NAME" "&&&&&&& else &&&&&&&&&& v_tx_date=`db2 -x "select& DATE(SUBSTR(varchar(date('"$WORK_DATE"')),1,8)||'01') -(int(trim('"$KEEP_DATE"'))-2) MONTHS -1 DAYS from sysibm.sysdummy1 "`&&&&&&&&&& echo "$v_tx_date"&&&&&&&& delete_table="delete from "$DBSCHEMA"."$TAB_NAME" where date("$TAB_DATE") = date('"$v_tx_date"')"&&&&&& fi&&& fi&&& &&& if [ "$SCHEDULE" = 'D' ]&&&&&&& then &&&&&&& if [ "$KEEP_DATE" = 1 ]&&&&&&&&&&& then &&&&&&&&&&& delete_table="delete from "$DBSCHEMA"."$TAB_NAME" "&&&&&&& else &&&&&&&&&&& v_tx_date=`db2 -x "select date('"$WORK_DATE"') -(int(trim('"$KEEP_DATE"'))*31) days from sysibm.sysdummy1 "` &&&&&&&&& delete_table="delete from "$DBSCHEMA"."$TAB_NAME" where date("$TAB_DATE") = date('"$v_tx_date"')"&&&&&& fi&&& fi&&& DELDATA=`db2 -a $delete_table`&&&&&&&& echo "$DELDATA" |& sed -n -e 's/^.*sqlcode: \([-,0-9][0-9]*\).*/\1/p' |& read SQLCODE&&&&&&&& if [ $SQLCODE -ge 0 ]&&&&&&&&& then &&&&&&&&& echo "the job delete table sucessfull"&&&&&&&& else&&&&&&& echo "the job delete table false"&&&&&&&& fi&&& &&&& #提交&&&&&& COMMIT_DATE=`db2 -a "commit"` &&&&&& #设置自动提交&&&&&& COMMIT_ON=`db2 -a "update command options using c off"` else &&&& if [ "$SCHEDULE" = 'M' ]&&&&&&& then &&&&&&& if [ "$KEEP_DATE" = 1 ]&&&&&&&&&&& then &&&&&&&&&&& delete_table="delete from "$DBSCHEMA"."$TAB_NAME" "&&&&&&& else &&&&&&&&&&& v_tx_date=`db2 -x "select ( DATE(SUBSTR(varchar(date('"$WORK_DATE"')),1,8)||'01') -(int(trim('"$KEEP_DATE"'))-2) MONTHS -1 DAYS)& from sysibm.sysdummy1"`& &&&&&&&&& delete_table="delete from "$DBSCHEMA"."$TAB_NAME" where date("$TAB_DATE") = date('"$v_tx_date"')"&&&&&& fi&&& fi&&& &&& if [ "$SCHEDULE" = 'D' ]&&&&&&& then &&&&&&& if [ "$KEEP_DATE" = 1 ]&&&&&&&&&&& then &&&&&&&&&&& delete_table="delete from "$DBSCHEMA"."$TAB_NAME" "&&&&&&& else &&&&&&&&&& v_tx_date=`db2 -x "select date('"$WORK_DATE"') -(int(trim('"$KEEP_DATE"'))*31) days from sysibm.sysdummy1 "` &&&&&&&& delete_table="delete from "$DBSCHEMA"."$TAB_NAME" where date("$TAB_DATE") = date('"$v_tx_date"')"&&&&&& fi&&& fi&&& DELDATA=`db2 -a $delete_table`&&&&&&&& echo "$DELDATA" |& sed -n -e 's/^.*sqlcode: \([-,0-9][0-9]*\).*/\1/p' |& read SQLCODE&&&&&&&& if [ $SQLCODE -ge 0 ]&&&&&&&&& then &&&&&&&&& echo "the job delete table sucessfull"&&&&&&&& else&&&&&&& echo "the job delete table false"&&&&&&&& fifi
相关资讯 & & &
& (06/20/:37)
& (10/07/:24)
& (09/09/:38)
& (10/27/:32)
& (09/14/:02)
& (08/21/:21)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款