PostgreSQL运行日志管理

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：PostgreSQL运行日志管理

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

PostgreSQL目前配置中,不直接记录日志文件,这样的情况给数据库后期出现问题(特别是无法正常启动的情况)分析带来很大麻烦,不知道具体问题所在,建议在PG安装完成之后,启用日志功能,便于数据库运行状态检查和错误跟踪,主要日志参数涉及以下配置

log_destination = 'stderr'              # Valid values are combinations of
                                        # stderr, csvlog, jsonlog, syslog, and
                                        # eventlog, depending on platform.
                                        # csvlog and jsonlog require
                                        # logging_collector to be on.

# This is used when logging to stderr:
logging_collector = on          # Enable capturing of stderr, jsonlog,
                                        # and csvlog into log files. Required
                                        # to be on for csvlogs and jsonlogs.
                                        # (change requires restart)
//是否将日志重定向至文件中，默认是off。

# These are only used if logging_collector is on:
log_directory = 'pg_log'                   # directory where log files are written,
                                        # can be absolute or relative to PGDATA
//日志文件目录，默认是PGDATA的相对路径，即PGDATA的相对路径，即{PGDATA}/pg_log，也可以改为绝对路径。
//日志文件可能会非常多，建议将日志重定向到其他目录或分区。
//将此配置修改其他目录时，必须先创建此目录，并修改权限，使得postgres用户对该目录有写权限。

log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern,
                                        # can include strftime() escapes
log_file_mode = 0600                    # creation mode for log files,
                                        # begin with 0 to use octal notation
log_rotation_age = 1d                   # Automatic rotation of logfiles will
                                        # happen after that time.  0 disables.
log_rotation_size = 10MB                # Automatic rotation of logfiles will
                                        # happen after that much log output.
                                        # 0 disables.
#log_truncate_on_rotation = off         # If on, an existing log file with the
                                        # same name as the new log file will be
                                        # truncated rather than appended to.
                                        # But such truncation only occurs on
                                        # time-driven rotation, not on restarts
                                        # or size-driven rotation.  Default is
                                        # off, meaning append to existing files
                                        # in all cases.
//当日志文件已存在时，该配置如果为off，新生成的日志将在文件尾部追加，如果为on，则会覆盖原来的日志。

上述配置得到的结果如下

[postgres@xifenfei pg_log]$ pwd
/data/pg/15/data/pg_log
[postgres@xifenfei pg_log]$ ls -l
total 4
-rw------- 1 postgres postgres 1263 Apr  3 22:37 postgresql-2025-04-03_223117.log

pglog

ora-600 kdsgrp1 错误描述

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：ora-600 kdsgrp1 错误描述

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

当 fetch作找不到预期的行时，会引发 ora-600 [kdsgrp1] 错误。该错误在内存中命中，因此可能是仅内存错误或由磁盘损坏导致的错误。

此错误可能表示（但不限于）以下任何情况：

  • 丢失写入
  • 并行 DML 问题
  • 索引损坏
  • 数据块损坏
  • 一致性读取 [CR] 问题
  • 缓冲区缓存损坏

说明 285586.1 - ORA-600 [kdsgrp1] 中
提供了已知问题的完整列表：
每个错误都有一个简短描述，指示遇到它的情况。可以通过选择您的数据库版本来缩短 bug 列表，以仅显示可能影响您的问题。

此问题可能是间歇性的，也可能持续存在，直到修复底层磁盘级别损坏为止。间歇性问题可能是基于内存的（但是，对损坏的间歇性访问可能会与间歇性内存问题相混淆）。

常见的解决方法

如果问题仅在内存中，我们可以尝试通过刷新缓冲区缓存来立即解决问题，但请记住考虑对生产系统的性能影响：

更改系统刷新buffer_cache;

如果我们遇到间歇性一致性读取问题，我们可以尝试禁用 rowCR，这是一种优化，通过在初始化文件中设置 _row_cr=FALSE 来减少查询期间的一致性读取回滚。但是，这可能会导致查询的性能下降。请检查“RowCR hits”/“RowCR attempts”这两个统计信息的比率，以确定是否要使用解决方法。

如果这是索引损坏的结果，那么我们可以删除并重新构建索引。请注意，这将需要在 生产系统上有一个 maintenance window。

根本原因确定
现在让我们看看我们如何发现问题的根本原因：查找此问题根本原因的第一步是检查生成的跟踪文件。ora-600 将在跟踪目录中生成跟踪文件，并在事件目录中的事件 ID 下生成事件文件。
跟踪文件的顶部告诉我们遇到错误时正在运行的 SQL：

—–此会话的当前 SQL 语句 （sql_id=9mamr7xn4wg7x） —–

这立即向我们显示了访问的数据对象。在跟踪文件中搜索文本字符串 ‘Plan Table’ 将找到此跟踪文件中转储的 SQL 执行计划。对于持久性问题，这允许我们确定哪些索引已被访问，从而确定应验证以检查块损坏的索引：

SQL>分析索引 <OWNER>.<INDEX NAME>在线验证结构;

指数分析。

我们可以采取的另一种方法是使用 trace 文件中包含的 file 和 block 信息。在跟踪文件的顶部，我们将找到有关发现损坏的块的信息：

会话 ID：（3202.5644） 2011-03-19 04：12：16.910
行 07c7c8c7.a 在
文件# 31 块# 510151插槽 11 未找到的延续

此信息可用于识别 dba_extents 中的对象详细信息：

从 dba_extents 中选择 owner、segment_name、segment_type、partition_name，tablespace_name
其中 relative_fno = <文件 id>
并且 <block#> 在 block_id 和 （block_id+blocks-1） 之间;

然后我们可以验证这个对象，例如一个表和它的所有索引：

分析表 <OWNER>.<TABLE NAME>在线验证结构级联;

请记住，我们可能正在处理不在对象块本身中的永久损坏。这方面的示例包括：

  • 可传输表空间作导致的字典损坏问题：检查 dba_tablespaces 以查看表空间是否已插入。
  • ASM 磁盘组镜像中的写入丢失 – 最有可能在存在大量 IO 和磁盘重新同步活动时看到。要检查此内容，请运行 dbms_diskgroup.checkfile 以检测镜像差异

如果 analyze 报告没有损坏，则检查表上是否有任何链接的行。如果存在这些，则可能存在未检测到的损坏，并且每当运行 SQL 时，问题都会再次出现。导出表也会检测到此问题。

如果 analyze 和 export 表（在存在链式行的情况下）都报告没有错误，则应将其视为一致性读取问题。

了解问题的性质后，您可以查看已知 bug 列表并确定哪个 bug 与您的条件匹配。如果您无法确定哪个问题影响了您，请向 Oracle 技术支持提交服务请求，并上传所有节点的 RDBMS 和 ASM（如果适用）实例警报日志、生成的任何跟踪和事件文件以及问题性质的完整描述。

 

