启动oracle报ORA-01092错误解决方法
启动oracle报ORA-01092错误
执行startup报下面错误；

查看日志${ORACLE_BASE}/diag/rdbms/ora88/ora88/alert/log.xml报错信息如下：

原因是因为：oracle 10201升级到10204后出现的问题
解决方法如下：

重建数据字典表

编译失效对象

数据库启动成功

删除数据库用户失败，报“ORA-01940”
问题描述
删除数据库用户失败，系统显示如下错误信息：

说明：
username表示数据库用户名。
原因分析
查看数据库的联机错误码：

从错误码的信息看该数据库用户有session连接到数据库。
解决方法
1. 以oracle用户登录数据库所在机器。
2. 以sysdba用户连接数据库。

3. 查询该用户的session。

系统显示如下信息：

4. 删除该用户的session。

说明：

5. 查看session的状态，验证session是否被删除。

• 如果用户的session状态status值为inactive，说明没有被删除。请执行4。
• 如果用户的session状态status值为killed，说明已经删除。
6. 删除该用户。

删除用户成功，系统显示如下信息：

删除数据库用户过程报ORA-01940解决办法发表于：2012-09-14 15:06 浏览 （46 ） 标签：
删除数据库用户过程中有用户连接数据库导致无法删除的错误

问题提出：

由于当前用户正连接到数据库，所以无法删除
解决办法：
1、查询此用户的会话进程，

2、结束此用户的所有会话

3、删除用户

删除oracle数据库中的用户时ORA-01940的解决方法

问题如题：
解决方法：
1.查询此用户的会话进程;

2.结束此用户的会话进程；

3.删除用户；

无人连接却删除不了oracle用户（报ORA-01940错误？）
ORACLE数据库大量生成trace文件排查过程
现场彩铃业务环境，创建有USDP测试用数据库用户ring，割接前需要drop掉该用户并重新创建用户，创建应用数据库环境。SYS登陆数据库sqlplus后执行SQL>drop user ring cascade;
遇到如下错误：

反复尝试各种方法drop该用户，每次都遇到相同的报错，提示该用户正在使用。提单到oracle原厂，其专家提供以下方法尝试drop该用户：

再次执行SQL>drop user ring cascade， 发现可以成功的把ring用户drop掉了。
取数据库AWR报告，检查发现EVENT中top 1 是row cache wait；研发怀疑存在某个应用进程在不断的尝试链接数据库，现场检查了业务相关的所有网元中与数据库相关的配置部分，并没有发现错误的账号/密码配置内容。

研发提供方案在数据库部署触发器，检测是是哪个网元在不断的尝试连接数据库。如下：
1. 登录sys执行如下脚本，过几分钟看一下表logonaudittable并保存数据

2. 在logonaudittable有数据后执行如下命令删除触发器及新建的表

从logonaudittable表中发现反复尝试连接数据库的客户端信息如下;

192.168.108.133 是现网CTI主机的fabric平面地址，业务应用上考虑CTI到数据库的链接是由Aplogic来发起的。所以首先需要检查aplogic的配置。登陆WEB配置台检查，确认aplogic连接数据库对应的用户名,密码是完全正确的。需要继续排查是哪个进程在反复发起到数据库的连接。
root用户登陆CTI主机（192.168.108.133）检查主机与外部网元建链情况：

我们注意到蓝色字体部分显示，有大量的异常链接请求从133主机发送到135主机（数据库服务器ip），并且这些连接始终处于“TIME_WAIT”状态，表明链接无法成功建立。观察其他链接（如下），我们可以确认该连接是由aplogic进程发起，在133主机与135主机间建立了连接。

然而对于蓝色字体部分的链接，netstat –anp 命令却无法看到是哪个进程发起的请求。问题的
定位一时陷入了僵局。

排除了CTI主机业务应用的问题，考虑该主机上是否有其他程序在跑，��比CTI主机1和CTI主机2，发现只有CTI主机1上存在这样的问题。比较两者的配置发现CTI主机1上除了业务程序外还安装有WAS应用程序。并且该应用程序处于运行状态。由此怀疑问题出在WAS上。使用维护助手登陆WAS配置管理页面，检查配置发现WAS确实配置有老的数据库账号(ring).修改数据库账号并重启WAS进程后，执行netstat –anp |grep 192.168.108.133发现没有了异常的链接，相关情况如下：

