一、背景 复杂sql查询报错 二、原因 单条s q l使用内存默认为1G 三、解决 tiup cluster edit_config tidb-test server_configs: tidb: mem-quota-query: 4294967296 # 修改大小 tiup cluster rel
记druid 连接池没满,但超时问题 GetConnectionTimeoutException active 5, maxActive 100 问题说明 线上服务突然出现报错，通过日志查找发现是因为服务升级导致压力集中到某个节点上，出现连接获取超时导致的。 从日志中也找到了异常。 异常信息： co
1.什么是RAC（Real Application Cluster）？ RAC（Real Application Cluster）是Oracle数据库的一种部署架构，它将多个数据库服务器连接在一起，共同组成一个实例。这些服务器之间通过高速网络相互通信，共享存储和计算资源，从而提供更高的可用性、性能和
1. 环境 拓扑： host2 host3"> 网卡配置： host1: 192.168.1.1/24host2: 左eth0: 192.168.1.2/24 右eth1: 192.168.2.2/24 host3: 192.168.2.1/24 2. 需求描述 需要实现主机host1能够与host
vCenter报错：Vmware vAPI Endpoint 问题现象： 平台警报1：设备管理运行状况警报 平台警报2：Vmware vAPI Endpoint服务运行状况警报 vcenter版本：vc 6.7 监控，查找相关事件，appImgmt服务异常（状态从green转为red），appImg
前言 监控指标诚然是发现问题于微末之时的极佳手段，但指标往往有其表达的极限。在很多情况下，单独看一个黄金指标并不能表征系统的健康程度，反而有可能被其迷惑，进而忽略相关问题。(本文所提及的Linux Kernel源码版本为4.18.10) Bug现场 某天中午，某应用的999线突然升高。由于是个QPS
开篇 《K3s 系列文章》 《Rancher 系列文章》 问题概述 20220606 5G IoT 网关设备同时安装 K3S Server, 但是 POD 却无法访问互联网地址，查看 CoreDNS 日志提示如下： ... [ERROR] plugin/errors: 2 update.traefi
背景 最近真是和 Pulsar 杠上了，业务团队反馈说是线上有个应用消息重复消费。 而且在测试环境是可以稳定复现的，根据经验来看一般能稳定复现的都比较好解决。 定位问题 接着便是定位问题了，根据之前的经验让业务按照这几种情况先排查一下： 通过排查：1,2可以排除了。 没有相关日志 存在异常，但最外层
以下是一个使用乐观锁处理库存数量并发问题的c#示例代码： ```csharp using System; using System.Data; using System.Data.SqlClient; public class InventoryService { private string co
背景 最近有一个需求需要自定义一个多继承abc.ABC与django.contrib.admin.ModelAdmin两个父类的抽象子类，方便不同模块复用大部分代码，同时强制必须实现所有抽象方法，没想按想当然的写法实现多继承时，居然报错metaclass conflict： In [1]: impo
背景 之前在一次不规范HTTP请求引发的nginx响应400问题分析与解决 中写过客户端query参数未urlencode导致的400问题，当时的结论是： 对于query参数带空格的请求，由于其不符合HTTP规范，golang的net/http库无法识别会直接报错400，而nginx和使用uwsgi
## 背景 线上启用memcached(以下简称mc)作为热点缓存组件已经多年，其稳定性和性能都经历住了考验，这里记录一下踩过的几个坑。 ## 大key存储 某年某月某日，观察mysql的读库CPU占比有些异常偏高，去check慢查询log，发现部分应有缓存的慢sql居然存在几秒执行一次情况，不符合
回忆起来也是有些年没亲自动手搭建ADG了，今天正好有个机会重温，客户环境是19.16，恍惚记得上一次搭ADG还是在11.2.0.4的时代，时光荏苒啊。 正好看下19c的ADG和11g的ADG在部署方面有啥不同？ 主备库都是RAC架构，数据库是CDB架构，包含有4个PDB，整个搭建过程还是遇到很多小问
本文演示关于19c RU补丁常见报错问题的分析处理： 1.查看补丁应用失败的原因 2.问题解决后可继续应用补丁 3.发现DB的RU补丁未更新 4.opatchauto应用DB补丁报错解决 1.查看补丁应用失败的原因 补丁应用失败有详细日志记录原因; 故意使用oracle用户解压补丁，然后测试是否可以
技术人当遇到具体问题，能给出的各种解决方案，有一种类型叫做workaround，翻译过来通常为“应变方法”、“变通方法”； 其实这种方式通常是没有找到根本的解决方案，但是为了快速恢复业务而采用的一种巧妙规避/跳过的方式。 举个具体的例子：我有测试需求要在主库创建一个新的PDB： 1.创建新的PDB
最近，自己的一个测试环境，遭遇了hacker攻击。 具体是oracle用户被攻破了，原因是该环境通过DDNS连接到了外网，而因为只是测试，没有注意安全防范，设置的口令过于简单。 下面记录下，也作为警醒。 1.发现资源使用异常 CPU告警，使用top去查询资源使用情况发现CPU使用率非常高，达到94%
有客户遇到ORA-2289的报错，同事协助去现场排查，我帮着远程共同check下。 客户只是应用端报出的错误，为了进一步定位，服务端需要开errorstack协助定位具体问题。 下面就以这个ORA-2289为例，示范下errorstack的使用方法。 --开启errorstack alter sys
今天去现场帮一个客户排查备份网络速率问题。 用户期望是万兆的速率，但实际上目前只有千兆，因为目前上面运行着数据库，且数据量较大，千兆的备份网络速率不能满足用户备份数据库的时长要求。 首先，确认备份网络是由两块网卡（eth3，eth4）做了bonding，起名为bondeth1。 使用ethtool查
为客户测试一个ADG场景问题，发现测试环境的日志切换频率过低，总是需要定期手工切换，这非常影响测试心情。 实际上，可以设置archive_lag_target参数强制日志切换。 比如设置： alter system set archive_lag_target=1800; 这样即使库没任何压力，半小
最近有用户一体机有问题，需要技术支持，首先找到我这边，其实就是一个简单的坏盘类问题，换盘即可。 在保期间，要求客户提交一个SR给后台，但是客户提交后，就一直被要求提供HW的CSI号： > xxx: Can I have the HW CSI? 最后SR被后台关闭，并被转到CT，还是要求客户通过HW的