Bug Fixed Description
32311758 23.1.0.0.0 ORA-600: internal error code, arguments: [kdsgrp1] on spatial physical standby database
32065006 23.1.0.0.0 Sdo_filter() fails with ORA-600: internal error code, arguments: [kdsgrp1]
32022223 19.12, 21.3.0.0.0 Sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
28392179 19.11, 21.1.0.0.0 ORA-00600 [kdsgrp1] error on standby after intensive insert on the primary DB
29506942 18.11, 18.18, 19.8, 20.1 sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
29311927 18.11, 18.18, 19.8, 20.1 sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
28547478 12.2.0.1.DBRU:200714, 18.11, 18.18, 19.2, 20.1 ORA-600 [kdsgrp1] When Running Workload
27869764 19.1 Sdo_filter() call coredumps with [kdsgrp1] exception [optimized mbrs]
27397048 12.1.0.2.190115, 12.2.0.1.DBRU:190115, 18.18, 18.5, 19.1 Intermittent ORA-600[kdsgrp1] Raised By Query Using Index
26203182 11.2.0.4.200114, 12.1.0.2.190716, 12.2.0.1.DBRU:190115, 18.1 Lost Writes on ZFS if DNFS is enabled causing several Internal Errors. ORA-600 [kdsgrp1] ORA-8103 ORA-600 [3020] ORA-752 ORA-756
22581771 12.2.0.1.DBRU:180417, 18.1 ORA-600 [kdsgrp1] On Domain Index With Concurrent Insert And Select (With Clause)
21180699 18.1 ORA-7445/ ORA-00600 argument [kdibowrite()] / [kdibc3position()+78] / [20003] / [kcfrbd_3] / [25027] [kdsgrp1] with Execution plan ‘BITMAP’ access
22267274 12.2.0.1 CDB: Hit ORA-600 [kdsgrp1] and ORA-600 [4042]
17273253 12.1.0.1.1, 12.2.0.1 Various ORA-600 corruption errors with ASM
16195231 11.2.0.3.BP21, 11.2.0.4, 12.1.0.2, 12.2.0.1 ORA-7445 / ORA-600 from COMPRESSED table with LONG column
14576755 12.1.0.1.4, 12.1.0.2, 12.2.0.1 Corruption type ORA-600 errors from heavy concurrent DML on index cluster table
33005241 19.16, 21.7 ORA-00600 [kdsgrp1] error when using row CR
33599665 19.17 ORA-600 [kdsgrp_lost_piece] / ORA-600 [kdsgrp1-kdsgrp] While Running Flashback Query on FDA Enabled Table
31843845 19.13, 21.5 ORA-600 [kdsgrp1] Error or Wrong / Duplicate Results When Advanced Compressed Index Skip Scan Used to Access Rows
32417227 19.12 OLTP Compression Lock Bit Not Respected In Uncompressed Blocks
31228670 12.1.0.2.201020, 12.2.0.1.DBRU:201020, 18.12, 19.9 Corruption LOST Write : Rebalance disk resync causing lost write, mirror mismatches , several errors can be reported
31192039 12.2.0.1.DBRU:201020, 18.12, 18.18, 19.9 ORA-1554 and/or ORA-600 [kdsgrp1] While Deleting From A Compressed Index
31642462 19.14 ORA-600 [kdsgrp1-kdsgrp] when doing a version query using rowid having large row data with hybrid columnar compression enabled.
30651570 18.14, 18.18, 19.10 ORA-600: [kdsgrp1] After INSERT With APPEND Hint In Compressed Partitioned Table
32596207 21.0 ORA-600[kdsgrp1] failure using sdo_filter() function
29428230 18.11, 18.18, 19.8, 20.1 sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
29362596 18.11.0.0.200714DBRU, 18.11, 18.18, 19.8.0.0.200714DBRU, 19.8, 20.1 sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
29350868 18.11.0.0.200714DBRU, 18.11, 18.18, 19.8.0.0.200714DBRU, 19.8, 20.1 sdo_filter fails with ORA-600: internal error code, arguments: [kdsgrp1]
29139070 18.11.0.0.200714DBRU, 18.11, 18.18, 19.8.0.0.200714DBRU, 19.8, 20.1 very small adjacent insert causes index corruption ORA-600[kdsgrp1]
29048605 19.3.0.0.190416DBRU, 19.3, 20.1 index truncation causes index corruption ORA-600[kdsgrp1]
28881035 19.2, 19.2.0.0.181005R, 20.1 very small update causes index corruption ORA-600[kdsgrp1]
28802077 19.2, 19.2.0.0.181005R, 20.1 sdo_filter() fails with ORA-600[kdsgrp1]
27063461 19.11, 20.1 Physical Standby Hits ORA-600[kdbdmp_full:non-KDDBTDATA block. Use kcbtdu for it.]
28511632 23.4 Corruption LOST Write : Incomplete RMAN DUPLICATE can allow data file overwrites at Source database
27394954 19.1 sdo_filter fails with ORA-600 [kdsgrp1] after delete,insert,delete,insert,commit
27658186 12.2.0.1, 12.2.0.1.DBRU:190115, 18.5 ORA-600 [kdsgrp1] / Some rows not indexed in Text index in highly concurrent environment
24699619 12.2.0.1.171121DBRU, 12.2.0.1.171130WINDBBP, 12.2.0.1.DBRU:171121, 18.1 xdbstress hit ora 600 [kdsgrp1]
12690729 18.1 ORA-600 [kdsgrp1] errors when the active standby database recovery is enabled using CURRENT LOGFILE
22575209 12.2.0.1 ORA-600 [kdsgrp1] ORA-600 [25027] ORA-8103 ORA-1578 ORA-3254 in ADG Standby Database for Full Scan on ASSM segment – superseded
22519146 12.1.0.2.171017, 12.2.0.1 ORA-600 [kdsgrp1] or ORA-600 [kdsgrpcalcblockcount: hwmbno<=dbabno] or ORA-8103 in 12c on HCC Table in EXADATA
22241601 12.2.0.1 ORA-600 [kdsgrp1] ORA-1555 / ORA-600 [ktbdchk1: bad dscn] due to Invalid Commit SCN in INDEX block
21973601 12.2.0.0, 12.2.0.1 Querying a partitioned table may fail with ORA-00600 [kdsgrp1]
21634686 12.2.0.1 ORA-600 [kdsgrp1] / ORA-600 [ktfbhget:clsviol_kcbgcur_9] With Hybrid Columnar Compression (HCC)
21532755 11.2.0.4.171017, 12.1.0.2.171017, 12.2.0.1 ORA-600 [25027] By Concurrent queries while Create Index Online or ORA-8102 Table/Index mistmatch after Create Index Online or ONLINE_INDEX_CLEAN wait for DMLs
21096955 12.2.0.1 ORA-600 [kdsgrp1] / ORA-600 [ktfbhget:clsviol_kcbgcur_9] With Hybrid Columnar Compression (HCC)
19689979 11.2.0.4.170718, 12.1.0.2.160119, 12.1.0.2.DBBP07, 12.2.0.1 ORA-8103 or ORA-600 [ktecgsc:kcbz_objdchk] or Wrong Results on PARTITION table after TRUNCATE in 11.2.0.4 or above
19630914 12.2.0.1 ORA-600 [kdsgrp1] And Other Errors ORA-600 [6033] When BigSCN Testing Is Enabled
19614585 11.2.0.4.BP17, 12.1.0.2.DBBP03, 12.2.0.1 Wrong Results / ORA-600 [kksgaGetNoAlloc_Int0] / ORA-600 [12406] / ORA-7445 / ORA-8103 / ORA-1555 from query on RAC ADG Physical Standby Database
18607546 11.2.0.4.6, 11.2.0.4.BP16, 12.1.0.2.3, 12.1.0.2.DBBP06, 12.2.0.1 ORA-600 [kdblkcheckerror]..[6266] corruption with self-referenced chained row. ORA-600 [kdsgrp1] / Wrong Results / ORA-8102
18311351 12.2.0.1 ORA-1/ORA-10388 ORA-7445 [kdzsbuffercupiece_col] ORA-600 [kdsgrp1]/ORA-1499 Wrong Results, Index Inconsistency after Parallel Direct Path Insert of HCC table in EXADATA
17779978 12.2.0.1 ORA-00600 [kdsgrp1] & ORA-7445 [hshhsv] & ORA-7445 [pkrcd] errors on CDB
17761775 11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4.2, 11.2.0.4.BP03, 12.1.0.1.3, 12.1.0.2, 12.2.0.1 ORA-600 [kclchkblkdma_3] ORA-600 [3020] or ORA-600 [kcbchg1_16] Join of temp and permanent table in RAC might lead to corruption – superseded
17357359 12.1.0.2, 12.2.0.1 ORA-600 [kdsgrp1] during fetch by rowid
17160362 12.1.0.2, 12.2.0.1 ORA-600 [kdsgrp1] & [kclchkblk_3] & [kclchkblkdma_3] in rdbms
16849623 12.1.0.2, 12.2.0.1 ORA-600 [kdsgrp1] While Running Workload On Tables With Chained Rows
16698629 12.1.0.2, 12.2.0.1 ORA-600 [kdsgrp1] executing SELECT on table modified by a loosely coupled clusterwide global transaction
16555614 12.1.0.2, 12.2.0.1 mdidxridchk() causes buffer overrun problem when more than 4000 rows selected
16345143 12.2.0.1 Event 10231 does not skip row for IOT with non-existent nrid
14044260 12.1.0.2, 12.2.0.1 Update DML with long bind LOB that moves row to new partition fails with ORA-600 [kdsgrp1] – superseded
17449815 11.2.0.4.4, 11.2.0.4.BP11, 12.1.0.2, 12.2.0.1 ORA-8102 ORA-1499 after ORA-1/ORA-2291 by MERGE with DML ERROR LOGGING
17204397 12.1.0.2, 12.2.0.1 ORA-8005 ORA-8103 ORA-1410 ORA-600 [kdsgrp1] on Bitmap Index. Root Block may be repeatedly pinned/unpinned
16844448 11.2.0.3.9, 11.2.0.3.BP22, 11.2.0.4, 12.1.0.2, 12.2.0.1 ORA-600 [3020] after flashback database in a RAC
16563781 12.1.0.2, 12.1.0.2.180116, 12.2.0.1 version query may return wrong result on a table in TTS tablespace
21425496 11.2.0.4.190416, 12.1.0.1, 12.1.0.2.190716 ORA-752 or ORA-600 [3020] on recovery of Block Cleanout Operation OP:4.6
17518816 12.1.0.0, 12.1.0.1 ORA-600 [kdsgrp1] on select statements on a Active Dataguard Standby database
14790903 11.2.0.4, 12.1.0.1 ora 600 [kdsgrp1]
14527172 12.1.0.1 ORA-600 [4097] And [kdsgrp1] After unplugging and plugging the PDB In RAC Environment
13614906 12.1.0.1 ORA-600 [kdsgrp1] due to missing weak changes from an XA transaction in RAC – superceded
13399500 11.2.0.3.BP15, 11.2.0.4, 12.1.0.1 ORA-600 [kdsgrp1] when updating a chained rows on a ehcc table
13146182 11.2.0.2.11, 11.2.0.2.BP17, 11.2.0.3.10, 11.2.0.3.BP07, 11.2.0.4, 12.1.0.1 ORA-1499 ORA-8102 ORA-600 [kdsgrp1] Bitmap Index / Table mismatch
12821418 11.2.0.3.8, 11.2.0.3.BP18, 11.2.0.4, 12.1.0.1 Direct NFS appears to be sending zero length windows to storage device. It may also cause Lost Writes
12619529 11.2.0.3.BP18, 11.2.0.4, 12.1.0.1 ORA-600[kdsgrp1] from SELECT on plugged in tablespace with FLASHBACK
12330911 12.1.0.1 EXADATA LSI firmware for lost writes
10633840 11.2.0.2.7, 11.2.0.2.BP17, 11.2.0.3, 12.1.0.1 ORA-1502 on insert statement on INTERVAL partitioned table. ORA-8102 / ORA-1499 Index inconsistency
10245259 11.2.0.2.BP03, 11.2.0.3, 12.1.0.1 PARALLEL INSERT with +NOAPPEND hint or if PARALLEL INSERT plan is executed in SERIAL corrupts index and causes wrong results
10209232 11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.1 ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM
10205230 11.2.0.1.6, 11.2.0.1.BP09, 11.2.0.2.2, 11.2.0.2.BP04, 11.2.0.3, 12.1.0.1 ORA-600 / corruption possible during shutdown in RAC
9770451 10.2.0.5.3, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.3, 12.1.0.1 ORA-600 [20022] with bitmap indexes
9734539 11.2.0.2, 12.1.0.1 ORA-8102 / ORA-1499 corrupt index after update/merge using QUERY REWRITE
9469117 10.2.0.5.4, 11.2.0.1.BP04, 11.2.0.2, 12.1.0.1 Corrupt index after PDML executed in serial. Wrong results. OERI[kdsgrp1]/ORA-1499 by analyze
9457185 11.2.0.1.BP12, 11.2.0.2, 12.1.0.1 Intermittent ORA-600 [kdsgrp1] during CR read
9231605 11.1.0.7.4, 11.2.0.1.3, 11.2.0.1.BP02, 11.2.0.2, 12.1.0.1 Block corruption with missing row on a compressed table after DELETE
9145541 11.1.0.7.4, 11.2.0.1.2, 11.2.0.2, 12.1.0.1 OERI[25027]/OERI[4097]/OERI[4000]/ORA-1555 in plugged datafile after CREATE CONTROLFILE in 11g
9061269 11.2.0.2, 12.1.0.1 ORA-600 [kdsgrp1] executing CTX_QUERY.COUNT_HITS during concurrent sync Text index
8951812 11.2.0.2, 12.1.0.1 Corrupt index by rebuild online. Possible OERI [kddummy_blkchk] by SMON
8837919 11.2.0.2, 12.1.0.1 DBV / RMAN enhanced to detect ASSM blocks with ktbfbseg but not ktbfexthd flag set as in Bug 8803762
8803762 11.1.0.7.6, 11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1 ORA-600[kdsgrp1], ORA-600[25027] or wrong results on 11g database upgrade from 9i
8771916 10.2.0.5.3, 11.1.0.7.6, 11.2.0.1.BP12, 11.2.0.2, 12.1.0.1 OERI [kdsgrp1] during CR read
8635179 10.2.0.5, 11.2.0.2, 12.1.0.1 Solaris: directio may be disabled for RAC file access. Corruption / Lost Write
8597106 11.2.0.1.BP06, 11.2.0.2, 12.1.0.1 Lost Write in ASM when normal redundancy is used
8546356 10.2.0.5.1, 11.2.0.1.3, 11.2.0.1.BP07, 11.2.0.2, 12.1.0.1 ORA-8102/ORA-1499/OERI[kdsgrp1] Composite Partitioned Index corruption after rebuild ONLINE in RAC
7710827 11.2.0.2, 12.1.0.1 Index rebuild or Merge partition causes wrong results in concurrent reads instead of ORA-8103
7705591 10.2.0.5, 11.2.0.1.1, 11.2.0.1.BP04, 11.2.0.2, 12.1.0.1 Corruption with self-referenced row in MSSM tablespace. Wrong Results / OERI[6749] / ORA-8102
7251049 11.2.0.1.BP08, 11.2.0.2, 12.1.0.1 Corruption in bitmap index introduced when using transportable tablespaces
16579042 11.2.0.4 ORA-600 [kjbmpocr:alh] ORA-600 [kclchkblkdma_3] by LMS in RAC which may lead to corruption
9527635 11.2.0.1.BP04, 11.2.0.2, 12.1.0.1 ORA-00600 [kdsgrp1] On Exadata
8650661 11.1.0.7.2, 11.2.0.1 OERI / corruption type errors using global transactions in RAC
8588540 11.1.0.7.2, 11.2.0.1 Corruption / ORA-8102 in RAC with loopback DB links between instances
7682186 11.2.0.1 ORA-600[kdsgrp1] on consistent read in RAC with global transaction
7329252 10.2.0.4.4, 10.2.0.5, 11.1.0.7.5, 11.2.0.1 ORA-8102/ORA-1499/OERI[kdsgrp1] Index corruption after rebuild index ONLINE
7289224 11.2.0.1 ORA-600 [kdsgrp1] on CR read with parallel query
6791996 11.2.0.1 ORA-600 errors for a DELETE with self referencing FK constraint and BITMAP index
6772911 10.2.0.5, 11.1.0.7.3, 11.2.0.1 OERI[12700] OERI[qertbFetchByRowID] OERI[kdsgrp1] due to bad CR rollback of INDEX block
6445948 10.2.0.4.4, 10.2.0.5, 11.1.0.7.8, 11.2.0.1 Intermitent ORA-600 [kdsgrp1] accessing table with a LONG
6404058 10.2.0.5, 11.1.0.7, 11.2.0.1 OERI:12700 OERI:kdsgrp1 OERI:qertbFetchByRowID wrong results from CR rollback of split index leaf
6129296 11.2.0.1 ORA-600 [kdsgrp1] by PARALLEL select for update with LOB
5621677 10.2.0.4, 11.1.0.6 Logical corruption with PARALLEL update
5374225 10.2.0.4, 11.1.0.6 SDO_FILTER query fails with OERI[kdsgrp1]
5368945 10.2.0.5, 11.1.0.6 ORA-600 [kdsgrp1] on Index Organized Table with Overflow
4883635 10.2.0.4, 11.1.0.6 MERGE (with DELETE) can produce wrong results or Logical corruption in chained rows
3408192 9.2.0.6, 10.1.0.3, 10.2.0.1 Heavy concurrent DML scenarios can cause $R table to contain deleted rowids

 

 

