ITPub博客

call stack 和system call 的区别！在ORACLE 中我们常用call stack 来匹配是否命中某些bug，这时查看call stack 中的函数调用路径来进一步印证。在某些情况下，例如进程执行慢，我又会通过strace ,truss 来追踪某个进程，查看其系统调用 情况。那么call stack 和system call 的区别是什么？首先说system call：操作系统

用于快速分析10046的时间消耗情况~1）本次追踪的会话一共花费的时间是37秒左右，2）其中17秒左右花费在sql实际执行上，主要是fetch时的cpu消耗，3）其中18秒左右是在空闲等待上，等待事件是SQL*Net message from client。具体我画了以下图表以便更直观理解：

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

问题描述：cpu 瞬间爆满，前台应用程序报出 too many connection错误，mysql ERROR日志报出[Warning] Too many connections，操作系统日志报出： kernel: TCP: time wait bucket table overflow。主机的资源情况如下：1.CPU 总体资源不高，但出现单核使用率100% 情况2.CPU 系统中断和上下文切换

    针对RAC中一些启动故障，常常是与GPNP相关的问题，在这篇文章中，我将解释什么是GPnP配置文件以及它如何被群集件使用，并且通过小小实验来进行常说的修改GPNP文件。什么是GPNP？    GPNP配置文件是位于GRID_HOME / gpnp / / profiles / peer中的一个很小XML文件

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

SELECT homepageId, userId, homepagesummary, totalviews, totalleadpercents, totalappointments, homepagestatus, linkphone, imagepath, createtime, updatetime, recommendtime, sortcode, designerimagepath,

因刚好遇到12c 监听注册的问题，现将以前关于oracle 12c lreg进程的一些学习文章分享下：在oracle数据库中pmon 进程一直承担着较多的工作，例如清理进程以及监听注册等,这相当于一个人需要同时做好几件工作，而当其中一件让他应接不暇时，也许这会影响它负责的其他工作，曾经在11g r2版本的数据库遇到过pmon 进程因忙于清理异常中断的会话而导致服务更新和服务注册

在某次重启数据库后，发现实例服务一直无法注册，而仅有asm实例的服务注册：lsnrctl status LSNRCTL for Linux: Version 12.2.0.1.0 - Production on 17-JAN-2020 19:43:44 Listening En

如果你的系统需要在一张很大的表上创建一个索引，你会考虑哪些因素？ 1）关于大表创建索引，如果从综合考虑多个维度来看，我会考虑:1.为什么需要创建索引，即索引创建的之后的性能是否能够提升2.创建什么样的索引，即索引的类型3.创建索引的影响，此时需要了解索引的创建过程，以及如果优化索引的创建效率以减少对业务的影响4.什么时候创建索引5.有没有其他方式来替代这个过程 2）以下关于几种

instrunments:生产者，用于采集mysql中各种操作产生的事件信息，对应配置表中的配置项，我们可以称之为采集配置项。consumers:消费者，对应的消费者用于存储来自instruments采集的数据，对应配置表的配置项，我们可以称之为消费存储配置项。启用所有等待事件的instruments:use performance_schemaupdate  setup_instrum

在数据库进行CTAS操作查询表ooo.A_D_BRXXX_XXX_XXX时报出了ORA-08103错误，SQL> create table A_D_BRXXX_XXX_XXX_1125 as select * from OOO.A_D_BRXXX_XXX_XXX;ORA-08103: object no longer exists 关于ORA-08103的解释：Error: ORA

介绍    XA代表“扩展架构”，是The Open Group创建的用于分布式事务处理的标准。MySQL 5.0是第一个支持XA的版本，到了MySQL 5.7已经去消除了主要限制问题，修复了许多bug，并增加了覆盖总体范围测试用例。背景    XA解决了当跨分布式资源情况下能在单个事务中保留ACID属性的问题。资源本身可以是其他MySQ

　　1 原理　　关于MySQL数据库的分布式事务XA，分布式事务实现的原理，可见[3];关于MySQL XA的说明，可见[1][2]。　　MySQL XA分为两类，内部XA与外部XA;内部XA用于同一实例下跨多个引擎的事务，由大家熟悉的Binlog作为协调者;外部XA用于跨多MySQL实例的分布式事务，需要应用层介入作为协调者(崩溃时的悬挂事务，全局提交还是回滚，需要由应用层决定，对应用层的实现要

示例SQL:SELECT q.queueid FROM render.queues q WHERE q.queueid in ( SELECT max(queueid) FROM ( SELECT t.queueid FROM queues t WHERE

        在ORACLE 中,我们常常推荐使用exists 来替代in,往往也能取得比较好的优化效果。在ORACLE应用迁往MYSQL的过程中，我们发现部分in 的子查询语句带到MYSQL中，其执行效率变得非常低下，这很让人觉得匪夷所思。于是，我分析了一波。    对两个表

10个并发共插入10万行总耗时(s)第一次第二次第三次NT(-2147483648-2147483647)198.13197.25197.56BIGINT(-9223372036854775808-9223372036854775807)195.83197.75197.85VARCHAR[0-655

10个并发共插入10万行 总耗时(s)                              &

最近在ORACLE 到MYSQL的使用ＯＧＧ进行数据迁移中遇到了数据在双向同步数据死循环的问题，在正常对oracle的同步上，我们使用以下参数来防止抽取进程对复制进程提交的事务进行抽取：TRANLOGOPTIONS EXCLUDEUSER OGG GETAPPLOPS  IGNOREREPLICATES实际上tranlogoptions excludeuser　Ｏ

最近在ORACLE 到MYSQL的使用ＯＧＧ进行数据迁移中遇到了数据在双向同步数据死循环的问题，在正常对oracle的同步上，我们使用以下参数来防止抽取进程对复制进程提交的事务进行抽取：TRANLOGOPTIONS EXCLUDEUSER OGG GETAPPLOPS  IGNOREREPLICATES实际上tranlogoptions excludeuser　Ｏ