记一次存储Inode数量引发的生产故障

前一段时间,突然收到了系统报警,某上传服务异常。

经过排查,上传服务正常,但存储无法正常写入,一直写入失败,表现为:
1、一块新盘,32T,已使用2T,可用30T,控制台和命令行操作结果一直
2、服务写入时,一直报“no space left on device”
3、没有收到任何存储报警

立刻找了云服务厂商的老师,解决了问题:
1、除了限制写入文件总量的大小、并发写入的速度,同时还限制了inode数量
2、上传服务,写入了大量小文件,耗尽了inode数量
3、上传服务,再次写入后,inode申请失败,导致写入失败
4、存储组的老师,紧急扩展了inode数量,解决了问题

经排查,云服务商反馈:
1、为了控制成本,我们之前买了一块较小的硬盘,然后进行了扩容
2、而存储的底层协议为FlexGroup
3、而FlexGroup的普通卷,在扩容的时候,只要超过了1T,默认的Inode数量就一直为21251126,不再提升
4、而我们的上传服务,一个小文件只有几百k,很快就把Inode数量耗尽了
5、对于Inode数量限制,云服务商没有提供任何监控

虽然FlexGroup的超大卷默认会提升Inode数量,但我们一开始购买的服务确是普通卷,然后进行扩容,扩容后仍是普通卷,就触发了Inode数量不会自动增加这个问题。

后续,我们做了两个约定:
1、尽量采购超大卷
2、如果要采购普通卷,同时提单,增加Inode数量
3、云服务商同步进行产品更新,后续产品迭代时,从根源上解决这个问题

PS:
最近发现,他们居然做了一个inode扩容的功能,默认是最小值,可以手工扩展,也能设置为自动扩展。
不知道是谁定的需求,默认选项不应该是自动扩展吗?

记一次分布式锁引发的生产问题

近期发版,要修复一个并发引起的主键冲突报警。

运维要求没有此类报警,组里同事顺手就改了。

结果第二天一早服务高峰期,服务直接卡死没有反应了。

快速定位到是这段代码的问题,回滚,解决问题。

然后分析了一下,开发、测试、架构都有问题:

原始逻辑:
1、服务A加了分布式锁L1
2、服务A调用服务B
3、服务B加了分布式锁L2
4、服务B调用数据库服务入库
由于加锁逻辑比较特殊,并发时,会造成主键冲突。

问题逻辑:
1、服务A加了分布式锁L1
2、服务A调用服务B
3、服务B加了分布式锁L1
4、服务B调用数据库服务入库
服务直接卡死,要么服务超时,要么锁超时,服务能不卡死吗

解决问题并不复杂,在这里就不罗嗦了。

问题是很简单,但暴漏的问题十分多:
1、开发对程序逻辑、分布式锁理解明显不够
2、在开发、测试、UAT环境下,开发和测试其实都发现了性能下降的问题,但都没有重视
3、架构和资深开发,代码审核工作问题也很大
其实很多时候,工具是一回事,但人员的专业性思维,其实更重要。

记一次HTTPS授权失败

我们伟大的云提供商告诉我们,他们廊坊机房要关停了,要求我们迁移到其他机房,春节前一定要迁移完毕。

和运维、架构沟通后,做了迁移计划,做了演练,虽然时间仓促,问题特别多,但还是扛过去了。

迁移后,不少用户受到了影响,比如有一个省由于网络供应商问题,整个省的用户无法解析DNS。

这其中,印象最深的是,我们一个用户,服务、配置、权限各种都是正确的。但就是无法登录。

分析了几个小时,最后发现,原来是用户机器时间不对,时差有几个小时,在HTTPS请求到达防火墙时,就被干掉了。

设好时间,一切正常。

其实,之前也遇到过两三次类似问题,频率太低了,一开始根本就没考虑这种可能。

记一次Excutor引发的生产故障

当时看到《阿里巴巴Java编码规范》时,我感觉这里面说的不是大家都该知道的事情吗?真有必要汇总个规范出来?

出来混,总要还的,最近在老项目上就遇到了。

我们有两个服务,遗留项目,代码写的实在是不敢恭维。
用量其实不大,或者说偏小,但很默契的每两周挂一次,到今天是第三次了。

第一次OOM(没定位到根本问题):
K8S网络组件异常,DNS解析失败,和架构一起排查后,发现问题如下:
1、系统原来使用过RabbitMQ,后来代码注释了
2、但POM中,还是有MQ的引用,别的不会做,但会启动MQ的监听
3、结果有一天K8S网络组件异常,DNS解析失败
4、MQ的心跳包瞬间起了几千个线程,连接找不到的MQ Server
5、服务挂了

