概念上:1.spid (system process id)  是操作系统层面的进程id .2.pid(process id)  这个是基于oracle的进程id个人理解为就是oracle给自己的进程的一个编号.3.sid.(这个就是session 的id) 这个个人理解为,就是有人在同oracle连接会话,oracle为其分配的一个编号.长用于连接其他列.说道这还的和几个动态性能视图联系起来.1.v$process视图  此视图包含当前系统中oracle的所有的进程信息,常被用于将oracle

v$cluster_interconnects 集群节点间通信使用的IP地址 错误信息 使用了公网进行连接 SQL> select * from v$cluster_interconnects; NAME IP_ADDRESS IS_ SOURCE CON_ID eth0 192.168.1.70 OS dependent software 0 日志信息 Filename=alert_+ASM1.log ~~~~~~~~~~~~~~~~正常启动~~~~~~~~~~~~~~~~~~~~~~~~ T

作为SQL Trace的扩展功能,Oracle 10046 event(10046事件)是一个重要的调试事件,也可以说是系统性能分析时最重要的一个事件,它包含比SQL Trace更多的信息.但可惜的是,10046事件并不是Oracle官方提供给用户的诊断工具,官方文档上面也没有详细的说明,不过还是可以从很多国内外专家技术文档找到相关学习资料,本文主要参考Oracle MOS文档来学习总结下10046事件的用法. 关于SQL Trace的收集方式可以参考另一篇博文:Oracle 11g R2性能优

该资料已上传至本人QQ群空间,如需该资料,可到本人QQ群空间查找.下面贴表文本: Oracle Performance Diagnostic GuideHang/LockingVersion 3.1.0 January 13, 2009Welcome to the Oracle Performance Diagnostic Guide This guide is intended to help you resolve query tuning, hang/locking, and slow d

2: dump (不包括lock element) 10: dump 11: dump + global cache of RAC 256: short stack (函数堆栈) 258: 256+2 -->short stack +dump(不包括lock element) 266: 256+10 -->short stack+ dump 267: 256+11 -->short stack+ dump + global cache of RAC level 11和 267会 dump

一.准备工作 1.准备CentOS 7 系统环境 由于是使用静默模式(silent)安装的,无需使用图形化界面,我选择了最小安装的服务器版的CentOS 7.安装完成后,只有命令行界面. 2.下载 Oracle 11g (1)Oracle官方网站:http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html 我的机器安装的是CentOS7 64位系统,因此下载的Oracle版本也是64位的 特

