下图是抓到的操作系统的io信息，11.2.0.4的库，上面有好几个数据库实例，这个问题出现了一会就没了，还没定位到问题就消失了，想着下次再出现了问题能快速定位到具体哪个库影响的

rac的service不是漂移，是双活，两个节点同时有可用的服务存在的，你确认一下一个另一个节点在1节点宕机前后的状态

你这怕是windows环境啊，环境变量有问题了，紧急的话建议把client卸载掉，环境变量里面的配置好好检查检查，装了oracle软件之后就不用装client了

distinct要排序，要走全表，数据量大之后会非常慢建议把去重操作改一下，可以通过group by，方法有很多

修改一下环境变量，export申明一下ORACLE_SID,ORACLE_HOME

亲锁啊有锁问问开发是不是做了变更操作了

见过好些，19c的gi加11.2.0.4的db

没辙，多看~看着看着就能看懂了网上有很多讲解教程

这个和数据库体量有关，业务逻辑有关awr瞅瞅都在跑哪些sql，DML语句频繁的话这个就不可避免了

https://www.oracle.com/tools/downloads/sqldev-downloads.htmloracle官方下一个sqldeveloper就行，有linux版本的，尽量别用盗版软件

测一下磁盘ioiostat命令看看磁盘等待监控一下系统的整体负载个人感觉存储方面的可能性比较大

SELECT tablespace_name 表空间,sum(blocks*8192/1000000) 剩余空间M FROM dba_free_space GROUP BY tablespace_name;查一下就知道了，也可能是本地空间不足了df -h看下，如果是rac就看看grid 用户下的asmcmd lsdg；

找存储厂商要一个官方建议的mount参数试试~

个人感觉expdp/impdp最简单方便，迁移前做好测试就行，通过本地sys用户导出导入，不需要修改目标用户密码，命令也简单，工具也成熟

就是字面意思，肯定是参数不对看你这像是主库出问题了，你先把参数都去掉让库起来再说，搭建dg是可以完全不影响主库的，不用重启，确定备库正常同步运行后，做主备切换的时候才会做主库重启教你个笨办法，多搜几篇dg实施的文档，把这个参数相关的配置都摘出来对比一下，多来几次就顺了，你这么问很难给你回答

最近出差没顾上回~~~你要第三方工具，还不如搞个专门的监控啊，我玩过一个叫weadmin，绿色安装解压就用，数据库主机之类的都能监控，去年的事了有环境的话装个zabbix也可以的~

一般情况，在这一步出现问题不是存储问题就是网络问题，仔细检查一下两个节点的共享磁盘是否存在差异，网络是否有丢包