展开

关键词

突发状况,数据库表,抓瞎了?

背景 在程序员的职业生涯中,总会遇到数据库表的情况,前些天就又撞见一次。由于业务突发需求,各个部门都在批量操作、导出数据,而数据库又未做读写分离,结果就是:数据库的某张表了! 用户反馈系统部分功能无法使用,紧急排查,定位是数据库表,然后进行紧急处理。这篇文章给大家讲讲遇到类似紧急状况的排查及解决过程,建议点赞收藏,以备不时之需。 解决方案 想象一个场景,当然也是软件工程师职业生涯中会遇到的一种场景:原本运行正常的程序,某一天突然数据库的表了,业务无法正常运转,那么我们该如何快速定位是哪个事务了表,如何结束对应的事物? 重启是可以解决表的问题的,但针对线上业务很显然不太具有可行性。 下面来看看不用跑路的解决方案: 第一步:查看表使用 遇到数据库阻塞问题,首先要查询一下表是否在使用。 第二步:查看进程 查看数据库当前的进程,看看是否有慢SQL或阻塞的线程。

6510

如何定位Oracle数据阻塞会话的根源

首先再次明确下,数据库因为要同时保证数据的并发性和一致性,所以操作有等待是正常的。 只有那些长时间没有提交或回滚的事物,阻塞了其他业务正常操作,才是需要去定位处理的。 用户感知就是长时间无法执行成功,很可能还会直接抱怨数据库性能慢。 USERNAME ---------- ---------- ------------------------------ 144 102 JINGYU 这里可以清楚的看到会话149是会话 再次看阻塞的会话操作已经恢复正常。

