Oracle Recovery Tools解决ORA-00279 ORA-00289 ORA-00280故障

Posted on 2020 年 09 月 06 日 by 惜分飞

标题：Oracle Recovery Tools解决ORA-00279 ORA-00289 ORA-00280故障

对于ORA-00279 ORA-00289 ORA-00280故障,一般是由于缺少日志(比如数据库非归档模式,或者归档日志丢失),导致某些文件无法正常online,对此Oracle Recovery Tool能够一键式快速解决.
模拟故障
非归档环境,模拟datafile 4 offline,然后多次切换日志,导致该文件无法正常online

SQL> select owner,segment_name from dba_segments where tablespace_name='USERS' AND OWNER='SYSTEM';

OWNER                          SEGMENT_NAME
------------------------------ ------------------------------
SYSTEM                         T_XIFENFEI

SQL> SELECT COUNT(1) FROM SYSTEM.T_XIFENFEI;

  COUNT(1)
----------
     87752

SQL> ALTER DATABASE DATAFILE 4 OFFLINE DROP;

Database altered.

SQL> ALTER SYSTEM SWITCH LOGFILE;

System altered.

SQL> /

System altered.

SQL> /

System altered.

SQL> /

System altered.

SQL> /

System altered.

SQL> archive log list;
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            D:\app\Administrator\product\11.2.0\dbhome_1\RDBMS
Oldest online log sequence     22
Current log sequence           24
SQL> select group#,status,sequence# from v$log;

    GROUP# STATUS            SEQUENCE#
---------- ---------------- ----------
         1 INACTIVE                 22
         2 INACTIVE                 23
         3 CURRENT                  24

SQL> RECOVER DATAFILE 4;
ORA-00279: change 1525881 generated at 09/06/2020 13:46:17 needed for thread 1
ORA-00289: suggestion :
D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\RDBMS\ARC0000000019_1046476315.0001
ORA-00280: change 1525881 for thread 1 is in sequence #19


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

使用Oracle Recovery Tools快速修复

online文件成功

SQL> recover datafile 4;
Media recovery complete.
SQL> alter database datafile 4 online;

Database altered.

SQL> SELECT COUNT(1) FROM SYSTEM.T_XIFENFEI;

  COUNT(1)
----------
     87752

通过该工具就可以快速解决oracle丢失归档数据文件online的问题

Oracle Recovery Tools恢复MISSING00000文件故障

Posted on 2020 年 08 月 08 日 by 惜分飞

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：Oracle Recovery Tools恢复MISSING00000文件故障

前几天介绍了自己开发的Oracle Recovery Tools工具,今天有客户遇到故障,数据库由于断电无法正常启动,第三方对其进行了重建控制文件操作,但是有两个数据文件没有加入到重建控制文件脚本中,当数据库被resetlogs方式打开之后出现如下效果

数据库已经被多次resetlogs打开,这两个丢失的文件无法正常加载进去,通过Oracle Recovery Tools进行处理

这里可以明显看到,resetlogs scn和checkpoint scn均不一样,常规方法肯定无法处理.

直接在恢复库只读情况下把文件加入到数据库中

通过Oracle Recovery Tools点击鼠标就可以快速的解决这类问题,省去的大量的bbed处理的烦劳(在win上要去找bbed软件,要去考虑各种偏移量,修改目标值等)

重命名sys用户引起数据库启动报ORA-01092 ORA-00600 kokasgi1错误

Posted on 2020 年 08 月 07 日 by 惜分飞

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：重命名sys用户引起数据库启动报ORA-01092 ORA-00600 kokasgi1错误

有客户和我反馈,他们为了防止有人使用sys用户进行登录,对sys用户进行了重命名,具体操作语句为:

update user$ set name='THISISSYS' where user#=0;

然后重启数据库发现数据库无法正常启动,报ORA-01092 ORA-00600 kokasgi1错误

[oracle@ecs-d75e-0618923 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Fri Aug 7 14:40:28 2020

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

Connected to an idle instance.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 6881345536 bytes
Fixed Size                  2214056 bytes
Variable Size            4227860312 bytes
Database Buffers         2617245696 bytes
Redo Buffers               34025472 bytes
Database mounted.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [kokasgi1], [], [], [], [], [], [],[], [], [], [], []
Process ID: 6269
Session ID: 530 Serial number: 3

以前写过处理过类似问题,参见:ORA-600 kokasgi1故障恢复,通过特殊处理,数据库open之后,对其user#=0的用户修改为SYS.

[oracle@ecs-d75e-0618923 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Fri Aug 7 14:52:09 2020

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

Connected to an idle instance.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 6881345536 bytes
Fixed Size                  2214056 bytes
Variable Size            4227860312 bytes
Database Buffers         2617245696 bytes
Redo Buffers               34025472 bytes
Database mounted.
SQL> alter database open;

Database altered.

SQL> select name from user$ where user#=0;

NAME
------------------------------
THISISSYS

SQL> update user$ set name='SYS' where user#=0;

1 row updated.

SQL> commit;

Commit complete.

SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup;
ORACLE instance started.

Total System Global Area 6881345536 bytes
Fixed Size                  2214056 bytes
Variable Size            4227860312 bytes
Database Buffers         2617245696 bytes
Redo Buffers               34025472 bytes
Database mounted.
Database altered.

至此恢复完成,再次sys是oracle内部默认的超级用户,系统很多调用在程序中写死的sys.,对其用户不能进行重命名操作.

coincidenceleague加密数据库恢复

Posted on 2020 年 08 月 05 日 by 惜分飞

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：coincidenceleague加密数据库恢复

今天接到一个朋友的数据库被加密的请求

这种类型的加密,以前也遇到过很多次,而且能够实现效果较好的恢复,参考:mysql数据库被加密恢复,以前这类病毒一般主要就是对文件起始位置一些block进行破坏,这次对其分析发现和以前有了本质区别(采用间隔加密,每个文件分给为10段,每次加密7个block[8k])

不过这点破坏难不倒我们,通过底层恢复,绝大部分情况可以直接open数据库,如果运气不太好,也可以最大限度恢复数据

对于oracle数据文件被加密,在大部分情况下,我们可以通过底层恢复技术,实现数据库open,然后通过exp/expdp导出数据,实现恢复之后业务直接运行的效果,最大限度提高数据恢复效果和减少业务恢复的时间.

Oracle Recovery Tools—202008

Posted on 2020 年 08 月 02 日 by 惜分飞

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：Oracle Recovery Tools—202008

近期对Oracle Recovery Tools小工具进行了一些完善,增加了一些小功能和修复了一些bug,现在对该小工具进行工具和使用说明:
具有功能
修复单个block 坏块
标记单个block为坏块
查看数据块内容
修改数据块中数据
修复数据文件头SCN信息
修复数据文件头resetlogs 信息
修复数据文件头fuzzy信息
数据块拷贝

软件界面