推断的问题链路为:
DNS无法解析-》MQ心跳包不断起线程,而且没有连接池-》线程耗尽内存-》OOM-》服务挂掉

解决方法:
在POM中,干掉了MQ的引用,以为问题被修复了。

第二次OOM(大意了):
1、表现仍是K8S网络组件异常,DNS解析失败
2、架构感觉容器DNS解析不了应该运维去查
3、只好拉上运维查,运维也比较给力,很快把日志给出来了
4、但是系统OOM时,并没有生成镜像,架构建议添加JVM参数,结果和运维排查后发现JVM参数已经加了,OOM应该有Dump啊
5、最后的结论是,非常规问题,等下次发生再解决
6、这个时候,已经感觉怪怪的了,问题根源根本没有找到啊,但大家都忙着机房搬迁,就没能跟下去(我的问题)

推断的问题链路为:
DNS无法解析-》不断起新线程去连接-》线程耗尽内存-》OOM-》但没有Dump文件-》无法定位问题

解决方法:
碰运气,等下一次OOM生成Dump文件?我当时咋想的呢

第三次OOM(真的解决问题了吗?):
1、感觉不对劲啊,为什么总是两周挂,于是拉取了日志
2、日志上没看出什么来
3、仍然没有OOM的Dump
4、jstack一看线程,傻眼了,一堆线程在waiting on condition
5、赶快看相关源码,居然是用了Excutor,然后线程和队列都是默认的
6、你懂的,线程数和队列默认几乎都是无限的,参数设置错误,导致线程池根本不会服用原来的工作线程
7、服务挂掉是早晚的事情

推断的问题链路为:
DNS无法解析-》不断起新线程去连接-》线程耗尽内存-》OOM-》但没有Dump文件-》无法定位问题

解决方法:
修改Executor默认配置

咋说呢,再次认识到规范强制推行也是必要的,全靠人的个人水平,是不行的。他们的规范,恐怕也是各种坑汇总成的结晶吧。

记一次PG引发的生产故障

前几天,突然收到报修,一个文件接收服务突然宕了。
我们运维同事很快就进行了重启,此时怪异的事情发生了:
重启服务后,服务一会儿就没响应了,端口可以通,文件全部上传失败,没有任何异常日志输出。

那就排查吧:
1、PG数据库连接正常,无死锁,表空间正常,数据查询秒回
2、服务配置几个月都没人改过,CPU、内存、存储、IO、网络,全部正常
3、上传客户端日志输出,显示其工作正常
4、只有文件接收服务,没有响应,也没有日志输出
初步判断,文件接收服务出问题了。

于是,新开一个云主机,重新安装服务,仍然无响应。
然后,拷贝了一个正常工作的主机,修改配置后,仍然无响应。
来来回回折腾了几个小时,还是不行。

无奈之余,试了一下向PG数据库插入数据,我去,几十秒都没有响应。
赶快问DBA,原来是做了高可用,主从库数据同步,从库异常了,导致主库可读不可写。
众人皆表示无奈,重启从库,问题解决。

其实,一开始就排查数据库了,但由于是生产库,只试过查询,没有试过写入。
但是,我们都大意了:
1、服务日志,输出不够详细,就算DEBUG打开,也不知道数据进行到哪一步了,这个最坑
2、没有正确的设置超时时间,原因是接收文件后,写入数据库一直在等待,服务日志没有任何数据库异常
3、数据库监视软件,只做了主库监视,根本没做从库监视
4、数据库主从配置,本应该是异步,但现在配置成了同步
5、没有监视主从库同步的情况
6、生产库,不敢轻易进行写操作,只看了查询效率及死锁,没有看慢语句

就这样一个小问题,绕过了层层监控机制,让问题排查十分困难,花费了大量的人力。
反思起来,如果只是为了记录日志而记录日志,但日志不能反应服务状态,那不如不记;如果只是为了监控而监控,但监控不到位,那不如不监控。
我们日常做事情,也是同样的道理,细节是魔鬼,把该把控的把控好了,才能提升效率,得到想要的结果。

导致惨重代价的Bug

导致惨重代价的Bug

纪念“瞳”解体事件

