ITPub博客

随着国产、分布式数据库大规模落地，多类型数据库运维难度不断攀升。传统诊断、问答工具相互割裂、效率低下，DBA 在故障排查、报告分析、知识库检索等工作中消耗大量重复人力。历经数月架构重构、知识库打磨与全流程内测，BIC‑QA v2正式上线。平台搭载全新一代 GraphMind V3 融合知识架构，一站式整合 AWR/WDR 报告解析、日志故障诊断、智能知识问答、自动化巡检等运维能力，高效破解多数据库运维痛点。

一套达梦DM8的数据库突然宕机了，从达梦数据库的日志中没有发现任何有价值的报错信息： 13点13分的最后一个报错信息是一个网络报错，因为有会话断开导致，只是一个警告，并不是导致达梦数据库宕机的主要原因。在操作系统上也找不到core dump的信息： 如何进一步定位问题呢？这时候D-SMART登场了。从告警台可以看出11：00开始系统开始出现大量的runtime error报警，

1.1.1 openGauss的USTORE与ZHEAP有区别吗当openGauss推出USTORE存储引擎的时候，就不止一个朋友说高斯的USTORE是基于开源项目ZHEAP开发的。以前没怎么研究，所以也不方便发表意见。正好这几天在研究高斯USTORE，顺便也找了些ZHEAP的资料看了看。ZHEAP这个项目目前似乎已处于停滞状态，这个原本计划PG 15时合并到PG主版本的项目很可能会夭折

大家都已经很熟悉openGauss了，昨天我的文章中说陕西电力的用采系统用Gaussdb替代了Oracle，就有朋友问我这个Gaussdb是不是就是openGauss。这个问题还真的有点不好回答，Gaussdb和openGauss渊源很近，但是还不是一码事。华为在数据库产品这方面还是挺复杂的。这个Gaussdb实际上指的是Gaussdb企业版，在早期的华为云上，叫做Gaussdb for

目前国内外的运维工具中，SQL SERVER的工具偏少，而且也仅仅偏向于简单的状态监测和一些关键指标基线告警。缺乏深度问题的分析与发现能力，也缺乏复杂问题溯源的能力。因此我们可能知道某个指标异常了，但是不知道为什么异常，是什么引发的异常，我们该如何去优化它。微软虽然提供了一些诊断分析工具，不过这些工具用起来太复杂了，一般人也真的不太容易掌握。再加上Windows的问题本身就比较难以分析，这导致了S

昨天聊了下SQLSERVER的spinlock，当时我认为spinlock是与Oracle LATCH相对应的结构，事实上碎片化的阅读会带来一些知识掌握的不准确。Oracle的LATCH是通过spin来实现锁的获取的，spin是LATCH获取轻量级锁的一种方式。而在SQLSERVER中，LATCH和spinlock被设计成两种轻量级锁，分别用于不同的场景。Oracle有shared po

可能有朋友会有疑惑，SQLSERVER是跑在WINDOWS平台上的，也会有SPINLOCK吗？事实上，只要是现代的多核心CPU环境中，多路服务器环境中，要实现高并发环境下的串行化访问，spinlock就必定会存在的，只是Windows和Linux在自旋锁的实现代码上不同而已。正是因为spinlock的存在，SQLSERVER也会和Oracle、MySQL、PG等数据库一样因为spinlock较为严

前些年和搞PG的朋友交流的时候，他说PG数据库是比较简单的数据库，但是用好PG数据库并简单。和Oracle数据库比起来，Oracle数据库很复杂，想管好，优化好技术就要很好，掌握管理Oracle的技术需要下大功夫，一旦掌握了，反而管理起来很简单，很顺手了。而PG数据库相对简单，想管好，优化好，在技术上并不复杂，掌握技术难度不大，但是你需要更为精细的去管理它，才能用好它。我觉得他说的挺有道理，PG可

数据库优化是一个综合工程，不仅仅是需要DBA参与，更重要的是研发设计人员针对PG数据库的特点来进行相关的优化设计。不过对于DBA来说，一旦接到上线和运维任务，基本上都是木已成舟，软件设计方面留下的坑已经挖好，DBA的作为已经十分有限了。不过既然要干运维，那么少不了就要参与优化。PG的优化工作该如何开展呢？今天我从几个主要的方面聊聊PG优化的几个常见的角度。针对PG数据库，只要做好了下面几个方面的优

PostgreSQL近些年热度越来越高，特别在国内，基于其生态的数据库产品种类繁多。如果有人问“信创数据库学啥比较好”，从今后的工作机会以及学习资料的普及程度来说，我首先推荐的就是PostgreSQL。不过目前大多数PostgreSQL用户都没有认真配置数据库，让其达到最 佳的使用效果，并充分发挥出硬件的性能特征。其中数据库IO的优化是重中之重，IO延时较大会导致所有的SQL都会变慢。 

