lmxx2020的博客

这时候如果有前面正常的rman备份，那么我们就可以通过rman备份直接对数据文件块做恢复。或者直接检查数据文件：VALIDATE DATAFILE 5。检查完，我们可以通过视图查询到坏块信息。再使用dbv检查发现没有坏块了。

检查从alert日志里看军事文件无法写入导致实例终止，后检查虚拟机磁盘配置为精简模式，磁盘存放的共享存储空间使用率较高。O/S-Error: (OS 1453) 配额不足，无法完成请求的服务。O/S-Error: (OS 1453) 配额不足，无法完成请求的服务。O/S-Error: (OS 1453) 配额不足，无法完成请求的服务。O/S-Error: (OS 1453) 配额不足，无法完成请求的服务。OSD-04008: WriteFile() 失败, 无法写入文件。

发现有个删除触发器相关的表，检查框住的存储过程，发现里面有触发器的禁用启用，没有授权增删改系统表权限导致。但是原先是正常的，异常宕机之后才发生这个报错，怀疑是bug造成。job执行plsql存储过程异常终止报错，alert日志如下。授权表triggercol$增删改权限后恢复正常。查看导出dump文件。

其中ret:gipcretKeyNotFound (36)比较可疑。集群起来后gipcd服务不能正常启动。mos文档：2034669.1。建议清理网络socket文件。清理后再次启动恢复正常。

检查数据库补丁情况，发现没有打任何补丁，怀疑是bug造成，最终在mos查到对应的一篇文档。

max_enabled_roles实际上配置只能从0到148，所以配置就算是150，生效148，所以超过148的角色就不会加载进入了。发现有250条角色授权记录。

在备库开始复制：(RAC 在执行rman duplicate的时候，报如下ORA-19505错误：可以在备库TNS增加单机配置，主库先连单节点进行duplicate)控制文件备份恢复要在end backup之后，不然有可能fuzzy状态不对，不能打开数据库。RMAN>(将上述命令在该处运行)（select查询出来的）

object number（objn）或者object id（objd）

迁移过程带lob字段的T_EC_EVENT表特别慢，停机时间太长，通过物化视图提前迁移T_EC_EVENT表。含lob字段大表通过dblink，创建物化视图（不停机）最后一次增量，删除物化视图（停业务）修改sequences与主库保持一致。

linux模拟盘aix盘。

采用sh文件来调用这三个级别的备份。三个sh的文件可命名为lev0.sh、lev1. sh、lev2. sh。这三个备份脚本对应文件lev0.rcv、lev1.rcv、lev2.rcv。1、level 0备份脚本。采用crontab来制定计划任务。2、level 1备份脚本。3、level 2备份脚本。

安装服务器一般C盘的物理空间会被服务器当做虚拟内存使用，服务器调用大量虚拟内存供数据库使用，但是C盘空间不足以支撑数据库的内存需求，导致C盘空间爆满，最后导致数据库宕机，所以正常情况下，建议修改虚拟内存设定的位置，把默认的C盘更改为其他更大的D盘做虚拟内存使用。剩余空间不足于支撑50G的虚拟内存空间，所以导致交换内存出现异常，最终导致实例宕机。按道理不该出现虚拟内存不足的情况，检查操作系统发现，默认C盘剩余空间比较少。发现在宕机之前，出现了虚拟内存不足的情况。由于pga内存不足，而导致的数据库宕机。

如，执行一条 SQL 的时候，如果该 SQL 在共享池中不存在，这就是硬解析，需要首先分配共享池空间，创建父游标的结构，然后创建一个子游标。如果下一次再执行一条类似的 SQL，该 SQL 的父游标存在，经过检查发现子游标是可以共享的，而且这个子游标的所有关联对象在共享池中都存在，那么就可以马上执行了，这就是软软解析，也是软解析的一种。如果子游标是不可共享的，那么就需要创建一个新的子游标（对于 SQL 来说，又增加了一个版本， Version），解析执行计划，然后执行。

数据库性能得到了很大的提升，dbtime从600多min降到24min，业务也恢复正常。调整该sequence的cache_size大小。

建议该模块放到容灾库去跑，业务停止DDTEK ODBC Oracle模块，操作IO负载降下来，在50%左右，后台等待事件消除，业务恢复正常。后台有两个并行rman备份在，停止备份io繁忙没有好转，检查最近ash报告，发现DDTEK ODBC Oracle程序模块占用最高。检查后台，发现直接路径读和DDTEK ODBC Oracle等待事件比较多。检查该模块，发现是通过odbc过来的挖掘程序。一大早就有喊业务卡的，检查等待事件源头，均为oracle写等待。查看IO负载持续维持在100%繁忙。

