ORACLE通过透明网关建dblink连接Postgresql的几个问题
问题1:where条件查询失败ORA-00997:select "big","small" from "test_bigint"@dblink_b_bak where "big"='1';select "big","small" from "test_b
MySQL数据库架构——高可用演进
原创 徐轶韬 MySQL解决方案工程师 MySQL发展至今,在高可用性方面
MySQL数据库SYS CPU高的可能性分析
转自:http://mysql.taobao.org/monthly/2015/05/02/问题背景我们在管理繁忙的 MySQL 数据库时,可能都有碰到 SYS CPU 高的经历:系统突然 SYS CPU 高起来,甚至比 USER CPU 高很多,这时系统 QPS、TPS 急剧下降。SYS CPU高是什么造成的呢?主要有2种可能:context switch 不高,但在内核态 spin,导致 SY
MYSQL connector 的 NullReferenceException bug
mysql connector 连接报错, 客户端在MySqlClient.MySqlDataReader.NextResult() 处报错,IIS进程池crash后 db端提示Got an error reading communication packets。异常时堆栈调用信息:ServerConnectionInfo.Finallize()=>ServerConnection
MYSQL connector/.NET 默认的 show variables 引起的线程mutex锁争用
1)检查当时的主机资源状态,其cpu 内存,磁盘IO 负载实际都并不高。 复查主机资源发现当时的load avage指标异常,1分钟平均负载量达到100以上,5分钟平均负载量达到90以上,10分钟平均负载量达到60以上,说明当时cpu的运行队列出现排队现象。2)当时的thread cache size 分别出现两次耗尽情况,大量的线程处于running的状态。3)从后台慢日志看,show vari
obj$等数据字典表的统计信息采集机制一些整理
从11g开始,自动统计信息收集任务的时间窗口:11g+ Automatic Maintenance TasksWhat is the name of the default stats gathering job on 11g?The automatic statistics gathering job on 11g is called "auto optimizer stats col
关于Heap中的一些概念
Oracle的内存是以heap的形式进行管理,这包括常见的SGA和PGA。- 物理形式上,一个内存heap包括header或者header descriptor以及一些extents 。- 逻辑形式上,一个heap可能包含多个subheap。subheap中的extents来源于它的父heap;heap和subheap通过free lists和LRU lists来管理空闲以及使用的空间
关于mysql字符集及排序规则设置
How Can I Change the Default Character Set and Collation for a Database in MySQL? (Doc ID 1023320.1)To determine the default character set and collation for a database, enter this SQL statement:查询:Beg
datapump 导出导入ORA-07445
没有规范整理,比较乱,仅作为笔记备忘!Archived Log entry 52860 added for thread 1 sequence 52864 ID 0x453c1294 dest 1:Wed Aug 12 19:27:25 2020DM00 started with pid=628, OS id=46554, job SYS.SYS_EXPORT_SCHEMA_01Wed Aug 1
create index ORA-00376 处理方法
临时段reuse引起的异常,小记!SQL> create index cwdtest.testidx1 on cwdtest.tab_level_2(FID) tablespace testidx;create index cwdtest.testidx1 on cwdtest.tab_level_2(FID) tablespace testidx &nbs
java.sql.SQLRecoverableException: IO Error: Socket read timed out 排查历程
一:12c迁移19c工程,针对大数据相关定时作业进行性能对比,发现部分作业连接19c 出现 Socket read timed out 问题,并且可以复现,该部分作业连接12c并无异常初步排查情况如下:1)在执行到某部分sql时jdbc抛出Error: java.io.IOException: SQLException in nextKeyValue 错误,导致的原因是Caused by: jav
oracle 并行查询时并行资源分配追踪测试
小实验:通过oracle自带的并行追踪进行对比测试,参考文档(Tracing Parallel Execution with _px_trace (Doc ID 444164.1))。分别进行了3次对比测试:1.第一次实验:parallel_max_servers=2,表并行度=2,查询观察启用并行进程情况。 实验结果:执行计划px,sql启用2个并行
oracle trouble shooting 时看 call stack
call stack 和system call 的区别!在ORACLE 中我们常用call stack 来匹配是否命中某些bug,这时查看call stack 中的函数调用路径来进一步印证。在某些情况下,例如进程执行慢,我又会通过strace ,truss 来追踪某个进程,查看其系统调用 情况。那么call stack 和system call 的区别是什么?首先说system call:操作系统
从10046 trace 的trca报告中总结的时间模型示例
用于快速分析10046的时间消耗情况~1)本次追踪的会话一共花费的时间是37秒左右,2)其中17秒左右花费在sql实际执行上,主要是fetch时的cpu消耗,3)其中18秒左右是在空闲等待上,等待事件是SQL*Net message from client。具体我画了以下图表以便更直观理解:
session视图中wait_time
V$SESSIONWAIT_TIMENUMBERIf the session is currently waiting, then the value is 0. If the session is not in a wait, then the value is as follows:> 0 - Value is the duration of the last wait in hundr
MYSQL CPU部分单核占满会影响建立数据库连接效率?
问题描述:cpu 瞬间爆满,前台应用程序报出 too many connection错误,mysql ERROR日志报出[Warning] Too many connections,操作系统日志报出: kernel: TCP: time wait bucket table overflow。主机的资源情况如下:1.CPU 总体资源不高,但出现单核使用率100% 情况2.CPU 系统中断和上下文切换
RAC中GPNP 文件相关及修改
针对RAC中一些启动故障,常常是与GPNP相关的问题,在这篇文章中,我将解释什么是GPnP配置文件以及它如何被群集件使用,并且通过小小实验来进行常说的修改GPNP文件。什么是GPNP? GPNP配置文件是位于GRID_HOME / gpnp / / profiles / peer中的一个很小XML文件
oracle12.2 adg ORA-46952: standby database format mismatch for password file
oracle 12.2 adg 在应用日志时报出这个问题Errors in file /app/oracle/oracle/diag/rdbms/o12dbadg/O12DBDG/trace/O12DBDG_pr00_186543.trc:ORA-46952: standby database format mismatch for password file '/app/or
MYSQL count标量子查询改left join
SELECT homepageId, userId, homepagesummary, totalviews, totalleadpercents, totalappointments, homepagestatus, linkphone, imagepath, createtime, updatetime, recommendtime, sortcode, designerimagepath,
oracle 12c 新增的LREG进程及其动态注册的过程
因刚好遇到12c 监听注册的问题,现将以前关于oracle 12c lreg进程的一些学习文章分享下:在oracle数据库中pmon 进程一直承担着较多的工作,例如清理进程以及监听注册等,这相当于一个人需要同时做好几件工作,而当其中一件让他应接不暇时,也许这会影响它负责的其他工作,曾经在11g r2版本的数据库遇到过pmon 进程因忙于清理异常中断的会话而导致服务更新和服务注册