每天都在变化

照片是第7天的调皮的样子。前天8.21，居委会的人过来看了下小孩，长了7两，达到6斤8两了。

新的生命诞生了

2007.8.11 11:18

ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4194], [35], [45], [], [], [], [], []

应用系统捕捉到ora-600错误，查找了相关文档，确认是回滚段的问题，于是创建新的回滚段表空间代替现有的

估计售后工作也做不了多久了，想一想虽然事情很杂很琐碎，成天就是接客户的问题还得做开发做需求，很磨人，但还是学到了一些东西。

售后期间做了两次小的培训

a、沈阳商业城项目（百货单店版）的移交培训；

b、韶关广客隆项目（标准超市版）的移交培训；

锻炼了一下自己的说话能力，天天对着电脑，说话都不会了。

第一次做oracle调优，使日终数据发送、日初批量数据生成等能够正常运行。现在对sql优化有兴趣了，但现实工作这样的调优机会太少，想进步只能慢慢积累了。

1.源数据库exp table1

2.目标数据库truncate table table1。刚开始用了delete语句（table1表有多个源的数据，但每天日终会重发这些数据），汗啊，如果能用truncate就尽量用truncate。

3.目标数据库imp table1（此步进行到2/5时，发现目标数据库马上要shutdwon备份了，再汗一次。马上停止imp，再truncate table table1，在远程机器搞了个计划任务，02:15开始执行imp）

4.今天大早检查执行情况，3:59完成imp，一切ok.

又是一个教训，任务无论繁杂与否难度与否，都需要考虑可能的各种风险，并用最小代价去完成它。

客户总部日初中有个过程每次执行都要花2个半小时甚至更多，影响到业务正常进行，后来以至于影响门店发送数据到总部不完成，POS日初执行不完成（门店和POS是同一台机器）。

此时必须对sql进行优化了。

原语句:

Select JGLMARKET,JGLMFID,jglcatid,JGLSUPID,Sum(jglqmsl) QCSL,Sum(JGLQMHSJJJE) QCJE
From hq_jxcgoodslist
Where jgldate>=add_months(initdate,-6) and jgldate<=initdate-1 and
jglseq
In (select max(jglseq)
From hq_jxcgoodslist
Where jgldate>=add_months(initdate,-6) and jgldate<=initdate-1
group by JGLMARKET,JGLMFID,jglsupid,jglwmid,JGLMD,JGLSHELF,JGLSAMPLE,jglgdid)

第一次优化：

新建中间表rpt_tempjxc_seq1(jglsseq, jglsmarket)，加parallel hint，dbms_stats.gather_table_stats。

1.生成中间表

FOR row_jgl1 IN (SELECT jglseq FROM
(SELECT *+ PARALLEL(hq_jxcgoodslist,4) *jglseq FROM hq_jxcgoodslist
WHERE jgldate >= date1 AND jgldate <= date2 AND
jglmarket = vmkt
GROUP BY jglseq, jglmarket, jglmfid, jglsupid, jglwmid, jglmd, jglshelf, jglsample, jglgdid
ORDER BY jglseq DESC)
WHERE rownum = 1) LOOP
INSERT INTO rpt_tempjxc_seq1 (jglsseq, jglsmarket)
VALUES (row_jgl1.jglseq, vr.mfcode);
END LOOP;

2.查询数据

Select JGLMARKET,JGLMFID,jglcatid,JGLSUPID,Sum(jglqmsl) QCSL,Sum(JGLQMHSJJJE) QCJE
From jxcgoodslist,rpt_tempjxc_SEQ1
Where jgldate >= date1 and jgldate <= date2 and
jglseq = jglsseq and jglmarket = jglsmarket
Group by JGLMARKET,JGLMFID,jglcatid,JGLSUPID)

半小时能搞定。高兴中...

跟踪了一些天，发现这个sql执行时间也越来越长，然后回到优化之前的状态：影响门店发送数据到总部不完成，POS日初执行不完成。

于是有了第二次优化。

充分利用索引，绑定变量。

