ORACLE中比较常见的一些错误的解释

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

标题:ORACLE中比较常见的一些错误的解释

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

 

ORA-1578 ORA-1578 The data block indicated was corrupt.  This was a physical corruption, also called a media corruption. The cause is unknown but is most likely external to the database. If ORA-26040 is also signaled, the corruption is due to NOLOGGING or UNRECOVERABLE operations.
ORA-1410 This error is raised when an operation refers to a ROWID in a table for which there is no such row.
The reference to a ROWID may be implicit from a WHERE CURRENT OF clause or directly from a WHERE ROWID=… clause.
ORA-1410 indicates the ROWID is for a BLOCK that is not part of this table.
ORA-8103 The object has been deleted by another user since the operation began; example: another session truncated or dropped the segment while the SQL statement was still active.
If the error is reproducible, following may be the reasons:
a.) The header block has an invalid block type.
b.) The data_object_id (seg/obj) stored in the block is different than the data_object_id stored in the segment header. See dba_objects.data_object_id and compare it to the decimal value stored in the block (field seg/obj).
ORA-8102 An ORA-08102 indicates that there is a mismatch between the key(s) stored in the index and the values stored in the table. What typically happens is the index is built and at some future time, some type of corruption occurs, either in the table or index, to cause the mismatch.
ORA-1498 Generally this is a result of an ANALYZE … VALIDATE … command.
This error generally manifests itself when there is inconsistency in the data/Index block. Some of the block check errors that may be found:-
a.) Row locked by a non-existent transaction
b.) The amount of space used is not equal to block size
c.) Transaction header lock count mismatch.
While support are processing the tracefile it may be worth the re-running the ANALYZE after restarting the database to help show if the corruption is consistent or if it ‘moves’.
Send the tracefile to support for analysis.
If the ANALYZE was against an index you should check the whole object. Eg: Find the tablename and execute:
ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE;
ORA-1499 An error occurred when validating an index or a table using the ANALYZE command.
One or more entries does not point to the appropriate cross-reference.
ORA-752 Media recovery detected a lost write of a data block.  A data block write to storage was lost during normal database operation on the primary database.
ORA-26040 Trying to access data in block that was loaded without redo generation using the NOLOGGING/UNRECOVERABLE option.
This Error raises always together with ORA-1578
ORA-600 [12700] Oracle is trying to access a row using its ROWID, which has been obtained from an index.
A mismatch was found between the index rowid and the data block it is pointing to. The rowid points to a non-existent row in the data block. The corruption can be in data and/or index blocks.
ORA-600 [12700] can also be reported due to a consistent read (CR) problem.
ORA-600 [3020] This is called a ‘STUCK RECOVERY’.
There is an inconsistency between the information stored in the redo and the information stored in a database block being recovered.This error indicates a lost write or a lost change in the database
ORA-600 [4194] A mismatch has been detected between Redo records and rollback (Undo) records.
Oracle is validating the Undo record number relating to the change being applied against the maximum undo record number recorded in the undo block.
This error is reported when the validation fails.
ORA-600 [4193] A mismatch has been detected between Redo records and Rollback (Undo) records.
Oracle is validating the Undo block sequence number in the undo block against the Redo block sequence number relating to the change being applied.
This error is reported when this validation fails.
ORA-600 [4137] While backing out an undo record (i.e. at the time of rollback) Oracle found a transaction id mismatch indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.
This would indicate a corrupted rollback segment.
ORA-600 [6101] Not enough free space was found when inserting a row into an index leaf block during the application of undo.
ORA-600 [2103] Oracle is attempting to read or update a generic entry in the control file.
If the entry number is invalid, ORA-600 [2130] is logged.
ORA-600 [4512] Oracle is checking the status of transaction locks within a block.
If the lock number is greater than the number of lock entries, ORA-600 [4512] is reported followed by a stack trace, process state and block dump.
This error possibly indicates a block corruption.
ORA-600 [2662] A data block SCN is ahead of the current SCN.
The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN identified by the process that is normally close to the database scn.
If the SCN is less than the dependent SCN then ORA-600 [2662] is signaled.
ORA-600 [4097] Oracle is accessing a rollback segment header to review if a transaction has been committed.
However, the xid given is in the future of the transaction table.
This could be due to a rollback segment corruption issue.
ORA-600 [4000] It means that Oracle has tried to find an undo segment number in the data dictionary and this undo segment number was not found.
ORA-600 [6006] Oracle is undoing an index leaf key operation. If the key is not found, ORA-00600 [6006] is logged.
ORA-600[6006] is usually caused by a media corruption problem related to either a lost write to disk or a corruption on disk.
ORA-600 [4552] This assertion is raised because Oracle is trying to unlock the rows in a block, but receive an incorrect block type.
The second argument is the block type received.
ORA-600[6856] Oracle is checking that the row slot that is about to be freed is not already on the free list.
This internal error is raised when this check fails.
ORA-600[13011] During a delete operation Oracle is deleting from a view via an instead-of trigger or an Index organized table and have exceeded a 5000 pass count
ORA-600[13013] During the execution of an UPDATE statement, after several attempts (Arg [a] passcount) Oracle is unable to get a stable set of rows that conform to the WHERE clause.
ORA-600[13030]
ORA-600[25012] Oracle is trying to generate the absolute file number given a tablespace number and relative file number and cannot find a matching file number or the file number is zero.
ORA-600[25026] Looking up/checking a tablespace invalid tablespace ID and/or rdba found
ORA-600[25027] Invalid tsn and/or rfn found
ORA-600 [kcbz_check_objd_typ_3] An object block buffer in memory is checked and is found to have the wrong object id. This is most likely due to corruption.
ORA-600[kddummy_blkchk] ORA-600[kdblkcheckerror] ORA-600 [kddummy_blkchk] is for 10g and ORA-600[kdblkcheckerror] for 11g onward.  This error reports a Logical Block Corruption
ORA-600[ktadrprc-1] Orphan segment or invalid rdba in Index,Table,Partition etc.  Example:  An entry in sys.ind$ does not exist in sys.seg$Note 136697.1 : “hcheck.sql” Script to Check for Known Problems in Oracle8i, Oracle9i, Oracle10g, Oracle 11g and Oracle 12c
ORA-600[ktsircinfo_num1] This exception occurs when there are problems obtaining the row cache information correctly from sys.seg$. In most cases there is no information in sys.seg$.Note 136697.1 : “hcheck.sql” Script to Check for Known Problems in Oracle8i, Oracle9i, Oracle10g, Oracle 11g and Oracle 12c
ORA-600[qertbfetchbyrowid] This error might be that a row was not found in an Index.  Perform the check in section “Identify TABLE / INDEX Mismatch” in:Note 836658.1 : Identify the Corruption Extension for Block Corruption, Table/Index Inconsistency, Data Dictionary and Lost Writes
ORA-600[ktbdchk1-bad dscn] This exception is raised when Oracle is performing a sanity check on the dependent SCN and fail.
The dependent scn is greater than the current scn.

