[转帖]记一次线上Oracle连接耗时过长的问题

一次,oracle,连接,耗时,过长,问题 · 浏览次数 : 0

小编点评

## 问题定位排查总结 **问题现象1、2、3、4、5:** 都是由于DNS配置问题导致的连接缓慢问题。 **问题1、2、3:** * 使用了不同的文件路径修改DNS配置,导致设置不完整或存在语法错误。 * 清空DNS配置后,由于DNS缓存机制,旧的 DNS 记录无法 immediately 被更新,导致连接速度缓慢。 **问题4:** * Windows运维机器安装了Navicat客户端,可能使用的是本地DNS服务,而宿主机配置的DNS服务器无法被访问。 **问题5:** * 使用了Linux的SQLPLUS客户端,可能需要设置环境变量`ORACLE_HOME`来指定Oracle数据库的安装路径,该路径可能不包含`/dev/urandom`等文件路径。 ## 解决方案 1. **检查DNS配置:** * 使用`dig`工具测试宿主机和目标Oracle数据库的DNS配置是否正确。 * 使用`nslookup`工具测试宿主机通过DNS向目标数据库服务器发送查询。 2. **修改DNS配置:** * 确保文件路径在DNS配置文件中正确配置。 * 确保DNS服务器能够访问目标Oracle数据库的服务器。 3. **测试连接速度:** * 使用`ping`工具测试宿主机和目标数据库服务器的响应时间。 * 使用数据库连接工具测试连接速度。 4. **检查Navicat连接:** * 确保Navicat客户端已正确安装并配置。 * 测试连接目标Oracle数据库的服务器地址和端口。 5. **设置环境变量`ORACLE_HOME`:** * 在Linux环境中,设置`$ORACLE_HOME`环境变量,指定Oracle数据库的安装路径。 * 在Windows环境中,设置`%ORACLE_HOME%`环境变量,指定Oracle数据库的安装路径。

正文

https://www.cnblogs.com/changxy-codest/p/15670495.html

 

问题现象

1、远程Oracle数据库通过IP:PORT/SERVICE_NAME连接

2、应用服务通过Docker容器部署,访问Oracle联通性测试接口,需要50s左右才能返回连接成功;

3、写了个JDBC测试程序,放在宿主机进行JDBC连接Oracle数据库测试,发现连接耗时不稳定,时快时慢,下图为宿主机连接数据库耗时截图;

4、通过Windows运维机器安装Navicat客户端,连接目标Oracle数据库,连接速度很快;

5、Linux宿主机安装SQLPLUS客户端,连接目标Oracle数据库,连接速度很快;

 

 

 

初步排查

看了很多技术博客,基本都是将file:/dev/random修改为file:/dev/urandom、file:/dev/./urandom、file:/dev/../dev/urandom等,实测无效,可能碰到的不是一个问题

 

问题定位

排查到DNS时,发现宿主机DNS配置清空后,通过JDBC连接目标Oracle数据库速度很快

进入容器中进行测试,发现清空DNS配置后连接速度也很快了,至此问题解决

清空DNS配置命令:echo > /etc/resolv.conf

与[转帖]记一次线上Oracle连接耗时过长的问题相似的内容:

[转帖]记一次线上Oracle连接耗时过长的问题

https://www.cnblogs.com/changxy-codest/p/15670495.html 问题现象 1、远程Oracle数据库通过IP:PORT/SERVICE_NAME连接 2、应用服务通过Docker容器部署,访问Oracle联通性测试接口,需要50s左右才能返回连接成功;

[转帖]记一次使用nacos2踩到的坑

https://cloud.tencent.com/developer/article/2077110?areaSource=104001.26&traceId=7WZNP412yK3vh7ebw4th0 前言 本文素材来源朋友学习nacos2.1.1踩到的坑。直接上正菜 坑点一:出现端口被占用 因

[转帖]记一次靠谱的 K8S 排错实战过程,硬核!

http://blog.itpub.net/31545813/viewspace-2925035/ 一 背景 收到测试环境集群告警,登陆 K8s 集群进行排查。 二 故障定位 2.1 查看 Pod 查看 kube-system node2 节点 calico pod 异常。 查看详细信息,查看nod

[转帖]记一次靠谱的 K8S 排错实战过程,硬核!

http://blog.itpub.net/31545813/viewspace-2925035/ 一 背景 收到测试环境集群告警,登陆 K8s 集群进行排查。 二 故障定位 2.1 查看 Pod 查看 kube-system node2 节点 calico pod 异常。 查看详细信息,查看nod

[转帖]记一次flannel网络调整

https://www.jianshu.com/p/a772e4b951f2 背景 最近给一个子公司部署一套k8s集群,集群搭建完之后有几个新需求需要新增几个node节点,在新增节点时发现添加失败,经过查询发现是网络规划问题导致。 flannel启动失败,报错信息如下:Error registeri

[转帖]记一次压测引起的nginx负载均衡性能调优

https://xiaorui.cc/archives/3495 这边有个性能要求极高的api要上线,这个服务端是golang http模块实现的。在上线之前我们理所当然的要做压力测试。起初是 “小白同学” 起头进行压力测试,但当我看到那压力测试的结果时,我也是逗乐了。 现象是,直接访问Golang

[转帖]记一次使用gdb诊断gc问题全过程

https://www.cnblogs.com/codelogs/p/17092141.html 简介# 上次解决了GC长耗时问题后,系统果然平稳了许多,这是之前的文章《GC耗时高,原因竟是服务流量小?》然而,过了一段时间,我检查GC日志时,又发现了一个GC问题,如下:从这个图中可以发现,我们GC有

[转帖]记一次vcsa6修复过程

一、 某天发现一台vmware vCenter Server Appliance services 6偶尔能登陆了,但极不稳定,连shell都偶尔能进...... 然后利用各种手段想方设法进到shell里,这是必须的,否则白谈.... 首先查看空间:df -h,发现/和/storage/log都用了

[转帖] 记一次使用gdb诊断gc问题全过程

记一次使用gdb诊断gc问题全过程 原创:扣钉日记(微信公众号ID:codelogs),欢迎分享,转载请保留出处。 简介# 上次解决了GC长耗时问题后,系统果然平稳了许多,这是之前的文章《GC耗时高,原因竟是服务流量小?》然而,过了一段时间,我检查GC日志时,又发现了一个GC问题,如下:从这个图中可

[转帖]记一次sst文件损坏修复过程

https://tidb.net/blog/54e388c8 【2023-07-14 14:26:28】应用系统报警删除数据失败,查看日志报Region is unavailable,同时企业微信群也收到数据库告警信息。 二、问题定位 首先查看集群进程都正常,登录tidb dashboard查看日志