- 博客(83)
- 资源 (11)
- 收藏
- 关注
RSS订阅原创 由于bug造成truncate table卡住问题
另外在Truncate Slow in 11.2.0.3 and Higher (Doc ID 1667223.1)文档中也提到，“local write wait”和“enq: RO - fast object reuse”事件，该事件由BUG:18251841造成。该bug可以通过打补丁解决，补丁在11.2.0.4.180116中已解决，同时也可以设置隐含参数解决“_db_fast_obj_truncate=FASE”。但这个案例中，是最后打算最新补丁，该问题解决。
2024-06-18 17:19:10
107
原创 oracle主机虚拟内存不足导致实例宕机
安装服务器一般C盘的物理空间会被服务器当做虚拟内存使用，服务器调用大量虚拟内存供数据库使用，但是C盘空间不足以支撑数据库的内存需求，导致C盘空间爆满，最后导致数据库宕机，所以正常情况下，建议修改虚拟内存设定的位置，把默认的C盘更改为其他更大的D盘做虚拟内存使用。剩余空间不足于支撑50G的虚拟内存空间，所以导致交换内存出现异常，最终导致实例宕机。按道理不该出现虚拟内存不足的情况，检查操作系统发现，默认C盘剩余空间比较少。发现在宕机之前，出现了虚拟内存不足的情况。由于pga内存不足，而导致的数据库宕机。
2024-05-24 14:15:44
221
原创 oracle数据库解析过高分析
如，执行一条 SQL 的时候，如果该 SQL 在共享池中不存在，这就是硬解析，需要首先分配共享池空间，创建父游标的结构，然后创建一个子游标。如果下一次再执行一条类似的 SQL，该 SQL 的父游标存在，经过检查发现子游标是可以共享的，而且这个子游标的所有关联对象在共享池中都存在，那么就可以马上执行了，这就是软软解析，也是软解析的一种。如果子游标是不可共享的，那么就需要创建一个新的子游标（对于 SQL 来说，又增加了一个版本， Version），解析执行计划，然后执行。
2024-05-24 11:24:30
235
原创 sequence cache太小导致enq: SQ – contention
数据库性能得到了很大的提升，dbtime从600多min降到24min，业务也恢复正常。调整该sequence的cache_size大小。
2024-05-23 15:10:38
676
原创 数据挖掘导致直接路径读（direct path read）耗尽了IO
建议该模块放到容灾库去跑，业务停止DDTEK ODBC Oracle模块，操作IO负载降下来，在50%左右，后台等待事件消除，业务恢复正常。后台有两个并行rman备份在，停止备份io繁忙没有好转，检查最近ash报告，发现DDTEK ODBC Oracle程序模块占用最高。检查后台，发现直接路径读和DDTEK ODBC Oracle等待事件比较多。检查该模块，发现是通过odbc过来的挖掘程序。一大早就有喊业务卡的，检查等待事件源头，均为oracle写等待。查看IO负载持续维持在100%繁忙。
2024-05-23 14:45:13
219
原创 机器重启oracle数据库自动启动异常
所以当数据库处于热备模式下，不要进行重启服务器，或者重启数据库的操作，应先将数据库关闭热备模式，再行进重启操作。造成的原因是数据库在热备模式下被关闭，导致数据库无法打开，报错系统文件需要恢复。连入数据库：Select * from v$backup。检查历史日志，发现有开启热备模式的记录。发现数据文件都处于热备模式。
2024-05-22 10:29:06
307
原创 19c数据库19.9以下dg切换打开hang住问题
原主库发起切换请求，原主库正常切换数据库角色，但原从库无法正常打开数据库，尝试关闭重启，依旧无法解决问题。查看切换过程中原从库数据库后台日志，发现数据库一直不断重试清理。版本针对19.3.0.0~19.8.0.0，解决办法。信息确实完全匹配相关信息，包括相关数据库版本。
2024-05-21 14:59:22
424
原创 oracle数据库无法连接问题排查
检查应用端、服务器端、防火墙的MTU值是否一致，更改应用端、服务端的MTU值与防火墙一致，MTU默认值为1500，参考可调至9000（oracle原厂建议oracle服务器是 9000，同时参考了其他银行的MTU值），建议网络工程师可以用ping包的方式 测试出符合当前环境的最佳MTU。ORACLE官方针对这类错误明确：错误堆栈依次为TNS-12170/TNS-12535/TNS-12560/TNS-00505，这表明由于网络问题，已建立的连接超时。这是一个网络/应用程序问题，而不是oracle错误。
2024-05-21 11:36:10
814
原创 大数据量RMAN部署方案及方法
计划任务的设置就是按照第十章中的案例来设置的，星期天晚上一个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。
2024-05-20 16:10:45
917
原创 RMAN各类文件恢复及恢复方式
-from可以是具体的备份文件。通过RMAN连接到目标数据库。10、基于日志序列的恢复。1、恢复SPFILE。9、基于SCN的恢复。
2024-05-20 15:46:28
327
原创 RMAN备份策略及参数配置
RMAN可以配置一些参数，如通道、备份保持策略、控制文件自动备份等等。查看RMAN默认的配置参数，可以通过show all命令来实现。
2024-05-17 14:35:45
591
原创 rac asm新增磁盘报0RA-15333或ORA-15075
通过修改asm_diskstring不要把新加的sdf、sdg、sdh、sdi显示出来，asm_diskstring设置为“/dev/sd[b-e],/dev/mapper/asm*”，再次添加磁盘成功。
2024-05-13 15:24:11
153
原创 expdp不能通过attach连接job
通过attach连接时，不能正常连接：Owner: SYS或者Owner: SYS段错误这是由于用存储过程发起的备份，如果需要attach连接上去处理必须也要存储过程，比如停止备份操作：先查询出运行种的job：然后停止：declareh1 NUMBER;BEGINEND;
2024-05-07 17:46:53
453
1
原创 expdp突然变非常慢
当 streams pool 完成收缩时，该值应返回“0”，但如果它一直返回“1”，则您可能遇到此问题。也就是当遇到Bug 27634991在streams pool 完成收缩时，有可能还是“1”该文中说当发生该事件时，尝试去收缩STREAMS_POOL_SIZE就会hang住，也就是STREAMS_POOL_SIZE初始化一个较大的值，避免该池做收缩操作导致该堵塞，这是一个bug造成。检查日志expdp日志，发现已经表都已经基本上导出完成，都是0 KB 0 rows，就没是导出完成的标识。
2024-05-07 14:07:27
245
原创 Solaris系统参数未配置导致rac节点重启异常
创建文件vi /etc/rc2.d/S99nddconfig，设置TCP UDP内核参数，内容如下：（两节点）在两个节点上配置同样的Solaris内核参数。修改两台节点的/etc/system文件。配置Solaris内核参数。
2024-04-16 10:55:32
435
原创 crf空间满导致集群重启异常
此操做除了丢失 CHM 收集的操作系统统计信息外，删除 bdb 文件不会产生其他影响，重新启动后，会重新生成bdb文件，CHM 将再次开始收集操作系统统计信息。bdb 文件非常大，甚至超过 2GB的另一个原因是由于bug造成，因为默认情况下bdb大小限制在1GB，除非CHM数据保留期修改变大了。这是保留CHM数据三天，259200单位是秒。
2024-04-16 10:48:59
360
原创 19c数据库/dev/shm/过小导致pga内存不够
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还是报内存不够。
2024-04-11 18:32:38
438
原创 oracle分区表迁移后空间占用增大
参考文档：Initial Extent Size of a Partition Changed to 8MB from 64KB After Upgrade to 11.2.0.2 or Later (Doc ID 1295484.1)可以把隐含参数_partition_large_extents、_index_partition_large_extents设置成false的话能够节约空间。主要是定义的分区init_extent大小不一样导致，默认是64k，这里定义了8M导致表空间占用增大了。
2024-04-11 15:34:19
579
原创 关闭TED报ORA-28365: wallet is not open
V$ENCRYPTION_WALLET.STATUS列如果不为CLOSED，重启后也不能是CLOSED，或者清理完成后，再次初始化报“Master Key已存在”错误。这条SQL中的表空间名UNDOTBS1，就是上面show parameter undo_tablespace查询出的结果。UNDO表空间在/oracle/oradata路径处。如删除不成功，需要重启数据库后，才能删除成功。切换当前UNDO表空间并删除原UNDO表空间。创建同样大小的UNDO表空间。获取UNDO表空间大小。
2024-04-10 11:28:09
440
原创 rac数据库默认网关不通导致集群异常
集群CSSD进程reconfiguration完成，显示2个节点都在线。但ora.net1.network服务启动失败，且有依赖关系的资源随后启动失败并且已经达到上限。查看两个节点的网络信息，发现两个节点的默认网关是不一致的。
2024-04-08 16:16:18
285
原创 rac数据库宕机重启未生成日志
通过查看数据库告警日志、以及css日志。但是数据库日志并没有相关记录信息，操作系统日志也未记录，日志状况类似服务器断电情况，突然中断均未生成。检查/etc/kdump.conf，在/var/crash目录下也未发现crash记录生成。这是应该在当时系统hang住了，没有panic，正常来说hang不会产生coredump。所以为了后续排查问题，修改系统panic配置，从而达到hang也会出发coredump。增加：kernel.hung_task_panic = 1。
2024-04-07 09:54:57
175
原创 asm内存不足导致归档报错
检查发现当前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文件。
2024-04-02 09:14:15
1034
原创 TQ-DDL contention事件导致数据库hang死
1 、发生“enq: TQ - DDL（TM） contention”堵塞原因是bug，建议升级到19c并打上最新补丁。数据库一天内多次hang住，最后只能重启恢复，操作系统及数据库版本：Windows Oracle 12.2.0.1。检查hang住时间段alert日志，发现数据库多次重启日志，基本上是hang住然后手工重启。2、临时处理，使用PL/SQL脚本频繁清除队列，该作业可以配置为自动运行。检查重启前的ash记录。
2024-03-29 09:45:10
338
原创 dataguard配置SYNC导致数据库性能频繁卡顿
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”表空间。
2024-03-28 10:40:42
467
原创 sql Tuning Advisor启用导致业务性能问题
22:00数据库的统计信息开始收集， Sql Tuning Advisor堵塞了统计信息的收集，等待事件是“library cache lock”，Sql Tuning Advisor的等待事件是ON CUP。后续导致insert大量堵塞。查看业务卡顿时的blocking_session,主要发生在dbms_sqltune.execute_tuning_task('SYS_AUTO_SQL_TUNING_TASK')除了收集统计信息有必要保留之外，另外两个其实用处不大，只是收集。
2024-03-26 10:11:38
978
原创 bond私网主备切换导致RAC集群自动重启
根据文档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，不然会导致双网卡切换时发生异常，双网卡可以通过拔插网线来验证切换是否正常。
2024-03-25 10:35:42
343
原创 分区表索引失效导致业务异常
核查该sql语句执行慢的原因，分析其执行计划发生了变动，出现了全表扫描。频繁对400G的大表进行一个全表扫描，导致数据库卡死。为了确保业务快速恢复，最快的解决方式就是先通过手动绑定对的执行计划，恢复sql的执行效率。绑定执行计划后发现，并没有执行正确的索引扫描。排查出造成阻塞的源头sql，该条sql语句与分区表相关。业务无法正常进行，查看数据库后台进程，发现有大量阻塞。可以看到新分区表部分索引状态出现了异常。修复索引完毕后，业务sql恢复效率。开始修复状态异常的索引。
2024-03-22 15:42:05
753
原创 aix小机rac仲裁盘故障处理
如果没有/etc/exports文件，使用mknfs命令之后，nfsd、rpc.mounted进程不会启动，需要添加一个空的此文件。# lssrc -s portmap （状态为active即可）在客户端检查进程 portmap是否启动正常。
2024-03-19 15:53:20
708
原创 数据库hang住分析处理
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。
2024-03-19 09:54:08
661
原创 dg归档gap，主备库归档已清理，增量备份恢复
先在dg库查看scn，x$kcvfh和V$DATABASE种的scn都要查，选择小的scn去主库备份。备份数据在dg库上通过“catalog start with '差异备份数据路径';转换完成后进行recover database操作恢复的较新的数据，然后重启dg归档应用。dg库和主库归档都已经不存在，除了重新拉dg，还可以通过增量备份恢复方式快速恢复dg。
2024-03-15 10:46:41
484
原创 rac心跳延迟现象及排查
4、当然还有可以通过oswatch的netstat日志去检查，当发现IpReasmFails指标开始增长，且增长速度很快，就说明私网通信有异常。1、心跳流量是否达到了网络带宽的上限，可以通过：ethtool eth3、ethtool eth4去确定网口的协商速率。发生异常时，一般流量较大，这里每秒流量达到了24M，如果带宽比较小或者MTU大小为默认的1500，可能造成较大的影响。3、调整mtu后需要测试mtu设置，mtu服务器和交换机都要调整。在正常情况下，心跳网络每秒流量基本上很小，这里才580k。
2024-03-14 14:32:22
862
原创 19c使用asm报磁盘组未挂在及密码错误
oracle mos查找，找到一篇文档"ORA-17502 /ORA-01017: invalid username/password;logon denied " (Doc ID 2610682.1)经过对比发现"/etc/group" 未显示 "oracle" user 对应为 "oinstall" 组。datadg磁盘组正常mount，数据库也能正常起来。
2024-03-13 08:47:06
499
原创 内存抖动导致shared pool资源征用分析
shared pool大小从开始的8640M调整到了8512M，但buffer cache却从8448M到8576M，说明buffer cache的内存需求增大，挤占了shared pool的内存。发现都是MMAN进程堵塞，我们都知道Oracle的MMAN进程（Memory Manager Process，内存管理进程）会根据系统负载的变化和内存需要，自动调整SGA中各个组件的内存大小。也就是两个内存资源均不够了，导致性能下降，所以最好的解决方式是增加物理内存和sga，或者优化sql降低内存消耗。
2024-03-12 12:18:57
607
原创 19c补丁后oracle属主变化，导致不能识别磁盘组
在grid用户下检查磁盘组，发现data磁盘组正常mount。进入data磁盘组，检查redo、密码文件均正常。修改完属组，再次重启数据库，正常起来。2、data磁盘组不能访问。1、不能读取redo文件。
2024-03-11 11:59:00
425
原创 11gRAC二节点重构
Dg库需要修改db_unique_name和db_name一致，不然会报错，等加好实例再把db_unique_name修改回去。（如果二节点是ping状态，需要执行这步：[grid@rac1 ~]$crsctl unpin css -n rac2）忽略addnote的时候进行的自检（因为我们不使用DNS和NTP，若addnode的时候自检不通过，则无法增加节点）（4）：创建相应的目录，并保证权限对应（根据实际情况创建目录,非常重要）（3）：配置系统参数，用户参数和原有节点一样，配置网络。
2024-03-04 11:20:15
1215
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人