因为篇章问题,无法详细描述,如果需要深入了解的,可以单独进行沟通

sysaux中HEATMAP 对象较大

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

标题:sysaux中HEATMAP 对象较大

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

在一次数据检查中,发现HEATMAP对象比较大

SQL> select * from v$version;

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production              0
PL/SQL Release 12.1.0.2.0 - Production                                                    0
CORE    12.1.0.2.0      Production                                                        0
TNS for Linux: Version 12.1.0.2.0 - Production                                            0
NLSRTL Version 12.1.0.2.0 - Production                                                    0


SQL> col owner for a30
SQL> col  segment_name for a30
SQL> col segment_type for a20
set lines 150
SELECT owner, segment_name, segment_type, sum(bytes/1024/1024/1024)
FROM dba_extents
WHERE tablespace_name='SYSAUX'
and segment_name='HEATMAP'
group by owner, segment_name, segment_type;SQL> SQL>   2    3    4    5  

OWNER                          SEGMENT_NAME                   SEGMENT_TYPE         SUM(BYTES/1024/1024/1024)
------------------------------ ------------------------------ -------------------- -------------------------
SYS                            HEATMAP                        SYSTEM STATISTICS                   1.58789063

检查Heat Map特性为关闭

SQL> show parameter HEAT_MAP;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
heat_map                             string      OFF

查询mos发现相关Bug 20678613 – HEATMAP SIZE IS 500 MB, THOUGH HEAT_MAP IS TURNED OFF.通过设置_drop_stat_segment为1来自动减小HEATMAP(其默认值为0)

---默认值
SQL> col name for a52
SQL> col value for a24
SQL> col description for a50
set linesize 150
select a.ksppinm name,b.ksppstvl value,a.ksppdesc description
  from x$ksppi a,x$ksppcv b
 where a.inst_id = USERENV ('Instance')
   and b.inst_id = USERENV ('Instance')
   and a.indx = b.indx
   and upper(a.ksppinm) LIKE upper('%&param%')
SQL> SQL>   2    3    4    5    6    7  order by name
/  8  
Enter value for param: _drop_stat_segment
old   6:    and upper(a.ksppinm) LIKE upper('%&param%')
new   6:    and upper(a.ksppinm) LIKE upper('%_drop_stat_segment%')

NAME                                                 VALUE                    DESCRIPTION
---------------------------------------------------- ------------------------ ----------------------------
_drop_stat_segment                                   0                        drop ilm statistics segment

---设置值
ALTER SYSTEM SET "_drop_stat_segment" =1; 

如果需要也可以人工进行删除

exec dbms_space_admin.heat_map_segment_drop;