千年虫事件
在上个世纪,软件行业初期,计算机硬件资源十分昂贵,很多软件为了节省内存会省略掉代表年份的前两位数字”19”,或默认前两位为”19”。按这个规则,1999年12月31日过后,系统日期会更新为1900年1月1日而不是2000年1月1日,这样可能意味着无数的灾难事件,导致数据丢失,系统异常或更加严重的灾难。

幸好大家发现的早,最终全球花了上亿的美元用来升级系统,没有引起毁灭性后果。

水手1号探测器
1962年7月28日,水手1号空间探测器发射升空,但由于程序编码中的轨道计算公式是错误的,导致火箭轨道偏离预定路线。最终在大西洋上空自爆。

南极臭氧层测绘事件
1978年,NASA启动臭氧层测绘的计划。但在设计时,用于该计划的数据分析软件忽略了和预测值有很大差距的数据。直到1985年,才发现南极洲上方的臭氧层空洞,但是英国科学家先发现的。直到NASA重新检测它们的数据,才发现这一错误。在修正错误后,NASA证实南极臭氧层的确有个很大的空洞。

反导系统误报事件
1980年,北美防空联合司令部曾报告称美国遭受导弹袭击。后来证实,这是反馈系统的电路故障问题,但反馈系统软件没有考虑故障问题引发的误报。

1983年,苏联卫星报告有美国导弹入侵,但主管官员的直觉告诉他这是误报。后来事实证明的确是误报。

幸亏这些误报没有激活“核按钮”。在上述两个案例中,如果对方真的发起反击,核战争将全面爆发,后果不堪设想。

辐射治疗超标事件
1985到1987年,Therac-25辐射治疗设备卷入多宗因辐射剂量严重超标引发的医疗事故,其罪魁祸首是医疗设备软件的Bug。据统计,大量患者接受高达100倍的预定剂量的放射治疗,其中至少5人直接死于辐射剂量超标。

AT&T网络终端事件
1990年1月15日,纽约60万用户9个小时无法使用电话服务。原因是,AT&T交换机从故障中恢复后,就会发送一条特殊的小时给临近的设备,但在新版本软件中,这条消息会导致电话交换机重启。于是,每6秒,所有交换机都会重启一次。最后,将程序换回了上一个版本,解决了问题。

宰赫兰导弹事件
在1991年2月的第一次海湾战争中,一枚伊拉克发射的飞毛腿导弹准确击中美国在沙地阿拉伯的宰赫兰基地,当场炸死28个美国士兵,炸伤100多人,造成美军海湾战争中唯一一次伤亡超过百人的损失。

在后来的调查中发现,由于一个简单的计算机bug,使基地的爱国者反导弹系统失效,未能在空中拦截飞毛腿导弹。当时,负责防卫该基地的爱国者反导弹系统已经连续工作了100个小时,每工作一个小时,系统内的时钟会有一个微小的毫秒级延迟,这就是这个失效悲剧的根源。爱国者反导弹系统的时钟寄存器设计为24位,因而时间的精度也只限于24位的精度。在长时间的工作后,这个微小的精度误差被渐渐放大。在工作了100小时后,系统时间的延迟是三分之一秒。

对一般人人来说,0.33秒是微不足道的。但是对一个需要跟踪并摧毁一枚空中飞弹的雷达系统来说,这是灾难性的——侯赛因飞毛腿导弹空速达4.2马赫(每秒1.5公里),这个“微不足道的”0.33秒相当于大约600米的误差。在宰赫兰导弹事件中,雷达在空中发现了导弹,但是由于时钟误差没有能够准确地跟踪它,因此基地的反导弹并没有发射。

Intel奔腾处理器浮点错误
1993年。Intel奔腾处理器在计算特定范围的浮点数除法时,会发生技术错误。Intel最终花费了4.75亿美元来为用户置换处理器。

飞行事故
1993年,瑞典的一架JAS 39鹰狮战斗机因飞行控制软件的Bug而坠毁。

1994年,苏格兰一架吉努克型直升飞机坠毁,29名乘客全部罹难。然而最初指责声都指向飞行员,但后来有证据表明,直升飞机的系统错误才是罪魁祸首。

死Ping
1995-1996年,由于没有进行足够的校验,在收到特殊构造的Ping包时,会导致Windows设备蓝屏并重启。

阿丽亚娜5型运载火箭事件
1996年6月4日,阿丽亚娜5型运载火箭的首次发射点火后,火箭开始偏离路线,最终被逼引爆自毁,整个过程只有短短30秒。(原计划将运送4颗太阳风观察卫星到预定轨道)

