1,故障描写叙述: 一条select有两个运行计划.在sqlplus中运行选择好的运行计划.仅仅要40毫秒.而在程序中运行选择了差的运行计划,要1分23秒左右,导致前台业务超时报错. 2.故障解决: 使用outline固定好的运行计划后攻克了该故障. 3,故障发展顺序: (1),早上一上班,说CRM的一个业务报错,crm应用开发者.接口的.tuxdo.dba集中到一起開始诊断错误. (2),业务返回超时错误 (3),数据库这边抓取AWR报告发现例如以下信息: watermark/2/text/a…

问题描述:业务突然变得巨卡 分析思路: (1)分析用户请求进程:查看是否有长期运行霸占锁的情况,或者进程数量巨多.很明显我这里就是巨多,正常情况一般0~40来个的样子,在业务使用高峰期居然达到了140多个.且等待类型大多为WRITELOG与PAGEIOLATCH_SH(参考:https://www.cnblogs.com/gered/p/9359266.html),意思是写日志等待和系统同步资源被占用需要等待共享锁释放(这里个人很明显感觉是因为查询时间太久,共享锁不释放)导致写入.查询等操作被阻…

前言 又和大家见面了!又两周过去了,我的云笔记里又多了几篇写了一半的文章草稿.有的是因为质量没有达到预期还准备再加点内容,有的则完全是一个灵感而已,内容完全木有.羡慕很多大佬们,一周能产出五六篇文章,给我两个肝我都不够.好了,不多说废话了... 最近在线上环境遇到了一次SQL慢查询引发的数据库故障,影响线上业务.经过排查后,确定原因是SQL在执行时,MySQL优化器选择了错误的索引(不应该说是"错误",而是选择了实际执行耗时更长的索引).在排查过程中,查阅了许多资料,也学习了下MySQ…

--需求有变,需要往t_login表的f_userName字段添加外国人名,之前设置的varchar(10)不够,商议决定改成varchar(30),执行的时候,提示消息 索引'uq_f_userName' 依赖于 列'f_userName'.由于一个或多个对象访问此列,ALTER TABLE ALTER COLUMN f_userName 失败.--原来,之前为了防止f_userName重复,添加了唯一索引uq_f_userName.--进行如下操作后,问题妥妥解决--表名:t_login(登…

原文:在Web.Config文件中使用configSource,避免动态修改web.config导致asp.net重启(另添加一个Config文件用于管理用户数据) 我们都知道,在asp.net中修改了配置文件web.config后,会导致应用程序重启,所有 会话(session)丢失.然而,应用程序的配置信息放在配置文件里是最佳选择,在后台修改了配置后导致所有会话丢失是非常不爽的事情,这个时候可将配 置文件中经常需要改变的参数配置节 放到外面来,例如appSetting节. 一.原来的web.…

背景知识: 截至目前,MySQL一共向用户提供了包括DBD.HEAP.ISAM.MERGE.MyIAS.InnoDB以及Gemeni这7种Mysql表类型.其中DBD.InnoDB属于事务安全类表,而其他属于事务非安全类表. DBD    Berkeley DB(DBD)表是支持事务处理的表,由Sleepycat软件公司开发.它提供MySQL用户期待已久的功能--事务控制.事务控制在任何数据库系统中都是一个极有价值的功能,因为它们确保一组命令能成功地执行或回滚. MyIASM MyIASM基于了…

背景知识:MySQL有三种锁的级别:页级.表级.行级. MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking):BDB存储引擎采用的是页面锁(page-level locking),但也支持表级锁:InnoDB存储引擎既支持行级锁(row-level locking),也支持表级锁,但默认情况下是采用行级锁. MySQL这3种锁的特性可大致归纳如下: 表级锁:开销小,加锁快:不会出现死锁:锁定粒度大,发生锁冲突的概率最高,并发度最低.行级锁:开销大,加锁慢:会…

前因 今天检查一个vue页面问题,就是在切换Tab时候(某些win10电脑),页面会卡顿一段很长的时间,短则3秒,长则十几秒,这个体验非常糟糕,于是我着手寻找其中原因. 概况 这个vue页面的元素非常多,主要分为六个Tab内容,切换Tab也只是控制Tab内容的显隐.按道理这是非常简单的行为,不应该出现卡顿的情况. 检查 代码上,我将切换Tab做的一些业务逻辑去掉,只留下控制显隐部分,并打印执行时间. 测试过后发现,即便是这么简单的操作,页面还是会卡顿,从打印的日志上看,我发现了切换的代码很快就执…

5月20号下午4-5点,某项目组进行数据入库作业,作业人员反映入库速度很慢.在16:30和16:50分别采集了快照,并根据两个快照得到AWR报告. 直接看TOP 5 EVENTS,这是数据库问题诊断的最快捷径. 先看占DB TIME达63.33%的direct path read事件.等待次数78586次,等待总时间3833s(约64分钟),而elapsed time只有20分钟.因此我们需要弄清楚是什么动作导致这么高的direct path read. 那什么是direct path read…

今天,某个环境又发生了死锁,如下: *** (1) TRANSACTION:TRANSACTION 735307073, ACTIVE 0 sec insertingmysql tables in use 1, locked 1LOCK WAIT 6 lock struct(s), heap size 1184, 3 row lock(s), undo log entries 1MySQL thread id 2754, OS thread handle 0x7f29cd89a700, quer…