参见:HEATMAP Segment Size Is Large In SYSAUX Even When Heatmap=Off (Doc ID 2024036.1)
Bug 24704547 : SYS.HEATMAP GROWS IN SIZE IN 12C UNDER SYSAUX TBS

WARNING: too many parse errors

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

标题:WARNING: too many parse errors

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

从12.2开始,如果sql解析失败超过一定次数,会在alert日志中记录类似警告信息,便于对其进行排查

2020-01-05T20:30:50.559569+08:00
ARC0 (PID:29542): Archived Log entry 25044 added for T-1.S-12532 ID 0x6564f341 LAD:1
2020-01-05T20:30:50.626457+08:00
TT02 (PID:29552): SRL selected for T-1.S-12533 for LAD:2
2020-01-05T20:40:34.688814+08:00
WARNING: too many parse errors, count=1551097 SQL hash=0xec3987d3
PARSE ERROR: ospid=2240, error=923 for statement:
2020-01-05T20:40:34.688981+08:00
SELECT 1
Additional information: hd=0xef18d268 phd=0xee42c9c8 flg=0x28 cisid=106 sid=106 ciuid=106 uid=106 sqlid=4bwp0wrq3m1ym
...Current username=XIFENFEI
...Application: JDBC Thin Client Action:
2020-01-05T21:00:50.528469+08:00
Thread 1 advanced to log sequence 12534 (LGWR switch)
  Current log# 4 seq# 12534 mem# 0: /u01/app/oracle/oradata/XFF/redo04.log
  Current log# 4 seq# 12534 mem# 1: /u01/app/oracle/fast_recovery_area/XFF/onlinelog/redo04.log
2020-01-05T21:00:50.572028+08:00
ARC1 (PID:29546): Archived Log entry 25046 added for T-1.S-12533 ID 0x6564f341 LAD:1
2020-01-05T21:00:50.636035+08:00
TT02 (PID:29552): SRL selected for T-1.S-12534 for LAD:2
2020-01-05T21:05:32.671478+08:00
WARNING: too many parse errors, count=1551197 SQL hash=0xec3987d3
PARSE ERROR: ospid=4172, error=923 for statement:
2020-01-05T21:05:32.671641+08:00
SELECT 1
Additional information: hd=0xef18d268 phd=0xee42c9c8 flg=0x28 cisid=106 sid=106 ciuid=106 uid=106 sqlid=4bwp0wrq3m1ym
...Current username=XIFENFEI
...Application: JDBC Thin Client Action:

通过查询mos,确认相关记录是通过_kks_parse_error_warning参数来控制,默认每100次解析失败写入alert日志一次

[oracle@kage28 trace]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Sun Jan 5 21:23:21 2020
Version 19.3.0.0.0

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


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

SQL> col name for a52
SQL> col value for a24
SQL> col description for a50
set linesize 150
select a.ksppinm name,b.ksppstvl value,a.ksppdesc description
  from x$ksppi a,x$ksppcv b
 where a.inst_id = USERENV ('Instance')
   and b.inst_id = USERENV ('Instance')
   and a.indx = b.indx
   and upper(a.ksppinm) LIKE upper('%&param%')
SQL> SQL>   2    3    4    5    6    7  order by name
  8  /
Enter value for param: _kks_parse_error_warning
old   6:    and upper(a.ksppinm) LIKE upper('%&param%')
new   6:    and upper(a.ksppinm) LIKE upper('%_kks_parse_error_warning%')

NAME                                                 VALUE                    DESCRIPTION
---------------------------------------------------- ------------------------ ----------------------
_kks_parse_error_warning                             100                      Parse error warning

由于某种原因,解析错误sql,短期内无法进行修改,又不想让其在alert中提示,可以通过设置该值为0,实现让其不记录在alert日志中

alter system set "_kks_parse_error_warning"=0;

在12.2之前版本,解析错误默认不记录到alert日志中,但是也可以通过event 10035实现类似功能,具体参见:failed parse elapsed time过大分析案例

ORA-00700: soft internal error, arguments: [pga physmem limit]

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

标题:ORA-00700: soft internal error, arguments: [pga physmem limit]

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

19c数据库启动有ORA-00700警告

2019-12-31T20:29:10.905779+08:00                                                                                                                  
PGA_AGGREGATE_TARGET specified is high                                                                                                            
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_25403.trc  (incident=122887):                                                  
ORA-00700: soft internal error, arguments: [pga physmem limit], [3332374528], [2112652492], [], [], [], [], [], [], [], [], []                    
Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_122887/orcl_ora_25403_i122887.trc  

分析trace文件

WARNING: PGA_AGGREGATE_TARGET (3178 MB) is too high for                                                                                           
         the amount of physical memory (31783 MB) and                                                                                             
         SGA size (24576 MB) - it should be less than 2014 MB.  

提示PGA_AGGREGATE_TARGET 设置过大.官方对于此问题有说明,分配给数据库的内存(sga+pga)小于80%即可
20200101023312