GAM、SGAM 或 PFS 页上存在页错误处理

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：GAM、SGAM 或 PFS 页上存在页错误处理

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户sql server数据库由于硬件故障,导致dbcc的时候报类似GAM、SGAM 或 PFS 页上存在页错误

kzj2025的 DBCC 结果。
Service Broker 消息 9675，状态 1: 已分析的消息类型: 14。
Service Broker 消息 9676，状态 1: 已分析的服务约定: 6。
Service Broker 消息 9667，状态 1: 已分析的服务: 3。
Service Broker 消息 9668，状态 1: 已分析的服务队列: 3。
Service Broker 消息 9669，状态 1: 已分析的会话端点: 0。
Service Broker 消息 9674，状态 1: 已分析的会话组: 0。
Service Broker 消息 9670，状态 1: 已分析的远程服务绑定: 0。
Service Broker 消息 9605，状态 1: 已分析的会话优先级: 0。
消息 8939，级别 16，状态 98，第 1 行
表错误: 对象 ID 0，索引 ID -1，分区 ID 0，分配单元 ID -2958221917649371136 
(类型为 Unknown)，页 (12337:808857908)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 12716041 和 -10。
消息 8998，级别 16，状态 2，第 1 行
GAM、SGAM 或 PFS 页上存在页错误，无法对数据库 ID 6 中从 (1:186024) 到 (1:194111) 
 的页继续进行分配完整性检查。原因请参阅其他错误消息。
