<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[DBAIOps的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/DBAIOps</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; DBAIOps]]></copyright><item><title><![CDATA[从活跃会话数指标谈起]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/137065461</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/137065461</guid><author>DBAIOps</author><pubDate>Wed, 27 Mar 2024 09:27:07 +0800</pubDate><description><![CDATA[实际上智能化诊断的实现有很多种渠道，不过大部分做智能化诊断的厂家都会选择从数据入手，通过数据的异常来发现系统可能存在的问题，这种做法只要有算法工程师和略懂运维的人参与就可以开展，不需要大量的运维专家参与，比较容易开展工作。因为如果简单的通过有向图扫描所有诊断路径，最终的结果肯定是把所有的工具都执行一遍，然后所有的诊断路径中发现的问题再做汇聚。如果不通过知识梳理的方式，而采用深度学习的方法对数据进行分析，从而形成这样的诊断路径，那么所需要的数据和案例是海量的，其数据归集和数据标注工作也是一项巨大的工程。]]></description><category></category></item><item><title><![CDATA[从kcbwds结构谈Oracle dbwr的技术演进]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136535639</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136535639</guid><author>DBAIOps</author><pubDate>Thu, 07 Mar 2024 15:36:14 +0800</pubDate><description><![CDATA[不过使用这个结构的最主要的是dbwr，这个数据结构里和DBWR相关的数据项特别多。LRU链是我们传统所说的replacement list,用于BUFFER的LRU替代，LRU-W是需要DBWR写入数据文件的链，LRU-P是当前正在写入的链表，当时所有的BUFFER都被PIN住，等写入完成后会降低锁定级别，并被重新链入LRU。当时他们的研发负责人也十分理解我们的需求，不过从他们目前的情况来看，如果要统计每个等待事件的时间，则会严重的影响数据库的执行效率，对SQL执行性能有很大的负面影响。]]></description><category></category></item><item><title><![CDATA[HEAP结构与ORA-4031]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136535587</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136535587</guid><author>DBAIOps</author><pubDate>Thu, 07 Mar 2024 15:34:38 +0800</pubDate><description><![CDATA[第三个是扩大经常动态扩展的列表对象的初始大小，减少其动态扩展的次数，最好能够让它们不再动态扩展，这个做法会浪费一定的共享池空间，但是是可以解决这个问题的最好的方法。正因为这样，如果系统并发量很大的时候，很多共享池的内存是被PIN住，无法释放的，这样，共享池的空闲空间就被分给为无数个很小的碎片，对于一些较大的分配，可能就无法满足，出现ORA-4031也就不可避免了。根据HEAP的内存管理方法可以看出，共享池碎片化是不可避免的，随着数据库实例的启动时间的增长，这种碎片化趋势会越来越明显。]]></description><category></category></item><item><title><![CDATA[RAC数据库丢失某个current redo log的故障处理]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136446138</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136446138</guid><author>DBAIOps</author><pubDate>Mon, 04 Mar 2024 10:46:04 +0800</pubDate><description><![CDATA[根据对数据库的理解，如果单实例能够打开，说明这个数据库的数据字典是基本一致的，有可能存在的问题是第二个实例的REDO丢失部分数据，导致某些数据出现不一致，另外一个实例的UNDO出现不一致。5、不过这时候数据库是存在一些数据不一致的地方的，会有一些坏块，对这种情况，一般有两种后续处理方法，第一种是继续找存在问题的对象，进行修复，还有一种是导出数据，重建数据库，再倒入数据，使数据库重新恢复正常，一般情况下，对于一个十分重要的数据库，第二种可能是最佳方法，当然需要一定的停机时间才可以进行类似的操作。]]></description><category></category></item><item><title><![CDATA[Smon死锁引发的数据库宕机]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136445664</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136445664</guid><author>DBAIOps</author><pubDate>Mon, 04 Mar 2024 10:33:07 +0800</pubDate><description><![CDATA[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等待的对象仍然是一样的。]]></description><category></category></item><item><title><![CDATA[一个CRS节点无法安装的故障分析]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136445557</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136445557</guid><author>DBAIOps</author><pubDate>Mon, 04 Mar 2024 10:30:11 +0800</pubDate><description><![CDATA[他回答是这些都没错，然后我问他网卡的顺序是否正确，在HP-UX下有时候私网和公网的网卡在两台服务器上的设备名不对应，也可能会出一些莫名其妙的错误。这下子就很明确了，估计是HP-UX的补丁没有打全，经过检查，发现GOLDQPK11i 没有打，打了补丁后，测试一下/usr/sbin/pingnode1 -n 1 -m 3 ,一切都OK了，于是再安装CRS，一切正常。那么下面该怎么处理呢？在常规方法无法找到问题的时候，使用操作系统跟踪工具对某个出问题的配置过程进行跟踪是十分有效的方法，命令去检查节点的健康性。]]></description><category></category></item><item><title><![CDATA[Rman跳过坏块快速修复的的技巧]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136445419</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136445419</guid><author>DBAIOps</author><pubDate>Mon, 04 Mar 2024 10:24:42 +0800</pubDate><description><![CDATA[因为在不设置这个事件的时候，如果RMAN恢复数据文件的时候发现备份集有坏块，就会在坏块的位置写入一个空块。而设置了这个事件，不管怎样，都会将这个块写入数据文件，这可能导致不一致的产生。不过设置了这个事件也不一定能够跳过坏块恢复文件，因为一个备份集往往有多个文件，如果标志哪个块属于哪个文件的数据块坏了，那么恢复数据将变得不可能。：如果在恢复的时候还没有恢复到所需要的所有数据块，就碰到文件结束了，这个时候会报 ORA-19612,如果设置了这个事件就会忽略这个错误。为了解决这个问题，Oracle提供了两个。]]></description><category></category></item><item><title><![CDATA[用KFED REPAIRE快速修复ASM磁盘头]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136445319</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136445319</guid><author>DBAIOps</author><pubDate>Mon, 04 Mar 2024 10:22:52 +0800</pubDate><description><![CDATA[到目前位置，用kfed使用常规方法修复磁盘头还是一件十分困难的事情。直到Oracle 10.2.0.5开始，Oracle也意识到了asm的这个问题，在asm metadata中保留了一个备份块，这样使用 kfed的一个隐含功能就可以实现asm磁盘头的一键修复了。ASM磁盘头故障的原因十分复杂,一般和安装与运维有关，其根本原因就是Oracle.比如在AIX平台上,如果没有清掉PVID，下次服务器重启时就可能会出现设备名混乱的问题，如果你用chdev去修改设备，那么ASM磁盘头可能会丢失。]]></description><category></category></item><item><title><![CDATA[ASM的文件结构]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136445155</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136445155</guid><author>DBAIOps</author><pubDate>Mon, 04 Mar 2024 10:20:28 +0800</pubDate><description><![CDATA[是不是很简单，不过有些细心的人会有疑问了，一个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。]]></description><category></category></item><item><title><![CDATA[体验一把Oceanbase单机版]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136395069</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136395069</guid><author>DBAIOps</author><pubDate>Fri, 01 Mar 2024 14:20:37 +0800</pubDate><description><![CDATA[这意味着，当CM操作发生时，整个OB数据库的写入性能是受到限制的，因为只有一部分MEMSTORE内存可以被用于新数据的写入，而大部分内存都要被用于freezen。最重要的就是KVCACHE，这个CACHE类似于Oracle的BUFFER CACHE，用于存储常用的数据，不过和BUFFER CACHE不同的是，OB的KVCACHE不仅仅用于存储数据，所有的KV结构的数据都可以使用KVCACHE来做缓冲。今天简单的用了用OB，没有做深入的分析，不过从与oracle数据库的兼容性来说，还是不错的。]]></description><category></category></item><item><title><![CDATA[简单体验一把Polardb的等待事件]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136371931</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136371931</guid><author>DBAIOps</author><pubDate>Thu, 29 Feb 2024 15:12:06 +0800</pubDate><description><![CDATA[我们看到，WAL方面的lwlock等待小多了，从系统的TPMC指标上来看，也有了明显的改善。其中最为重要的是，我们能够获得等待事件的等待时长的数据了。记得数年前和一个国产数据库研发团队交流的时候，他们也提出过在自己数据库中开启了等待时间监控后，数据库并发性能受到了很大的影响，最终在正式版本中，他们只能舍弃了这个监控功能。实际上，一些基于PG内核的数据库，大多数是有等待事件的，不过PG原生态的等待事件只有事件，没有等待时间，而且缺乏统计等待事件的汇总信息表，所以使用起来并不容易。这正是我们一直期待的。]]></description><category></category></item><item><title><![CDATA[从PolarDB开启监控插件的对比谈起]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136371627</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136371627</guid><author>DBAIOps</author><pubDate>Thu, 29 Feb 2024 15:02:09 +0800</pubDate><description><![CDATA[关闭POLAR_MONITOR_PRELOAD,开启POLAR_MONITOR。没有开启polar_monitor。开启polar_monitor。]]></description><category></category></item><item><title><![CDATA[体验一把PolarDB单机版]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136371452</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136371452</guid><author>DBAIOps</author><pubDate>Thu, 29 Feb 2024 14:58:16 +0800</pubDate><description><![CDATA[接入D-SMART后我们就可以仔细端详一下PolarDB了，从版本信息可以看出，PolarDB基于PostgreSQL的11.9.18.从发行版本信息中可以看出，该版本是兼容Oracle数据库的，这和PolarDB-O的宣传是一致的，据说与Oracle的语法保持了90%以上的兼容性。昨天下班前我做了一次系统压测，可以看出，在压测的高峰期，BGWRITER的脏块写入比例还是不高，大约在60%多，不过大多数情况下，BGWRITER的脏块写入比例都接近100%，说明PolarDB的这个改进还是有效的。]]></description><category></category></item><item><title><![CDATA[从PolarDB读写分离原理谈起]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136361875</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136361875</guid><author>DBAIOps</author><pubDate>Thu, 29 Feb 2024 09:22:41 +0800</pubDate><description><![CDATA[如果当前的共享存储中的某个PAGE不是最新的，也就是说是我们需要的PAGE的过去页面，那么根据内存中Wal Buffer中存储的元数据，我们就可以让这个PAGE的数据重演，得到应用所需的时间点的页面。PolarDB-O是基于PostgreSQL的，因此要让只读实例共享读写实例的数据文件，首先要解决的一个问题是要让PostgreSQL支持DIRECTIO，因为如果某个缓冲在数据库层面写盘了，而实际数据并没有被写入磁盘，还在主实例的内存中，那么只读实例从文件中读出的数据块就可能是老的。]]></description><category></category></item><item><title><![CDATA[KINGBASE ES V8的等待事件增强]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136323876</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136323876</guid><author>DBAIOps</author><pubDate>Tue, 27 Feb 2024 15:29:53 +0800</pubDate><description><![CDATA[今天我给大家初步介绍了KES V8.6在数据库可观测性上的两个十分重要的特性，实际上我们最近也正在利用这两个特性做一些研发工作，通过这些特性，我们可以大大提升数据库在遇到问题时的分析诊断能力，为用户分析问题，发现需要优化的重点提供一手的结论。通过和人大金仓的技术人员的交流，我们了解到在V8.6版本中，他们在可观测性接口上有两个较大的提升，一个是提供了等待事件时长的指标，另外一个是提供了类似Oracle ASH的等待事件历史采样。有了这一个指标，就为通过等待事件的变化来分析数据库出现了某些问题提供了基础。]]></description><category></category></item><item><title><![CDATA[聊聊KingbaseES的可观测性能力加强]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136323767</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136323767</guid><author>DBAIOps</author><pubDate>Tue, 27 Feb 2024 15:27:47 +0800</pubDate><description><![CDATA[因为我们团队缺乏对金仓数据库的了解，并且当时能够获得的文档也十分有限，而人大金仓数据库能够对外提供的可观测性接口也十分有限，也没有我们在Oracle数据库上习惯使用的AWR报告，ASH报告，等待事件分析等功能。丰富的文档为我们梳理KES的运维知识提供了很大的便利，我和几个KES的老用户交流的时候，他们也觉得V8版本在文档上的提高还是挺大的，这些文档对他们日常运维也很有帮助。我们不仅能够了解数据库的IO负载情况，也能了解数据库的IO质量，从而更为准确的掌握数据库的状态，找到数据库运行中的短板。]]></description><category></category></item><item><title><![CDATA[进一步讨论达梦的故障定位与分析]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136323677</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136323677</guid><author>DBAIOps</author><pubDate>Tue, 27 Feb 2024 15:24:54 +0800</pubDate><description><![CDATA[将dmserver的oom_score_adj设置为-1000后，dmserver的oom_score就永远是0了，于是达梦数据库就不会被杀掉了（对于早期一点的Linux版，将oom_adj设置为-17达到的是同样的效果，在7.4上面直接设置oom_adj为-17，系统自动会将oom_score_adj设置为-1000）。上一篇遇到的达梦数据库宕库问题，最终分析的结论虽然是操作系统SWAP区耗尽导致，与达梦数据库无关，但是根本原因是什么，以及以后如何规避类似问题，是更为重要的问题。至此，此问题基本解决。]]></description><category></category></item><item><title><![CDATA[一次达梦数据库宕机的分析过程]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136314826</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136314826</guid><author>DBAIOps</author><pubDate>Tue, 27 Feb 2024 10:04:14 +0800</pubDate><description><![CDATA[至此我们的工作并没有完成，由于我们以前在知识上的误区，导致了这次宕机并没有被十分明显的报出来，我们的健康模型与运维经验报警都没有准确的对此次故障进行预警。通过这个故障的分析，我们将调整两个知识库，一个是达梦的健康模型，以前的模型中只关注物理内存空闲比例，而没有关注SWAP的使用率，因此我们必须将SWAP使用率的成分加入到健康模型中。从诊断报告上可以看出，在可能导致宕机故障的时间段内，有一个明显的问题，就是虽然物理内存还有较多空闲，但是操作系统的SWAP使用率比较高，超过95%，甚至出现了100%的现象。]]></description><category></category></item><item><title><![CDATA[学习达梦数据库的基本概念]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136298777</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136298777</guid><author>DBAIOps</author><pubDate>Mon, 26 Feb 2024 14:33:32 +0800</pubDate><description><![CDATA[每一个用户都有一个默认的表空间。达梦的数据记录是存储在页中的，因为一条达梦的数据记录不能跨页，因此记录的总长度收到页的限制，达梦7规定一条记录的总长度不能大于页大小的一半。达梦的页的概念与Oracle的BLOCK是类似的，页的大小从4K到32K，默认的页大小是8K，页大小在数据库创建时确定，一旦确定，不能修改。好了，今天就学习到这里，达梦数据库在逻辑架构上的与Oracle的相似性，是DBA的福音，Oracle DBA可以比较容易理解达梦数据库，在做数据库优化的时候，也可以参考部分Oracle的经验。]]></description><category></category></item><item><title><![CDATA[【无标题】]]></title><link>https://blog.youkuaiyun.com/DBAIOps/article/details/136292024</link><guid>https://blog.youkuaiyun.com/DBAIOps/article/details/136292024</guid><author>DBAIOps</author><pubDate>Mon, 26 Feb 2024 10:36:56 +0800</pubDate><description><![CDATA[因为从达梦的BLOCK结构来看，和Oracle是完全不同的，如果说相似，达梦的BLOCK结构和INNODB的PAGE结构有点类似，比较凑巧的是，达梦和INNODB都采用了BTREE表，而不是Oracle的HEAP表。提出这个问题的人可能感叹于达梦和Oracle在使用方法上的相似性，不过这种相似性，是达梦公司二十多年来不断的模仿，积累的结果，绝不是简单的偷了人家的代码。今天我简单的分析了一下目前PG的两个USTORE实现，这也是广大PGER期望的功能，如果PG能够解决ASTORE带来的问题，将会完美的多。]]></description><category></category></item></channel></rss>