阿丽亚娜5型运载火箭基于前一代4型火箭开发。在4型火箭系统中,对一个水平速率的测量值使用了16位的变量及内存,因为在4型火箭系统中反复验证过,这一值不会超过16位的变量,而5型火箭的开发人员简单复制了这部分程序,而没有对新火箭进行数值的验证,结果发生了致命的数值溢出。发射后这个64位带小数点的变量被转换成16位不带小数点的变量,引发了一系列的错误,从而影响了火箭上所有的计算机和硬件,瘫痪了整个系统,因而不得不选择自毁,4亿美元变成一个巨大的烟花。

火星气候探测者号事件
1999年9月,火星气候探测者号在火星坠毁。火星气候探测者号的目的为研究火星气候,花费3亿多美元。探测者号在太空中飞行几个月时间,接近火星时,探测器的控制团队使用英制单位来发送导航指令,而探测器的软件系统使用公制来读取指令。这一错误导致探测器进入过低的火星轨道(大约100公里误差),在火星大气压力和摩擦下解体。

火火星极地登陆者号件
1999年12月,火星极地登录者号在火星坠毁,原因是设计缺陷导致其在达到行星地表之间就关闭了主引擎,最终撞毁。

辐射治疗超标事件
2000年11月,巴拿马美国国家癌症研究所,从美国Multidata公司引入了放射治疗设备及软件,但其辐射剂量计算值有误(软件本身运行医生画四个方块来保护患者健康组织,但医生需要五块,于是医生自己想办法欺骗了软件,殊不知该操作方式将放射剂量进行了加倍处理)。部分患者接受了超标剂量的治疗,至少有5人死亡。后续几年中,又有21人死亡,但很难确定这21人中到底有多少人是死于本身的癌症,还是辐射治疗剂量超标引发的不良后果。

北美大停电事件
2003年8月,由于GE的一个监控软件,没有有效的通知操作人员有一个地方电站断掉了,电力缺口导致了多米诺骨牌效应,最终导致了加拿大安大略州和美国八个州断电,影响到了5千万人,总损失达60亿美元。

丰田普锐斯混合动力汽车召回事件
2005年10月,丰田宣布召回16000辆锐斯混合动力汽车。这次召回的原因是“发动机熄火意外”及“警示灯无故开启”。本次召回的根本原因不是硬件问题,而是汽车嵌入式编程代码的问题。

东京证券交易所事件
2005年12月,J-COM公司上市,开盘价格61.2万日元一股,日本瑞穗证券的一个交易员接到了客户委托“请以61万日元的价格,卖出1股J-Com的股票”。但交易员输入成了“以每股1日元的价格,卖出61万股”。由于交易系统限制,交易系统自动调整为“以57万日元,出售61万股”。

2分钟后,操作员发现操作失误,执行了3次撤单操作全部失败。J-COM股票一路狂跌,瑞穗证券拼命拉高到77.2万日元,仅此一项,瑞穗证券一共损失了约270亿日。但仍引起了很大的连锁效应。

更大的问题是,J-COM的股票一共只发行了14000多股,但卖出去的可远不止这么多。最后经过协商,瑞穗证券用每股91万日元的价格,现金清算了股民手上的9万多股,全部损失,扩大到400多亿日元。

然后瑞穗证券状告东京证券和富士通,官司打了十年。最后判定,以当日瑞穗证券电话联络东京证券的时间点为分界线,之前全部由瑞穗证券承担,之后产生的损失由东京证券承担70%瑞穗证券承担30%。富士通及程序员没有收到罚款。

恩,痛定思痛,决定开始开发了新的交易系统,开发商仍然是富士通。

Gmail故障
2009年2月份Google的Gmail故障,导致用户几个小时内无法访问邮箱。据Google反馈,故障是因数据中心之间的负载均衡软件的Bug引发的。

温州7.23动车事故
2011年7月23日,甬温线浙江省温州市境内,由北京南站开往福州站的D301次列车与杭州站开往福州南站的D3115次列车发生动车组列车追尾事故,造成40人死亡、172人受伤,中断行车32小时35分,直接经济损失近2亿元。

上海铁路局事后反馈,“7·23”动车事故是由于温州南站信号设备在设计上存在严重缺陷,遭雷击发生故障后,导致本应显示为红灯的区间信号机错误显示为绿灯。