原主库发起切换请求，原主库正常切换数据库角色，但原从库无法正常打开数据库，尝试关闭重启，依旧无法解决问题。查看切换过程中原从库数据库后台日志，发现数据库一直不断重试清理。版本针对19.3.0.0~19.8.0.0，解决办法。信息确实完全匹配相关信息，包括相关数据库版本。

检查应用端、服务器端、防火墙的MTU值是否一致，更改应用端、服务端的MTU值与防火墙一致，MTU默认值为1500，参考可调至9000（oracle原厂建议oracle服务器是 9000，同时参考了其他银行的MTU值），建议网络工程师可以用ping包的方式 测试出符合当前环境的最佳MTU。ORACLE官方针对这类错误明确：错误堆栈依次为TNS-12170/TNS-12535/TNS-12560/TNS-00505，这表明由于网络问题，已建立的连接超时。这是一个网络/应用程序问题，而不是oracle错误。

计划任务的设置就是按照第十章中的案例来设置的，星期天晚上一个0级备份、周三一个1级备份、其他时间为2级备份。在每天设置一个计划任务，调用对应的批处理文件即可。例如星期天晚上调用lev0.bat。对应lev0.rcv、lev1.rcv、lev2.rcv也要编写三个批处理文件来调用这三个级别的备份。这三个批处理文件命名为：lev0.bat、lev1. bat、lev2. bat。Unix、Linux要采用sh文件来调用这三个级别的备份。三个sh的文件可命名为lev0.sh、lev1. sh、lev2. sh。

-from可以是具体的备份文件。通过RMAN连接到目标数据库。10、基于日志序列的恢复。1、恢复SPFILE。9、基于SCN的恢复。

RMAN可以配置一些参数，如通道、备份保持策略、控制文件自动备份等等。查看RMAN默认的配置参数，可以通过show all命令来实现。

通过修改asm_diskstring不要把新加的sdf、sdg、sdh、sdi显示出来，asm_diskstring设置为“/dev/sd[b-e],/dev/mapper/asm*”，再次添加磁盘成功。

通过attach连接时，不能正常连接：Owner: SYS或者Owner: SYS段错误这是由于用存储过程发起的备份，如果需要attach连接上去处理必须也要存储过程，比如停止备份操作：先查询出运行种的job：然后停止：declareh1 NUMBER;BEGINEND;

当 streams pool 完成收缩时，该值应返回“0”，但如果它一直返回“1”，则您可能遇到此问题。也就是当遇到Bug 27634991在streams pool 完成收缩时，有可能还是“1”该文中说当发生该事件时，尝试去收缩STREAMS_POOL_SIZE就会hang住，也就是STREAMS_POOL_SIZE初始化一个较大的值，避免该池做收缩操作导致该堵塞，这是一个bug造成。检查日志expdp日志，发现已经表都已经基本上导出完成，都是0 KB 0 rows，就没是导出完成的标识。

创建文件vi /etc/rc2.d/S99nddconfig，设置TCP UDP内核参数，内容如下：（两节点）在两个节点上配置同样的Solaris内核参数。修改两台节点的/etc/system文件。配置Solaris内核参数。

此操做除了丢失 CHM 收集的操作系统统计信息外，删除 bdb 文件不会产生其他影响，重新启动后，会重新生成bdb文件，CHM 将再次开始收集操作系统统计信息。bdb 文件非常大，甚至超过 2GB的另一个原因是由于bug造成，因为默认情况下bdb大小限制在1GB，除非CHM数据保留期修改变大了。这是保留CHM数据三天，259200单位是秒。

PGA和MGA是不同的内存区域，从常规页分配PGA，通过/dev/shm领域分配MGA。另外，PGA和MGA的合计大小也将受到PGA_AGGREGATE_LIMIT的限制。另外可以通过设置_use_large_pages_for_mga参数为True，可以让MGA使用HugePage，减少对pga的影响。发现设置了7G，操作系统是512G，正常情况下/dev/shm应该是操作系统的一半，修改为250G后数据库恢复正常。pga_aggregate_limit已经设置了120G，alert还是报内存不够。

发现oinstall对应的用户已经丢失。

V$ENCRYPTION_WALLET.STATUS列如果不为CLOSED，重启后也不能是CLOSED，或者清理完成后，再次初始化报“Master Key已存在”错误。这条SQL中的表空间名UNDOTBS1，就是上面show parameter undo_tablespace查询出的结果。UNDO表空间在/oracle/oradata路径处。如删除不成功，需要重启数据库后，才能删除成功。切换当前UNDO表空间并删除原UNDO表空间。创建同样大小的UNDO表空间。获取UNDO表空间大小。

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

