ITPub博客

根据前面系列的文章的解释，我们知道PCM资源的Master节点是通过hash算法得出。那么在一个多节点的RAC集群中，数据块请求节点和存放它的相关锁元素信息节点有很大概率是不相同的。这就意味着用户对资源的请求会存在很多的2或3次回路，从而造成很多的消息通信增加私网的负载进而影响影响数据库的性能。为了缓解这种性能影响，Oracle使用资源的remaster来减少资源的跨节点请求。针对某一个数据库对象

在上一期《时区信息记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql系统库中的时区信息记录表，本期我们将为大家带来系列第七篇《复制信息记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！1、复制信息表概述复制信息表用于在从库在复制主库的数据期间，用于保存从主库转发到从库的二进制日志事件、记录有关中继日志当前状态和位置的信息。一共有

PCM锁资源存储方式有两种，1.如果PCM锁属于本地实例，那么它会被存储在本地实例的LE结构中。2.如果PCM锁属于远程实例那么它将会被分配存储在本地实例的共享池中。kclle结构：    kcllerls表示release;     kcllelnm表示 name（id1，id2）;    kcllemode表示 hold-m

在上一期《优化器成本记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql 系统库中的优化器成本记录表，本期我们将为大家带来系列第六篇《时区信息记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！01 时区信息概述MySQL服务器维护几个时区设置：系统时区：当Server启动时，尝试确定主机的时区并使用它来设置Server的syste

在这系列的前两个部分中，我们列举了一些生成或者找回执行计划的方法，也学习了一些额外的步骤可以帮助我们模拟真实的环境来判断执行计划是否存在问题。这部分我们会熟悉整体解释执行计划的基本准则。在第四部分前，我们不用考虑使用谓词的部分。The Shape of a plan我们会从一个简单的例子开始-创建几张表，连接它们，在我们检查执行计划的时候需要回答提出的问题。这里是数据

上一期《统计信息记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql系统库中的统计信息记录表，本期我们将为大家带来系列第五篇《优化器成本记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！01 优化器成本模型概述为了生成执行计划，优化器使用了基于成本的模型来对各种操作成本进行估算。优化器具有一组可编辑的默认“成本常量”（这些值存储在

一致性读请求  ktrget请求调用流程，调用kcbgtcr获取最佳缓存区域用以构建CR缓冲区，然后调用ktrgcm应用undo构建可用的CR缓存。kcbgtcr计算扫描hash桶，调用ktrexf查找最佳缓存区。如果在缓存区域在本地则结束，如果不在本地则调用kcbzib获得缓存区域。kcbzib请求调用kcbzgb获得一个buffer并且设置buffer的状态为Reading

01 背景select into outfile无论对于开发或DBA来说，都是一个爱不释手的导出数据的方式。相比mysqldump，它能够对需要导出的字段做限制，很好的满足了某些不需要导出主键字段的场景或分库分表的环境下数据的重新导入。且与load data infile配合起来，无疑是一款数据导入导出的利器。最近，开发小伙伴在测试环境使用select into file进行数据导出时，碰到了一个

在Part 1中我们了解了两种获取执行计划的方式，第一种是优化器预测它将会怎么执行，通过以下方法查询获取：explain plan for {sql statement} select * from table(dbms_xplan.display);第二种是优化器在我们执行语句后真正的执行路径，通过以下方法查询获取：set&

看懂执行计划是作为处理数据库性能问题的必备技能之一，接下来一系列的文章我会告诉你怎么去做。我们会从一些文章开始讨论几种获取执行计划的方法，并且评估不同来源的执行计划最适合哪种场景。完成上述的内容后我们会继续深入解释简单执行计划的基础，之后会介绍一个用来解释大部分执行计划的规则-需要小心使用该规则。同时也会重点说明因为优化器改写我们的SQL导致执行计划与预期的不符的情况。一些规则外的异常不可避免，所

在本系列的前一期文章中，我制作了一些图，突出显示了按表扫描执行大量删除操作和按索引范围扫描执行大量删除之间的主要区别。根据所涉及的数据模式，选择正确的策略可能对随机I/Os的数量、生成的undo的数量和排序所需的CPU数量产生显著影响——所有这些都可能影响执行删除所需的时间。然而，这个简单的演示跟生产环境当中相比，生产环境当中这个情况更为复杂。所以，如果你面临着一项艰巨的任务，你需要仔细考虑如何对

