WRI$_ADV_OBJECTS表过大,导致SYSAUX表空间不足

12.2的sysaux表空间使用过大

SQL> select * from v$version;

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

SQL> @tbs

Name      TS Type      All Size(MB)   Max Size(MB)  Free Size(MB)  Max Free Pct. Free Max Free%
--------- ---------- -------------- -------------- -------------- --------- --------- ---------
SYSAUX    PERMANENT          32,760         32,768             26        34         0         0
USERS     PERMANENT           1,784         32,768             85    31,069         5        95
SYSTEM    PERMANENT             860         32,768             10    31,917         1        97
R_INDEX   PERMANENT           5,900        229,376            927   224,403        16        98
RICHMAN   PERMANENT           3,000        196,608          1,895   195,503        63        99
UNDOTBS1  UNDO                1,600         32,768          1,560    32,728        97       100

6 rows selected.

awrinfo查看

********************************************************
(1b) SYSAUX occupants space usage (v$sysaux_occupants)
********************************************************
|
| Occupant Name        Schema Name               Space Usage
| -------------------- -------------------- ----------------
| SM/ADVISOR           SYS                       30,422.9 MB
| SM/OPTSTAT           SYS                        1,222.7 MB
| SM/AWR               SYS                          588.2 MB
| SM/OTHER             SYS                          152.4 MB

**********************************
(4) Space usage by non-AWR components (> 500K)
**********************************

COMPONENT        MB SEGMENT_NAME                                      SEGMENT_TYPE
--------- --------- ------------------------------------------------- -------------
NON_AWR    15,675.0 SYS.WRI$_ADV_OBJECTS                              TABLE
NON_AWR     8,764.0 SYS.WRI$_ADV_OBJECTS_IDX_01                       INDEX
NON_AWR     5,959.0 SYS.WRI$_ADV_OBJECTS_PK                           INDEX
NON_AWR       488.0 SYS.I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST                INDEX
NON_AWR       249.0 SYS.I_WRI$_OPTSTAT_H_ST                           INDEX

这里为ADVISOR功能模块导致,而且主要是WRI$_ADV_OBJECTS表及其索引
分析主要对象

SQL>  COL SEGMENT_NAME FORMAT A30
SQL>  COL OWNER FORMAT A10
SQL>  COL TABLESPACE_NAME FORMAT A10
SQL>  COL SEGMENT_TYPE FORMAT A15
SQL> SELECT * FROM (SELECT SEGMENT_NAME,OWNER,TABLESPACE_NAME,BYTES/1024/1024 
 2  "SIZE(MB)",SEGMENT_TYPE FROM DBA_SEGMENTS WHERE 
 3  TABLESPACE_NAME='SYSAUX' ORDER BY BYTES DESC) WHERE ROWNUM<=10;

SEGMENT_NAME                   OWNER      Name         SIZE(MB) SEGMENT_TYPE
------------------------------ ---------- ---------- ---------- ---------------
WRI$_ADV_OBJECTS               SYS        SYSAUX          15675 TABLE
WRI$_ADV_OBJECTS_IDX_01        SYS        SYSAUX           8764 INDEX
WRI$_ADV_OBJECTS_PK            SYS        SYSAUX           5959 INDEX
I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST SYS        SYSAUX            488 INDEX
I_WRI$_OPTSTAT_H_ST            SYS        SYSAUX            249 INDEX
SYS_LOB0000007350C00005$$      SYS        SYSAUX       133.1875 LOBSEGMENT
SYS_LOB0000010641C00038$$      SYS        SYSAUX       110.1875 LOBSEGMENT
WRH$_SQL_PLAN                  SYS        SYSAUX             64 TABLE
I_WRI$_OPTSTAT_HH_OBJ_ICOL_ST  SYS        SYSAUX             51 INDEX
SYS_LOB0000067470C00006$$      MDSYS      SYSAUX        50.1875 LOBSEGMENT

10 rows selected.

这里也比较明显主要是由于WRI$_ADV_OBJECTS表及其index占用空间较多导致.WRI$_ADV_OBJECTS表主要是12.2新特性Optimizer Statistics Advisor功能使用到的表,用来存储相关数据

清理WRI$_ADV_OBJECTS相关数据

