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 对象较大

在一次数据检查中,发现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

从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]

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


ORA-04020导致adg异常

今日早上有客户反馈adg停止同步了,通过检查alert日志发现

Tue Dec 24 18:17:41 2019
Media Recovery Waiting for thread 1 sequence 56655 (in transit)
Recovery of Online Redo Log: Thread 1 Group 11 Seq 56655 Reading mem 0
  Mem# 0: Y:\ORACLE\ORADATA\ORACLE11\STD_REDO11.LOG
Archived Log entry 56248 added for thread 1 sequence 56654 ID 0x5b6bcf9b dest 1:
Tue Dec 24 18:18:11 2019
Errors in file C:\APP\ADMINISTRATOR\diag\rdbms\oracle11dg\oracle11\trace\oracle11_lgwr_3252.trc:
ORA-04020: deadlock detected while trying to lock object SYS.orcl
LGWR (ospid: 3252): terminating the instance due to error 4020
Tue Dec 24 18:18:11 2019
System state dump requested by (instance=1, osid=3252 (LGWR)), summary=[abnormal instance termination].
System State dumped to trace file C:\APP\ADMINISTRATOR\diag\rdbms\oracle11dg\trace\oracle11_diag_3236_20191224181811.trc
Dumping diagnostic data in directory=[cdmp_20191224181811],
      requested by (instance=1, osid=3252 (LGWR)), summary=[abnormal instance termination].
Instance terminated by LGWR, pid = 3252

由于lgwr进程遭遇ORA-04020,从而使得lgwr进程异常,进而整个数据库crash.

分析trace文件

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows NT Version V6.1 Service Pack 1
CPU                 : 8 - type 8664, 8 Physical Cores
Process Affinity    : 0x0x0000000000000000
Memory (Avail/Total): Ph:8395M/32733M, Ph+PgF:41002M/65464M
Instance name: oracle11
Redo thread mounted by this instance: 1
Oracle process number: 10
Windows thread id: 3252, image: ORACLE.EXE (LGWR)
*** 2019-12-24 18:18:11.072
*** SESSION ID:(384.1) 2019-12-24 18:18:11.072
*** CLIENT ID:() 2019-12-24 18:18:11.072
*** SERVICE NAME:(SYS$BACKGROUND) 2019-12-24 18:18:11.072
*** MODULE NAME:() 2019-12-24 18:18:11.072
*** ACTION NAME:() 2019-12-24 18:18:11.072
A deadlock among DDL and parse locks is detected.
This deadlock is usually due to user errors in
the design of an application or from issuing a set
of concurrent statements which can cause a deadlock.
This should not be reported to Oracle Support.
The following information may aid in finding
the errors which cause the deadlock:
ORA-04020: deadlock detected while trying to lock object SYS.orcl
--------------------------------------------------------
  object   waiting  waiting       blocking blocking
  handle   session     lock mode   session     lock mode
--------  -------- -------- ----  -------- -------- ----
0000000676C20F08  000000066D22BE10 00000006738AB970    X  000000066D22BE10 00000006738A04B0    S
0000000677DF2E80  00000006792E2880 0000000673B13AE8    X  000000066D22BE10 00000006738A19B8    S
--------------------------------------------------------
---------- DUMP OF WAITING AND BLOCKING LOCKS ----------
--------------------------------------------------------
------------- WAITING LOCK -------------
----------------------------------------
SO: 0x00000006738AB970, type: 78, owner: 0x000000065D440498, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
 proc=0x000000066CDE7AD0, name=LIBRARY OBJECT LOCK, file=kgl.h LINE:8751, pg=0
LibraryObjectLock:Address=00000006738AB970 Handle=0000000676C20F08
  RequestMode=X CanBeBrokenCount=2 Incarnation=3 ExecutionCount=0
………………
SO: 0x00000006738A19B8, type: 78, owner: 0x000000065A38D6C0, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
 proc=0x000000066CDE7AD0, name=LIBRARY OBJECT LOCK, file=kgl.h LINE:8751, pg=0