骑士资本事件
2012年8月1日,骑士资本的技术人员,在1台设备中部署了错误版本的应用(一共8台,7台正常),该设备触发了n年前的代码,在一个小时内就执行完了原本应该在几天内完成的交易,导致错误的买入卖出,直接将公司推向了破产的边缘,投资人紧急注资4亿美元才得以幸免,最终损失高达5亿美元。

12306订票助手拖垮GitHub
2013年1月15日,GitHub受到中国大陆的DDOS攻击,网站几乎被拖垮。

最后发现,是由于春运期间,各大浏览器厂商集成了一位网友iFish(木鱼)的“订票助手”插件,帮助春运大军抢票回家。但该软件的早期版本,直接引用了GitHub的Raw File而不是静态文件,并且在访问文件失败时,每5S会重试一次。这样,抢票大军的每一个人,没5S都会向GitHub发送一次请求,造成对GitHub的DDOS攻击。

OpenSSL Bleeding Heart漏洞
2014年4月,谷歌和芬兰安全公司Codenomicon分别报告了OpenSSL存在重大缓冲区溢出漏洞。在OpenSSL心跳扩展的源码中,没有去校验缓冲区的长度,导致攻击者可以直接获取网站的私钥信息。这次漏洞的影响面很广,几乎所有厂商都在打补丁和更新私钥及证书。

Twitter丢失400万活跃用户
2015年2月,Twitter在在季度财报中指出,苹果iOS8升级后出现的漏洞让Twitter至少损失了400万用户。首先是iOS8和 Twitter的兼容性问题流失了100万用户,Safari流览器升级后的共用链接功能无法自动升级,这一问题流失了300万用户,另外还有100万iPhone使用者在升级系统后忘记了Twitter密码,导致无法使用而离开了Twitter。

日本天文卫星“瞳”解体事件
2016年03月,日本天文卫星升空不到一个月(仅正常工作3天),就解体了,该卫星造价约19亿人民币,并搭载了多国的观测设备。
首先,由于干扰,追星仪发生了故障,启用了备用的陀螺仪。
但是,陀螺仪也有故障,导致没有旋转的卫星开始加速旋转,并达到阀值。
然后,为了阻止卫星旋转,卫星开始反向喷气,但程序员把喷气的方向搞反了,卫星越转越快,最终解体。

============================================================
注:本文主要是整理了系统Bug导致的惨痛代价,没有记录下面几种情况(设计失败,黑客攻击,病毒爆发)
*从计算机诞生以来,众多失败的软件项目,没有加到列表中
*1982年,苏联天然气管道爆炸事件,涉及植入恶意代码,没有加到列表中

处理windows控制字符0x17

今天同事遇到了很诡异的问题,就是从数据库中读取一个字段时,有些数据中,会多一个0x17的控制字符。

暂时没太好的处理方法,自己写了个测试例子,仅供参考吧:

for java

    public static void main(String[] args)
    {
        byte[] b= { 0x30, 0x30, 0x1f, 0x37, 0x39, 0x33, 0x39, 0x36, 0x34, 0x31 };
        byte[] bt={0x1f};
        String s1 = new String(b);
        String st= new String(bt);
        String s2 = s1.replace(st,"");
        String s3 = s1.replace((char)0x1f,' ').replace(" ","");
        System.out.println(s1);
        System.out.println(s2);
        System.out.println(s3);
    }

for charp

        static void Main(string[] args)
        {
            Byte[] b = { 0x30, 0x30, 0x1f, 0x37, 0x39, 0x33, 0x39, 0x36, 0x34, 0x31 };
            Byte[] bt = {0x1f};
            String s1 = System.Text.Encoding.Default.GetString(b);
            String st = System.Text.Encoding.Default.GetString(bt);
            String s2 = s1.Replace(st, "");
            String s3 = s1.Replace((char) (0x1F), ' ').Replace(" ", "");
            Console.WriteLine(s1);
            Console.WriteLine(s2);
            Console.WriteLine(s3);
            Console.ReadLine();
        }

诡异的dll(2)

还是昨天,还是同一个哥们。他要实现一个语音叫号的功能,要先普通话叫号,然后再粤语叫号。

诡异的事情发生了,在调试状态下,怎么运行都是正常的,
但直接双击运行,只能叫第一种声音(粤语或普通话),另一个声音(粤语或普通话)怎么都发不出来。
悲剧的是,他语音叫号也是调用了一个dll。

只好慢慢调试了,开始以为是线程退出的太快,或者变量作用域问题,或变量中繁体中文乱码问题,或者函数退出太快,或者是release时优化掉了…