ECLARE
v_tname VARCHAR2(32767);
BEGIN
v_tname := 'AUTO_STATS_ADVISOR_TASK';
DBMS_STATS.DROP_ADVISOR_TASK(v_tname);
END;
/

EXEC DBMS_STATS.INIT_PACKAGE();

ALTER TABLE WRI$_ADV_OBJECTS MOVE;
ALTER INDEX WRI$_ADV_OBJECTS_IDX_01 REBUILD;
ALTER INDEX WRI$_ADV_OBJECTS_PK REBUILD;

禁用Optimizer Statistics Advisor Task

DECLARE
filter1 CLOB;
BEGIN
filter1 := DBMS_STATS.CONFIGURE_ADVISOR_RULE_FILTER('AUTO_STATS_ADVISOR_TASK','EXECUTE',NULL,'DISABLE');
END;
/

参考文档:SYSAUX Tablespace Grows Rapidly After Upgrading Database to 12.2.0.1 Due To Statistics Advisor (Doc ID 2305512.1)

发表在 Oracle | 标签为 , , | 留下评论

ORA-00333 故障恢复

数据库启动报错

SQL> startup
ORACLE instance started.

Total System Global Area 1241513984 bytes
Fixed Size                  1219136 bytes
Variable Size             218105280 bytes
Database Buffers         1006632960 bytes
Redo Buffers               15556608 bytes
Database mounted.
ORA-00333: redo log read error block 48641 count 8192

数据库启动报ORA-00333错误,官方解释为读redo log发生错误.

00333, 00000, "redo log read error block %s count %s"
// *Cause:  An IO error occurred while reading the log described in the
//          accompanying error.
// *Action: Restore accessibility to file, or get another copy of the file.

alert日志

Sat Apr 14 00:39:13 2018
 alter database open
Sat Apr 14 00:39:13 2018
Beginning crash recovery of 1 threads
 parallel recovery started with 7 processes
Sat Apr 14 00:39:13 2018
Started redo scan
Sat Apr 14 00:39:14 2018
Errors in file /oracle/admin/oa/udump/oa_ora_5659.trc:
ORA-00333: redo log read error block 54785 count 2048
ORA-00312: online log 1 thread 1: '/oracle/oradata/oa/redo01.log'
ORA-27072: File I/O error
Linux Error: 5: Input/output error
Additional information: 4
Additional information: 54785
Additional information: 957952
Sat Apr 14 00:39:14 2018
Errors in file /oracle/admin/oa/udump/oa_ora_5659.trc:
ORA-00333: redo log read error block 48641 count 8192
ORA-00312: online log 1 thread 1: '/oracle/oradata/oa/redo01.log'
ORA-27091: unable to queue I/O
ORA-27072: File I/O error
Linux Error: 5: Input/output error
Additional information: 4
Additional information: 54785
Additional information: 957952
Sat Apr 14 00:39:14 2018
Aborting crash recovery due to error 333
Sat Apr 14 00:39:14 2018
Errors in file /oracle/admin/oa/udump/oa_ora_5659.trc:
ORA-00333: redo log read error block 48641 count 8192
ORA-333 signalled during:  alter database open...

由于硬件异常,数据库在启动的时候读取redo异常,从而使得数据库无法正常启动

检查系统日志

Apr 14 11:14:58 oa kernel: Info fld=0x0, Current sda: sense key Hardware Error
Apr 14 11:14:59 oa kernel: Additional sense: Internal target failure
Apr 14 11:14:59 oa kernel: end_request: I/O error, dev sda, sector 190500041
Apr 14 11:14:59 oa kernel: SCSI error : <0 0 0 0> return code = 0x8000002
Apr 14 11:14:59 oa kernel: Info fld=0x0, Current sda: sense key Hardware Error
Apr 14 11:14:59 oa kernel: Additional sense: Internal target failure
Apr 14 11:14:59 oa kernel: end_request: I/O error, dev sda, sector 190500049
Apr 14 11:14:59 oa kernel: SCSI error : <0 0 0 0> return code = 0x8000002
Apr 14 11:14:59 oa kernel: Info fld=0x0, Current sda: sense key Hardware Error
Apr 14 11:14:59 oa kernel: Additional sense: Internal target failure
Apr 14 11:14:59 oa kernel: end_request: I/O error, dev sda, sector 190500057
Apr 14 11:14:59 oa kernel: SCSI error : <0 0 0 0> return code = 0x8000002
Apr 14 11:14:59 oa kernel: Info fld=0x0, Current sda: sense key Hardware Error
Apr 14 11:14:59 oa kernel: Additional sense: Internal target failure
Apr 14 11:14:59 oa kernel: end_request: I/O error, dev sda, sector 190500065
Apr 14 11:14:59 oa kernel: SCSI error : <0 0 0 0> return code = 0x8000002