LibraryObjectLock:Address=00000006738A19B8 Handle=0000000677DF2E80
   Mode=S CanBeBrokenCount=1 Incarnation=1 ExecutionCount=0
  User=000000066D22BE10 Session=000000066D22BE10 ReferenceCount=1 Flags=CNB/[0001] SavepointNum=1b749
  LibraryHandle:  Address=0000000677DF2E80 Hash=675351da LockMode=S PinMode=0 LoadLockMode=0 Status=0
  ObjectName:  Name=SYS.orcl
    FullHashValue=285b654fe3f440652c403c98675351da Namespace=DBINSTANCE(74) Type=CURSOR(00) Identifier=1 OwnerIdn=0
  Statistics:  InvalidationCount=0 ExecutionCount=0 LoadCount=0 ActiveLocks=1 TotalLockCount=74719 TotalPinCount=0
  Counters:  BrokenCount=1 RevocablePointer=1 KeepDependency=0 Version=0
        BucketInUse=2 HandleInUse=2 HandleReferenceCount=0
  Concurrency:  DependencyMutex=0000000677DF2F30(0, 0, 0, 0) Mutex=0000000677DF2FC0(0, 149471, 1, 0)
  Flags=RON/PIN/KEP/BSO/[00810003]
  WaitersLists:
    Lock=0000000677DF2F10[0000000673B13B58,000000067382E2F0]
    Pin=0000000677DF2EF0[0000000677DF2EF0,0000000677DF2EF0]
    LoadLock=0000000677DF2F68[0000000677DF2F68,0000000677DF2F68]
  Timestamp:
  HandleReference:  Address=0000000677DF3030 Handle=0000000000000000 Flags=[00] ---------------------------------
This lock request was aborted.
error 4020 detected in background process
ORA-04020: deadlock detected while trying to lock object SYS.orcl
kjzduptcctx: Notifying DIAG for crash event
----- Abridged Call Stack Trace -----
ksedsts()+585<-kjzdssdmp()+329<-kjzduptcctx()+288<-kjzdicrshnfy()+99<-ksuitm()+1525<-ksbrdp()+4578<-opirip()
+853<-opidrv()+906<-sou2o()+98<-opimai_real()+280<-opimai()+191
    <-BackgroundThreadStart()+646<-0000000076CF59CD<-0000000076E2A561
----- End of Abridged Call Stack Trace -----
*** 2019-12-24 18:18:11.165
LGWR (ospid: 3252): terminating the instance due to error 4020
*** 2019-12-24 18:18:17.483
ksuitm: waiting up to [5] seconds before killing DIAG(3236)

日志显示由于lgwr进程等待LIBRARY OBJECT LOCK超时,从而引起异常,根据经验此类问题一般是由于bug导致,查询mos发现匹配bug信息Bug 18515268 ORA-4020 in ADG Standby Database causing instance crash by LGWR
20191225112622


可以根据需要打上相关Patch 18515268: ACTIVE DATAGUARD STANDBY CRASHES DUE TO AN ORA-4020 ENCOUNTERED BY LGWR

helpservis@horsefucker.org加密恢复

最近有客户环境中大量服务器被感染类似如下病毒,邮箱为:helpservis@horsefucker.org,每个机器不一样的id,使用该id为文件后缀名
20191222182600
16进制方式打开文件头发现破坏如下
20191222182709


进一步分析发现文件中依旧有大量block没有被破坏
20191222182727


经过分析我们基本上可以较为完美的恢复该病毒加密数据库(sql server,oracle等)
20191222184051


这类的数据库加密,我们可以直接通过解密处理,恢复之后基本立即可用.如果需要可以联系我们从底层进行恢复:Phone:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

fuser命令缺失导致19c打补丁失败

Oracle 19.3数据库打最新补丁报错

