​二十年前搞Oracle运维的时候，被折腾得最厉害的是共享池的问题，ORA-4031绝对是DBA必须面对的，也是最束手无措的错误。很多DBA面试官也会问大量的共享池诊断与优化的问题，虽然他自己对很多问题的了解也不过如此。今早的这篇文章的主体结构是昨天下班前写出来的，今早做了一些补充就发出来了。因为昨天上午我一直在做D-SMART这个部分的优化设计，这篇文章实际上是我这一天工作的一些总结。Oracle10G以后有了SGA动态分配的能力，而且服务器的内存也从MB级别进入到了VLM的级别，共享池和ORA-4031的问题也就见得少了。在D-SMART里，针对ORA-4031的监控功能比较少，只提供了一

​昨天有朋友看了我的文章提问CHATGPT能不能解读AWR报告。怎么说呢，我们先来看一个例子。我输入了一个AWR报告的TOP10EVENT，看看CHATGPT如何解读吧。如果说解读AWR的TOPEVENTS数据，我想CHATGPT不会比一些人类DBA差了，实际上最初的时候我也是如此解读AWR报告的，只不过AWR报告不仅仅需要能解读，还需要能分析，能够把AWR中各种相关的数据综合起来分析，才能从AWR报告中分析出深层次的问题。对于一些十分明显的问题，仅仅从TOPEVENT就可以看出来了，而绝大多数复杂的问题，是无法从这些地方找出答案的。这一点CHATGPT肯定做不到，甚至大多数人类DBA也做不到

​上周五客户那边出现了一个很奇怪的故障，刚开始我们以为很简单，一个用户环境的Oracle11g数据库报了一个ORA-4030错误，对于DBA来说，这个错误太常见了，马上联想到物理内存不足了。     不过D-SMART的监控并未产生物理内存不足的告警，从监控指标上看，也没有出现物理内存突然下降的时点。D-SMART的诊断工具中也没有发现任何物理内存不足的情况，从ULIMIT上看也没有看到任何异常，和内存相关的限制都是unlimited。当时有点一头雾水的感觉，这肯定是一个我们以前比较少遇到的场景，并且在我们的运维知识图谱中并没有收录这个故障模型。于是我们再次研究了错误信息，发现OS报错的err

针对MySQL数据库如何发现慢SQL、如何优化及预防进行了一次分享，其中主要的理论内容先分享给大家，案例因涉及业务信息，待修改后于后期逐步分享。1主要内容简介本文主要从慢SQL的发现开始介绍，并通过演示，介绍如何发现、如何分析（通过工具等方式进行，文中因涉及业务，因此忽略）。在慢SQL优化部分，通过硬件、操作系统、数据库参数、表优化、SQL改写优化等方面进行介绍，因硬件、操作系统参数及数据库参数方面的实战案例演示需要进行压测等方式进行，分享时未做准备，后续推文中我们将对此进行分享。SQL改写方面，PPT中列举了主要方法（没有介绍全，只针对出现频率非常高的情况进行介绍）。SQL案例因根据生产环境

​前几天写了CPU分析与IO分析的文章，本来昨天想再凑一个内存分析的，不过因为昨天一大早就去拜访客户了，所以今天补上。今天早上本来和优诺的傲寒约好了去他那里取取经，听听他对智能化运维的看法，不过因为一些其他安排临时取消了，十分遗憾。PG数据库遇到内存问题要立即进行分析的场景并不多，因为大多数PG数据库的内存使用率过高的报警并不意味着内存使用情况异常，内存真的不够用了。因为PG数据库是使用DOUBLEBUFFERING机制的，大量的内存很可能被BUFFER/CACHE占用了。上面的free命令可以看到32G内存使用了15G多，但是free只剩下599M了，BUFF/CACHE占了15G多。不过如

环境部署下载源代码，使用IDEA进行部署，项目pom.xml进行maven依赖包添加、配置数据库账号密码、配置开启端口后即可使用tomcat7插件运行项目。搭建过程遇见两个坑点：mysql建议直接使用5.5.*版本的，高版本的会因为mysql的默认配置需要额外配置而遇见各种问题，虽然最后都能搭建成功，但是直接使用低版本的就无需额外配置。项目路径建议直接使用http://IP:port形式，后面不要配置额外的路径，加入额外项目配置后虽然可以部署成功，但是会导致一些页面或者图片加载不成功。进行代码审计时，记得需要额外把\src\main\webapp\WEB-INF\lib\目录下的jar包反编译

​引言TiDB是PingCAP公司研发的开源分布式关系型数据库,具有兼容MySQL协议，易水平扩展、高可用、强一致、HTAP等特性。目前TiDB已在汽车之家论坛，好友粉丝，智能推荐，财务报表，818台网互动等重要业务上应用，本文介绍TiDB数据库在汽车之家的应用与实践实践情况。1.TiDB介绍1.1TiDB数据库的发展 移动互联网时代，海量数据及各种应用场景给数据库存储带来诸多挑战，如海量数据的存储扩展，支持新的数据模型，弹性伸缩的需求等等给传统关系型数据(MySQL,SQLServer,Oracle等)带来巨大挑战。在此背景下新型数据库NewSQL层出不穷，TiDB就是其中的佼佼者。TiDB

前言对于某些特殊的业务场景，比如抢单、秒杀等业务，会导致服务流量瞬间飙升，我们虽然可以通过部署集群的方式分散请求压力，但是仍然可能造成很大的请求延迟。这时，我们可以通过接口限流的方式来保证系统的稳定运行。实现逻辑我们可以通过filter对所有的接口进行拦截，判断这个接口在当前时间窗口内的请求次数，如果超出我们设定的请求上限，就返回无效请求。以限制每个接口最大为10个QPS为例，可以有两种实现逻辑：其一，将这10个请求进行拆分，相当于每100ms可以请求一次。其二，每秒内最多请求10次，而不判断其请求分布范围。两种逻辑的实现也略有差异。实现一每秒请求一次。实现二每秒请求N次。判断每秒请求N次会比

​和人大金仓数据库的第一次接触是2014年某省的省调要把Oracle数据库去掉，换成人大金仓数据库。当时省调自动化处的处长十分忧虑，认为调度这么复杂并且关键的系统，用Oracle还算比较省心，换了国产数据库，会不会今后都没有好日子过了。2016年，全国产方案的调控云在他那儿成功上线，这也确实让我这个OracleDBA感到有些意外。在此期间，我们的优化团队也参与了一些基于金仓数据库的优化工作，第一次接触了这个国产数据库。说实在的，这次优化虽然按用户的需求完成了任务，不过也让我们感到了国产数据库与Oracle的技术差距。因为我们团队缺乏对金仓数据库的了解，并且当时能够获得的文档也十分有限，而人大金

据TechInsights研究机构报告，eSIM或eUICC被认为是SIM卡的下一个迭代，提供了通过OTA改变服务提供商配置文件的能力，而不需要物理的更换SIM卡本身。eSIM是专门为解决物理SIM卡的局限性而设计的。它们包含了所需的新功能，以支持难以或低效地访问物理SIM的连接设备，例如医疗保健设备、联网车辆或一系列其他物联网设备。此外，另一种物联网专用SIM技术iSIM(IT之家注：集成SIM)正在出现，它将eSIM功能结合到单个专用的SoC中。虽然eSIM是焊接在板上并连接到设备处理器的专用芯片，但iSIM将处理器核心和加密集成到SoC中。根据TechInsights对eSIM市场存量的