- 博客(108)
- 收藏
- 关注
RSS订阅原创 从活跃会话数指标谈起
实际上智能化诊断的实现有很多种渠道，不过大部分做智能化诊断的厂家都会选择从数据入手，通过数据的异常来发现系统可能存在的问题，这种做法只要有算法工程师和略懂运维的人参与就可以开展，不需要大量的运维专家参与，比较容易开展工作。因为如果简单的通过有向图扫描所有诊断路径，最终的结果肯定是把所有的工具都执行一遍，然后所有的诊断路径中发现的问题再做汇聚。如果不通过知识梳理的方式，而采用深度学习的方法对数据进行分析，从而形成这样的诊断路径，那么所需要的数据和案例是海量的，其数据归集和数据标注工作也是一项巨大的工程。
2024-03-27 09:27:07
745
原创 从kcbwds结构谈Oracle dbwr的技术演进
不过使用这个结构的最主要的是dbwr，这个数据结构里和DBWR相关的数据项特别多。LRU链是我们传统所说的replacement list,用于BUFFER的LRU替代，LRU-W是需要DBWR写入数据文件的链，LRU-P是当前正在写入的链表，当时所有的BUFFER都被PIN住，等写入完成后会降低锁定级别，并被重新链入LRU。当时他们的研发负责人也十分理解我们的需求，不过从他们目前的情况来看，如果要统计每个等待事件的时间，则会严重的影响数据库的执行效率，对SQL执行性能有很大的负面影响。
2024-03-07 15:36:14
513
原创 HEAP结构与ORA-4031
第三个是扩大经常动态扩展的列表对象的初始大小，减少其动态扩展的次数，最好能够让它们不再动态扩展，这个做法会浪费一定的共享池空间，但是是可以解决这个问题的最好的方法。正因为这样，如果系统并发量很大的时候，很多共享池的内存是被PIN住，无法释放的，这样，共享池的空闲空间就被分给为无数个很小的碎片，对于一些较大的分配，可能就无法满足，出现ORA-4031也就不可避免了。根据HEAP的内存管理方法可以看出，共享池碎片化是不可避免的，随着数据库实例的启动时间的增长，这种碎片化趋势会越来越明显。
2024-03-07 15:34:38
504
原创 RAC数据库丢失某个current redo log的故障处理
根据对数据库的理解，如果单实例能够打开，说明这个数据库的数据字典是基本一致的，有可能存在的问题是第二个实例的REDO丢失部分数据，导致某些数据出现不一致，另外一个实例的UNDO出现不一致。5、不过这时候数据库是存在一些数据不一致的地方的，会有一些坏块，对这种情况，一般有两种后续处理方法，第一种是继续找存在问题的对象，进行修复，还有一种是导出数据，重建数据库，再倒入数据，使数据库重新恢复正常，一般情况下，对于一个十分重要的数据库，第二种可能是最佳方法，当然需要一定的停机时间才可以进行类似的操作。
2024-03-04 10:46:04
375
原创 Smon死锁引发的数据库宕机
60号进程以S模式申请enq: RO - fast object reuse锁，但锁Enqueue RO-0002003C-00000001被15号进程以X模式占有，同时16号进程以X模式申请Enqueue RO-00020010-00000001锁，但Enqueue RO-00020010-00000001被15号进程以SS模式占有同时Enqueue RO-00020010-00000001被16号进程自己以SSX模式占有。229、231和3点42分的ssd trace等待的对象仍然是一样的。
2024-03-04 10:33:07
936
原创 一个CRS节点无法安装的故障分析
他回答是这些都没错，然后我问他网卡的顺序是否正确，在HP-UX下有时候私网和公网的网卡在两台服务器上的设备名不对应，也可能会出一些莫名其妙的错误。这下子就很明确了，估计是HP-UX的补丁没有打全，经过检查，发现GOLDQPK11i 没有打，打了补丁后，测试一下/usr/sbin/pingnode1 -n 1 -m 3 ,一切都OK了，于是再安装CRS，一切正常。那么下面该怎么处理呢？在常规方法无法找到问题的时候，使用操作系统跟踪工具对某个出问题的配置过程进行跟踪是十分有效的方法，命令去检查节点的健康性。
2024-03-04 10:30:11
836
原创 Rman跳过坏块快速修复的的技巧
因为在不设置这个事件的时候，如果RMAN恢复数据文件的时候发现备份集有坏块，就会在坏块的位置写入一个空块。而设置了这个事件，不管怎样，都会将这个块写入数据文件，这可能导致不一致的产生。不过设置了这个事件也不一定能够跳过坏块恢复文件，因为一个备份集往往有多个文件，如果标志哪个块属于哪个文件的数据块坏了，那么恢复数据将变得不可能。：如果在恢复的时候还没有恢复到所需要的所有数据块，就碰到文件结束了，这个时候会报 ORA-19612,如果设置了这个事件就会忽略这个错误。为了解决这个问题，Oracle提供了两个。
2024-03-04 10:24:42
385
原创 用KFED REPAIRE快速修复ASM磁盘头
到目前位置，用kfed使用常规方法修复磁盘头还是一件十分困难的事情。直到Oracle 10.2.0.5开始，Oracle也意识到了asm的这个问题，在asm metadata中保留了一个备份块，这样使用 kfed的一个隐含功能就可以实现asm磁盘头的一键修复了。ASM磁盘头故障的原因十分复杂,一般和安装与运维有关，其根本原因就是Oracle.比如在AIX平台上,如果没有清掉PVID，下次服务器重启时就可能会出现设备名混乱的问题，如果你用chdev去修改设备，那么ASM磁盘头可能会丢失。
2024-03-04 10:22:52
458
原创 ASM的文件结构
是不是很简单，不过有些细心的人会有疑问了，一个4096字节的块，只能包含60个AU项，如果有冗余，只能包含30M的AU的指针，超过30M的文件如何处理呢。在这个数据库中，SYSAUX的ASM文件号是257，因此这个文件的FILEDIR是AU 60的BLOCK 1。这个别名文件的ASM文件号是6。首先我们要了解的是DISK HEADER，每个DG的DISK都有一个HEAD，其位置是文件头部（如果以0为第一个块的话，那就是0号块），DISKHEADER其实就是每个DISK的AU 0的BLOCK 0。
2024-03-04 10:20:28
1212
原创 体验一把Oceanbase单机版
这意味着，当CM操作发生时，整个OB数据库的写入性能是受到限制的，因为只有一部分MEMSTORE内存可以被用于新数据的写入，而大部分内存都要被用于freezen。最重要的就是KVCACHE，这个CACHE类似于Oracle的BUFFER CACHE，用于存储常用的数据，不过和BUFFER CACHE不同的是，OB的KVCACHE不仅仅用于存储数据，所有的KV结构的数据都可以使用KVCACHE来做缓冲。今天简单的用了用OB，没有做深入的分析，不过从与oracle数据库的兼容性来说，还是不错的。
2024-03-01 14:20:37
545
原创 简单体验一把Polardb的等待事件
我们看到，WAL方面的lwlock等待小多了，从系统的TPMC指标上来看，也有了明显的改善。其中最为重要的是，我们能够获得等待事件的等待时长的数据了。记得数年前和一个国产数据库研发团队交流的时候，他们也提出过在自己数据库中开启了等待时间监控后，数据库并发性能受到了很大的影响，最终在正式版本中，他们只能舍弃了这个监控功能。实际上，一些基于PG内核的数据库，大多数是有等待事件的，不过PG原生态的等待事件只有事件，没有等待时间，而且缺乏统计等待事件的汇总信息表，所以使用起来并不容易。这正是我们一直期待的。
2024-02-29 15:12:06
920
原创 从PolarDB开启监控插件的对比谈起
关闭POLAR_MONITOR_PRELOAD,开启POLAR_MONITOR。没有开启polar_monitor。开启polar_monitor。
2024-02-29 15:02:09
216
原创 体验一把PolarDB单机版
接入D-SMART后我们就可以仔细端详一下PolarDB了，从版本信息可以看出，PolarDB基于PostgreSQL的11.9.18.从发行版本信息中可以看出，该版本是兼容Oracle数据库的，这和PolarDB-O的宣传是一致的，据说与Oracle的语法保持了90%以上的兼容性。昨天下班前我做了一次系统压测，可以看出，在压测的高峰期，BGWRITER的脏块写入比例还是不高，大约在60%多，不过大多数情况下，BGWRITER的脏块写入比例都接近100%，说明PolarDB的这个改进还是有效的。
2024-02-29 14:58:16
943
原创 从PolarDB读写分离原理谈起
如果当前的共享存储中的某个PAGE不是最新的，也就是说是我们需要的PAGE的过去页面，那么根据内存中Wal Buffer中存储的元数据，我们就可以让这个PAGE的数据重演，得到应用所需的时间点的页面。PolarDB-O是基于PostgreSQL的，因此要让只读实例共享读写实例的数据文件，首先要解决的一个问题是要让PostgreSQL支持DIRECTIO，因为如果某个缓冲在数据库层面写盘了，而实际数据并没有被写入磁盘，还在主实例的内存中，那么只读实例从文件中读出的数据块就可能是老的。
2024-02-29 09:22:41
565
原创 KINGBASE ES V8的等待事件增强
今天我给大家初步介绍了KES V8.6在数据库可观测性上的两个十分重要的特性，实际上我们最近也正在利用这两个特性做一些研发工作，通过这些特性，我们可以大大提升数据库在遇到问题时的分析诊断能力，为用户分析问题，发现需要优化的重点提供一手的结论。通过和人大金仓的技术人员的交流，我们了解到在V8.6版本中，他们在可观测性接口上有两个较大的提升，一个是提供了等待事件时长的指标，另外一个是提供了类似Oracle ASH的等待事件历史采样。有了这一个指标，就为通过等待事件的变化来分析数据库出现了某些问题提供了基础。
2024-02-27 15:29:53
642
原创 聊聊KingbaseES的可观测性能力加强
因为我们团队缺乏对金仓数据库的了解，并且当时能够获得的文档也十分有限，而人大金仓数据库能够对外提供的可观测性接口也十分有限，也没有我们在Oracle数据库上习惯使用的AWR报告，ASH报告，等待事件分析等功能。丰富的文档为我们梳理KES的运维知识提供了很大的便利，我和几个KES的老用户交流的时候，他们也觉得V8版本在文档上的提高还是挺大的，这些文档对他们日常运维也很有帮助。我们不仅能够了解数据库的IO负载情况，也能了解数据库的IO质量，从而更为准确的掌握数据库的状态，找到数据库运行中的短板。
2024-02-27 15:27:47
712
原创 进一步讨论达梦的故障定位与分析
将dmserver的oom_score_adj设置为-1000后，dmserver的oom_score就永远是0了，于是达梦数据库就不会被杀掉了（对于早期一点的Linux版，将oom_adj设置为-17达到的是同样的效果，在7.4上面直接设置oom_adj为-17，系统自动会将oom_score_adj设置为-1000）。上一篇遇到的达梦数据库宕库问题，最终分析的结论虽然是操作系统SWAP区耗尽导致，与达梦数据库无关，但是根本原因是什么，以及以后如何规避类似问题，是更为重要的问题。至此，此问题基本解决。
2024-02-27 15:24:54
693
原创 一次达梦数据库宕机的分析过程
至此我们的工作并没有完成，由于我们以前在知识上的误区，导致了这次宕机并没有被十分明显的报出来，我们的健康模型与运维经验报警都没有准确的对此次故障进行预警。通过这个故障的分析，我们将调整两个知识库，一个是达梦的健康模型，以前的模型中只关注物理内存空闲比例，而没有关注SWAP的使用率，因此我们必须将SWAP使用率的成分加入到健康模型中。从诊断报告上可以看出，在可能导致宕机故障的时间段内，有一个明显的问题，就是虽然物理内存还有较多空闲，但是操作系统的SWAP使用率比较高，超过95%，甚至出现了100%的现象。
2024-02-27 10:04:14
512
原创 学习达梦数据库的基本概念
每一个用户都有一个默认的表空间。达梦的数据记录是存储在页中的，因为一条达梦的数据记录不能跨页，因此记录的总长度收到页的限制，达梦7规定一条记录的总长度不能大于页大小的一半。达梦的页的概念与Oracle的BLOCK是类似的，页的大小从4K到32K，默认的页大小是8K，页大小在数据库创建时确定，一旦确定，不能修改。好了，今天就学习到这里，达梦数据库在逻辑架构上的与Oracle的相似性，是DBA的福音，Oracle DBA可以比较容易理解达梦数据库，在做数据库优化的时候，也可以参考部分Oracle的经验。
2024-02-26 14:33:32
725
原创 【无标题】
因为从达梦的BLOCK结构来看，和Oracle是完全不同的，如果说相似，达梦的BLOCK结构和INNODB的PAGE结构有点类似，比较凑巧的是，达梦和INNODB都采用了BTREE表，而不是Oracle的HEAP表。提出这个问题的人可能感叹于达梦和Oracle在使用方法上的相似性，不过这种相似性，是达梦公司二十多年来不断的模仿，积累的结果，绝不是简单的偷了人家的代码。今天我简单的分析了一下目前PG的两个USTORE实现，这也是广大PGER期望的功能，如果PG能够解决ASTORE带来的问题，将会完美的多。
2024-02-26 10:36:56
739
原创 简单分析下openGauss的USTORE
openGauss的UNDO记录寻址采用64位，分为ZONEID(20)+BLOCKID(31)+OFFSET(13)，从这里看，每个UNDO ZONE的大小也是受限的，最大不能大于BLOCKID的最大值*UNDO BLOCKSIZE，而一个事务是不能跨UNDO ZONE的，因此从理论shan上讲,USTORE下的一个事务的最大大小的物理极限在我们当前的数据库应用环境中还是有可能达到的。这个Size的默认值是32GB，这个值够大，不过还是有限的，在使用USTORE的时候还是要注意。
2024-02-23 15:59:11
911
原创 简单分析openGauss的MOT功能
日本NTT的Takashi Menjo的团队HACK了PG的源代码，将数据库访问接口改为内存接口后，同样在AEP的测试环境中，发现PG数据库的性能获得了较大的提升，这个案例我以前的文章中介绍过。这种融合的优势和缺陷并存。WAL的融合为双引擎的进一步融合提供了基础，而另一方面因为磁盘引擎和内存引擎的巨大的差异，导致WAL的融合要做好还需要更多的时间，我想MOT 2.0发布后，这方面应该会有比较大的改进吧。内存数据库的持久化和磁盘数据库的持久化是有巨大的差异的，WAL是内存数据库持久化目前最好的方法。
2024-02-23 14:55:35
587
原创 openGauss的ASH
asp_sample_num参数控制了在内存中保存的ASP采样刷盘数量，达到这个数量ASP数据会被刷盘，默认是10万条，如果我们的业务高峰时期，活跃会话数量是500，那么10万条可以保存200秒的数据，也就是3分多钟，对于较为大型的系统来说，如果物理内存足够大，可以设置更大的值。从数据上看，ASP的数据已经包含了ASH分析所需要的基本信息，唯一让Oracle dba感到有些遗憾的是，等待事件的等待时间并没有包含，当然openGauss也提供了某个等待事件的等待次数和时长的统计数据供参考。
2024-02-23 14:53:36
440
原创 openGauss的可观测性能力简析
早期的数据库监控系统的目标是尽可能把数据库的运行状态展现给运维人员，实际上普通的DBA根本看不懂这些花里胡哨的图表和数据，这些数据背后内在的关系，以及能够暴露出数据库运行状态的信息才是运维的关键。健康模型是充分利用openGauss中的一些关键指标，利用运维专家的经验构建的一个指示性模型，可以十分直观的反映出高斯数据库的运行状态，哪怕对高斯数据库了解不深的DBA也可以通过这个雷达图快速的发现系统中存在的问题。通过等待事件的汇总分析，可以发现系统中存在的主要问题，协助运维人员快速定位故障，发现系统隐患。
2024-02-23 14:51:59
335
原创 分析一下opengauss的等待事件
然后来看看有哪些等待事件是非零的。比较Oracle（上图是11g）的这张视图，openGauss提供了一些类似信息最大值，最小值，平均值的数据，只是有经验的DBA都知道全局的最大值最小值是没有意义的，数据库启动后只要出现过一次极端现象，就会把这些值固化了，反而对于运维来说没有价值了。最后我们再来看看thread_wait_status，令人略感遗憾的是在会话级的等待事件上并没有包含等待时间，我想以后的版本应该会慢慢的加上，能做系统级的等待事件分析已经为具有细粒度等待事件分析的能力提供了一个基础。
2024-02-23 14:43:42
971
原创 openGauss可观测性综述
默认每秒钟采集一个样本，存储在特定的内存里，可以通过dbe_perf.local_active_session接口获取，内存中保留10万条记录（可配置），超过则写入持久化存储，持久化存储可以使用两种模式：表gs_asp或者文件（默认为表），默认的持久化保存采样比例为10：1，也就是说内存中的采样的1/10会被写入持久化存储，如果你觉得这种采样比例不足以用于分析，通过参数进行调整，从而将所有数据都写入持久化存储。我想Oracle的AWR也是这么一点点的走来的，因此我们也期望以后的WDR会做的越来越好。
2024-02-23 14:39:55
679
原创 简单了解一下GaussDB
首先PL/SQL存储过程的兼容性还是不错的，大多数Oracle的存储过程是可以简单的迁移过去的，当然PL/SQL上不大可能100%兼容，大多数国产数据库，哪怕是和Oracle兼容性做得很好的达梦数据库都只能做到90+%的存储过程语法兼容，不过这些兼容对于大多数应用迁移来说就完全够用了，Oracle PL/SQL的一些特殊语法，可能大多数开发人员都没听说过。语法兼容性还是一些表面的问题，实际上如果把应用从集中式的Oracle数据库迁移到分布式的Gaussdb，还有很多性能方面的问题需要考虑。
2024-02-22 10:14:15
629
原创 为SQL SERVER准备一只透视眼
比如上面所说的问题完全可以通过“指标关联性分析”工具进行分析，比如我们发现数据库的闩锁等待有点不正常，从“指标关联度分析”的结论上看，这个指标相关联的问题主要几种在IO并发量过大上，而最终定位的问题是操作系统IO延时过大，IO能力不足引发了IO性能问题。当然，目前的智能诊断仅仅是为我们提供了一双透视眼，让我们能够更好的看数据，帮我们自动分析数据，其大脑目前还不够聪明，分析的最后一公里依然需要依靠人的判断，不过已经为我们的运维人员，特别是三线专家提供了很好的分析方向。在报告的后面，会提供这个分析。
2024-02-22 10:07:04
666
原创 SQL SERVER的LATCH
在为大型服务器设计的高吞吐量系统上，必定会出现高并发的闩锁争用，在此类系统中存在闩锁争用是十分正常的现象。Oracle的LATCH是通过spin来实现锁的获取的，spin是LATCH获取轻量级锁的一种方式。实际上有些指标之间是存在较为同步的关联关系的，通过上升或者下降的幅度（可以通过统计学方法计算出一个可评估的度量）之间的对比，可以发现一些系统的性能问题。因为闩锁的行为是确定性的，数据库SCHEMA的设计，表、索引等的设计会影响闩锁争用。的一些原理的问题并不是仅仅为了分析原理，而是要更好的用到诊断中。
2024-02-22 10:02:00
806
原创 学习SQL SERVER SPINLOCK诊断
LOCK_HASH这个spinlock我们还是比较容易理解的，当很多并发进程访问某个锁HASH的同一个桶的时候，很容易出现此等待，比如大量的并发会话都在争用某几个具体的行数据的时候，就会发生。事实上，在绝大多数情况下，CPU 的增加是由于自旋锁争用以外的原因。上面的查询可以显示出SQLSERVER的spinlock的统计信息，如果我们在某个固定的时间区间内去采集这些数据，并通过delta计算增量差值，就可以掌握最近一个采样周期内各种spinlock的情况，从而从中推测数据库可能存在的并发方面的问题。
2024-02-22 09:56:56
851
原创 从HASH JOIN的执行细节可以看出什么
WORK_MEM参数是可会话级动态设置的，如果我们的某些要做大型排序或者HASH JOIN的SQL能够在应用层面做设置，执行大型SQL的时候设置一个较大的值，SQL执行完毕RESET一下参数，这样WORK_MEM的使用效率是最高的。刚开始就有点扯远了，今天我们的重点不是讨论NL和HASH JOIN的差异，而是带大家看看PG数据库的HASH JOIN执行计划中的一些容易被忽略的点，在查看执行计划的时候，如果能够比较好的抓住这些关注点，对于SQL优化来说很有帮助。
2024-02-21 14:27:06
549
原创 通过预热来优化PG数据库的SQL性能
这种情况下，数据预热可以加速查询的同时，减少I/O操作的次数，从而提高系统的稳定性。不过用户并不认同我的观点，他们认为如果日常运维遇到了必须分析TOP SQL的时候往往就是遇到了十分严重的性能问题，对于他们这种金融服务企业，这个时候定位问题解决问题的时间是十分关键的，这时候就需要每个操作都有十分快的响应。需要注意的是，如果数据表的大小比较小，或者该数据表的查询不频繁，或者反过来说，某些特别热的小表，其数据大部分都在共享缓冲区中，那么进行数据预热的效果可能不太明显，反而会浪费系统资源。# 获取表所在的目录。
2024-02-21 11:05:52
317
原创 PG数据库优化上我们都能做点什么
对于数据库参数来说，实际上不同的应用场景下的最佳调整方案是不同的，一般来说，设置合理的shared_buffers，以及优化好相关的而bgwriter，WAL，checkpoint，work_mem，VACUUM等相关的参数，就能够满足大多数应用的需求了。硬件资源不足的问题我们就不多加讨论了，这种情况一般会出现在CPU、IO等方面，在分析这方面问题的时候，需要关注R队列的长度是否超过CPU逻辑核数的2倍以上，对于IO来说，不仅仅要看IOPS/IO吞吐量等指标，更重要的是要看IO延时是否合理。
2024-02-21 10:03:55
871
原创 PG数据库IO优化技巧
调整 wal_buffers 的值时，重要的是要考虑生成 WAL 数据的速率，增加 wal_buffers 的值有助于降低磁盘写入频率并提高性能，不过在普通的负载下，调整wal_buffers并不能看到数据库性能的提升，只有当WAL写入BUFFER的速度大于Walwriter写盘的速度的时候，加大wal_buffers才会有特别明显的性能提升。举个例子，如果你的物理内存是256GB，而你的常用设数据是100GB，那么设置一个128GB的shared_buffers有可能是比较好的配置。
2024-02-20 15:12:21
597
原创 基于知识图谱与异常检测的PG数据库故障定位
这种智能化辅助的手段可以减轻DBA的工作负担，提高问题定位的正确性。于是我们想到了模仿Oracle的统计信息，以一定周期为单位（比如一周，半个月），滚动更新统计数据，采集指标的数据进行采样，构建常规运行的数据模型，然后根据这些数据模型，建立算力要求较低的算法，用于生产环境的指标异常检测。当时我们采用在生产系统中采样，并进行专家标注的方法构建分析中最为核心的异常检测算法，结合知识图谱定义的诊断路径，找出与某个故障现象相关的指标集，然后通过异常检测发现其中存在问题的子集，最后通过收敛算法，找到问题的根因。
2024-02-20 15:03:43
729
原创 PG数据库SQL优化小技巧
分区表往往是优化大数据量业务的利器，分区表可以让每个表分区的数据量得到有效的控制，从而减少Seq Scan的成本，也可以降低表维护的成本。因此在POSTGRESQL的SQL优化工作中，一定要认真研究使用适当的索引类型来优化某个比较难以解决的问题，这种工作思路是其他数据库中所没有的，对于解决复杂的SQL性能问题十分有效。：确保SQL语句使用了合适的扫描方式。这些技巧可能很多都是总体性的，并不能直接应用于你的SQL之中，不过这些技巧如果应用得当，会让你的POSTGRESQL数据库的SQL性能得到极大的提升。
2024-02-20 14:40:46
1028
原创 如何阅读PG数据库的执行计划
如果这张表上的数据量比较大，那么这种扫描方式可能会产生较大的IO，消耗较多的CPU资源，持续较长的时间。否则，将使用临时文件。不过我们要注意的是，有些时候，索引扫描的效率还不一定比顺序扫描高，比如某个扫描需要返回的行数较多，底层存储的顺序读性能远高于离散读，这种情况下，如果我们还一味追求索引扫描，那么可能会起到副作用。PG的扫描方式与Oracle等其他数据库类似，但也存在较大的不同，为了掌握好SQL语句优化的技术，我们首先要学会看SQL语句的执行计划，而看执行计划的最为基础的能力就是看懂每一步的扫描方式。
2024-02-20 14:33:31
865
原创 聊聊PG数据库的索引
它是一个带有 WHERE 子句的索引。对于自定义索引，是PostgreSQL的一个更为强大的功能，我们可以通过编写插件的方式来实现自己的索引，根据自己的业务逻辑去对数据创建个性化的索引，从而提升应用访问的效率。实际上索引优化是应用驱动的，索引的优化一定要根据应用的特点来做专业的设计，否则索引有可能会成为应用系统出现问题的隐患。如果键值存在某种单边增长的趋势，那么创建BRIN索引后，根据这个键值做范围扫描的时候，可以根据BRIN索引找到所需要扫描的数据块，跳过其他的所有数据块，快速的将所需的数据扫描出来。
2024-02-20 14:28:39
779
原创 MVCC缺陷与高负载PG数据库优化要点
不过随着这些年PostgreSQL数据库的快速发展，每个版本对Vacuum的算法都有了极大的改善，在目前硬件性能极大提升与PostgreSQL Vacuum的算法的优化双重作用下，目前Vacuum对高负载数据库的影响也越来越低了。前阵子我在网上看到过一个某互联网汽车租赁公司的案例，他们的PostgreSQL数据库的AutoVacuum出现了严重的性能问题，租车订单表每天要消耗几百万个xid，而每天的autovacuum只能回收其中70%的xid，这意味着一个十分严重的问题，xid wraps的问题。
2024-02-20 14:18:06
345
原创 Postgresql的CURSOR SHARING
在Oracle 9iR2之前，所有执行计划都是在变量绑定之前完成的，从9.2开始,Oracle将执行计划的生成放到了变量绑定之后，这样就让执行计划的生成更为精准了，不过这也带来了另外一个问题，那就是SQL第一次执行时的变量成为生成执行计划的依据，因此CURSOR共享会导致存在多种最优执行计划的SQL语句的运行性能变得不稳定。在PostgreSQL的一个会话中，一条SQL的前五次执行，每次都会重新生成执行计划，这样就可以避免因为绑定变量的差异导致存在多种最优执行计划的问题无法被发现的问题出现。
2024-02-20 14:08:43
482
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人