CHECKDB 发现有 2 个分配错误和 0 个一致性错误与任何单个的对象都没有关联。
sys.sysrscols的 DBCC 结果。
对象 'sys.sysrscols' 的 171 页中有 16248 行。
sys.sysrowsets的 DBCC 结果。
……………………
对象 'gspz_pmaintainidx' 的 12 页中有 1658 行。
DiseasesMedicationsIndex_temp的 DBCC 结果。
对象 'DiseasesMedicationsIndex_temp' 的 0 页中有 0 行。
GSP_BackBill的 DBCC 结果。
对象 'GSP_BackBill' 的 0 页中有 0 行。
Gsp_L_KwGradeIndex的 DBCC 结果。
对象 'Gsp_L_KwGradeIndex' 的 0 页中有 0 行。
Web_T_Message的 DBCC 结果。
对象 'Web_T_Message' 的 0 页中有 0 行。
CHECKDB 在数据库 'kzj2025' 中发现 2 个分配错误和 0 个一致性错误。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

完成时间: 2025-03-29T19:53:21.6977003+08:00

QQ20250329-225441

由于GAM、SGAM 或 PFS是和sql数据库文件的空间分配有关系,对于这种情况,一般无法直接修复,需要对库进行重构的方法进行修复,我们处理之后,dbcc检查一切正常
dbcc-ok

ORA-600 krhpfh_03-1208

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：ORA-600 krhpfh_03-1208

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

最近一个客户咨询一个问题,他正常的drop tbs,结果触发ORA-600 krhpfh_03-1208 错误,导致数据库crash

Wed Mar 26 14:33:20 2025
Thread 1 cannot allocate new log, sequence 478485
Checkpoint not complete
  Current log# 2 seq# 478484 mem# 0: /apps/data/oracle/orcl/redo02.log
Thread 1 advanced to log sequence 478485 (LGWR switch)
  Current log# 3 seq# 478485 mem# 0: /apps/data/oracle/orcl/redo03.log
Wed Mar 26 14:35:06 2025
Wed Mar 26 14:35:06 2025
drop tablespace XFF_MON_2016 including contents and datafiles cascade constraint
Read of datafile '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf' (fno 17) header failed with ORA-01208
Rereading datafile 17 header failed with ORA-01208
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_188213.trc  (incident=7677):
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: 数据库文件 17 验证失败
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: 数据文件是旧的版本 - 不能访问当前版本
Incident details in: /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_7677/orcl_ora_188213_i7677.trc
Wed Mar 26 14:35:07 2025
Trace dumping is performing id=[cdmp_20250326143507]
ORA-600 signalled during: drop tablespace XFF_MON_2016 including contents and datafiles cascade constraint...
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_188213.trc  (incident=7678):
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: 数据库文件 17 验证失败
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: 数据文件是旧的版本 - 不能访问当前版本
Incident details in: /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_7678/orcl_ora_188213_i7678.trc
Wed Mar 26 14:35:08 2025
Sweep [inc][7678]: completed
Sweep [inc][7677]: completed
Sweep [inc2][7677]: completed
Wed Mar 26 14:35:09 2025
Thread 1 cannot allocate new log, sequence 478486
Checkpoint not complete
  Current log# 3 seq# 478485 mem# 0: /apps/data/oracle/orcl/redo03.log
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_188213.trc  (incident=7679):
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: 数据库文件 17 验证失败
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: 数据文件是旧的版本 - 不能访问当前版本
Incident details in: /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_7679/orcl_ora_188213_i7679.trc
Trace dumping is performing id=[cdmp_20250326143511]
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_188213.trc:
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: 内部错误代码, 参数: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935],[],[],[],[],[]
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: 数据库文件 17 验证失败
ORA-01110: 数据文件 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: 数据文件是旧的版本 - 不能访问当前版本
Thread 1 advanced to log sequence 478486 (LGWR switch)
  Current log# 1 seq# 478486 mem# 0: /apps/data/oracle/orcl/redo01.log
Wed Mar 26 14:35:13 2025
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_188213.trc  (incident=15551):
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: database file 17 failed verification check
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: data file is an old version - not accessing current version
Incident details in: /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_15551/orcl_ora_188213_i15551.trc
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_15551/orcl_ora_188213_i15551.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01122: database file 17 failed verification check
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-01208: data file is an old version - not accessing current version
Trace dumping is performing id=[cdmp_20250326143514]
Wed Mar 26 14:35:15 2025
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_pmon_139367.trc  (incident=7224):
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
Incident details in: /apps/svr/oracle/diag/rdbms/orcl/orcl/incident/incdir_7224/orcl_pmon_139367_i7224.trc
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_pmon_139367.trc:
ORA-00600: internal error code, arguments: [krhpfh_03-1208],[fno =],[17],[fecpc =],[454709],[fhcpc =],[402935]
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
Wed Mar 26 14:35:19 2025
drop tablespace XFF_MON_2016 including contents and datafiles cascade constraint
Wed Mar 26 14:35:20 2025
DBW0 (ospid: 139390): terminating the instance due to error 472
Instance terminated by DBW0, pid = 139390

这个报错信息看,但是发起drop tbs之后,数据库应该是检查file 17号文件的状态,发现这个版本状态过旧(ORA-01208: 数据文件是旧的版本),由于某种原因报出来了krhpfh_03-1208,导致数据库crash了,然后他尝试启动数据库报ORA-01113: file 17 needs media recovery

Wed Mar 26 17:11:00 2025
Starting ORACLE instance (normal)
Wed Mar 26 17:11:17 2025
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Wed Mar 26 17:11:28 2025
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =168
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options.
Using parameter settings in server-side spfile /apps/svr/oracle/product/11.2.0/dbhome_1/dbs/spfileorcl.ora
System parameters with non-default values:
  processes                = 1000
  sga_target               = 0
  memory_target            = 66048M
  memory_max_target        = 66048M
  control_files            = "/apps/data/oracle/orcl/control01.ctl"
  control_files            = "/apps/svr/oracle/flash_recovery_area/orcl/control02.ctl"
  db_block_size            = 8192
  compatible               = "11.2.0.0.0"
  db_recovery_file_dest    = "/apps/svr/oracle/flash_recovery_area"
  db_recovery_file_dest_size= 3882M
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
  audit_file_dest          = "/apps/svr/oracle/admin/orcl/adump"
  audit_trail              = "DB"
  db_name                  = "orcl"
  open_cursors             = 300
  pga_aggregate_target     = 0
  diagnostic_dest          = "/apps/svr/oracle"
