- 博客(68)
- 资源 (11)
- 收藏
- 关注
RSS订阅原创 Solaris系统参数未配置导致rac节点重启异常
创建文件vi /etc/rc2.d/S99nddconfig，设置TCP UDP内核参数，内容如下：（两节点）在两个节点上配置同样的Solaris内核参数。修改两台节点的/etc/system文件。配置Solaris内核参数。
2024-04-16 10:55:32
424
原创 crf空间满导致集群重启异常
此操做除了丢失 CHM 收集的操作系统统计信息外，删除 bdb 文件不会产生其他影响，重新启动后，会重新生成bdb文件，CHM 将再次开始收集操作系统统计信息。bdb 文件非常大，甚至超过 2GB的另一个原因是由于bug造成，因为默认情况下bdb大小限制在1GB，除非CHM数据保留期修改变大了。这是保留CHM数据三天，259200单位是秒。
2024-04-16 10:48:59
341
原创 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
422
原创 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
560
原创 关闭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
420
原创 rac数据库默认网关不通导致集群异常
集群CSSD进程reconfiguration完成，显示2个节点都在线。但ora.net1.network服务启动失败，且有依赖关系的资源随后启动失败并且已经达到上限。查看两个节点的网络信息，发现两个节点的默认网关是不一致的。
2024-04-08 16:16:18
273
原创 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
166
原创 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
1028
原创 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
323
原创 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
448
原创 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
970
原创 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
328
原创 分区表索引失效导致业务异常
核查该sql语句执行慢的原因，分析其执行计划发生了变动，出现了全表扫描。频繁对400G的大表进行一个全表扫描，导致数据库卡死。为了确保业务快速恢复，最快的解决方式就是先通过手动绑定对的执行计划，恢复sql的执行效率。绑定执行计划后发现，并没有执行正确的索引扫描。排查出造成阻塞的源头sql，该条sql语句与分区表相关。业务无法正常进行，查看数据库后台进程，发现有大量阻塞。可以看到新分区表部分索引状态出现了异常。修复索引完毕后，业务sql恢复效率。开始修复状态异常的索引。
2024-03-22 15:42:05
734
原创 aix小机rac仲裁盘故障处理
如果没有/etc/exports文件，使用mknfs命令之后，nfsd、rpc.mounted进程不会启动，需要添加一个空的此文件。# lssrc -s portmap （状态为active即可）在客户端检查进程 portmap是否启动正常。
2024-03-19 15:53:20
697
原创 数据库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
637
原创 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
466
原创 rac心跳延迟现象及排查
4、当然还有可以通过oswatch的netstat日志去检查，当发现IpReasmFails指标开始增长，且增长速度很快，就说明私网通信有异常。1、心跳流量是否达到了网络带宽的上限，可以通过：ethtool eth3、ethtool eth4去确定网口的协商速率。发生异常时，一般流量较大，这里每秒流量达到了24M，如果带宽比较小或者MTU大小为默认的1500，可能造成较大的影响。3、调整mtu后需要测试mtu设置，mtu服务器和交换机都要调整。在正常情况下，心跳网络每秒流量基本上很小，这里才580k。
2024-03-14 14:32:22
795
原创 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
490
原创 内存抖动导致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
597
原创 19c补丁后oracle属主变化，导致不能识别磁盘组
在grid用户下检查磁盘组，发现data磁盘组正常mount。进入data磁盘组，检查redo、密码文件均正常。修改完属组，再次重启数据库，正常起来。2、data磁盘组不能访问。1、不能读取redo文件。
2024-03-11 11:59:00
416
原创 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
1192
原创 数据库专用、共享服务连接报ORA-12520
设置max_shared_servers, shared_server_sessions为0，关闭了共享模式，检查监听日志，新进连接是否都是专用模式。当然了，当前客户要求不使用共享模式，所以关闭共享模式，使用专用模式。检查process配置及连接数均正常，没有达到上限。专用模式正常，查看资源使用情况，没有达到上限，配置了5个共享服务进程，最大可以增加到15个。那么检查共享模式连接，使用情况查看。默认情况共享模式是5个连接。
2024-02-28 10:26:56
595
原创 oracle数据库10g升级到11g性能分析比较
通过该优化结果优化完，继续做spa性能分析比较，跟最新的snap快照做比较。正常无需操作，异常做解压，解压中转表的数据到SQL Tuning Set。如sql_id为：fp6mb0ja0u1xp，性能变差了，执行计划也变了。11g也可以从现有awr报告中获取数据做分析数据来源，跟10g的做比较。正常情况下，无需操作，异常重建sqlset，并做解压操作。也可以通过其他方式加载指定数据，如下。重建11g的spa性能分析数据。用来做10g的Spa数据保存。从cpu_time来进行比较。物理升级，刷试图升级（略）
2024-02-27 10:29:58
1261
原创 delete误删基表（seg$）bbed恢复cluster table
有客户通过delete误删了sys.seg$表的数据，重启数据库，发现数据库不能正常启动。删除命令：delete from sys.seg$ t where ts#=2;跟普通表所在行不一样，存数据的是row 30，没有数据。ckix@5048: 30 《—-连接到30行。从数据块里面获取修复脚本。通过dump删除标识。
2024-02-26 14:11:04
779
原创 Oracle DB Replay新上数据库性能测试分析
Database Replay实施的流程是workload_capture->workload preprocess->replay client prepare->replay->generate replay report，对于同一个capture可以进行多次replay。执行完毕后，会生成wcr_process.wmd,wcr_login.pp, wcr_seq_data.extb, wcr_scn_order.extb , wcr_conn_data.extb等文件。
2024-02-23 10:23:25
938
1
原创 索引聚簇因子clustering_factor太大导致不走索引
正常情况blocks<clustering_factor<num_rows，clustering_factor越靠近block数，说明表中的记录很有序，读取少量的data block就能得到想要的数据，但clustering factor接近表记录数，说明表的存储和索引排序差异很大，在做index range scan的时候，会额外读取多个block，代价较高。差异特别大，可以对索引做rebuild操作，聚簇因子会自己改成合适的数值，略大于块数。设置成500万后，查询终于走索引。
2024-02-22 09:14:27
570
原创 ORA-07445异常报错opixguid()+13
ORA-07445: 出现异常错误: 核心转储 [opixguid()+13] [SIGSEGV] [ADDR:0x7F67B7F4EBC0] [PC:0x648BB7D] [Address not mapped to object] []ORA-07445: 出现异常错误: 核心转储 [opixguid()+13] [SIGSEGV] [ADDR:0x7F67B7F4EBC0] [PC:0x648BB7D] [Address not mapped to object] []这是一个bug导致。
2024-02-21 10:33:53
949
原创 据库异常sql耗尽CPU资源
由于SQL语句（sql_id: 1hwgwzgw0vfrc）执行性能较差，导致CPU资源耗尽，影响了整体数据库运行，总结情况如下：1、rac两个节点访问量不均衡，发生性能问题时节点一CPU资源耗尽，建议通过scanip去访问数据库。2、发生异常情况时，消耗高资源(CPU)的sql语句“1hwgwzgw0vfrc”，sql执行次数比正常情况多，同正常比较，半个小时内就多执行了2300多次。3、建议优化sql_id为“1hwgwzgw0vfrc”的sql语句，该语句已经优化，业务恢复正常。
2024-02-20 15:03:55
1046
原创 跑批SQL性能异常分析
通过上述分析判断，最主要的问题还是SQL语句本身未使用绑定变量导致执行计划不稳定，执行效率低所导致。解决方法：1. 规范开发SQL语句编写统一使用绑定变量2. 评估bs_account_jnls_tax表大小，keep到buffer cache内存中，或问题SQL前先执行select count(*) from trans_jnls_no/ bs_account_jnls_tax。
2024-02-20 09:44:41
1064
原创 HP小机下async模式数据库启动故障
RAC环境下，direct I/O是默认开启的。disk_asynch_io是相当于主开关，不管是文件系统还是裸设备，它都控制着异步io的开启与关闭，filesystemio_options是子开关，控制着文件系统上的异步io。当然在正常情况下使用默认参数即可，不建议调整DISK_ASYNCH_IO和filesystemio_options参数，因为调整后可能会影响数据库性能，io流量也会受到影响。RAC环境下，Asynchronous IO受DISK_ASYNCH_IO参数控制，默认是TRUE，
2024-02-18 09:57:53
360
原创 rac二节点实例redo故障无法启动修复
2、对损坏的redo log组进行清理（由于28组redo log状态为active，active和CURRENT状态的redo可能存在无法清理的情况）查询v$log视图发现节点二的redo log组没有状态为current的日志组。大概率redo log已经损坏，无法正常打开数据库进行应用。目前节点二为mount状态，open报错。3、如果无法清理，在1节点进行disable 二节点。节点二由于redo故障问题无法正常启动。4、在1节点清理二节点故障redo。5、在1节点重新开启二节点。
2024-02-05 14:19:06
354
原创 oracle视图二次查询慢
这个问题首先想到了，基数反馈(Cardinality Feedback )问题导致的查询慢，由于并不确认是否真是这个问题造成，首先在会话级别调试，设置session级别"_optimizer_use_feedback"=FALSE。基数反馈是 Oracle 11.2 引入的关干 SQL性能优化的新特性，但是该参数存在不稳定因素，可能会带来执行效率的问题，所以建议关闭优化器反馈。同样一个sql查询视图，首次查询很快，1s内就查询出来，第二次再查需要1分多钟才能出来。
2024-02-05 11:01:32
769
原创 rac使用默认闪回区归档空间满
检查归档配置，发现配置到“db_recovery_file_dest_size”闪回空间里了，由于近期归档增量较多，导致空间达到500G，超过db_recovery_file_dest_size设置的值。调整db_recovery_file_dest_size=600000M后业务恢复，最后为了防止后续再次发生空间满，把归档路径设置成'+DATA'。检查，实例状态正常，
2024-02-04 09:08:14
360
原创 file-max设置过小导致oracle数据库hang住
open files (-n) 65536 <===============配置正常。一个进程可以打开的文件数 < hard limit < nr_open，soft limit是告警值，可以超过这个值。file-max操作系统对于文件打开数有一个全局的限制，可以通过/proc/sys/fs/file-max查看。另外：nr_open用于限制单个进程可以分配的最大文件打开数。修改后恢复正常，message异常告警消失。
2024-02-02 11:07:03
431
原创 oracle数据回滚导致业务性能问题排查
本次性能故障主要原因是大表delete被异常终止，引起大事物回滚，系统资源开销上升，间接影响了相同表格上其他insert操作，引起latch:undo global data争用，导致该业务模块性能下降。所以，对于大事物回滚建议将系统参数fast_start_parallel_rollback修改为false,关闭并行恢复，减小高峰期系统资源争用。另外该业务表格存日期字段o360seq为varchar类型，而且此字段含有主键索引、联合索引多达3个，但实际上删除中条件使用了函数，索引并未产生作用。
2024-02-01 11:28:00
1480
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人