[oracle@www.xifenfei.com 30125133]$ opatch apply ./
Oracle Interim Patch Installer version 12.2.0.1.18
Copyright (c) 2019, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/app/oracle/product/19.0/db_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/19.0/db_1/oraInst.loc
OPatch version    : 12.2.0.1.18
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19.0/db_1/cfgtoollogs/opatch/opatch2019-12-16_08-00-53AM_1.log

分析日志

Verifying environment and performing prerequisite checks...
Prerequisite check "CheckSystemCommandAvailable" failed.
The details are:
Missing command :fuser
UtilSession failed:
Prerequisite check "CheckSystemCommandAvailable" failed.
Log file location: /u01/app/oracle/product/19.0/db_1/cfgtoollogs/opatch/opatch2019-12-16_08-00-53AM_1.log
OPatch failed with error code 73
[Dec 16, 2019 8:00:57 AM] [INFO]    Following patches can be applied:  30125133
[Dec 16, 2019 8:00:57 AM] [INFO]    Following patches are not required:
[Dec 16, 2019 8:00:57 AM] [INFO]    Following patches are auto rollbackable:
[Dec 16, 2019 8:00:57 AM] [INFO]    Finished checking prereq checkConflictAgainstOHWithDetail
[Dec 16, 2019 8:00:58 AM] [INFO]    Running prerequisite checks...
[Dec 16, 2019 8:00:58 AM] [INFO]    Space Needed : 3052.647MB
[Dec 16, 2019 8:00:58 AM] [INFO]    Missing command :fuser
[Dec 16, 2019 8:00:58 AM] [INFO]    Prerequisite check "CheckSystemCommandAvailable" failed.
                                    The details are:
                                    Missing command :fuser
[Dec 16, 2019 8:00:58 AM] [SEVERE]  OUI-67073:UtilSession failed:
                                    Prerequisite check "CheckSystemCommandAvailable" failed.

基本上可以确定是由于无fuser命令导致CheckSystemCommandAvailable失败.处理办法为安装上相关程序

[root@www.xifenfei.com tmp]# yum search fuser
Loaded plugins: product-id, search-disabled-repos, subscription-manager
This system is not registered with an entitlement server. You can use subscription-manager to register.
==================================== Matched: fuser ===========================
psmisc.x86_64 : Utilities for managing processes on your system
[root@www.xifenfei.com tmp]#
[root@www.xifenfei.com tmp]# mount /dev/cdrom /media/ -o loop
[root@www.xifenfei.com tmp]# yum install -y psmisc
Loaded plugins: product-id, search-disabled-repos, subscription-manager
This system is not registered with an entitlement server. You can use subscription-manager to register.
rhel-yum                       | 4.3 kB  00:00:00
Resolving Dependencies
--> Running transaction check
---> Package psmisc.x86_64 0:22.20-15.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
=============================================================================================
 Package                    Arch              Version                    Repository     Size
=============================================================================================
Installing:
 psmisc                     x86_64            22.20-15.el7               rhel-yum      141 k
Transaction Summary
=============================================================================================
Install  1 Package
Total download size: 141 k
Installed size: 475 k
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : psmisc-22.20-15.el7.x86_64          1/1
  Verifying  : psmisc-22.20-15.el7.x86_64          1/1
Installed:
  psmisc.x86_64 0:22.20-15.el7
Complete!

重新打补丁