Wed Mar 26 17:11:29 2025
PMON started with pid=2, OS id=28315 
Wed Mar 26 17:11:29 2025
VKTM started with pid=3, OS id=28317 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Wed Mar 26 17:11:29 2025
GEN0 started with pid=4, OS id=28324 
Wed Mar 26 17:11:29 2025
DIAG started with pid=5, OS id=28326 
Wed Mar 26 17:11:29 2025
DBRM started with pid=6, OS id=28328 
Wed Mar 26 17:11:29 2025
PSP0 started with pid=7, OS id=28330 
Wed Mar 26 17:11:29 2025
DIA0 started with pid=9, OS id=28334 
Wed Mar 26 17:11:29 2025
MMAN started with pid=8, OS id=28336 
Wed Mar 26 17:11:29 2025
DBW0 started with pid=10, OS id=28338 
Wed Mar 26 17:11:29 2025
DBW1 started with pid=11, OS id=28340 
Wed Mar 26 17:11:29 2025
DBW2 started with pid=12, OS id=28342 
Wed Mar 26 17:11:29 2025
DBW3 started with pid=13, OS id=28344 
Wed Mar 26 17:11:29 2025
LGWR started with pid=14, OS id=28346 
Wed Mar 26 17:11:29 2025
CKPT started with pid=15, OS id=28348 
Wed Mar 26 17:11:29 2025
SMON started with pid=16, OS id=28350 
Wed Mar 26 17:11:29 2025
RECO started with pid=17, OS id=28352 
Wed Mar 26 17:11:29 2025
MMON started with pid=18, OS id=28354 
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
Wed Mar 26 17:11:29 2025
MMNL started with pid=19, OS id=28356 
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /apps/svr/oracle
Wed Mar 26 17:11:29 2025
ALTER DATABASE   MOUNT
Wed Mar 26 17:11:32 2025
Sweep [inc][7679]: completed
Sweep [inc][7224]: completed
Sweep [inc][15551]: completed
Sweep [inc2][7679]: completed
Sweep [inc2][7678]: completed
Sweep [inc2][7224]: completed
Sweep [inc2][15551]: completed
Successful mount of redo thread 1, with mount id 1724539585
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Wed Mar 26 17:11:34 2025
ALTER DATABASE OPEN
Errors in file /apps/svr/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_28406.trc:
ORA-01113: file 17 needs media recovery
ORA-01110: data file 17: '/apps/data/oracle/XFF_MON/XFF_MON_2016.dbf'
ORA-1113 signalled during: ALTER DATABASE OPEN...

由于现场已经破坏,无法分析当时库的情况和17号文件的具体情况做进一步判断,只能通过日志记录下这个类型的错误.
在oracle中关于ORA-600 krhpfh_03的bug也比较多
ORA-600-krhpfh_03

VMware勒索加密恢复(vmdk勒索恢复)

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：VMware勒索加密恢复(vmdk勒索恢复)

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

客户运行VMware Esxi由于被黑客攻破,导致所有的vmdk文件均被加密,其中包含大量的数据库虚拟机,这段时间,客户找了不少人进行分析恢复,要不就是恢复效果不好,要不就是要加太高,通过底层分析,确认可以比较完美的恢复,包括虚拟机直接运行的mysql、oracle数据库,docker中运行的mysql数据库,那其中一个恢复case来说明,被加密的虚拟机文件是一个500G的vmkd文件(.vmdk.{74C1B740-FEC0-01BD-914B-5F2CBAAA094E}.tianrui)
通过工具对其扫描,该磁盘采用的是lvm方式管理
lvm1
lvm2

lvm中的文件采用的是xfs格式文件系统,对其进行解析,并直接看到oracle数据库文件
lvm_oracle111
lvm_oracle
把相关oracle数据库相关文件恢复出来,然后使用工具检测无坏块,直接上传到服务器中,直接open库,实现oracle数据库完美恢复
对于类似这种被加密的勒索的虚拟机,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持，请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
系统安全防护措施建议：
1.多台机器，不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性，并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制，并进行定期备份
4.定期检测系统和软件中的安全漏洞，及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件，并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。
9.保存良好的备份习惯，尽量做到每日备份，异地备份。

ORA-39773: parse of metadata stream failed故障处理

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：ORA-39773: parse of metadata stream failed故障处理

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

客户expdp导出数据,在写入生成SYS_EXPORT_SCHEMA表所在的users表空间不足,导致expdp报部分异常

