刚帮你查了一下，这个应该是一个BUG，尝试下下面的WORKAROUND
Abstract: ORA-7445 [ACCESS_VIOLATION] [_KKQSFOUNDINSOL+55]
*** 07/23/08 11:43 am ***
TAR:
----
PROBLEM:
--------
Select * from a view fails with the following error:
ORA-7445: exception encountered: core dump [ACCESS_VIOLATION]
[_kkqsFoundInSol+
55] [PC:0x203CC1F] [ADDR:0x8400038] [UNABLE_TO_READ] []
Current SQL statement for this session:
select * from test1a
DIAGNOSTIC ANALYSIS:
--------------------
The customer is trying to create a rewrite_equivalence using this view and is
unable to do so due to the error.
The issue was originally reported as
ORA-600: internal error code, arguments: [kkqscsoe:p1=p2], [], [], [], [],
[],
but this error was fixed by applying Patch 7154241
and now the ora-7445 is being reported.
Determined that setting optimizer_features_enable = '9.2.0' allows the select
from the view to complete without error.
WORKAROUND:
-----------
Setting optimizer_features_enable = '9.2.0' allows the select to work without
error. The work around is unacceptable since it is likely to
introduce new severe issues in the customers applications.
MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。
临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。
10.2.0.4版本的基本情况
10.2.0.4是第二个大量用于生产系统的10g版本，第一次发布时间是2008年4月，根据目前Oracle的支持政策该版本已经终止支持，即DeSupport。
一个数据库版本DeSupport就意味着：
如果是已知的Bug，已经有相应Patch的，仍然可以使用；
如果问题可能是新的Bug引发的，后台部门不再提供补丁开发支持；
以下是10.2.0.4版本的发布时间，补丁终止时间及最新补丁集的信息：
Release Platform Release Date Patch End PSU CPU Bundle Patch
10.2.0.4 HPIA11.23/31 30-Apr-2008 31-Jul-2011 PSU15(overlay PSU4) P+P In PSU 2012Jan N/A
10.2.0.4与之前10.2.0.3版本不同之处在于，PSU(PatchSet Updates)在这个版本被引入了,这种类型的补丁包是在两个PATCHSET之间以季度为周期发布的补丁，它一般包含了一些关键补丁和CPU补丁。通常建议用户周期性的应用PSU补丁来增加代码的代码的强壮性。
对于任何数据库版本而言，关键Bug以两种方式来区分：
通用的关键Bug：即与特定的硬件通用的，所有相同的数据库版本均会受影响；
2. 相关的关键Bug：即与特定相关的环境,OS补丁有关的关键Bug，该Bug只在这个出现，而在其它不会触发；
接下来将按照两种分类来描述关键Bug。
10.2.0.4的关键Bug
通用的关键Bug
参考Known Issue文档及RAT建议，目前该版本通用的关键Bug包含：
Bug/Doc Description Impact
Dump (ksuklms) / instance crash Instance Crash
.1 OERI [kddummy_blkchk] / OERI [5467] for an aborted transaction of allocating extents MEM/DATA/Dictionary损坏
.1 RFS in Standby with a wrong location for archived log corrupting/overwriting database files when max_connections >1 MEM/DATA/Dictionary损坏
.1 ORA-1578 corrupt block with AUTH SQL*Net strings MEM/DATA/Dictionary损坏
ORA-600 [7999] [9] [1] [<lob block rdba>] / ORA-1555 double allocated LOB block MEM/DATA/Dictionary损坏
Buffer cache corruptions. ORA-7445 [ktsk_l1_redo_reset_shrink] caused by SHRINK 宕机或/MEM/DATA/Dictionary损坏
Dump [under kxspoac] / ORA-1722 as SQL uses child with mismatched BIND metadata MEM/DATA/Dictionary损坏
ORA-8102 / ORA-1499 corrupt index after update/merge using QUERY REWRITE MEM/DATA/Dictionary损坏
Corrupt index after PDML executed in serial. Wrong results. OERI[kdsgrp1]/ORA-1499 by analyze MEM/DATA/Dictionary损坏
Database corruption / OERI[kcbgcur_6] if many undo segments are created MEM/DATA/Dictionary损坏
EXPDP/IMPDP corrupts the data for a LONG column MEM/DATA/Dictionary损坏
.1 Corruption / OERI [kddummy_blkchk] .. [18021] with ASSM MEM/DATA/Dictionary损坏
ORA-8102/ORA-1499/OERI[kdsgrp1] Index corruption after rebuild index ONLINE MEM/DATA/Dictionary损坏
Alter tablespace drop datafile drops can corrupt the database MEM/DATA/Dictionary损坏
.1 Array Update can corrupt a row. Errors OERI[kghstack_free1] or OERI[kddummy_blkchk][6110] MEM/DATA/Dictionary损坏
.1 ORA-955 during CTAS / OERI [ktsircinfo_num1] / dictionary inconsistency for PARTITIONED Tables MEM/DATA/Dictionary损坏
.1 Block corruption / OERI[kddummy_blkchk] after direct load of ASSM segment MEM/DATA/Dictionary损坏
Wrong results from range predicate on concatenated index with NULLs WrongResult
.1 NUMA enabled by default can cause high CPU / OERI Performance
PMON SPINNING IN NETWORKING CODE Performance
以下是各个Bug的详细描述：
Bug
影响程度 Instance May Crash
有无补丁 有
Bug描述 当一个系统进程被异常Kill时，如果正在调用ksuklms函数，则有可能导致系统宕机。这个问题与一个变量没有初始化有关。
该问题在RAC上居多，但单实例库也仍然有可能会触发。
Workaround 可以使用EVENT 10422,Level 1, 强制变量初始化。
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 当用户以alter table allocate extent为LOB段分配空间，并且空间位于ASSM表空间内时，当过程被异常中止时系统报ORA-600 [ktsptrn_fix-extmap]，这说明可能触发了这个Bug
Workaround 使用DBMS_SPACE_ADMIN对表空间进行分析，并删除问题段，同时重建表空间位图。详细步骤请参考Note .1；
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 在Dataguard环境中，主库的LOG_ARCHIVE_DEST_N中设置了max_connections>1时，备库可能会错误的向数据文件，日志文件等写入数据，导致Corruption(MEM/Block/Dictionary/Index)。
Workaround 保证LOG_ARCHIVE_DEST_N的max_connections>1
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 在Dataguard环境中，主库的LOG_ARCHIVE_DEST_N中设置了max_connections>1时，备库可能会错误的向数据文件，日志文件等写入数据，导致数据损坏。
Workaround 保证LOG_ARCHIVE_DEST_N的max_connections>1
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 当数据库服务器端SQLNET.ORA设置sqlnet.inbound_connect_timeout 大于0时，SQL*Net在异常情况下将AUTH字符覆盖数据文件，并且后续SQL访问会报ORA-1578.
Workaround To prevent it:
1. set sqlnet.inbound_connect_timeout=0 in the sqlnet.ora for the server side.
2. use ODM library.
To repair the block:
1. use RMAN Blockrecover or Datafile media recovery.
2. If the affected block is the OS BLock header, resize the datafile.
Bug
影响程度 Hang(Process Hang/Spins)/Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 当一个表的LOB列被重复分配后会触发ORA-600 [7999]/ORA-1555
语句类似于：
update D set c1 = (select to_lob(c1) from S where D.pk = S.pk)
其中D.C1是clob类型，S.C1是long类型；
文档.8提供了确认受影响对象的脚本；
Workaround 无
Bug
影响程度 Instance May Crash
有无补丁 可用
Bug描述 当数据库_db_block_cache_protect为Enabled，并且执行SHRINK SPACE *** 作后Buffer Cache元数据未做同步，导致出现大量ORA-600 [ktsk_l1_redo_reset_shrink]和ORA-7445错误。
Workaround 无
Bug
Bug号
影响程度 进程异常退出
有无补丁 可用
Bug描述 在会话新生成一个子游标时，其嵌入变量的元数据与已有游标的元数据不一致时报ORA-1722错误，调用堆栈位于_intel_fast_memcmp
Workaround 应用代码中嵌入变量的类型定义需要保持一致。
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 在UPDATE/MERGE的子查询中使用查询重写(Query Rewrite)时索引没有同步维护。因为表与索引不一致所以会报如下错误：
ORA-8102
ORA-600 [kdsgrp1]
ORA-600 [qertbFetchByRowID]
Workaround 对于UPDATE/MERGE语句通过Hint避免使用Query_Rewrite，比如：
UPDATE <table>SET <column>= <value>WHERE (SELECT /*+ NOREWRITE */.)
对于已经出现不一致的索引，可以使用Drop/Create来重建。
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 对于UPDATE/DELETE/MERGE语句启动PDML时，由于并行进程不足使索引没有同步维护。当不一致发生时，系统会报：
ORA-600 [kdsgrp1]
ORA-600 [qertbFetchByRowID]
ORA-600 [13013] with error code 17 KDCMPF11 by an update
ORA-8102
Workaround 确认Parallel_max_server足够或者对DML使用串行方式。
Bug
影响程度 Process May Dump (Failure)
有无补丁 可用
Bug描述 数据库在管理大量UNDO（接近32K时）可能会报ORA-600 [kcbgcur_6]，之后SMON进程会异常退出，进而影响实例正常运行。
Workaround 无
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 在使用DATAPUMP导入时，并且满足以下条件时可能会触发此Bug:
导出的数据源自多字节的字符集，如al32utf8
2. 表包含long类型字段；
3. 创建表之后立即追加一个列；
Workaround 无
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 用户会话在向对象追加空间时失败，进而PMON/SMON会报错。数据库关闭后因为SMON无法恢复事务而无法打开；
Workaround 可以按照以下步骤恢复数据：
通过EVENT10513屏蔽SMON对失败事务的恢复；
2. 以Restrict模式启动数据库；
3. 删除问题对象，并清理回收站；
4. 关闭EVENT，重新启动数据库即可；
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 当索引重建的表为高并发访问时，在线索引重建可能会丢失一些索引键值。之后一些 *** 作会报错，包括：
ORA-8102 by a delete/update
ORA-1499 by "analyze table validate structure cascade"
ORA-600 [kdsgrp1]
ORA-600 [qertbFetchByRowID]
Workaround 避免频繁UPDATE时在线重建索引
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 alter tablespace XXX drop datafiles时可能会删除包含某些段的数据文件，这就导致数据库损坏。
Workaround 避免使用这些语句删除某些数据文件；
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 在使用Forall . update对行进行更新时可能会报
ORA-600 [kghstack_free1]
ORA-600 [kcbzpbuf_1]
ORA-600 [kcbbvr_verify_disk_blk_1]
ORA-600 [kdourp_inorder2]
Workaround 如果发现问题，请使用ROWID跳过损坏数据来重建问题表，或使用dbms_repair跳过问题数据。
具体的 *** 作方式可参考文档.1
Bug /
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 当使用Create table AS以并行方式创建表时可能会触发这两个Bug。导致数据字典的SEG$与TAB$不一致或TABPART$与SEG$不一致；
Workaround 避免在并发DDL开始后对分区或表进行维护 *** 作
Bug
影响程度 Corruption(MEM/Block/Dictionary/Index)
有无补丁 可用
Bug描述 在对位于ASSM表空间里的Direct Path对象进行Drop/Truncate时，可能会报ORA-600 [kddummy_blkchk]错误
Workaround 确认问题请用DBMS_SPACE_ADMIN.ASSM_TABLESPACE_VERIFY；可重建对象解决，但问题触发因素有许多种，应当根据不同情况确认，可根据文档.1详细判断
Bug
影响程度 Wrong Results
有无补丁 可用
Bug描述 在对一个复合索引的非首列使用< *** 作符时没有使用is not null过滤时会触发；
Workaround 无
Bug
影响程度 Performance Affected
有无补丁 可用
Bug描述 NUMA特性在Oracle数据库中使用时可能会出现性能不稳定的情况，该补丁用于修改数据库对于NUMA特性的使用，应用此补丁后NUMA特性缺省为关闭状态。
Workaround 通过参数关闭NUMA特性：
_enable_numa_optimization=FALSE
_db_block_numa=1
Bug
影响程度 Hang(Process Hang/Spins)
有无补丁 可用
Bug描述 PMON在调用某些网络访问代码时可能陷入死循环，当时的调用堆栈为：
nlsqInsert
nstoHandleEventTO
nstoToqWalk
nsevwait
ksnwait
ksliwat
kslwaitns
kskthbwt
kslwait
ksuclnwt
ksucln
ksbrdp
opirip
opidrv
sou2o
Workaround 无
10.2.0.4与Hp-ux相关的Bug
OS Bug
影响程度 Instance May Crash
有无补丁 无
Bug描述 RAC diagnostics 可能引起实例 crash，建议升级到10.2.0.5修复这个bug。
Workaround 无
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）