[oracle@www.xifenfei.com 30125133]$ opatch apply ./
Oracle Interim Patch Installer version 12.2.0.1.18
Copyright (c) 2019, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/app/oracle/product/19.0/db_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/19.0/db_1/oraInst.loc
OPatch version    : 12.2.0.1.18
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19.0/db_1/cfgtoollogs/opatch/opatch2019-12-16_08-08-44AM_1.log
Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   30125133
Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.
Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/app/oracle/product/19.0/db_1')
Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Applying interim patch '30125133' to OH '/u01/app/oracle/product/19.0/db_1'
ApplySession: Optional component(s) [ oracle.network.gsm, 19.0.0.0.0 ],[ oracle.rdbms.ic, 19.0.0.0.0 ],
[ oracle.network.cman, 19.0.0.0.0 ],[ oracle.net.cman, 19.0.0.0.0 ],[ oracle.options.olap.awm, 19.0.0.0.0],
[ oracle.oraolap.mgmt, 19.0.0.0.0 ],[ oracle.assistants.usm, 19.0.0.0.0 ],[ oracle.assistants.asm, 19.0.0.0.0],
[ oracle.tfa, 19.0.0.0.0 ]  not present in the Oracle Home or a higher version is found.
Patching component oracle.rdbms, 19.0.0.0.0...
Patching component oracle.rdbms.rsf, 19.0.0.0.0...
Patching component oracle.assistants.acf, 19.0.0.0.0...
Patching component oracle.assistants.deconfig, 19.0.0.0.0...
Patching component oracle.assistants.server, 19.0.0.0.0...
Patching component oracle.buildtools.rsf, 19.0.0.0.0...
Patching component oracle.ctx, 19.0.0.0.0...
Patching component oracle.ldap.rsf, 19.0.0.0.0...
Patching component oracle.network.rsf, 19.0.0.0.0...
Patching component oracle.rdbms.dbscripts, 19.0.0.0.0...
Patching component oracle.sdo, 19.0.0.0.0...
Patching component oracle.sqlplus, 19.0.0.0.0...
Patching component oracle.ldap.rsf.ic, 19.0.0.0.0...
Patching component oracle.rdbms.rman, 19.0.0.0.0...
Patching component oracle.ctx.atg, 19.0.0.0.0...
Patching component oracle.rdbms.oci, 19.0.0.0.0...
Patching component oracle.rdbms.util, 19.0.0.0.0...
Patching component oracle.xdk, 19.0.0.0.0...
Patching component oracle.ovm, 19.0.0.0.0...
Patching component oracle.network.listener, 19.0.0.0.0...
Patching component oracle.rdbms.install.plugins, 19.0.0.0.0...
Patching component oracle.dbjava.jdbc, 19.0.0.0.0...
Patching component oracle.dbdev, 19.0.0.0.0...
Patching component oracle.rdbms.deconfig, 19.0.0.0.0...
Patching component oracle.nlsrtl.rsf, 19.0.0.0.0...
Patching component oracle.oraolap.dbscripts, 19.0.0.0.0...
Patching component oracle.install.deinstalltool, 19.0.0.0.0...
Patching component oracle.dbjava.ic, 19.0.0.0.0...
Patching component oracle.sdo.locator, 19.0.0.0.0...
Patching component oracle.rdbms.scheduler, 19.0.0.0.0...
Patching component oracle.rdbms.dv, 19.0.0.0.0...
Patching component oracle.ons, 19.0.0.0.0...
Patching component oracle.ldap.security.osdt, 19.0.0.0.0...
Patching component oracle.ctx.rsf, 19.0.0.0.0...
Patching component oracle.duma, 19.0.0.0.0...
Patching component oracle.ldap.owm, 19.0.0.0.0...
Patching component oracle.oracore.rsf, 19.0.0.0.0...
Patching component oracle.rdbms.install.seeddb, 19.0.0.0.0...
Patching component oracle.odbc, 19.0.0.0.0...
Patching component oracle.sdo.locator.jrf, 19.0.0.0.0...
Patching component oracle.network.client, 19.0.0.0.0...
Patching component oracle.sqlplus.ic, 19.0.0.0.0...
Patching component oracle.dbjava.ucp, 19.0.0.0.0...
Patching component oracle.xdk.rsf, 19.0.0.0.0...
Patching component oracle.marvel, 19.0.0.0.0...
Patching component oracle.xdk.parser.java, 19.0.0.0.0...
Patching component oracle.rdbms.rsf.ic, 19.0.0.0.0...
Patching component oracle.nlsrtl.rsf.core, 19.0.0.0.0...
Patching component oracle.precomp.common, 19.0.0.0.0...
Patching component oracle.precomp.lang, 19.0.0.0.0...
Patch 30125133 successfully applied.
Sub-set patch [29517242] has become inactive due to the application of a super-set patch [30125133].
Please refer to Doc ID 2161861.1 for any possible further required actions.
Log file location: /u01/app/oracle/product/19.0/db_1/cfgtoollogs/opatch/opatch2019-12-16_08-08-44AM_1.log
OPatch succeeded.
[oracle@www.xifenfei.com 30128191]$ opatch apply ./
Oracle Interim Patch Installer version 12.2.0.1.18
Copyright (c) 2019, Oracle Corporation.  All rights reserved.
Oracle Home       : /u01/app/oracle/product/19.0/db_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/19.0/db_1/oraInst.loc
OPatch version    : 12.2.0.1.18
OUI version       : 12.2.0.7.0
Log file location : /u01/app/oracle/product/19.0/db_1/cfgtoollogs/opatch/opatch2019-12-16_08-12-44AM_1.log
Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   30128191
Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.
Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/app/oracle/product/19.0/db_1')
Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...
Applying interim patch '30128191' to OH '/u01/app/oracle/product/19.0/db_1'
Patching component oracle.javavm.server, 19.0.0.0.0...
Patching component oracle.javavm.server.core, 19.0.0.0.0...
Patching component oracle.rdbms.dbscripts, 19.0.0.0.0...
Patching component oracle.rdbms, 19.0.0.0.0...
Patch 30128191 successfully applied.
Log file location: /u01/app/oracle/product/19.0/db_1/cfgtoollogs/opatch/opatch2019-12-16_08-12-44AM_1.log
OPatch succeeded.