弄了一个多小时,没有任何进展。无奈之下,我翻出了Process Explorer,去查看环境变量。
结果调试的时候,第一个环境变量是

__COMPAT_LAYER=WinXpsp3

天啊,这不是兼容模式吗。
于是将exe设成兼容模式,双击运行,就好了。

原来,他用BCB6做开发,在Win7 sp1上无法正常运行,就设成了兼容模式,调试时运行的exe当然也继承了兼容模式的环境变量咯。
吐血啊……

回家,搜了一下__COMPAT_LAYER环境变量,可以设置为以下数值:

兼容性:

值 兼容模式
WIN95 Windows 95
WIN98 Windows 98 / Windows Me
NT4SP5 Windows NT 4.0 (Service Pack 5)
WIN2000 Windows 2000
WINXP Windows XP
WINXPSP2 Windows XP (Service Pack 2)
WINXPSP3 Windows XP (Service Pack 3)
WINSRV03SP1 Windows Server 2003 (Service Pack 1)
WINSRV08SP1 Windows Server 2008 (Service Pack 1)
VISTARTM Windows Vista
VISTASP1 Windows Vista (Service Pack 1)
VISTASP2 Windows Vista (Service Pack 2)
WIN7RTM Windows 7

权限:

值 权限
RUNASADMIN 以管理员权限运行
RUNASINVOKER 以调用者权限运行

显示模式:

值 显示模式
DISABLETHEMES 禁用视觉主题
640X480 用640×480屏幕分辨率运行
HIGHDPIAWARE 高DPI设置时禁用显示缩放
256COLOR 用256色运行
DISABLEDWM 禁用桌面元素

另外,也可以通过注册表,设置程序的兼容模式:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"D:\\TEST\\Hello.exe"="WINXPSP3"
    HKEY hKey;
    LPCTSTR strSubKey = "Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers";
    long lRet = ::RegOpenKeyEx( HKEY_CURRENT_USER, strSubKey, 0, KEY_WRITE, &hKey );
    if ( lRet == ERROR_SUCCESS )
    {
        TCHAR achValue[] = { _T("WINXPSP3") };
        CString strExePath = _T("D:\\Test\\Hello.exe");
        lRet  = ::RegSetValueEx( hKey, strExePath, NULL, REG_SZ, (LPBYTE)&achValue, sizeof(achValue) );
        RegCloseKey( hKey );
    } 

诡异的dll(1)

昨天,和哥们一起调试程序。由于上线压力较大,他最近一直在狂改程序,但遇到了一个问题:

从PACS Server取影像时,怎么都取不回来。

首先排查了PACS Server设置,发现稍微有些问题,修改配置后,我以前写的一个测试程序,
就可以正常取回影像了。

但诡异的事情发生了,我写的程序,可以查,可以取,但他写的就是无法取回影像,只能查询。

吐血啊。

经过了一个小时的奋战,实在发现不了问题,他决定把无线网卡禁用后再测一下,
结果就通了~~

原来他取影像用的是一个dll,估计这个dll中,启用监听的时候,会自动选用某一块网卡,
但刚好选了无线网卡,悲剧啊。

能不能不要自作主张选网卡啊~~
能不能调试的时候,先把不需要的网卡禁用了啊~~

查询视图时不使用索引

今天发生了一件很诡异的事情,平台网关有一张对外提供的视图,用某字段进行查询时,效率奇低无比。

--view
select * from user1.view1 v1 where v1.mark='mark001';
--table
select * from user1.table1 t1 where t1.mark='mark001';

分析视图对应的表信息后发现,虽然对mark字段建立了索引,但查询语句中使用的mark字段值“mark001”,
所占比例竟然已经达到40%,应该是历史数据导致的。

然后将历史数据处理后,重建mark字段索引,诡异的事情发生了:
即使mark字段值“mark001”的比例小于0.1%,查询依然不走索引。

重建索引无效,就差重新建表了,压力山大啊。

最后,休息了一下,抱着试试看的态度,重新分析了表table1:

analyze table user1.table1 compute statistics for table for all indexes for all indexed columns;

查询终于走索引了,速度立刻上去了。

这才记起来,前几天,按某人的建议,把oracle的统计信息关掉了。。。
自己挖坑把自己埋了。。。
四个小时啊。。。
我的考评还没来得及写,还有十几封邮件要写,悲剧啊~~
我恨某潘~~