大量类似I/O error, dev sda, sector错误,很可能是由于硬件方面异常导致.

损坏redo为当前redo
redo


针对这样的情况,由于是硬件故障,先要通过dbv或者rman检查其他数据文件是否正常,如果有数据文件不能读,那需要对数据文件进行特殊处理.本次恢复的中,客户相对比较幸运,所有数据文件全部可以正常访问,只是当前redo异常,通过隐含参数强制拉库,然后导出数据,重建库解决.类似文章:又一起存储故障导致ORA-00333 ORA-00312恢复

发表在 ORA-xxxxx, Oracle备份恢复 | 标签为 , | 留下评论

.CHAK1 比特币加密恢复

最近有朋友遇到oracle数据库被加密后缀名为.CHAK1的比特币勒索
oracle-chak1


我们通过确认,这次的破坏和上次的(比特币加密勒索间隔加密)比较类似
oracle-chak1
oracle-chak2

通过分析,此类损坏结果为:
1)1280 block 间隔加密,
2)每个加密文件前10M数据可能丢失
对于这个客户,我们通过分析,业务数据可以比较完美的恢复
data

如果您的数据库被比特币加密勒索,需要恢复支持请联系我们
Phone:13429648788    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

发表在 Oracle | 标签为 , , | 留下评论

ORA-00702: bootstrap verison ” inconsistent with version ’8.0.0.0.0′

数据库启动报ORA-01092 ORA-00704 ORA-00702错误

SQL> startup
ORACLE instance started.

Total System Global Area 3056513024 bytes
Fixed Size                  2257152 bytes
Variable Size             704646912 bytes
Database Buffers         2332033024 bytes
Redo Buffers               17575936 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00702: bootstrap verison '' inconsistent with version '8.0.0.0.0'
Process ID: 27344
Session ID: 191 Serial number: 3

bootstrap-ORA-00702


查看alert日志

Mon Apr 09 16:22:34 2018
ALTER DATABASE   MOUNT
Successful mount of redo thread 1, with mount id 1383493834
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Mon Apr 09 16:22:39 2018
ALTER DATABASE OPEN
Thread 1 opened at log sequence 3
  Current log# 3 seq# 3 mem# 0: /u01/app/oracle/oradata/orcl/redo03.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_27344.trc:
ORA-00704: bootstrap process failure
ORA-00702: bootstrap verison '' inconsistent with version '8.0.0.0.0'
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_27344.trc:
ORA-00704: bootstrap process failure
ORA-00702: bootstrap verison '' inconsistent with version '8.0.0.0.0'
Error 704 happened during db open, shutting down database
USER (ospid: 27344): terminating the instance due to error 704
Instance terminated by USER, pid = 27344
ORA-1092 signalled during: ALTER DATABASE OPEN...
opiodr aborting process unknown ospid (27344) as a result of ORA-1092
Mon Apr 09 16:22:40 2018
ORA-1092 : opitsk aborting process

错误比较明显是由于数据库open过程中bootstrap异常导致,出现此类错误一般是由于软件介质和db不匹配或者bootstrap表的block故障导致.

官方说明

Versions 9.2, 10.1, 10.2, 11.1, 11.2, 12.1

Error:  ORA-00702 bootstrap verison '%s' inconsistent with version '%s' 
---------------------------------------------------------------------------
Cause:  The reading version of the boostrap is incompatible with the current 
	bootstrap version. 
Action: Restore a version of the software that is compatible with this 
	bootstrap version

由于bootstrap$以及其中相关表处理比较特殊,如果您遭遇此类bootstrap$相关异常无法解决,需要恢复支持,请联系我们
Phone:13429648788    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

发表在 Oracle | 标签为 , , , | 留下评论

数据库不能open 报ORA-7445 lmebucp错