导致ring用户一直无法drop掉的根本原因在于WAS依然使用ring账户链接数据库。检查数据库/opt/oracle/diag/rdbms/instancename/SID/trace/ 下已经不再大量产生trace文件，制作ARW报告检查确认EVENT中top 1 已经不再是row cache wait了。如下; 至此可以确认问题解决。

不过这里还有个疑问，为何通过netstat –anp 命令查看主机与外部网元链接情况时无法检测到是WAS发起这些链接的呢？

总结：
在数据库部署触发器，检查是哪个客户端在反复尝试建立链接是解决这个问题的关键。之前有尝试过多次探寻到底是哪个网元/进程还在连接数据库，一直没有找到很好的方法，曾经重启数据库��主机，业务各个组件都无法解决。
附件： ORACLE数据库大量生成trace文件问题排查.docx ( 106.56 KB ,11 downs )
从v$session中可以看到吧！对这个事情太有印象了，国内某局点遇到过，忘记修改WAS连接数据库的密码，导致数据库hang住。 回复
•
等级:
2楼刘建军发表于2012-05-28 11:49
Oracle 11g引入了用户登陆数据库失败后延迟一段时间再次尝试的机制。在某些特定应用场景下，此机制将导致row cache entry被持续的延迟而锁住，进而引起dc_users上对某些用户或schema的的row cache lock。严重时引起整个数据库hang住。 bug 7715339 回复

回复 刘建军 发表于 2012-05-28 11:49
Oracle 11g引入了用户登陆数据库失败后延迟一段时间再次尝试的机制。在某些特定应用场景下，此机制将导致row cache entry被持续的延迟而锁住，进而引起dc_users上对某些用户或schema的的row cache lock。严重时引起整个数据库hang住。 bug 7715339

v$session看不到，用户名都不存在啦，连不上来啊。 回复
•
等级:
4楼罗晓明发表于2012-05-28 14:03
回复 刘建军 发表于 2012-05-28 11:49
Oracle 11g引入了用户登陆数据库失败后延迟一段时间再次尝试的机制。在某些特定应用场景下，此机制将导致row cache entry被持续的延迟而锁住，进而引起dc_users上对某些用户或schema的的row cache lock。严重时引起整个数据库hang住。 bug 7715339
用户名或密码错误， v$session看不到，通过登录触发器才能锁定IP 回复
•
等级:
5楼李捷发表于2012-06-11 19:23
“有大量的异常链接请求从133主机发送到135主机（数据库服务器ip），并且这些连接始终处于“TIME_WAIT”状态，表明链接无法成功建立”

能否详细解释一下这个机制，为何TIME_WAIT 就表明链接无法成功建立 回复

询语句
1.如果查询的结果记录很多，可以查看前N条结果记录。

2.条件设置查询。

oracle如何设置输出显示效果？
1. 设置显示的宽度。
使用默认的显示宽度，发现显示有点混乱。

设置显示宽度后的效果要整齐很多。可以使用“set linesize 1000” 或“set line 1000”

2. 设置列的宽度
对于字符型的字段可以 使用“col 字段 format a50”

3. 设置页面显示的量
设置页面的大小可以使用“set pagesize 10” 。

如何踢出访问数据库的用户？
应用场景
在数据库管理中，不希望有一些不速之客访问我的数据库，这时候管理员需要把这些不俗之客踢出出去。
查看谁在访问我的数据库
执行命令“select saddr,sid,serial#,paddr,username,status from v$session where username is not null;” 可用查看谁在访问我的数据库。

删除访问数据库用户的Session
删除该用户的session。

说明：

5. 查看session的状态，验证session是否被删除。

• 如果用户的session状态status值为inactive，说明没有被删除。
• 如果用户的session状态status值为killed，说明已经删除。
操作示例

如何根据数据库用户的Session信息获取操作系统的PID信息

从操作系统层面kill掉登录用户的Session

学习了，好详细

学习一下

学习学习

学习了