OPEN cur_jxctemp FOR 'SELECT jglseq FROM
(SELECT /*+ PARALLEL(hq_jxcgoodslist,4) */jglseq FROM hq_jxcgoodslist
WHERE jgldate >= :1 AND jgldate <= :2 AND
jglmfid like :3 AND jglmarket = :4
GROUP BY jglseq, jglmarket, jglmfid, jglsupid, jglwmid, jglmd, jglshelf, jglsample, jglgdid
ORDER BY jglseq DESC)
WHERE rownum = 1' USING date1, date2, vlike, vmkt;
LOOP
FETCH cur_jxctemp INTO l_seq;
EXIT WHEN cur_jxctemp%NOTFOUND OR cur_jxctemp%NOTFOUND IS NULL;

INSERT INTO rpt_tempjxc_seq1 (jglsseq, jglsmarket)
VALUES (l_seq, vmkt);
END LOOP;
CLOSE cur_jxctemp;

最大变化就是jglmfid like :3，where语句中加了这一条

充分利用了IDX_JGL_DTMFID索引，where条件语句中不加此语句和加此语句，执行结果差异非常之大。

不加此语句执行要1000多秒，加此语句100多秒搞定。索引还是很管用，哪怕之前用parallel hint，新建中间表，采集统计信息，用绑定变量，效果都不如利用索引！

IDX_JGL_DTMFID索引语法为

create index IDX_JGL_DTMFID on HQ_JXCGOODSLIST (JGLDATE, JGLMFID)

继续跟踪...

跟踪了几天发现在执行时间慢慢变长，测试发现是因为m201门店goodsbatch每天日终发送数据影响到总部的日初执行(m201门店goodsbatch有近两百条记录)，不是总部日初影响到门店发送数据。后来暂停m201门店的goodsbatch表发送，最近一段时间包括黄金周五一都没有出现总部日初慢或者门店发送数据慢的问题了。

此问题告一段落。

老婆在老家休养，我一个人在武汉。开始觉得没什么，一个人挺好，想game就game，想TV就TV，想出去运动就运动，一个人嘛不用考虑另外一半。慢慢觉得没意思了，上班的锁事太多，售后事情杂七杂八的，慢慢开始疯狂打游戏，打到累的不行了，倒头就睡，第二天掐着时间80:25前一定起床，不然到公司肯定超过9:30了。

慢慢体会到以前我长期出差，老婆一个人在家日子的辛苦了。

由此想到我们公司很多家庭很多人都有这样的经历

...

11:50张森就跑来说去吃饭，他等不及要看比赛了。到了小店，拿着遥控器半天没找到CCTV5，问老板这是湖北有线还是武汉有线吗？她说你想看看武汉有线对，马上跑到墙边把有线换了个口，我们绝倒！一家竟然装了两个有线，强人啊。换成武汉有线后顺利找到CCTV5（因为我家是武汉有线，台的先后顺序很清楚）。

比赛看完了，饭也吃完了（如果比赛没完，估计饭也吃不完，哈哈）。结果不错，98:90，总比分2:0。

2007.03.25 天气晴朗

中午起来，吃了东西。骑着自行车从小区到沿着巡司河、武泰闸体育场（里面有人在踢球，只不过球场还在割草）、随便看了汽渡码头、武船来到江边，在江边洗了下自行车。江边风不错，太阳也不错，江边有钓鱼。返回取道紫阳路、起义门。在武泰闸市场买了点菜、水果回家。往返共花了两小时。

昨晚把窗台清理了下，让师傅安装了白色的大理石，方便以后做清洁，以后可以躺在石头上晒太阳看书看小区的风景什么的。

周六的时候订的灶送过来，但灶台没有打孔（以前用的是非嵌入式灶，现在终于坏了），顺便一起让师傅用切割机切了个孔。灶台不是很宽，石头切换完之后，下面有一点木头要锯，骑着自行车去师傅那拿锯子，木头在孔里面不好下锯，费了九牛二虎之力终于边锯边用锤子锤，搞定。

收拾残局，打扫卫生。切割机弄的到处是灰、几个房间的地板也很脏了。

洗衣服、洗澡

再看时间23:30了，赶紧睡觉！