Export: Release 11.2.0.4.0 - Production on Thu Feb 27 15:12:36 2025

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
;;; 
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
FLASHBACK automatically enabled to preserve database integrity.
Starting "XFF"."SYS_EXPORT_SCHEMA_95":XFF/**** directory=DUMP dumpfile=20250227.dmp logfile=20250227.log schemas=XFF 
Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
ORA-39171: Job is experiencing a resumable wait.
ORA-01653: unable to extend table XFF.SYS_EXPORT_SCHEMA_95 by 128 in tablespace USERS
Total estimation using BLOCKS method: 481.9 GB
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/SYSTEM_GRANT
Processing object type SCHEMA_EXPORT/ROLE_GRANT
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processing object type SCHEMA_EXPORT/TYPE/TYPE_SPEC
Processing object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE
Processing object type SCHEMA_EXPORT/TABLE/TABLE
Processing object type SCHEMA_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type SCHEMA_EXPORT/TABLE/COMMENT
Processing object type SCHEMA_EXPORT/PACKAGE/PACKAGE_SPEC
Processing object type SCHEMA_EXPORT/FUNCTION/FUNCTION
Processing object type SCHEMA_EXPORT/PROCEDURE/PROCEDURE
Processing object type SCHEMA_EXPORT/PACKAGE/COMPILE_PACKAGE/PACKAGE_SPEC/ALTER_PACKAGE_SPEC
Processing object type SCHEMA_EXPORT/FUNCTION/ALTER_FUNCTION
Processing object type SCHEMA_EXPORT/PROCEDURE/ALTER_PROCEDURE
Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/INDEX/FUNCTIONAL_INDEX/INDEX
Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/FUNCTIONAL_INDEX/INDEX_STATISTICS
Processing object type SCHEMA_EXPORT/VIEW/VIEW
Processing object type SCHEMA_EXPORT/PACKAGE/PACKAGE_BODY
Processing object type SCHEMA_EXPORT/TABLE/TRIGGER
Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
Processing object type SCHEMA_EXPORT/MATERIALIZED_VIEW
Processing object type SCHEMA_EXPORT/JOB
. . exported "XFF"."PUB_WORKINGTASKLOG"              88.09 GB  112681 rows
. . exported "XFF"."SM_BUSILOG_DEFAULT"              51.94 GB 3149092 rows
. . exported "XFF"."FFW_DISTRIBUTESUBTASK"           46.47 GB  552214 rows
. . exported "XFF"."GL_DETAIL"                       11.32 GB 16214805 rows
…………
. . exported "XFF"."ZDP_10000000RR8NKX"                  0 KB       0 rows
. . exported "XFF"."ZDP_10000000RTB1GI"                  0 KB       0 rows
. . exported "XFF"."ZDP_10000000RTB1GK"                  0 KB       0 rows
Master table "XFF"."SYS_EXPORT_SCHEMA_95" successfully loaded/unloaded
******************************************************************************
Dump file set for XFF.SYS_EXPORT_SCHEMA_95 is:
  /rman_bak/dump/20200227.dmp
Job "XFF"."SYS_EXPORT_SCHEMA_95" completed with 10 error(s) at Thu Feb 27 19:32:22 2025 elapsed 0 04:16:28

尝试把该dmp导入数据库,报ORA-31694/ORA-02354/ORA-39773错误

Import: Release 11.2.0.4.0 - Production on 星期日 3月 16 02:38:14 2025

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
;;; 
连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORA-31694: 加载/卸载主表 "XFF"."SYS_IMPORT_FULL_01" 失败
ORA-02354: 导出/导入数据时出错
ORA-39773: parse of metadata stream failed

客户需要恢复其中的GL_DETAIL表数据,通过dul实现expdp dump文件转换sqlldr格式方法进行恢复,实现数据完美恢复
QQ20250322-211130

对于dmp(exp/expdp)文件,我们可以实现比较完美的恢复,最后限度抢救数据.如果你有oracle expdp/exp dmp被加密或者破坏,无法正常导入数据库,可以联系我们对其进行恢复处理:提供(ORACLE数据库恢复技术支持)：
Phone:17813235971    Q Q:107644445    E-Mail:dba@xifenfei.com

sql数据库备份失败—失败: 23(数据错误(循环冗余检查)

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：sql数据库备份失败—失败: 23(数据错误(循环冗余检查)

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户sql server数据库备份失败,提示如下
bk-fail

从这个报错看,比较明显是由于底层(文件系统损坏或者扇区访问异常导致),进一步查看系统事件确认是由于扇区异常导致(设备\Device\HarddiskO\DR0有一个不正确的区块)
disk-error
对于这种情况,当访问到文件所在的损坏扇区位置,就会报io错误,终止访问,文件也无法直接拷贝.通过专业工具对文件进行拷贝恢复确认一些扇区损坏而且被跳过(这部分数据肯定丢失)
sq
由于文件本身跳过了损坏的扇区,需要确认损坏的部分影响哪些对象和哪些类型的损坏,通过DBCC检测出来异常信息如下

消息 8976，级别 16，状态 1，第 1 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)。在扫描过程中未发现页 (1:1577857)，但该页的父级 (1:87825) 和上一页 (1:1576364) 都引用了它。请检查以前的错误消息。
消息 8978，级别 16，状态 1，第 1 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)。页 (1:1577859) 缺少上一页 (1:1577857) 对它的引用。可能是链链接有问题。
消息 8939，级别 16，状态 98，第 1 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)，页 (1:1577857)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 133129 和 -4。
消息 8928，级别 16，状态 1，第 1 行
对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data): 无法处理页 (1:1577857)。有关详细信息，请参阅其他错误消息。


消息 8939，级别 16，状态 98，第 1 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)，页 (1:385339)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 133129 和 -4。
消息 8928，级别 16，状态 1，第 1 行
对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data): 无法处理页 (1:385339)。有关详细信息，请参阅其他错误消息。
消息 8976，级别 16，状态 1，第 1 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)。在扫描过程中未发现页 (1:385339)，但该页的父级 (1:127857) 和上一页 (1:385338) 都引用了它。请检查以前的错误消息。
消息 8978，级别 16，状态 1，第 1 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)。页 (1:1682744) 缺少上一页 (1:385339) 对它的引用。可能是链链接有问题。

然后通过DBCC进行修复,修复成功提示如下

修复: 已为数据库 'myhis' 中的对象 'dbo.h_xxxxx, idx_xxxxx_ckdmx_id' 成功地重新生成了 Nonclustered 索引。
修复: 页 (1:1577857) 已从对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)释放。
消息 8945，级别 16，状态 1，第 6 行
表错误: 将重新生成对象 ID 1478296326，索引 ID 70。
        该错误已修复。
消息 8928，级别 16，状态 1，第 6 行
对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data): 无法处理页 (1:1577857)。有关详细信息，请参阅其他错误消息。
        该错误已修复。
消息 8939，级别 16，状态 98，第 6 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)，页 (1:1577857)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 2057 和 -4。
        该错误已修复。
消息 8976，级别 16，状态 1，第 6 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)。在扫描过程中未发现页 (1:1577857)，但该页的父级 (1:87825) 和上一页 (1:1576364) 都引用了它。请检查以前的错误消息。
        该错误已修复。
消息 8978，级别 16，状态 1，第 6 行
表错误: 对象 ID 1478296326，索引 ID 70，分区 ID 72057594244038656，分配单元 ID 72057594277527552 (类型为 In-row data)。页 (1:1577859) 缺少上一页 (1:1577857) 对它的引用。可能是链链接有问题。
        该错误已修复。
对象 'h_zysfdmx' 的 365541 页中有 2705291 行。
CHECKDB 在表 'h_xxxxx' (对象 ID 1478296326)中发现 0 个分配错误和 4 个一致性错误。
CHECKDB 在表 'h_xxxxx' (对象 ID 1478296326)中修复了 0 个分配错误和 4 个一致性错误。

修复: 已为数据库 'myhis' 中的对象 'dbo.h_xxx, idx_xxx_ckdmx_id' 成功地重新生成了 Nonclustered 索引。
修复: 页 (1:385339) 已从对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)释放。
消息 8945，级别 16，状态 1，第 6 行
表错误: 将重新生成对象 ID 2005582183，索引 ID 66。
        该错误已修复。
消息 8928，级别 16，状态 1，第 6 行
对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data): 无法处理页 (1:385339)。有关详细信息，请参阅其他错误消息。
        该错误已修复。
消息 8939，级别 16，状态 98，第 6 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)，页 (1:385339)。测试(IS_OFF (BUF_IOERR, pBUF->bstat))失败。值为 2057 和 -4。
        该错误已修复。
消息 8976，级别 16，状态 1，第 6 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)。在扫描过程中未发现页 (1:385339)，但该页的父级 (1:127857) 和上一页 (1:385338) 都引用了它。请检查以前的错误消息。
        该错误已修复。
消息 8978，级别 16，状态 1，第 6 行
表错误: 对象 ID 2005582183，索引 ID 66，分区 ID 72057594242859008，分配单元 ID 72057594276347904 (类型为 In-row data)。页 (1:1682744) 缺少上一页 (1:385339) 对它的引用。可能是链链接有问题。
        该错误已修复。
对象 'h_sfdmx' 的 1226 页中有 10928 行。
CHECKDB 在表 'h_xxx' (对象 ID 2005582183)中发现 0 个分配错误和 4 个一致性错误。
CHECKDB 在表 'h_xxx' (对象 ID 2005582183)中修复了 0 个分配错误和 4 个一致性错误。

QQ20250320-220759

再次使用DBCC检查数据库,一切正常,没有其他报错.然后在恢复过程中ldf文件也有大量扇区异常,对ldf文件进行截断处理

ALTER DATABASE MYHIS SET RECOVERY SIMPLE;
DBCC SHRINKFILE (MYHIS_log, 0);
ALTER DATABASE MYHIS SET RECOVERY FULL;

vmdk文件被加密恢复(虚拟机文件加密)

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：vmdk文件被加密恢复(虚拟机文件加密)

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户的vm虚拟化平台被勒索病毒加密,扩展名为:.{110DCD0A-295C-27A4-914B-5F2CBAAA094E}.tianrui
tainrui

README.TXT文件内容如下,预留邮箱为:tianrui@mailum.com

I'll try to be brief: 1. It is beneficial for us that your files are decrypted no less than you, 
we don't want to harm you, we just want to get a ransom for our work.
2. Its only takes for us at list 20 minutes after payment to completely decrypt you,
to its original state, it's very simple for us!
3.If you contact decryption companies, you are automatically exposed to publicity,also, 
these companies do not care about your files at all, they only think about their own benefit!
4.They also contact the police. Again, only you suffer from this treatment!
5. We have developed a scheme for your secure decryption without any problems, unlike the above companies,
who just as definitely come to us to decipher you and simply make a profit from you as intermediaries, 
preventing a quick resolution of this issue!

6. In case of refusal to pay, we transfer all your personal data such as (emails, link to panel, 
   payment documents , certificates , personal information of you staff, SQL,ERP,
financial information for other hacker groups) and they will come to you again for sure!

We will also publicize this attack using social networks and other media,
   which will significantly affect your reputation

7. If you contact us no more than 12 hours after the attack, the price is only 50% of the price afterwards!

8. Do not under any circumstances try to decrypt the files yourself; you will simply break them!
         YOU MUST UNDERSTAND THAT THIS IS BIG MARKET AND DATA RECOVERY NEED MONEY ONLY !!!
9.IF YOU CHOOSE TO USE DATA RECOVERY COMPANY ASK THEM 
   FOR DECRYPT TEST FILE FOR YOU IF THEY CANT DO IT DO NOT BELIEVE THEM

10.Do not give data recovery companies acces to your network they make your data cant be decrypted by us - 
for make more money from you !!!!! DO NOT TELL THEM YOUR COMPANY NAME BEFORE THEY GIVE YOU TEST FILE !!!!!! 



Contacts :

Download the (Session) messenger (https://getsession.org)  
You fined me "0585ae8a3c3a688c78cf2e2b2b7df760630377f29c0b36d999862861bdbf93380d"

MAIL:tianrui@mailum.com

通过底层分析,确认vmdk文件可以通过找出来分区信息,确认当时运行的是一个win操作系统
QQ20250320-231317

查看对应分区中数据情况
QQ20250320-231716
对于类似这种被加密的勒索的虚拟机,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持，请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
系统安全防护措施建议：
1.多台机器，不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性，并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制，并进行定期备份
4.定期检测系统和软件中的安全漏洞，及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件，并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。
9.保存良好的备份习惯，尽量做到每日备份，异地备份。

差点被误操作的ORA-600 kcratr_nab_less_than_odr故障

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：差点被误操作的ORA-600 kcratr_nab_less_than_odr故障

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

晚上接到一个客户电话,数据库无法启动,咨询我的Oracle Recovery Tools工具的授权问题,我远程登录客户的环境进行查看故障,发现客户进行了一下操作导致最后open报ORA-01152错误

C:\Users\Administrator>sqlplus sys/sys as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Tue Mar 18 22:43:24 2025

Copyright (c) 1982, 2010, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> startup mount
ORACLE instance started.

Total System Global Area 1603411968 bytes
Fixed Size                  2176168 bytes
Variable Size             973081432 bytes
Database Buffers          620756992 bytes
Redo Buffers                7397376 bytes
Database mounted.
SQL> recover database;
Media recovery complete.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1],
[27890], [1589], [1649], [], [], [], [], [], [], []

SQL> recover database;
ORA-00283: 恢复会话因错误而取消
ORA-00264: 不要求恢复


SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcratr_nab_less_than_odr], [1],
[27890], [1589], [1649], [], [], [], [], [], [], []


SQL> recover database until cancel;
ORA-10879: error signaled in parallel recovery slave
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01152: 文件 1 没有从过旧的备份中还原
ORA-01110: 数据文件 1: 'D:\APP\ADMINISTRATOR\ORADATA\orcl\SYSTEM01.DBF'

SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: 'D:\APP\ADMINISTRATOR\ORADATA\orcl\SYSTEM01.DBF'


SQL> RECOVER DATABASE USING BACKUP CONTROLFILE;
ORA-00279: change 17384974762395 generated at 03/18/2025 18:30:34 needed for
thread 1
ORA-00289: suggestion :
D:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\orcl\ARCHIVELOG\2025_03_19\O1_MF_1_27
890_%U_.ARC
ORA-00280: change 17384974762395 for thread 1 is in sequence #27890


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
D\APP\ADMINISTRATOR\ORADATA\orcl\RED001.LOG
ORA-00308: 无法打开归档日志 'D\APP\ADMINISTRATOR\ORADATA\orcl\RED001.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 3) 系统找不到指定的路径。


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
D:\app\Administrator\oradata\orcl\RED001.LOG
ORA-00308: 无法打开归档日志 'D:\app\Administrator\oradata\orcl\RED001.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

最初数据库启动报ORA-600 kcratr_nab_less_than_odr错误(这个是一个非常典型的错误,早期写过处理方法:ORA-600 kcratr_nab_less_than_odr故障解决)，客户处理故障思路不太清晰,使用了recover database until cancel和alter database open resetlogs等不当操作,导致数据库没有open成功.然后希望使用我的Oracle Recovery Tools小工具进行修复,但是根据我的判断,这个故障还用不上该工具,直接可以open库.对其进行ctl重建并open库

SQL> alter database backup controlfile to trace as 'd:/ctl.txt';

Database altered.

SQL> create pfile='d:/pfile.txt' from spfile;

File created.

SQL> shutdown immediate;
ORA-01109: database not open


Database dismounted.
ORACLE instance shut down.
SQL> startup nomount;
ORACLE instance started.

Total System Global Area 1603411968 bytes
Fixed Size                  2176168 bytes
Variable Size             973081432 bytes
Database Buffers          620756992 bytes
Redo Buffers                7397376 bytes
SQL> @d:/xifenfei/rectl.sql

Control file created.

SQL>
SQL>
SQL> recover database;
Media recovery complete.

SQL> alter database open;

Database altered.

在open之后,数据库报ORA-600 4194错误

Wed Mar 19 01:51:12 2025
alter database open
Beginning crash recovery of 1 threads
 parallel recovery started with 23 processes
Started redo scan
Completed redo scan
 read 793 KB redo, 0 data blocks need recovery
Started redo application at
 Thread 1: logseq 27890, block 2, scn 17384974741793
Recovery of Online Redo Log: Thread 1 Group 4 Seq 27890 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO04.LOG
Completed redo application of 0.00MB
Completed crash recovery at
 Thread 1: logseq 27890, block 1589, scn 17384974762395
 0 data blocks read, 0 data blocks written, 793 redo k-bytes read
Wed Mar 19 01:51:14 2025
Thread 1 advanced to log sequence 27891 (thread open)
Thread 1 opened at log sequence 27891
  Current log# 2 seq# 27891 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO02.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Mar 19 01:51:14 2025
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
Tablespace 'TEMP' #3 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'TEMP1' #11 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
         This condition can occur when a backup controlfile has
         been restored.  It may be necessary to add files to these
         tablespaces.  That can be done using the SQL statement:
 
         ALTER TABLESPACE <tablespace_name> ADD TEMPFILE
 
         Alternatively, if these temporary tablespaces are no longer
         needed, then they can be dropped.
           Empty temporary tablespace: TEMP
           Empty temporary tablespace: TEMP1
*********************************************************************
Database Characterset is ZHS16GBK
No Resource Manager plan active
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4084.trc  (incident=158542):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_158542\orcl_smon_4084_i158542.trc
Wed Mar 19 01:51:26 2025
Trace dumping is performing id=[cdmp_20250319015126]
Wed Mar 19 01:51:31 2025
Sweep [inc][158542]: completed
Sweep [inc2][158542]: completed
Wed Mar 19 01:51:35 2025
Doing block recovery for file 3 block 1415
Resuming block recovery (PMON) for file 3 block 1415
Block recovery from logseq 27891, block 86 to scn 17384974782720
Recovery of Online Redo Log: Thread 1 Group 2 Seq 27891 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO02.LOG
Block recovery stopped at EOT rba 27891.87.16
Block recovery completed at rba 27891.87.16, scn 4047.3242135803
Doing block recovery for file 3 block 264
Resuming block recovery (PMON) for file 3 block 264
Block recovery from logseq 27891, block 86 to scn 17384974782714
Recovery of Online Redo Log: Thread 1 Group 2 Seq 27891 Reading mem 0
  Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO02.LOG
Block recovery completed at rba 27891.87.16, scn 4047.3242135803
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4084.trc:
ORA-01595: 释放区 (2) 回退段 (12) 时出错
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Wed Mar 19 01:51:36 2025
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_5680.trc  (incident=158590):
ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_158590\orcl_ora_5680_i158590.trc

数据库open成功,但是后台报ORA-01595/ORA-600 4194错误,这个问题比较常见,直接处理异常undo即可恢复.

win平台19c 打patch遭遇2个小问题汇总

联系：手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题：win平台19c 打patch遭遇2个小问题汇总

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

在给19c的库打ru patch的过程中遇到两个错误,进行记录,以供以后遇到类似错误参考:
UtilSession 失败: oracle/cluster/install/InstallException

C:\Users\Administrator>F:\updatecode\WINDOWS.X64_193000_db_home\opatch\opatch apply F:\oracle_patch\37486199
Oracle 临时补丁程序安装程序版本 12.2.0.1.45
版权所有 (c) 2025, Oracle Corporation。保留所有权利。


Oracle 主目录       ：F:\updatecode\WINDOWS.X64_193000_db_home
主产品清单：C:\Program Files\Oracle\Inventory
   来自           ：
OPatch 版本    ：12.2.0.1.45
OUI 版本       ：12.2.0.7.0
日志文件位置：F:\updatecode\WINDOWS.X64_193000_db_home\cfgtoollogs\opatch\opatch2025-03-17_18-19-56下午_1.log

Verifying environment and performing prerequisite checks...
UtilSession 失败: oracle/cluster/install/InstallException
Log file location: F:\updatecode\WINDOWS.X64_193000_db_home\cfgtoollogs\opatch\opatch2025-03-17_18-19-56下午_1.log

OPatch failed with error code = 73

对应的日志错误部分

[2025-3-17 18:19:57] [INFO]   CAS Dynamic Loading :
[2025-3-17 18:19:57] [INFO]   CUP_LOG: Trying to load HomeOperations object
[2025-3-17 18:19:57] [INFO]   CUP_LOG: HomeOperations object created. CUP1.0 is enabled
[2025-3-17 18:19:57] [INFO]   OPatch invoked as follows: 'apply F:\oracle_patch\37486199 '
[2025-3-17 18:19:57] [INFO]   Runtime args: [-DOPatch.ORACLE_HOME=F:\updatecode\WINDOWS.X64_193000_db_home, -DOPatch.DEBUG=false,
                              -DOPatch.RUNNING_DIR=F:\updatecode\WINDOWS.X64_193000_db_home\OPatch, -DOPatch.MW_HOME=, 
                              -DOPatch.WL_HOME=, -DOPatch.COMMON_COMPONENTS_HOME=, -DOPatch.OUI_LOCATION=, -DOPatch.FMW_COMPONENT_HOME=,
                               -DOPatch.WEBLOGIC_CLASSPATH=, -DOPatch.OPATCH_CLASSPATH=]
[2025-3-17 18:19:57] [INFO]   Heap in use : 120 MB
                              Total memory: 1917 MB
                              Free memory : 1796 MB
                              Max memory  : 27305 MB
[2025-3-17 18:19:57] [INFO]   Oracle 主目录       : F:\updatecode\WINDOWS.X64_193000_db_home
                              主产品清单: C:\Program Files\Oracle\Inventory
                                 从           : 
                              OPatch 版本    : 12.2.0.1.45
                              OUI 版本       : 12.2.0.7.0
                              OUI 位置      : F:\updatecode\WINDOWS.X64_193000_db_home\oui
                              日志文件位置 : F:\updatecode\WINDOWS.X64_193000_db_home\cfgtoollogs\opatch\opatch2025-03-17_18-19-56下午_1.log
[2025-3-17 18:19:57] [INFO]   Patch history file: F:\updatecode\WINDOWS.X64_193000_db_home\cfgtoollogs\opatch\opatch_history.txt
[2025-3-17 18:19:59] [INFO]   [OPSR-TIME] Loading raw inventory
[2025-3-17 18:20:00] [INFO]   [OPSR-MEMORY] Loaded all components from inventory. Heap memory in use: 150 (MB)
[2025-3-17 18:20:00] [INFO]   [OPSR-MEMORY] Loaded all one offs from inventory. Heap memory in use: 160 (MB)
[2025-3-17 18:20:00] [INFO]   [OPSR-TIME] Raw inventory loaded successfully
[2025-3-17 18:20:00] [INFO]   NApply::no CAS enabled, OPatch runs with legacy process.
[2025-3-17 18:20:00] [INFO]   Verifying environment and performing prerequisite checks...
[2025-3-17 18:20:00] [INFO]   [OPSR-TIME] Running prerequisite checks
[2025-3-17 18:20:00] [INFO]   opatch-external.jar is in F:\updatecode\WINDOWS.X64_193000_db_home\OPatch\jlib\opatch-external.jar
[2025-3-17 18:20:00] [SEVERE] OUI-67073:UtilSession 失败: oracle/cluster/install/InstallException
[2025-3-17 18:20:00] [INFO]   Finishing UtilSession at Mon Mar 17 18:20:00 CST 2025
[2025-3-17 18:20:00] [INFO]   堆栈说明: java.lang.RuntimeException: oracle/cluster/install/InstallException
                              	at java.lang.Class.getDeclaredConstructors0(Native Method)
                              	at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
                              	at java.lang.Class.getConstructor0(Class.java:3075)
                              	at java.lang.Class.getConstructor(Class.java:1825)
                              	at oracle.opatch.OPatchExternalFactory.getRac(OPatchExternalFactory.java:158)
                              	at oracle.opatch.napplyhelper.EnvValidation.validateConnectStringNodes(EnvValidation.java:104)
                              	at oracle.opatch.napplyhelper.EnvValidation.checkConnectString(EnvValidation.java:92)
                              	at oracle.opatch.napplyhelper.EnvValidation.validate(EnvValidation.java:64)
                              	at oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:530)
                              	at oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:374)
                              	at oracle.opatch.opatchutil.NApply.process(NApply.java:354)
                              	at oracle.opatch.opatchutil.OUSession.napply(OUSession.java:1143)
                              	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                              	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
                              	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                              	at java.lang.reflect.Method.invoke(Method.java:498)
                              	at oracle.opatch.UtilSession.process(UtilSession.java:355)
                              	at oracle.opatch.OPatchSession.process(OPatchSession.java:2640)
                              	at oracle.opatch.OPatch.process(OPatch.java:888)
                              	at oracle.opatch.OPatch.main(OPatch.java:945)
                              Caused by: java.lang.NoClassDefFoundError: oracle/cluster/install/InstallException
                              	... 20 more
                              Caused by: java.lang.ClassNotFoundException: oracle.cluster.install.InstallException
                              	at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
                              	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
                              	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
                              	... 20 more

通过mos给出来的文档:Windows:opatch file with error: [SEVERE] OUI-67073:UtilSession failed: oracle/cluster/install/InstallException (Doc ID 3020534.1),可能是由于%ORACLE_HOME%\oui\jlib\srvm.jar 文件异常导致该问题,查看打patch机器,发现该文件丢失[丢失原因未知],从37486199的patch文件中拷贝该文件到数据库对应目录,后续没有再报该错误
srvm.jar

然后提示Prerequisite check “CheckActiveFilesAndExecutables” failed.错误
注意参考:win平台 UtilSession 失败: Prerequisite check “CheckActiveFilesAndExecutables” failed. 处理没有解决问题(因为文件本身没有被占用)

F:\oracle_patch\37486199>F:\updatecode\WINDOWS.X64_193000_db_home\opatch\opatch apply
Oracle 临时补丁程序安装程序版本 12.2.0.1.45
版权所有 (c) 2025, Oracle Corporation。保留所有权利。


Oracle 主目录       ：F:\updatecode\WINDOWS.X64_193000_db_home
主产品清单：C:\Program Files\Oracle\Inventory
   来自           ：
OPatch 版本    ：12.2.0.1.45
OUI 版本       ：12.2.0.7.0
日志文件位置：F:\updatecode\WINDOWS.X64_193000_db_home\cfgtoollogs\opatch\opatch2025-03-17_18-34-40下午_1.log

Verifying environment and performing prerequisite checks...
Prerequisite check "CheckActiveFilesAndExecutables" failed.
The details are:

Following active files/executables/libs are used by ORACLE_HOME :F:\updatecode\WINDOWS.X64_193000_db_home
F:\updatecode\WINDOWS.X64_193000_db_home\bin\oravssmsgus.dll
F:\updatecode\WINDOWS.X64_193000_db_home\bin\ORAEVRUS19.dll


UtilSession 失败: Prerequisite check "CheckActiveFilesAndExecutables" failed.
Log file location: F:\updatecode\WINDOWS.X64_193000_db_home\cfgtoollogs\opatch\opatch2025-03-17_18-34-40下午_1.log

OPatch failed with error code = 73

通过命令分析确认oravssmsgus.ddl和ORAEVRUS19.dll动态库没有被其他程序占用

F:\oracle_patch\37486199>tasklist /M ora*
信息: 没有运行的任务匹配指定标准。

F:\oracle_patch\37486199>tasklist /M ORA*
信息: 没有运行的任务匹配指定标准。

对于这种情况,根据mos文档:Database Release Update Bundle Windows Patch (XXX) Error”UtilSession failed: Prerequisite check “CheckActiveFilesAndExecutables” failed.” (Doc ID 3046640.1)建议,把对一个文件重命名

F:\updatecode\WINDOWS.X64_193000_db_home\bin>dir *bak.dll
 驱动器 F 中的卷是 安全区
 卷的序列号是 4407-E854

 F:\updatecode\WINDOWS.X64_193000_db_home\bin 的目录

2022-07-28  17:35             4,096 ORAEVRUS19-bak.dll
2022-07-28  17:35           100,352 oravssmsgus-bak.dll
               2 个文件        104,448 字节
               0 个目录 680,382,025,728 可用字节

后续打patch操作一切正常,没有再出现其他问题.