通过查看数据库告警日志、以及css日志。但是数据库日志并没有相关记录信息，操作系统日志也未记录，日志状况类似服务器断电情况，突然中断均未生成。检查/etc/kdump.conf，在/var/crash目录下也未发现crash记录生成。这是应该在当时系统hang住了，没有panic，正常来说hang不会产生coredump。所以为了后续排查问题，修改系统panic配置，从而达到hang也会出发coredump。增加：kernel.hung_task_panic = 1。

该问题只能重建磁盘组，要解决这个bug升级到12.2以上版本。

检查发现当前ASM 使用自动内存管理方式，目前设置大小为560M，该数值对于生产库来说小了，参考MOS文档ID 437924.1 ，Oracle建议ASM实例memory_target= 1536M，memory_max_target=4G。检查发现ASM实例shared pool空间不足，数据库无法连接ASM实例。修改两个节点$GRID_HOME/dbs目录下pfile文件。检查发现当前ASM上没有OCRDG磁盘组。通过pfile创建spfile。未发现spfile存在。检查spfile文件。

1 、发生“enq: TQ - DDL（TM） contention”堵塞原因是bug，建议升级到19c并打上最新补丁。数据库一天内多次hang住，最后只能重启恢复，操作系统及数据库版本：Windows Oracle 12.2.0.1。检查hang住时间段alert日志，发现数据库多次重启日志，基本上是hang住然后手工重启。2、临时处理，使用PL/SQL脚本频繁清除队列，该作业可以配置为自动运行。检查重启前的ash记录。

LNS wait on SENDREQ”，“LGWR-LNS wait on channel”，这两个都跟dataguard的数据发送有关系，检查dg配置发现使用了“SYNC，AFFIRM”参数，如果网络出现波动或者dg库异常，会导致生产库卡住，所以建议使用async模式。获取卡时间段的堵塞事件，发现大部分事件是“cursor: pin S wait on X”，“log file parallel write”，“LGWR-LNS wait on channel”等。文件号2为“SYSAUX”表空间。

根据文档HAIP Fails to Start as GIPC Has Rank 0 or -1 for Interconnect (Doc ID 1374360.1)，bond1私网发生”rank -1”或着”rank 0”就说明私网有故障发生.NetworkManager是自动管理网络的服务，正常情况下配置bond需要关闭NetworkManager，不然会导致双网卡切换时发生异常，双网卡可以通过拔插网线来验证切换是否正常。

核查该sql语句执行慢的原因，分析其执行计划发生了变动，出现了全表扫描。频繁对400G的大表进行一个全表扫描，导致数据库卡死。为了确保业务快速恢复，最快的解决方式就是先通过手动绑定对的执行计划，恢复sql的执行效率。绑定执行计划后发现，并没有执行正确的索引扫描。排查出造成阻塞的源头sql，该条sql语句与分区表相关。业务无法正常进行，查看数据库后台进程，发现有大量阻塞。可以看到新分区表部分索引状态出现了异常。修复索引完毕后，业务sql恢复效率。开始修复状态异常的索引。

如果没有/etc/exports文件，使用mknfs命令之后，nfsd、rpc.mounted进程不会启动，需要添加一个空的此文件。# lssrc -s portmap （状态为active即可）在客户端检查进程 portmap是否启动正常。

LEAF一般都是堵塞者，找到对应列的ospid列的值，然后通过OS层面去kill -9杀掉进程，KILL 前一定要ps 看下是不是系统进程。BLOCK进程一般会在State of ALL nodes部分的以下状态的会话中产生，主要有LEAF，NLEAF，IN_HANG进程。IN_HANG一般都是堵塞者，但是基本上不止一条，找到对第一个堵塞者的SPID，通过OS层面去kill -9杀掉进程。对于LEAF，NLEAF类，把LEAF，NLEAF的对象过滤出来。方式一、做hanganalyze。

先在dg库查看scn，x$kcvfh和V$DATABASE种的scn都要查，选择小的scn去主库备份。备份数据在dg库上通过“catalog start with '差异备份数据路径';转换完成后进行recover database操作恢复的较新的数据，然后重启dg归档应用。dg库和主库归档都已经不存在，除了重新拉dg，还可以通过增量备份恢复方式快速恢复dg。

4、当然还有可以通过oswatch的netstat日志去检查，当发现IpReasmFails指标开始增长，且增长速度很快，就说明私网通信有异常。1、心跳流量是否达到了网络带宽的上限，可以通过：ethtool eth3、ethtool eth4去确定网口的协商速率。发生异常时，一般流量较大，这里每秒流量达到了24M，如果带宽比较小或者MTU大小为默认的1500，可能造成较大的影响。3、调整mtu后需要测试mtu设置，mtu服务器和交换机都要调整。在正常情况下，心跳网络每秒流量基本上很小，这里才580k。