确认补丁安装成功

[oracle@www.xifenfei.com 30128191]$ opatch lspatches
30128191;OJVM RELEASE UPDATE: 19.5.0.0.191015 (30128191)
30125133;Database Release Update : 19.5.0.0.191015 (30125133)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399)
OPatch succeeded.

mos上也有类似文章可参考:Prerequisite check “CheckSystemCommandAvailable” failed (Doc ID 1581604.1)

dbca删除库和rm删库恢复

由于误操作删除库的事情偶有发生,遇到过dbca误删除数据库,遇到过rm删除数据文件的故障.近期有过两次类似的恢复请求,一次是win平台dbca本该删除测试库,结果选择错误把生产库给删除,发生误操作之后,没有及时对磁盘进行卸载,而是有一些写操作,当事人找了各种反删除软件进行恢复,结果只是成功了恢复了部分文件,核心文件全部丢失.另外一次是linux平台误操作,rm -rf 删除了整个oracle目录,而且数据文件也全部在里面,所幸没有任何写操作.

对于dbca客户已经使用反删除软件进行恢复,但是效果不行,我们直接从底层扫描,恢复出来需要数据
scan-disk-win


有个别文件少量block被覆盖,而且客户只要其中部分核心表数据,因此直接使用dul恢复出客户需要数据,完美完成恢复

对于rm掉所有数据文件的客户,通过extundelete进行反删除恢复(参考:extundelete恢复Linux被删除文件),由于句柄丢失,导致有几个数据文件恢复失败.通过linux平台底层恢复,实现需要数据文件完全恢复,数据库正常open,实现完美恢复
SCAN-DISK


20191206142008
对于这类删库的操作,一定要保护好现场,对数据文件存在分区不要有二次写操作,尽可能的减少覆盖.理论上数据文件在磁盘上,都可以恢复出来.如果有遇到数据库文件误删除,或者文件系统损坏的恢复需求,无法自行解决,可以联系我们从底层进行恢复:Phone:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
类似恢复案例:
又一例asm格式化文件系统恢复
文件系统损坏导致数据文件异常恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
oracle asm disk格式化恢复—格式化为ntfs文件系统
oracle asm disk格式化恢复—格式化为ext4文件系统
ORA-15042: ASM disk “N” is missing from group number “M” 故障恢复