一.前期环境准备 1.硬件信息 (1)主机版本 [root@localhost ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.7 (Maipo) [root@localhost ~]# (2)CPU [oracle@localhost soft19]$ cat /proc/cpuinfo | grep "physical id" | uniq |wc -l 8 [root@localhost

终止EBS并发请求后,解锁相关的进程. 还有种方法可以在PLSQL->tools->session 中找到并且kill Every concurrent Request uses some resources for running. If we find that the concurrent request is taking long time and decided to terminate the concurrent request , the resources may not

这篇博客是上一篇博客Oracle shutdown immediate遭遇ORA-24324 ORA-24323 ORA-01089的延伸(数据库挂起hang时,才去重启的),其实这是我们海外一工厂的遇到的案例,把内容拆开是因为这个case分开讲述显得主题明确一些.正式进入主题: 服务器数据库版本Oracle Database 10g Release 10.2.0.4.0,操作系统为Red Hat Enterprise Linux Server release 5.7,虚拟机.当时告警日志里面出

shutdown immediate 经常关库时hang住,在alert中有 License high water mark = 4All dispatchers and shared servers shutdown 多等一会会出现SHUTDOWN: Active processes prevent shutdown operation 造成这个现象的原因是(也可能是em的原因,这篇与em无关): 之前的session没有断开,而后又使用了host切换到OS提示符下,导致数据库无法正常关闭 [

Library cache lock/pin 一.概述 ---本文是网络资料加metalink 等整理得来一个实例中的library cache包括了不同类型对象的描述,如:游标,索引,表,视图,过程,等等. 这些对象不能在他们被使用的时候改变,他们在被使用的时候会被一种library locks and pins的机制锁住. 一个会话中,需要使用一个对象,会在该对象上先得到一个library lock(null, shared or exclusive模式的)这是为了,防止其他会话也访问这个对

在使用shutdown immediate关闭数据库时hang住,查看alert 日志,遭遇了SHUTDOWN: Active processes prevent shutdown operation.也即是说有一些活动进程阻止了当前的shutdown操作.咦,数据库是测试数据库啥也没有干,也没有配置db console,还有活动进程阻止呢? 1.情景再现 SQL> select * from v$version where rownum<2; BANNER -----------------

数据库连接的客户端异常断开后,其占有的相应并没有被释放,如从v$session视图中依旧可以看到对应的session处于inactive,且对应的服务器进程也没有释放,导致资源长时间地被占用,对于这种情形开该如何处理呢?SQLNET.EXPIRE_TIME对于这个问题我们提供了解决方案,专门用于清理那些异常断开的情形,如网络异常中断,客户端异常掉电,异常重启等.本文描述了设置SQLNET.EXPIRE_TIME参数以及演示死连接以及资源被释放的情形. 1.理解SQLNET.EXPIRE_TIME

[20190319]shared pool latch与library cache latch的简单探究.txt --//昨天看Oracle DBA手记3:数据库性能优化与内部原理解析.pdf 电子书,看了eygle的关于latch之类的测试.--//自己也重复测试看看. --//首先说明一下11g已经不存在这个shared pool latch,改为mutexes.所以测试在10g下进行:--//注意不要在生产系统做这样的测试!! 1.环境:SCOTT@test> @ &r/ver1POR

今天启动数据库时报错了! SQL> startup mount ORACLE instance started. Total System Global Area  608174080 bytes Fixed Size                 1220844 bytes Variable Size            176164628 bytes Database Buffers      427819008 bytes Redo Buffers             296960

今天启动数据库时报错了! SQL> startup mount ORACLE instance started. Total System Global Area  608174080 bytes Fixed Size                 1220844 bytes Variable Size            176164628 bytes Database Buffers      427819008 bytes Redo Buffers             296960

--查询dbwr进程号 select pname,spid from v$process where pname like 'DBW%'; PNAME SPID----- ------------------------DBW0  9776      ---查询的是操作系统的进程号 --linux 系统查询的进程号 [oracle@yang admin]$ ps -ef|grep ora_dbw |grep -v grep UID        PID  PPID       C        

启动数据库时报错了! SQL> startup mount ORACLE instance started. Total System Global Area  608174080 bytes Fixed Size                 1220844 bytes Variable Size            176164628 bytes Database Buffers      427819008 bytes Redo Buffers             2969600

无意翻到之前收藏的一个文档,共享一下. Solaris/Linux 命令手册 1. 系统 # passwd:修改口令 # exit:退出系统 2. 文件 # cp:复制文件或目录,参数:-a递归目录,-i覆盖确认 # mv:改名移动 # rm:删除,参数:-r递归删除 3. 目录 # mkdir:创建目录 # rmdir:删除空目录 # cd:改变工作目录 # pwd:查看当前路径 # ls:列目录,参数:-a所有文件,-c按时间排序,-l详细信息 4. 文本 # sort:排序 # uniq:

[20191119]探究ipcs命令输出2.txt --//继续上午的测试:http://blog.itpub.net/267265/viewspace-2664758/=>[20191119]探究ipcs命令输出.txt--//先补充ipcs 剩余2个参数 -l -u--//-l     limits--//-u     summary $ ipcs -l------ Shared Memory Limits --------max number of segments = 4096max s

今天数据库访问突然很慢,通过top命令发现oracle的cpu使用率很高.同事建议查询一下看看是什么语句导致的oracle运行变慢.于是从网上查了一下,可以根据pid查询出正在执行的查询语句,发现是一个大表的字段没有创建索引导致全表扫描.具体操作步骤如下: 切换到oracle账户下并输入密码 su - oracle 通过sqlplus nolog进入命令查询界面 sqlplus /nolog 连接进入sysdba账户 connect sysdba 执行以下sql语句     SELECT