PostgreSQL数据库是近年来热度上升最快的关系型数据库之一，近年来大量国内企业都在把系统向PostgreSQL上迁移。目前热度较高的国产数据库中也有一大半的厂商选择了PostgreSQL开源项目作为数据库产品的研发基础。不过PostgreSQL的运维一直是个难点，与Mysql相比，PostgreSQL过于复杂，运维难度远大于Mysql。而与Mysql相比，熟悉PostgreSQL运维与优化的

SQL优化是数据库优化中十分重要的手段，也是见效最快的手段。有时候添加一个索引，修改一条SQL语句能够把一个即将崩溃的数据库系统挽救回来。SQL优化的手段很多，大家比较常用的是添加索引、调整表连接方式、改写等价SQL等方法。实际上POSTGRESQL数据库的SQL优化技巧大多数是和其他数据库，比如Oracle是类似的，因为现代数据库产品的核心技术就是CBO优化器技术。POSTGRESQL在内的多种

如果我们已经找到了某条TOP SQL,要针对SQL进行优化分析，该如何进行呢？在学习其他数据库的时候，我们已经了解到了，SQL优化主要从三个角度进行：1）扫描方式；2）连接方式；3）连接顺序。如果解决好这三方面的问题，那么这条SQL的执行效率就基本上是靠谱的。看懂SQL的执行计划的关键也是要首先了解这三方面的基本概念，只有搞清楚了这些基本概念，才能够更好的看懂SQL的执行计划，下面我们分别来学习这

 索引是关系型数据库应用系统优化的关键，在早期的应用开发上，我们对索引的认知不足，因此应用系统在索引设计上总是存在很多问题。在2000年以前我给用户做的优化项目中，一般来说通过优化索引就可以解决几乎所有的问题。随着这些年我们在Oracle数据库上应用经验越来越丰富，Oracle数据库的索引优化也越来越纯熟了。不过如果我们把应用系统从Oracle迁移到PostgreSQL上的时候，我们很可

PostgreSQL的MVCC实现机制是采用数据块中生成多个副本的方式的，这种机制被很多DBA和架构师认为是PostgreSQL数据库在大型高负载系统中的一个巨大的缺陷。实际上不只是PostgreSQL采用了多副本行元来实现MVCC，目前比较热门的基于LSM-Tree存储引擎的数据库系统（比如阿里的Oceanbase，PingCAP的TiDB）也采用了这种方式。LSM-Tree需要通过Compar

Oracle DBA最怕遇到CURSOR 相关的问题，如果发生了CURSOR争用导致的性能问题，是很难在短时间内分析清楚的。有时候我们重启数据库就解决了这个问题，不过有时候重启数据库后问题依然存在。幸运的是在PostgreSQL数据库中好像很少会遇到类似的问题，这是什么原因呢？在一个高并发的系统中，SQL执行过程需要对SQL进行编译，这个过程无论哪种数据库都是必须有的。大体上分为语法语义解析、SQ

很多PG的老用户都对AUTOVACUUM存有不好的印象，因为VAVCUUM导致的系统问题也让运维人员对PG有十分不好的印象，甚至认为PostgreSQL 不适合于7*24的高并发负载场景。实际上，任何数据库技术都会有不堪的童年，就算是现在的王炸Oracle，当年也让DBA痛恨不已。二十多年前，我从使用RDB数据库转向使用ORACLE的时候，第一印象是，这是个什么玩意，咋这么难用呢。等用惯

大家用Oracle数据库的时候，根本不需要过多的去考虑数据库物理结构以及OS物理结构方面的优化。因为Oracle把一切都帮我们做好了，只需要交给Oracle足够容量，足够能力的物理资源就一切OK了。不过作为近几十年前就开始使用Oracle数据库的我们这一代DBA，还是经历过很多这样的优化案例的。在那个年代，曾经通过底层存储的重新条带化设计，让一套IO负载极高的数据库系统的批处理作业性能提高数倍。现

昨天谈了PG的Double Buffering，这一点是很多诟病PG的人经常提到的问题。不过昨天老白也说了，Double Buffering其实也不是什么太大的问题，对于绝大多数PG数据库系统来说，这个问题的负面影响绝对没有网上的那些文章说的那么玄乎，甚至对于绝大多数数据库来说，这个问题我们可以忽略。不过对于一些超大型的PG数据库，比如从Oracle迁移到PG的大型或者超大型数据库来说，我们还是需

最近有朋友和我们交流PostgreSQL运维的问题，其中交流提纲里提到了关于Double Buffering的问题。对于以往习惯于使用Oracle数据库的人来说，不会体会到Double Buffering这个词的含义。很多Oracle DBA也认为Oracle天生就不需要考虑Double Buffering的问题的，只有PG/MYSQL这样的开源数据库才需要