49510
  • 广告
    关闭

    腾讯云图限时特惠0.99元起

    腾讯云图是一站式数据可视化展示平台,旨在帮助用户快速通过可视化图表展示大量数据,低门槛快速打造出专业大屏数据展示。新用户0.99元起,轻松搞定数据可视化

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    老大说:谁再用redis 的 keys命令,立刻给我走人

    接下来我们看看是什么回事: 最近有好多个项目要迁移了,一般迁移前都会做评估,对现有的业务,资源,关系等等做整理,其中有个项目,在做旧云 与 新云之间的数据源(redis)同步时,同步工具卡死了,新云的数据源竟然报警 于是就想看看它的量有多大,于是就有了下面的操作 redis-cli keys * | args redis-cli del (error) ERR network error (30.00s) 直接30秒超时,并且直接锁住了整个 redis,执行 keys 模糊的匹配命令是为了清理没用的键,但是没有考虑到keys *进行模糊匹配引发 Redis ,造成 Redis 锁住,CPU 飙升,引起了所有调用链路的超时并且卡住,等 Redis 的那几秒结束,所有的请求流量全部请求到 RDS 数据库中,使数据库产生了雪崩,使数据库宕机 那应该怎么办呢,其实有改进方案的 所有线上操作,全部要经过运维通过后方可执行,运维部门逐步快速收回各项权限 切记严重会导致程序的雪崩,删除的时候用SCAN命令,看完这篇文章应该都记住了

    1.9K30

    【DB笔试面试375】当数据对象A事务加上排它,则其它事务对A()

    Q 题目 当数据对象A事务加上排它,则其它事务对A() A、加排它式封锁 B、不能再加任何类型的 C、可以加排它式封锁和保护式封锁 D、加保护式封锁 A 答案 答案:B。 排它又称写(简称X),当事务对数据对象加了X后,则只允许T读取和修改该数据,其它的任何事务都不能再对它加任何类型的,直到事务释放了该数据对象的。 DB笔试面试历史连接 http://mp.weixin.qq.com/s/Vm5PqNcDcITkOr9cQg6T7w About Me:小麦苗 ● 本文作者:小麦苗,只专注于数据库的技术,更注重技术的运用

    9220

    同事埋了个坑:Insert into select 语句把生产服务器炸了!

    由于考虑到会占用数据库I/O,为了不影响业务,计划是9:00以后开始迁移,但是xxx在8:00的时候,尝试迁移了少部分数据(1000条),觉得没啥问题,就开始考虑大批量迁移。 ---- 从上面可以发现一开始能正常插入,但是后面突然就卡住了,并且耗费了23s才成功,然后才能继续插入。这个时候已经迁移成功了,所以能正常插入了。 逐步(扫描一个一个)。 这也就可以解释,为什么一开始只有少量用户出现支付失败,后续大量用户出现支付失败,初始化订单失败等情况,因为一开始只锁定了少部分数据,没有锁定的数据还是可以正常被修改为正常状态。 使用insert into tablA select * from tableB语句时,一定要确保tableB后面的where,order或者其他条件,都需要有对应的索引,来避免出现tableB全部记录锁定的情况

    7610

    同事埋了个坑:Insert into select语句把生产服务器炸了

    由于考虑到会占用数据库I/O,为了不影响业务,计划是9:00以后开始迁移,但是xxx在8:00的时候,尝试迁移了少部分数据(1000条),觉得没啥问题,就开始考虑大批量迁移。 从上面可以发现一开始能正常插入,但是后面突然就卡住了,并且耗费了23s才成功,然后才能继续插入。这个时候已经迁移成功了,所以能正常插入了。 逐步(扫描一个一个)。 这也就可以解释,为什么一开始只有少量用户出现支付失败,后续大量用户出现支付失败,初始化订单失败等情况,因为一开始只锁定了少部分数据,没有锁定的数据还是可以正常被修改为正常状态。 使用insert into tablA select * from tableB语句时,一定要确保tableB后面的where,order或者其他条件,都需要有对应的索引,来避免出现tableB全部记录锁定的情况

    16820

    同事埋了个坑:Insert into select语句把生产服务器炸了

    由于考虑到会占用数据库I/O,为了不影响业务,计划是9:00以后开始迁移,但是xxx在8:00的时候,尝试迁移了少部分数据(1000条),觉得没啥问题,就开始考虑大批量迁移。 ? 从上面可以发现一开始能正常插入,但是后面突然就卡住了,并且耗费了23s才成功,然后才能继续插入。这个时候已经迁移成功了,所以能正常插入了。 逐步(扫描一个一个)。 这也就可以解释,为什么一开始只有少量用户出现支付失败,后续大量用户出现支付失败,初始化订单失败等情况,因为一开始只锁定了少部分数据,没有锁定的数据还是可以正常被修改为正常状态。 使用insert into tablA select * from tableB语句时,一定要确保tableB后面的where,order或者其他条件,都需要有对应的索引,来避免出现tableB全部记录锁定的情况

    1.1K30

    因用了Insert into select语句,码农开除了!

    “ Insert into select 请慎用,同事因为使用了 Insert into select 语句引发了重大生产事故,最后开除。 ? 由于考虑到会占用数据库 I/O,为了不影响业务,计划是 9:00 以后开始迁移,但是 xxx 在 8:00 的时候,尝试迁移了少部分数据(1000 条),觉得没啥问题,就开始考虑大批量迁移。 ? 从上面可以发现一开始能正常插入,但是后面突然就卡住了,并且耗费了 23s 才成功,然后才能继续插入。这个时候已经迁移成功了,所以能正常插入了。 逐步(扫描一个一个)。 这也就可以解释,为什么一开始只有少量用户出现支付失败,后续大量用户出现支付失败,初始化订单失败等情况,因为一开始只锁定了少部分数据,没有锁定的数据还是可以正常被修改为正常状态。

    14520

    Insert into select语句引发的生产事故

    由于考虑到会占用数据库I/O,为了不影响业务,计划是9:00以后开始迁移,但是xxx在8:00的时候,尝试迁移了少部分数据(1000条),觉得没啥问题,就开始考虑大批量迁移。 [insert_data.png] ---- [insert_complete.png]   从上面可以发现一开始能正常插入,但是后面突然就卡住了,并且耗费了23s才成功,然后才能继续插入。 逐步(扫描一个一个)。 这也就可以解释,为什么一开始只有少量用户出现支付失败,后续大量用户出现支付失败,初始化订单失败等情况,因为一开始只锁定了少部分数据,没有锁定的数据还是可以正常被修改为正常状态。 使用insert into tablA select * from tableB语句时,一定要确保tableB后面的where,order或者其他条件,都需要有对应的索引,来避免出现tableB全部记录锁定的情况

    69911

    MySQL 数据库sql命令查询的表实例演示,mysql的表与解锁,mysql强制解锁杀掉进程,mysql查询表一直转圈

    show open tables where in_use > 0 命令可以查询表。 in_use 为 1 表示这个表同时两个用户使用,一个正在用,一个在锁定中。 -- 为md_class表增加个写锁定 lock tables md_class write; -- 查看表 show open tables where in_use > 0; -- 表解锁 unlock tables; 查看表: 特殊情况下的锁定是线程阻塞导致的,查询表都查不出来,一直转圈,即使查询出也无法解锁,需要强制杀掉阻塞的线程。

    27930

    经验分享(2) 一次表空间不足引起的连锁反应

    加表空间数据文件呗, 用的ASM, 还剩好几十T呢, 遗憾的是不行, 因为表空间数据文件加到上限了.... 我实际上是1023个32GB的数据文件, 也就是32T左右, 已经达到上限了. image.png 那咋办呢? 第一反应是迁移表/表分区, 那哪张表呢? 也不知道啊. 那就迁移表吧, 在线迁移还是表迁移? 在线迁移不表, 但是巨慢无比(1T左右大概20+小时), 表迁移好一点, 反正也没得人使用. 最终决定是:把那几张历史表导出来,再删...... 难道是表太大, 数据库太忙,没收集完统计信息旧到点了. no_invalidate => FALSE, degree => 4,granularity => 'AUTO',cascade > TRUE); 也可以用脚本(有需要的可以联系我) image.png 后面再迁移了这个表空间的一些大表

    32610

    因用了Insert into select语句,美女同事开除了!

    由于考虑到会占用数据库I/O,为了不影响业务,计划是9:00以后开始迁移,但是xxx在8:00的时候,尝试迁移了少部分数据(1000条),觉得没啥问题,就开始考虑大批量迁移。 ? 从上面可以发现一开始能正常插入,但是后面突然就卡住了,并且耗费了23s才成功,然后才能继续插入。这个时候已经迁移成功了,所以能正常插入了。 逐步(扫描一个一个)。 这也就可以解释,为什么一开始只有少量用户出现支付失败,后续大量用户出现支付失败,初始化订单失败等情况,因为一开始只锁定了少部分数据,没有锁定的数据还是可以正常被修改为正常状态。 使用insert into tablA select * from tableB语句时,一定要确保tableB后面的where,order或者其他条件,都需要有对应的索引,来避免出现tableB全部记录锁定的情况

    17210

    redis-port支持前缀迁移

    一、介绍 redis-port是一款redis数据迁移工具,用来将数据从一个redis迁移到另一个redis实例/redis集群中 ,以下是官方地址: https://github.com/CodisLabs 我们在生产上迁移了多个redis集群的数据,运行非常稳定。 最近有这么一个场景:只迁移指定前缀的key,因为一个redis集群有好几个应用在用,如果全部都,时间太长,占的内存也比较大。 rdb文件,然后1条1条的向目标redis写入数据; 4、接收主redis发送过来的增量命令,发往目标redis。 再make编译下,可以试下效果: 开两个redis实例,实例A为6379端口,实例B为6380端口,实例A数据如下: ? 执行redis-sync: ? 看下实例B中的数据: ? 可以看到只有order前缀的数据才迁移过来了。

    18220

    springboot项目集成nacos配置中心

    但是我们有一个项目一直搁置了,就是开源的xxl-job项目, 由于我们定时任务一直用的都是xxl-job,并且在源码基础上做过一些小的改动(前边文章里介绍过),这个项目没的原因,一是懒,二是它是一个springboot 项目和常规的springcloud项目迁移还不太一样,springcloud迁移是通过bootstrap.yml文件指定,我当时知道两者方式不太一样, 今天终于有时间把它也迁移了一下。 这个直接上官网下载即可,并且按照步骤,修改自己的数据库配置等。 2. 项目集成,首先就是要依赖jar, 在springboot的配置文件中加入依赖。 <!

    9730

    MySQL行、表、间隙,你都了解吗

    先将自动提交事务改成手动提交:set autocommit=0; 我们启动两个会话窗口 A 和 B,模拟一个抢到,一个没抢到阻塞住了。 我们可以看到 B 窗口不能看到更新后的结果,看到的还是老数据,这是因为 a = 1 的这行记录 A 窗口执行的 SQL 语句抢到了,并且没有执行 commit 提交操作。 这个时候发现,虽然窗口 A 和 B 更新的行不一样,但是窗口 B 还是阻塞住了,就是因为窗口 A 的索引失效,导致行升级成了表,把整个表锁住了,索引窗口 B 阻塞了。 间隙的危害 范围查找时,会把整个范围的数据全部锁定住,即便这个范围内不存在的一些数据,也会被无辜的锁定住,比如我要在 1、3、5、7 中插入 2,这个时候 1-7 都被锁定住了,根本无法插入 2。 这个时候发现窗口 B 更新 a = 2 的操作一直在等待,因为 1~7 范围的数据间隙,锁住了

    36230

    MySQL系列 | 悲观与乐观最佳实践

    开启事务,如果是回滚或者提交事务,会自动释放掉的。按照主键查询该语句,则第二个查询相同主键的的语句会自动解除阻塞(已经释放掉了),查询结果。 窗口2 也开启了事务,查询订单号 :order_no = "S640641911161202555241",查询阻塞,说明 窗口1 把该记录给锁住了(其实这里表已经锁定, 而不是该记录了)。 窗口2 也开启了事务,查询订单号 :id > 511 的记录,查询阻塞,说明 窗口1 把该记录给锁住了(其实这里表已经锁定, 而不是该行住了)。 只要有一个不明确的事务查询存在,则这个表一直是锁定的,太可怕了!!! 四、小结 当执行 select ... for update时,将会把数据锁住,因此,我们需要注意一下的级别。 在实际的实践中,对于并发很高的场景并不会使用悲观,因为当一个事务锁住了数据,那么其他事务都会发生阻塞,会导致大量的事务发生积压拖垮整个系统。

    40510

    【沙龙干货】RDS平台介绍

    为了支持jobcenter的分布式扩展,我们用mysql的任务队列做了一个很轻量级的互斥来达到多任务中心的互斥功能。 RDS系统实现了DBA的一键集群搭建,扩容/缩容,备份还原,流量控制,动态库/拆库,以及单表拆分等功能。我们主要来看看动态数据迁移。 ? 动态库/拆库在可靠性和自动化程度相较之前都有了一个很大的提升。而动态库/拆库主要分为四个步骤:1.种子数据的迁移;2.增量数据迁移;3.账号权限迁移;4.数据源切换。 在切换数据源时,我们采用:校验权限→表→校验数据一致性→切换动态数据源→kill阻塞query→renametable...→resetslave这样一个流程来保证整个流程的安全可靠。 其中对于表,我们必须在一个事务中进行lock tables,数据一致性校验我们采用官方的checksum算法来check每张表的最后1000条数据(1000是我们的一个经验值),然后针对迁移过程中被阻塞的

    86040

    XSS模拟实战训练【XSS Challenges平台】

    "><script>alert(document.domain)</script>< Stage #3 这一道题我们的注入点也是在标签里面,唯一的不同是用于标签构造的<>转义了,用于匹配掉双引号的双引号也转义了 javascript:alert(document.domain) Stage #9 这道题卡住了,暂时没做出来。先用改包的方式绕过。拦截返回的数据包,修改如下: ? 这道题卡住了,暂时没做出来。先用改包的方式绕过。拦截返回的数据包,修改如下: ? script和expression,想用&#num;的形式实体一下其中的字母,但发现&号也移了mmp,然后试了下/**/应该也是可以的,可惜不能复现。 拦截返回的数据包,修改如下: ?

    54620

    XSS模拟实战训练【XSS Challenges平台】

    "><script>alert(document.domain)</script>< Stage #3 这一道题我们的注入点也是在标签里面,唯一的不同是用于标签构造的<>转义了,用于匹配掉双引号的双引号也转义了 javascript:alert(document.domain) Stage #9 这道题卡住了,暂时没做出来。先用改包的方式绕过。拦截返回的数据包,修改如下: ? 这道题卡住了,暂时没做出来。先用改包的方式绕过。拦截返回的数据包,修改如下: ? script和expression,想用&#num;的形式实体一下其中的字母,但发现&号也移了mmp,然后试了下/**/应该也是可以的,可惜不能复现。 拦截返回的数据包,修改如下: ?

    48220

    扫码关注云+社区

    领取腾讯云代金券