- 博客(83)
- 收藏
- 关注
RSS订阅原创 19C低版本导致BUG32653669
Lsinventory Output file location : /oracle/app/product/19.3.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory2023-05-16_19-29-16下午.txt。日志文件位置：/oracle/app/product/19.3.0/db_1/cfgtoollogs/opatch/opatch2023-05-16_19-29-16下午_1.log。主产品清单：/oracle/oraInventory。
2024-06-20 22:55:45
579
原创 trace文件异常暴增问题分析
通过数据库参数MAX_DUMP_FILE_SIZE限制单个TRACE文件的上限值，一定程序上会减少TRACE文件占用的空间，但是无法限制TRACE文件的个数。同时限制单个TRACE文件的上限值后，例如限制为10M，当问题进程对应的TRACE文件达到10M时，后续的TRACE信息无法写入TRACE文件；因短时间内产生海量的TRACE文件，导致TRACE文件所在的目录空间不足，进而导致数据库软件运行出现异常，无法进行备份操作。ALERT日志中提到了大量trace文件，对此类TRACE文件进行了分析。
2024-06-20 22:48:57
802
原创 sql多版本(High Version Count)引起的应用程序插入错误
在数据库AWR中主要分析了多次重启前AWR中的如下信息，发现均是SQL_ID为22j335m33haq6的SQL在当时出现SQL版本多达5000多个，执行次数为0，同时占用较多的cpu time.与正常时刻同时段AWR对比，此SQL应该执行500次左右，与应用软件确认，此SQL确实是业务需要的，无法执行会导致业务执行不下去。同时MOS上提供了判断SQL多版本原因的脚本，可以快速、全面的收集SQL出现多版本的原因(cursor不能共享的原因，上一篇blog里就在写cursor不能共享的事情)。
2024-06-20 00:05:38
392
原创 ora-00600[2662]错误处理方法
方式查询SCN会导致SCN增加，可以参考我以前的 BLOG:http://blog.csdn.net/haibusuanyun/article/details/11590983 而使用dbms_flashback.get_system_change_number方式查询SCN不因查询而变化 [email protected]>select dbms_flashback.get_system_change_number current_scn from dual;resetlogs方式成功OPEN了数据库；
2024-06-20 00:03:45
331
原创 用10046找出impdp创建索引时异常缓慢的原因
发现在impdp导入表后的Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX ，创建索引速度比较慢。很少数据的表上的索引创建速度相比以前测试也不正常，大约5秒左右创建一个，在此次的创建20000多个很小索引的场景，就导致索引创建过程需要耗费10几个小时了；7.重新收集基表相关统计信息，执行计划依然不正确 ，绑定基表SQL执行计划，执行速度恢复正常。继续分析这条语句执行计划，并修正，之后执行速度正常。1.系统资源：CPU/MEMORY/IO使用正常。
2024-06-20 00:02:46
441
原创 SQL Tuning Advisor引起的ORA-07445
关闭SQL Tuning Advisor或者设置参数alter system set "_no_or_expansion" = true;单实例数据库环境，日志报错：ORA-07445:[apaneg()+227]、ORA-07445:[kkqcsnlocbk()+97]，解决方法关闭SQL Tuning Advisor或者设置参数alter system set "_no_or_expansion" = true;2.查看相应的trace报错文件。1.数据库alert日志中报错。
2024-06-20 00:00:53
641
原创 LOB字段列写数据报错ORA-600 [25027]问题处理
LOB字段列插入数据时遇到ORA-600 [25027]、ORA-600 [ktsplbfmb-dblfree] 错误的问题，在处理过程中发现是遇到ORA-01555 问题；ORA-00600 [25027] [x] [0] Raised by Insert into LOB (文档 ID 1608861.1)3.使用MOS提供的处理LOB ORA-01555的PL/SQL来找出报错的LOB段中的行的ROWID及报错信息。IF: ORA-1555 on LOB Data (文档 ID 1950896.1)
2024-06-19 23:59:25
528
原创 因密码文件引起归档日志无法应用的处理
当Lgwr和Arch进程发送redo/archive到standby端的时候，当前log sequence会同standby端RFS进程上次接收到的log sequence做比较，如果发现二者有断档，RFS会发送请求到primary端，要求主库传送缺失的日志。此时的思路是可以尝试手动从主库的节点scp传输归档日志过来进行注册和恢复或者主库重新关闭或开启相应的log目录，或者使用一下重启备库，重新启动相应的进程。涉及的归档较多，因此先尝试了重启DG备库，幸运的是通过重启DG的备库的方式解决了此问题。
2024-06-19 23:57:08
725
原创 一条SQL在library cache中解析涉及的锁
子游标随时可以被交换处library cache，当子游标被交换出library cache时，oracle可以利用父游标的信息重新构建出一个子游标出来，这个过程叫做reload（重载）。6.library cache pin，创建子游标堆6-执行计划的信息（通过优化器创建一个最优的执行计划，这个过程会根据数据字典里面记录的对象的统计信息，来计算最优的执行计划，这一步涉及的运算量很大，最耗CPU资源）。两种类型的Mutex。3.获得library cache pin，创建父游标堆0-父LCO的信息。
2024-06-19 23:55:51
681
原创 ORA-4031错误
长此以往，可能产生大量1K/2K等小CHUNK，总空间很大，但是如果SQL语句需要比如4K的CHUNK，就无法请求到所需的CHUNK，产生共享池碎片，引起ORA-04031错误。---不建议，刷新共享池后，所有的SQL语句都需要重新解析，对共享池中LATCH的争用，以及大量更解析会消耗大量CPU资源。这是一块独立管理的区域，这个区域中的chunk不会挂接到普通区域的链表中，普通区域的chunk也不会挂接到这个区域的链表中。引起这种情况的原因有：频繁更解析--需要内存空间多，并且容易产生更严重的内存碎片。
2024-06-19 23:51:59
848
原创 Oracle 执行计划浅析
这里的概念是在处理你这个操作的时候需要在一致性读状态上处理多少个块，这些块产生的主要原因是因为由于在你查询的过程中，由于其他会话对数据块进行操作，而对所要查询的块有了修改，但是由于我们的查询是在这些修改之前调用的，所以需要对回滚段中的数据块的前映像进行查询，以保证数据的一致性。当前模式块意思就是在操作中正好提取的块数目，而不是在一致性读的情况下而产生的块数。正常的情况下，一个查询提取的块是在查询开始的那个时间点上存在的数据块，当前块是在这个时刻存在的数据块，而不是在这个时间点之前或者之后的数据块数目。
2024-06-19 23:50:48
915
原创 ckptq检查点的工作机制
重做信息存在也为数据崩溃后，数据可以恢复。当检查点发生时，此时的SCN称为checkpoint scn,ORACLE会通知DBWR，把修改过的数据，即此checkpoint scn之前的脏数据dirty data从buffer cache写入磁盘，写入完成后，CKPT进程会相应更新控制文件和数据文件头，记录此检查点信息，标识变更。通过增量检查点，数据库可以将全部写出改为增量渐进写出，从而极大减少对于数据库性能的影响， 而检查点队列进一步将RBA和检查点关联起来，从而可以通过检查点确定恢复的起点。
2024-06-19 23:45:19
850
原创 buffer caceh中读取数据块解析
在DSS系统中，存在大量的direct path read是很正常的，但是在OLTP系统中，通常显著的直接路径读（direct path read）都意味着系统应用存在问题，从而导致大量的磁盘排序读取操作。同时也会根据此块的DBA进行HASH，查找相应的HASH BUCKET，将此块加入到对应的HASH CHAIN上，并对BH中的相应信息进行修改（如对应X$BH中的LRU_FLAG，NXT_HASH、BA等字段的具体值）--此过程也需要相应的CBC LATCH /buffer pin锁的获取释放等。
2024-06-19 23:43:58
505
原创 数据库内部错误00600 故障处理
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [99189], [43531], [43569], [], [], [], [], [], [], []ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [99189], [43531], [43569], [], [], [], [], [], [], []从而导致数据库无法正常open。
2024-06-19 23:41:26
761
原创 ORACLE 19C RAC集群ACFS菜单不显示
使用ORACLE 19C RAC的ASM功能进行磁盘的冗余配置（类似用ASM实现RAID卡的RAID功能），为了兼容低版本的数据库软件（数据库不升级），使用了ASM的ACFS文件系统，来提供一个挂载点目录，运行11G的数据库。重启服务器测试时，发现问题：ACFS的挂载点目录没自动挂载 ，数据库也就无从启动了。检查ASM的ALERT日志，磁盘组MOUNT后，没有操作 volume 的日志；1、加载ACFS文件模块（已经设置到/etc/rc.local）2、检查ACFS模块信息（lsmod没加载）
2024-06-19 23:41:13
845
原创 一些oracle不必要的新特性
在11gR2 中，为了优化这个过程，前台进程通知LGWR写之后，可以通过定时获取的方式来查询写出进度，这被称为 Poll 的模式，在11.2.0.3中，这个特性被默认开启。然而一个执行计划并不总是适用于所有绑定值，为了尽可能生成准确的执行计划，Oracle Database 11g 引入了自适应游标共享的新特性，在执行共享SQL时考虑更多的因素，如果与资源开销相比，使用多个执行计划所带来的收益更重要，则会为使用绑定变量的每条SQL 语句生成多个执行计划。那么可能需要调整这个特性的使用。
2024-06-18 02:38:21
354
原创 获取完整的sql执行计划
相信很多人都很清楚使用explain plan命令、dbms_xplan包、autotrace开关可以获取执行计划，但是如果还需要获取更为详细的执行计划，我们可以使用10046事件来获取。可以很明显的看出来，这样的执行计划很不方便查看，所以我们需要用tkprof命令来翻译，上述得到的trace文件；3、在当前session中执行目标sql，生成对应的trace文件；1、在当前的会话（session）中激活10046事件；4、查看步骤3中生成的trace文件的路径；2、在当前session中执行目标sql；
2024-06-18 02:37:03
750
原创 11gr2 rac修改私网IP
从11.2 Grid Infrastructure开始，私有网络配置存储在OCR和gpnp配置文件中。注意，不支持手动修改gpnp配置文件。5.OS层面修改IP并修改/etc/hosts中记录（两个节点均修改）并测通。5.OS层面修改IP并修改/etc/hosts中记录（两个节点均修改）并测通。具体步骤：--仅显示节点1，节点2同样步骤。3.查看并修改私网配置信息--单个节点进行。3.查看并修改私网配置信息--单个节点进行。7.删除原有私网信息并验证。1.备份gpnp配置文件。1.备份gpnp配置文件。
2024-06-18 02:34:42
603
原创 Oracle AWR报告指标全解析
本文摘自一堆历史性能数据，放在SYSAUX表空间上， AWR和SYSAUX都是10g出现的，是Oracle调优的关键特性；默认快照间隔1小时，10g保存7天、11g保存8天;
2024-06-18 02:32:04
394
原创 共享服务器模式(shared server)和专用服务器模式(dedicated server)
转载自：http://blog.csdn.net/tianlesoftware/article/details/5695784二. 说明2.1 Dedicated server 说对于专用服务器配置，在登录时，Oracle 总会创建一个新的进程，这个服务器进程会在会话生存期中专门这个连接服务。对于每个会话，都会出现一个新的专用服务器，会话与专用服务器之间存在一对一的映射。按照定义，这个专用服务器不是实例的一部分。
2024-06-18 02:29:26
302
原创 导致的library cacha lock的案例处理
而oracle 从202010 RU之后，禁止直接对user基表直接进行修改，会不会有新的bug。果然，提sr之后确认这是一个比较新的补丁或高版本才会触发的未公开bug。将在21c基础版本和19c后续的补丁中解决，解决方案是'_disable_last_successful_login_time'引进一个隐含参数，关闭update user的动作，从而规避该问题。Last_Successful_Logon_Time是12c一个特性，记录用户的最后登录时间。一条update user的sql导致的阻塞。
2024-06-18 02:25:34
291
原创 sql优化浅析
如果发生统计信息不准，执行计划变更，可以通过手工收集统计信息。可以加上no_invalidate=>false控制之后sql生效，否则已存在的执行计划默认5小时后才会使用新的统计信息。在生产中，绝大部分性能问题是由差sql或错误的执行计划导致。如何排查，如何优化呢？模糊查询无论是否有索引也不会走索引的。执行计划全表扫要3小时才能完成。
2024-06-18 02:23:52
381
原创 ORACLE RMAN避免Split Block的产生
这个过程是以Oracle block为最小单位进行的，不存在OS Block级别的拷贝或备份， 那么这个过程是不会产生所谓的"split block " 的。即，一个Oracle Block包含多个OS Block, OS Level的拷贝可能正拷贝的是一个Oracle Block的一部分(比如Header)，1. RMAN 将需要备份的数据文件的所有数据块(Oracle block, 不管是否已格式化，是否有数据) 读入输入缓冲区(PGA的一部分) ，而另一部分被用户更新，发生变化，
2024-06-18 02:21:43
125
原创 Advanced Replication及Stream Replication与dataguard区别
Oracle备份功能包括：高级复制（Advanced Replication）流复制（Streams Replication）备库（Dataguard）
2024-06-18 02:19:37
594
原创 临时表与普通表操作的REDO/UNDO对比
当一个会话结束(用户正常退出 用户不正常退出 ORACLE实例崩溃)或者一个事务结束的时候，Oracle对这个会话的表执行 TRUNCATE 语句清空临时表数据.但不会清空其它会话临时表中的数据.可以索引临时表和在临时表基础上建立视图.同样,建立在临时表上的索引也是临时的,也是只对当前会话或者事务有效. 临时表可以拥有触发器.因此，临时表不需要DML锁。但是临时表产生的REDO的大小却比普通表DML操作的小，是因为临时表中不记录表中数据变化所产生的REDO，只记录了UNDO数据变化所产生的REDO。
2024-06-18 02:17:34
907
原创 通过RMAN对SYSTEM表空间进行介质恢复
发现此时数据库还是正常运行，并且可以做DML操作。但是DDL或涉及数据字典表的操作会报错。--也验证了删除系统表空间的数据文件数据库并不会SHUTDOWN.可以看到，备份的SYSTEM表空间之后的创建表空间、建表插入数据的操作产生的数据都正常。3.模拟SYSTEM表空间故障--这里是把SYSTEM表空间的数据文件改名。此时打开数据库会报错，无法锁定数据文件。此时数据库是MOUNT状态。建表时报错--涉及数据字典，数据字典在系统表空间。2.创建一个表空间，并在此表空间上建表。4，使用RMAN恢复系统表空间。
2024-06-18 02:15:07
335
原创 数据泵（expdp/impdp)和导入导出（exp/imp)对比
EXPDP/IMPDP是Oracle推荐的数据泵导入导出工具，用于代替传统的EXP/IMP，只能在服务端使用，效率比EXP/IMP快几十倍，有续传功能和并行功能。EXPDP工具的效率差不多比EXP快几倍，IMPDP工具的效率差不多比IMP快几十倍，这两个工具适用于大数据导入导出的场景。在使用EXPDP/IMPDP之前需要定义一个目录对象，告知EXPDP/IMPDP工具导出的文件和导入的文件的存放目录。此次实验数据量不大，以上的每个工具的导入导出都测试两次，结果依然如上。1.使用EXP导出，用时30秒。
2024-06-18 02:13:12
368
原创 Oracle硬解析测试
4.获取library cache lock latch，然后访问kh --kh --kgh handle，latch保护小的块并很快释放 --3.获取library cache lock latch，然后访问kh --kh --kgh handle，latch保护小的块并很快释放 --exec ludaparse(3) --- 出现library cache pin的等待。------申请完latch得到lock，然后latch释放。------申请完latch得到lock，然后latch释放。
2024-06-18 02:09:56
245
原创 数据文件个数大于1024时FILE_ID及RELATIVE_FNO的变化示例
u01/oradata/bys3/test2/test1019.dbf 2047 1 -------结合第4步的查询，TEST2表空间的相对文件号也是从5开始的，所以这里可以有1 2 3 4的相对文件号。/u01/oradata/bys3/test1/test1018.dbf 1023 1023 ---可以看到相对文件号大于1023时，自动变为1--TEST1表空间的1。
2024-06-18 02:06:03
269
原创 Oracle数据块内部结构
第二部分为可变长度，包含itl，长度根据itl条目的个数变化，每个itl长度为24字节，内部结构名ktbbhitl。BBED是Oracle提供的块编辑器，借助BBED，可以帮助我们更好的理解Oracle的Block的结构。当然，反过来说，也只有更加理解块的结构，才能更好的利用BBED完成某些特殊情况下的灾难恢复。Data Layer：包括Data Header，Table Directory，Row Directory，Free Space和Row Data。每个条目长4字节，内部数据结构名kdbt。
2024-06-18 02:03:30
444
原创 如何处理Oracle数据库中的坏块
在我们对数据块进行读取写入操作的时候，数据库会对要读写的数据块做一致性的检查，其中包括。的系统函数，对数据块进行读写操作，因此，坏块是有可能由以下几种原因产生。，不同的值代表着数据块的不同的层出现问题，具体的如下表所示。标记有坏块的表，在做全表扫描的时候跳过坏块，执行以下的语句。然后从存在坏块的表中取出不存在坏块的数据，执行以下的语句。的方法取出没有坏块数据，然后重建表，表上的索引和限制。的方法来检测坏块，它执行坏块的检查，但是不会标记坏块为。根据临时表中的数据重建表，重建表上的索引，限制。
2024-06-18 02:01:59
519
原创 latch的基础概念
于是P1先将A从内存读入，检测A是0，于是准备将A置为1,在P1将A写回内存前，P2也将A读入，此时A仍然是0。但是与mutex的区别是，mutex互斥量，同一时间只能被一个进程获取，而信号量，可以同时好几个进程获取。但是请别忘了，你这个标志位本身，也是一种资源，对这种标志位本身的访问，也是会发生冲突的！问号处的[L]，现在你知道了，这里是Lock，但是如果没有上面的知识，你很难理解这里为什么会是Lock。本文只讲基础，那就是，你知道太多种latch了，可是，你真的知道什么是latch吗？
2024-06-18 01:57:40
246
原创 dump 控制文件头信息示例
Db ID=3358363031=0xc82c8d97, Db Name='BYS3' ---数据库的DBID和DB_NAME信息。SYS@ bys3> oradebug tracefile_name --找出产生的TRACE文件名。查看产生的TRACE文件信息 --因只DUMP了控制文件头的信息，所以内容并不多。1 控制文件中的文件头信息。
2024-06-18 01:54:26
249
原创 ORA-00604-ORA-20001处理排查
本次使用10046trace来跟踪删除语句，查找出对应的触发器SQL，应用厂商人员据此很快找到了对应的触发器。之后可以通过禁用触发器或使用高权限账户(system)来删除处理。经过测试，可以发现使用SYS/SYSTEM账号可以正常创建删除；业务账号可以创建、不能删除，基本确定是有相关安全策略或触发器的影响。检查报错信息后，初步判断可能是账户权限或触发器问题导致的此问题。但是到底哪些触发器影响呢，系统中有很多默认及应用的触发器，排查起来还有是难度的。5.格式化后检查分析10046 TRACE文件。
2024-06-18 01:53:02
408
原创 library cache和dictionary cache
有可能会发生该对象的句柄存在，但是句柄所指向的对象已经被交换出内存的情况出现。就是通过串连起来的对象句柄才体现出来的，它本身是一个逻辑上的概念，是一个逻辑组，而不像对象是一个具体的实体。用来存放与对象有直接关系的一些信息，比如对象类型、对象相关的表、实际的执行计划、执行。里的对象的一些属性，包括名称、标记、指向对象所处的内存地址的指针等。语句的对象就是书中的页，而句柄就是目录，通过目录可以快速定位到指定内容的页。）、有关对象的一些标记（比如对象是否为只读、为本地对象还是远程对象、是否被。
2024-06-18 01:52:15
555
原创 快速判断Oracle数据库运行效率
在这种情况下，我们的生产数据库在预期的响应时间内运行。显然，如果遇到数据库响应时间缓慢的问题，应该调查根本原因，并根据具体情况采取纠正措施。现在就有了数据库当前的响应时间。接下来需要做的就是和已经建立的阈值或其它窗口的响应时间做比较。可以检查以下视图： dba_hist_sysmetric_history 和 dba_hist_sysmetric_summary。你的工作是根据每种情况的具体细节来了解响应时间是否令人满意。查看过去一分钟数据库的最小、最大、平均的响应时间。查看过去一分钟数据库的响应时间。
2024-06-17 23:01:13
204
原创 Oracle RAC性能调整
1、CPU和wait time调节尺寸 当在调节system时，比较系统的CPU time 和wait time是十分重要的，从而确定在相应时间中多少是用于有效的工作时间，多少是在等待由其他进程占用的资源。 从一般规律来看，wait time占主要部分的系统比CPU time占主要部分的系统更需要调节。另一方面，CPU的大量使用可能是由不好的SQL写操作造成了。 尽管CPU time与wait time的比率总是随着系统装载的增加而趋于减小的，wait time的急剧增加是存在
2024-06-17 22:57:00
929
原创 Oracle闪回验证
类似归档日志，11G新增的后台进程FBDA（flashback data archiver process)用于对闪回数据进行归档写出。-- 网上查的，创建的闪回归档表名？5.通过执行计划可以看到查询来自SYS_FBA_TCRV_75320，这是属于闪回归档表空间用于记录闪回数据。ORACLE可以指定闪回归档数据保存时间，并可以通过内部分区和压缩算法减少空间使用。闪回数据归档需要独立的存储，使用此特性前需要创建独立的ASSM表空间。3.从alert日志中查看闪回归档表空间的创建及FBDA进程的启动。
2024-06-17 22:55:57
530
原创 buffer cache-lru和lruw链表
还未找到可用块，则将触发DBWR写LRUW上的脏块--（CKPTQ队列的写不涉及LRUW， 只有DBWR会写LRUW上脏块，并且写的是LRUW上的全部脏块-每三秒醒来也要全部写出LRUM上所有块才会休眠。同时也会根据此块的DBA进行HASH，查找相应的HASH BUCKET，将此块加入到对应的HASH CHAIN上，并对BH中的相应信息进行修改（如对应X$BH中的LRU_FLAG，NXT_HASH、BA等字段的具体值）--此过程也需要相应的CBC LATCH /buffer pin锁的获取释放等。
2024-06-17 22:54:55
543
原创 某单位信息中心一次数据库性能分析
由于部分SQL语句设计或编写效率低下，以及表缺少适应的索引，导致SQL语句需要全表扫描，在表较小时，ORACLE数据库将数据读取到缓存后，后续虽然是全表扫描，但均是从缓存中读取，所以问题未体现出来。在表的数据量不断增大后，根据ORACLE 11g数据库的算法，在表达到db_cache_size（GB）的2%（默认值）以后，认为采用直接路径读（跳过缓存，直接从磁盘文件中全扫描读取）截取当天9：00至11：00之间数据库性能指标快照。数据库存在较为严重的行级锁等待事件。发现较多执行耗时较高的语句（如图）
2024-06-17 22:53:03
523
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人