​​IT之家​​3月1日消息，微软今天更新了Windows发布运行状况日志。微软解释说，第三方定制应用程序可能导致explorer.exe出现错误，而且可能会在一个循环中重复多次。IT之家从日志中获悉，微软特别提到了StartAllBack和ExplorerPatcher这两个程序，不过其他类似的用户界面自定义工具也有可能导致该问题。Microsoft建议​​Windows11​​管理员在安装操作系统的最新累积更新之前，从设备中删除上述两个应用程序和任何其他应用程序。对于已经受到该问题影响的用户，微软建议联系所安装应用程序的开发人员寻求帮助。

当下泛DBA化的趋势是非常明显的，一方面业务对多类型数据库的实际需求，DBA不能只立足玩转一款数据库产品，关系型+非关系型/OLAP+OLTP/图数据库/消息存储，但凡跟数据有关的都可能是DBA需要去了解的。另一方面上云后DBA不用再为过去繁重的基础设施稳定性保障所拖累，同时云上提供了运维管理相关的PaaS化产品，这很大程度降低了DBA管理的复杂性，因此很多人会认为上云了对DBA的依赖就降低了或者干脆就不需要DBA了。从近3年对云实际使用经验看，在人员与业务体量小一点的公司对开发&运维&安全标准规范都没有严格要求跟约束的情况下是适用的，但是体量稍微大一点就玩不转了，尤其混合云的环境下依靠云商能

​二十年前搞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次会比