ITPub博客

在计算机的世界里，我们可以将业务进行抽象简化为两种场景——计算密集型和IO密集型。这两种场景下的表现，决定这一个计算机系统的能力。数据库作为一个典型的基础软件，它的所有业务逻辑同样可以抽象为这两种场景的混合。因此，一个数据库系统性能的强悍与否，往往跟操作系统和硬件提供的计算能力、IO能力紧密相关。

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

我们为什么要删除大量的数据？我们是否知道在删除操作完成后我们又需要如何验证我们是否到达最终目标？我们可以使用哪些方法来最小化的执行删除所带来的影响以及删除完成之后我们还需要做什么才能达到最终的目标？

前面的章节我们介绍了Oracle为实现Cache Fusion引入的各种改变和新的概念。本节我们从RAC环境中可能发生的场景对Oracle Cache Fusion的实现进行更近一步的探讨。

分享两个比较有意思的问题给大家：一个是在执行ALTER TABLE ADD COLUMN语句时，报了Duplicate entry的错误；另一个是关于在MySQL中正确存取emoji表情的问题。

死锁检测OracleRAC的死锁检测在多层完成，并且是由超时机制驱动。-ksq解决本地死锁问题。-kjd解决全局死锁问题。-消息流量控制器（TRFC）预防消息的死锁问题。在生产环境中涉及的资源和锁的数量非常多，因此查找是否存在死锁可能非常耗时消耗系统资源。因此，当有进程发生长时间的等待时，系统会认为

本期我们将为大家带来系列第三篇《元数据记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧。

案例演示场景：双节点RAC环境下，三个不同的会话访问同一张表T：1.P1申请表的共享模式锁。2.P2申请表的共享模式锁。3.P2执行回滚操作。4.P1申请表的独占模式锁。5.P3申请表的共享模式锁。6.P1执行回滚操作。第1-2步：核心流程在步骤1中，P1将表锁定在共享模式下。在步骤2中，P2在共享

Oracle研发工程师为了保证Cache Fusion的各个实例一致性使用了超过70种的队列锁,12.2版本有超过90种队列。

某客户反馈，在利用binlog做基于时间点的恢复时，频繁出现无法正确恢复数据的情况（出现概率大约5%~10%），这是为啥呢？

通过前面系列文章我们知道GRD或DLM是由GES组件和GCS组建组成，而这些功能的进程（LMON、LMS、LMD等）实现我们也有了大致的了解。现在我们来更进一步的了解这些进程的函数实现和参数调整。

分布式数据库技术论坛2019年06月29号在杭州市滨江区智汇中心的11楼准时召开，与会的相关人员积极参与，一起聆听了来自PlanetScale、阿里巴巴、Pivotal、沃趣科技的分布式数据库相关议题并进行了热烈的探讨。

6月29日（本周六），原Google的工程师、阿里云PolarDB For PG的工程师、Pivotal的资深产品经理、QFusion的产品经理给大家分享一下分布式数据库的最近进展和趋势

众所周知，出于产品的开发需求，搭建测试数据库是DBA一项日常工作，不同的行业频度可能差异很大。本文就来探讨探讨，如何降低这项工作的耗时，将原本一天的工作量降低为5分钟。

本篇主要通过针对同一业务场景，基于编程范式的概念，核心原理以及用例实现来对比不同范式及其实现业务功能的差异。

在写代码的日常中,if...else语句是极为常见的。正因其常见性,很多同学在写代码的时候并不会去思考其在目前代码中的用法是否妥当。而随着项目的日渐发展,糟糕的if...else语句将会充斥在各处,让项目的可维护性急剧下降。故在这篇文章中,笔者想和大家谈谈如何避免写出糟糕if...else语句。

Kubernetes 存储子系统已经非常强大，但是还欠缺一些基础功能，譬如支持 Expand Volume（部分 Storage Vendor 支持）和 SnapShot。本文尝试从我们的实现分享如下几个内容：现有 Kubernetes 存储插件系统问题、Container Storage Interface（CSI）、基于CSI 和分布式文件系统实现在 MySQL 的 Volume 动态扩展、对 CSI 的展望。

容器如何监控?微服务如何监控?集群性能如何进行分析计算?如何管理agent端大量配置脚本?