有一个朋友数据库启动报错ORA-03113

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

SQL> startup
ORACLE instance started.

Total System Global Area 1610612736 bytes
Fixed Size                  2096632 bytes
Variable Size             385876488 bytes
Database Buffers         1207959552 bytes
Redo Buffers               14680064 bytes
Database mounted.
ORA-03113: end-of-file on communication channel

alert日志报ORA-7445 lmebucp()+24错误

Sun Apr 08 08:05:07 CST 2018
ALTER DATABASE   MOUNT
Sun Apr 08 08:05:11 CST 2018
Setting recovery target incarnation to 2
Sun Apr 08 08:05:11 CST 2018
Successful mount of redo thread 1, with mount id 2650526067
Sun Apr 08 08:05:11 CST 2018
Database mounted in Exclusive Mode
Completed: ALTER DATABASE   MOUNT
Sun Apr 08 08:05:11 CST 2018
ALTER DATABASE OPEN
Sun Apr 08 08:05:11 CST 2018
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /u01/app/oracle/oradata/t10g/redo01.log
Successful open of redo thread 1
Sun Apr 08 08:05:11 CST 2018
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sun Apr 08 08:05:11 CST 2018
SMON: enabling cache recovery
Sun Apr 08 08:05:11 CST 2018
Errors in file /u01/app/oracle/admin/t10g/udump/t10g_ora_32810.trc:
ORA-07445: exception encountered: core dump [lmebucp()+24] [SIGSEGV] [Address not mapped to object] [0x000000000] [] []

对应trace文件

Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x0, PC: [0x37e6418, lmebucp()+24]
*** 2014-04-08 08:05:11.793
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [lmebucp()+24] [SIGSEGV] [Address not mapped to object] [0x000000000] [] []
Current SQL statement for this session:
ALTER DATABASE OPEN
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?
                                                   7F4238A22BD0 ? 7F4238A22C30 ?
                                                   7F4238A22B70 ? 000000000 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?
                                                   7F4238A22BD0 ? 7F4238A22C30 ?
                                                   7F4238A22B70 ? 000000000 ?
ssexhd()+629         call     ksedmp()             000000003 ? 000000001 ?
                                                   7F4238A22BD0 ? 7F4238A22C30 ?
                                                   7F4238A22B70 ? 000000000 ?
__restore_rt()+0     call     ssexhd()             00000000B ? 7F4238A23BF0 ?
                                                   7F4238A23AC0 ? 7F4238A22C30 ?
                                                   7F4238A22B70 ? 000000000 ?
lmebucp()+24         signal   __restore_rt()       000000000 ? 000008C00 ?
                                                   7FFF0F778790 ? 000000009 ?
                                                   000000000 ? 00000000D ?
kqlbebs()+1468       call     lmebucp()            000000000 ? 000008C00 ?
                                                   7FFF0F778790 ? 000000009 ?
                                                   000000000 ? 00000000D ?
kqlblfc()+172        call     kqlbebs()            000000000 ? 0BC119DE0 ?
                                                   7FFF0F778790 ? 000000009 ?
                                                   000000000 ? 00000000D ?
adbdrv()+58009       call     kqlblfc()            000000000 ? 7FFF0F77F610 ?
                                                   7FFF0F778790 ? 000000009 ?
                                                   000000000 ? 00000000D ?
opiexe()+13745       call     adbdrv()             000000000 ? 7FFF0F77F610 ?
                                                   0B9FFF9A8 ? 000000009 ?
                                                   000000000 ? 00000000D ?
opiosq0()+3398       call     opiexe()             000000004 ? 000000000 ?
                                                   7FFF0F7807CC ? 000000001 ?
                                                   000000000 ? 00000000D ?
kpooprx()+318        call     opiosq0()            000000003 ? 00000000E ?
                                                   7FFF0F780AF8 ? 0000000A4 ?
                                                   000000000 ? 600000013 ?
kpoal8()+783         call     kpooprx()            7FFF0F783CDC ? 7FFF0F781D30 ?
                                                   000000013 ? 000000001 ?
                                                   000000000 ? 600000013 ?
opiodr()+1184        call     kpoal8()             00000005E ? 000000017 ?
                                                   7FFF0F783CD8 ? 000000001 ?
                                                   000000001 ? 600000013 ?
