从OS层面上，建议您监控内存的使用是否逐步在增加，是否达到某一个阈值的时候就会触发该错误。svmon -G -i 2 2ipcs -a按照内存使用对进程进行排序，以发现是哪些进程使用了较多的内存，su -#ps avx |head -1 ;ps avx |grep -v PID |sort -rn +6 > ps_avx.output对于这些进程，查看它们究竟为什么

运维人员发现备份出现问题，通过查看数据库日志及主机运行信息，发现遇到大量ORA-00060死锁报错，产生大量TRACE文件，导致ORACLE软件目录空间资源耗尽；通过数据库参数MAX_DUMP_FILE_SIZE限制单个TRACE文件的上限值，一定程序上会减少TRACE文件占用的空间，但是无法限制TRACE文件的个数。同时限制单个TRACE文件的上限值后，例如限制为10M，当问题进程对应的TRAC

问题： 某客户来电，一个老数据库环境，登陆上进行检查时发现sqlplus命令执行出错，报sqlplus / as sysdba登陆数据库时，报错sqlplus:error while loading shared libraries: libclntsh.so.11.1: wrong ELF class: ELFCLASS32排查：这问题按照正常思路，检查：1.环境变量中LD_LIBRA...

问题： ORACLE数据库的勒索病毒是一个老话题了，2016/2017年时候爆发过一波，当时主要是PLSQ DEV/TOAD等工具的登陆数据库脚本被注入病毒；近期又有客户中招，所幸发现及时，相应的存储过程并未爆发，因此将相应的病毒存入过程删除即可。该客户也使用了堡垒机，但是还有部分维护人员是可以直连的,所以中招了。后续处理： 建议用户限制dba 权限，所有员工的数据库连接工具从内网的统一软件平台.

今天，客户反馈测试环境的数据库PGA资源不足，报错ORA-04036: 实例使用的 PGA 内存超出 PGA_AGGREGATE_LIMIT；查看总的PGA分布：select sum(pga_alloc_mem)/(1024*1024) "Mbytes allocated", sum(pga_used_mem)/(1024*1024) "Mbytes used" from v$process;1、

在一次数据库迁移过程中，发现数据库使用srvctl start database命令无法启动，ORA-29760: instance_number parameter not specified、PRCD-1120 : The resource for database mes could not be found.等问题，原因的DB_UNIQUE_NAME发生了改变。在11G中无此问题。

问题：一个忙碌的早上，某客户来电，业务部门反映系统反应很慢，正是早上业务最忙碌时刻，需要抓紧排查处理……排查：–登陆系统后，按ISO流程，查看OS及数据库ACTIVE会话/等待事件等，可以发现主机的CPU 较低，IO使用率较高，数据库所在磁盘iostat输出来看，%util列接近100%，其它几列指标的值也不乐观；–数据库中ACTIVE会话未见明显异常等待事件，也无BLOCKING_SES...

Oracle不再把sga放到共享段中，pmap工具诠释了进程相关共享内存的情况，可以看到许多个4MB的＂文件＂(此处的大小可能不是4M，可能是16M等)对应了Oracle服务进程的空间地址．这是linux上POSIX风格的共享内存管理模式，使用＂文件＂形式包含共享内存段．借助于将sga分割成许多块，Oracle可以很容易地把sga部分内存返回给OS，而服务器进程即可以利用到这些内存．（当memor

ORACLE 11Gr2开始，数据库AWR中的segment部分的block change小节，可以显示块变更多的表或索引信息，依据此信息结合TOP SQL部分，可以很快速的确定导致产生很多归档日志的SQL语句、程序模块信息等。，当日采样人员过多，超过上限导致程序混乱，产生大量update，导致归档暴增，应用采取加模组方式暂时解决，后续修改采样编码上限。导致，正常的SQL在出现异常执行时，也会产生

因此结合ORACLE官方文档中（High 'enq: TM - contention' Wait Event Causing Session Hangs in an Oracle Streams Environment (Doc ID 740728.1)），对于OGG附加日志时执行的语句：BEGIN DBMS_CAPTURE_ADM.PREPARE_TABLE_INSTANTIATION(tabl