ITPub博客

检查alert日志，发现pga资源分配时报内存不足：由于pga内存不足，而导致的数据库宕机。查看操作系统日志：发现在宕机之前，出现了虚拟内存不足的情况。检查确认设置的虚拟内存大小为50多G：按道理不该出现虚拟内存不足的情况，检查操作系统发现，默认C盘剩余空间比较少剩余空间不足于支撑50G的虚拟内存空间，所以导致交换内存出现异常，最终导致实例宕机。安装服务器一般C盘的物理空间会被服务器当做虚拟内存使

解析非常高，通过时间模型可以看到解析占比非常高解析大致可以分为硬解析（ hard parse）、软解析（ soft parse）和软软解析（ soft soft parse）。如，执行一条 SQL 的时候，如果该 SQL 在共享池中不存在，这就是硬解析，需要首先分配共享池空间，创建父游标的结构，然后创建一个子游标。如果下一次再执行一条类似的 SQL，该 SQL 的父游标存在，经过检查发现子游标是可

当业务卡的时候，发现大量等待事件为enq: SQ – contention，检查awr的top 5事件：sql语句对sequence的调用非常频繁：SQL> select SEQUENCE_OWNER,SEQUENCE_NAME,CACHE_SIZE from dba_sequences where SEQUENCE_name=&#

一大早就有喊业务卡的，检查等待事件源头，均为oracle写等待查看IO负载持续维持在100%繁忙后台有两个并行rman备份在，停止备份io繁忙没有好转，检查最近ash报告，发现DDTEK ODBC Oracle程序模块占用最高检查该模块，发现是通过odbc过来的挖掘程序。等待事件是直接路径读：检查后台，发现直接路径读和DDTEK ODBC Oracle等待事

业务连接报ora-01033： 检查服务器，发现有重启记录，oracle进程存在，数据库状态处于mount状态，检查日志，发现在数据库启动时没有正常open：连入数据库：Select * from v$backup发现数据文件都处于热备模式Alter database end backupAlter database open成功打开。造

       原主库发起切换请求，原主库正常切换数据库角色，但原从库无法正常打开数据库，尝试关闭重启，依旧无法解决问题。查看切换过程中原从库数据库后台日志，发现数据库一直不断重试清理 SRLs，后台alert日志：TT04 (PID:238141): Sleep 10 seconds and then try to clear SRLs in 3 

数据库告警日志如下图。发现问题时间段，没有数据库服务故障报错，但是存在较多TNS-12535、12560、12170、00505错误：通过检查问题时间段应用日志，也记录了Caused by:java.sql.SQLRecoverableException: IO 错误: Connection reset和Caused by: java.net.SocketException: Connection

最典型的增量备份案例，是按照一周为一个周期来进行备份：时间备份级别星期天晚上level 0 星期一晚上level 2 星期二晚上level 2 星期三晚上level 1 星期四晚上level 2星期五晚上level 2 星期六晚上level 21、编写脚本1.1、编写rman脚本根据上面的策略，编写lev0.rcv、lev1.rcv、lev2.rcv三个文件，文件具体内容为：--lev0.rcvc

1、恢复SPFILE通过RMAN连接到目标数据库startup nomountset dbid 1234567restore spfile to '/oracle/product/10.2.0/db_1/dbs/spfileorcl.ora' from autobackup;shutdown immediate;startup;2、恢复控制文件startup nomountrest

RMAN可以配置一些参数，如通道、备份保持策略、控制文件自动备份等等。查看RMAN默认的配置参数，可以通过show all命令来实现。RMAN> show   all; RMAN 配置参数为:CONFIGURE   RETENTION POLICY TO REDUNDANCY 1; # defaultCONFIGURE BACKUP   OPTIMIZ

向数据库导入json相关jar包loadjava -r -f -u bsuser/XXXX@192.168.10.31/bsorcl json.jar要删除的话，删除指定jardropjava -u bsuser/XXXX@192.168.10.31/bsorcl json.jarselect * from user_java_classes然后我们就可以取到json串中任意节点的值

虚拟化做的rac，发现原来加盘直接把sdb、sdc、sdd、sde加到asm里了，后面通过udev绑定的盘，增加到asm里就报错：[DBT-30007]Addition of disks to disk group DATA failedORA-15032:not all alterations performed0RA-15333: diek is not visible on client i

[oracle@alios dpdump]$ expdp \'/ as sysdba\' attach=SYS_EXPORT_SCHEMA_05Export: Release 19.0.0.0.0 - Production on Tue May 7 13:04:14 2024Version 19.16.0.0.0Copyright (c) 1982, 2019, Oracle an

检查日志expdp日志，发现已经表都已经基本上导出完成，都是0 KB 0 rows，就没是导出完成的标识。检查dba_datapump_jobs发现expdp任务还在执行中。检查v$session，发现存在等待事件“Streams AQ: Enqueue Blocked On Low Memory”检查mos关于该等待事件：Bug 17365043 - Session hangs on &quot

Solaris系统参数未配置导致rac节点重启异常，检查alert日志发现很多参数异常告警：配置Solaris内核参数：在两个节点上配置同样的Solaris内核参数。为grid用户和oracle用户创建projects，配置共享内存参数： # /usr/sbin/ndd /dev/tcp tcp_smallest_anon_port tcp_lar

集群重启，不能正常启动，启动日志如下：2024-04-12 00:16:40.557: [/u01/app/11.2.0/grid/bin/orarootagent.bin(15290)]CRS-5818:Aborted command 'check' for resource 'ora.crf'

pga_aggregate_limit已经设置了120G，alert还是报内存不够查询select * from v$pgastat，发现MGA占了80G内存查看/dev/shm:发现设置了7G，操作系统是512G，正常情况下/dev/shm应该是操作系统的一半，修改为250G后数据库恢复正常。PGA和MGA是不同的内存区域，从常规页分配PGA，通过/dev/shm领域分配MGA。但是MGA同样会

检查用户属组：[root@rac1 ~]# id oracleuid=1102(oracle) gid=1101(oinstall) groups=1101(oinstall),1102(dba)[root@rac1 ~]# id griduid=1101(grid) gid=1101(oinstall) groups=1101(oinstall),1102(dba)检查group组：cat /e

关闭钱包报ORA-28365:实际状态是open状态：V$ENCRYPTION_WALLET.STATUS列如果不为CLOSED，重启后也不能是CLOSED，或者清理完成后，再次初始化报“Master Key已存在”错误。获取UNDO表空间大小SQL> show parameter undo_tablespaceNAME      &nbsp

集群CSSD进程reconfiguration完成，显示2个节点都在线。但ora.net1.network服务启动失败，且有依赖关系的资源随后启动失败并且已经达到上限。查看两个节点的网络信息，发现两个节点的默认网关是不一致的。修改故障节点网关重启后恢复正常