ttcpip()+1226        call     opiodr()             00000005E ? 000000017 ?
                                                   7FFF0F783CD8 ? 000000000 ?
                                                   005BEBD70 ? 600000013 ?
opitsk()+1310        call     ttcpip()             006AF1FB0 ? 0054A6760 ?
                                                   7FFF0F783CD8 ? 000000000 ?
                                                   7FFF0F7837D8 ? 7FFF0F783E40 ?
opiino()+1024        call     opitsk()             000000003 ? 000000000 ?
                                                   7FFF0F783CD8 ? 000000001 ?
                                                   000000000 ? 721000200000001 ?
opiodr()+1184        call     opiino()             00000003C ? 000000004 ?
                                                   7FFF0F784ED8 ? 000000001 ?
                                                   000000000 ? 721000200000001 ?
opidrv()+548         call     opiodr()             00000003C ? 000000004 ?
                                                   7FFF0F784ED8 ? 000000000 ?
                                                   005BEB820 ? 721000200000001 ?
sou2o()+114          call     opidrv()             00000003C ? 000000004 ?
                                                   7FFF0F784ED8 ? 000000000 ?
                                                   005BEB820 ? 721000200000001 ?
opimai_real()+163    call     sou2o()              7FFF0F784EB0 ? 00000003C ?
                                                   000000004 ? 7FFF0F784ED8 ?
                                                   005BEB820 ? 721000200000001 ?
main()+116           call     opimai_real()        000000002 ? 7FFF0F784F40 ?
                                                   000000004 ? 7FFF0F784ED8 ?
                                                   005BEB820 ? 721000200000001 ?
__libc_start_main()  call     main()               000000002 ? 7FFF0F784F40 ?
+244                                               000000004 ? 7FFF0F784ED8 ?
                                                   005BEB820 ? 721000200000001 ?
_start()+41          call     __libc_start_main()  00072D108 ? 000000002 ?
                                                   7FFF0F785098 ? 000000000 ?
                                                   005BEB820 ? 000000002 ?

--------------------- Binary Stack Dump ---------------------

10046定位语句

SQL> staRTUP MOUNT
ORACLE instance started.

Total System Global Area 1610612736 bytes
Fixed Size                  2096632 bytes
Variable Size             385876488 bytes
Database Buffers         1207959552 bytes
Redo Buffers               14680064 bytes
Database mounted.
SQL> oradebug setmypid
Statement processed.
SQL> alter session set events '10046 trace name context forever, level 12';

Session altered.

SQL> oradebug tracefile_name
/u01/app/oracle/admin/t10g/udump/t10g_ora_32908.trc
SQL> alter database open;
ERROR:
ORA-03113: end-of-file on communication channel


SQL> 


PARSING IN CURSOR #2 len=55 dep=1 uid=0 oct=3 lid=0 tim=1463569438249596 hv=2111436465 ad='beb13e10'
select line#, sql_text from bootstrap$ where obj# != :1
END OF STMT
PARSE #2:c=0,e=471,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=1463569438249594
BINDS #2:
kkscoacd
 Bind#0
  oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
  oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0
  kxsbbbfp=7f8f940fadc0  bln=22  avl=02  flg=05
  value=56
EXEC #2:c=2000,e=61246,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,tim=1463569438310929
WAIT #2: nam='db file sequential read' ela= 41 file#=1 block#=377 blocks=1 obj#=56 tim=1463569438311099
WAIT #2: nam='db file scattered read' ela= 73 file#=1 block#=378 blocks=3 obj#=56 tim=1463569438311528
FETCH #2:c=1000,e=775,p=4,cr=5,cu=0,mis=0,r=0,dep=1,og=4,tim=1463569438311772
Exception signal: 11 (SIGSEGV), code: 1 (Address not mapped to object), addr: 0x0, PC: [0x37e6418, lmebucp()+24]
*** 2018-04-08 08:11:44.840
ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump [lmebucp()+24] [SIGSEGV] [Address not mapped to object] [0x000000000] [] []
Current SQL statement for this session:
alter database open

通过这里基本上可以定位,报错是由于bootstrap$中对象异常导致。由于该对象比较特殊,使用一些特殊方法进行处理,数据库正常启动成功

发表在 Oracle | 标签为 , , | 留下评论