在本系列的上一部分中，我们研究了在大数据删除表和索引和案例。在这一部分中，我们将继续讨论不同案例所隐含的工作量，然后考虑删除策略，或者需要制定减少工作量的策略。基本开销部分除了时间本身，我们还要关注其它三个指标，即大数据删除的过程中：生成的undo和生成的redo以及发生的I/ O量。这些因素并不是相互独立的，这在优化删除的一般性讨论中引入了很多复杂性，并且删除操作本身可能会影响同时运行的其他会话

在这个简短系列的第1部分中，我提供了两个场景的非正式描述，在这些场景中，我们可以从表中进行大规模删除。没有一个具体的例子,很难想象删除数据的性质和可用的访问路径会产生大数据量删除操作对系统的性能影响,所以我要把大部分的时间花在本文讨论的两个测试生成的数据集。这篇文章似乎有点长但相当多的空间会被表格占用。简单的数据集随着硬件的能力和规模的不断增长，我们越来越难以就“大表”或“大规模删除”的含义达成一

前言我们在日常维护数据库的时候，如果遇到慢语句查询的时候，我们一般会怎么做？执行EXPLAIN去查看它的执行计划？ 是的。我们经常会这么做，然后看到执行计划展示给我们的一些信息，告诉我们MySQL是如何执行语句的。BUT，执行计划往往只给我们带来了最基础的分析信息，比如是否有使用索引，还有一些其他供我们分析的信息，比如使用了临时表、排序等等。我们能从这些信息里面找一些优化点，这样就足够了吗？看看这

toc或许某些人会说MySQL Low，而且乐此不疲，不过，我完全也可以说某些人压根就不会用MySQL，万事万物都具有两面性的，最终结果的好坏还得看是谁在用、怎么用。关于这个问题的争论，相信大家都喜闻乐见了，尤其是数据库界的"郭德纲"的言论尤其精彩，没事听听数据库界的"郭德纲"讲讲故事、讲讲段子，也是一件蛮有意思的事情。说回到大事务，大家或多或少都不太喜欢它

MySQL 执行DDL语句 hang住了怎么办? 不要慌，先点支烟，听我娓娓道来！前两天，早上7点多的时候，抓起手机忽然看到了圈内的一则DDL语句 hang住的案例，阅读到文末，发现文中留有一些疑问（当然，文章是7月份的，现在或许作者已经解决了这些疑问），于是一咕噜从床上爬起来，按照文中的复现方法操作了一遍（复现方法见文末），然后，按照自己的思路解决了该疑问，现在将整个过程整理出来分享给大家。环境

1、故障现象某客户反馈，在利用binlog日志的解析内容做基于时间点的恢复时，出现hang死（超过12小时那种），恢复过程无法继续，而且100%重现基于时间点恢复的实现方式为：使用mysqlbinlog命令指定一个结束时间点，解析binlog并使用管道直接导入数据库中执行（例如：mysqlbinlog binlog_file | mysql -uroot -pxx）对此，我们收集了最基本的一些环境

本文主要介绍Prometheus，从他的来源，架构以及一个具体的例子等方面来说明，以及沃趣围绕Prometheus做了哪些工作。

前两天，无意间看到了林晓斌(丁奇)的一篇文章（详见文末参考链接的第一个），突发好奇心，想从MySQL暴露出来的一些信息上着手，看看能不能直观地看到MySQL 5.7的并行复制到底可以同时执行多少个binlog group(last_committed)的事务，经过一番折腾，将验证过程整理成这篇文章分享给大家。测试验证过程中，使用了两个MySQL版本，如下：MySQL 5.7.22：sysbench

Oracle数据库环境中隔离级别为readcommitted，每个事务都只能看到其他事务已提交的更改和自己未提交的更改。所有关于CR块的统计都可以通过x$bh视图查看。read-commited隔离级别下的有两种可能性：语句级别：查询结果与查询的开始一致（snap_scn=当前SCN）。事务级别：查