惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

罗磊的独立博客
Forbes - Security
Forbes - Security
Blog — PlanetScale
Blog — PlanetScale
P
Proofpoint News Feed
Apple Machine Learning Research
Apple Machine Learning Research
Google DeepMind News
Google DeepMind News
MyScale Blog
MyScale Blog
GbyAI
GbyAI
B
Blog RSS Feed
S
SegmentFault 最新的问题
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
小众软件
小众软件
The Last Watchdog
The Last Watchdog
W
WeLiveSecurity
Webroot Blog
Webroot Blog
S
Security @ Cisco Blogs
Hugging Face - Blog
Hugging Face - Blog
Microsoft Security Blog
Microsoft Security Blog
月光博客
月光博客
博客园 - 聂微东
F
Fortinet All Blogs
H
Hacker News: Front Page
A
About on SuperTechFans
Application and Cybersecurity Blog
Application and Cybersecurity Blog
C
Check Point Blog
V
V2EX
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Y
Y Combinator Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
N
News | PayPal Newsroom
Cisco Talos Blog
Cisco Talos Blog
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
The Cloudflare Blog
P
Privacy & Cybersecurity Law Blog
N
Netflix TechBlog - Medium
C
CXSECURITY Database RSS Feed - CXSecurity.com
Recorded Future
Recorded Future
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Google DeepMind News
Google DeepMind News
大猫的无限游戏
大猫的无限游戏
美团技术团队
Security Latest
Security Latest
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
I
InfoQ
Recent Announcements
Recent Announcements
The GitHub Blog
The GitHub Blog
Google Online Security Blog
Google Online Security Blog
T
The Exploit Database - CXSecurity.com

博客园 - 惜分飞

使用deepseek进行Oracle恢复,引起重大故障---惜分飞 硬件故障后数据文件大小不对故障处理—Oracle碎片扫描恢复 1.5T MySQL数据库完美恢复---惜分飞 asm dd 10M导致system文件部分坏块修复---惜分飞 一次断电引起的Oracle故障恢复-ora-600 2662故障---惜分飞 Oracle故障第一现场被恢复混乱的数据库恢复--惜分飞 OraScan (Oracle碎片扫描工具)使用说明 imp导入dmp报IMP-00098: INTERNAL ERROR: impgst2故障处理 记录一次win删除数据文件完美恢复案例 国产信创库fio破坏主备库以及备份故障处理--惜分飞 .wman扩展名勒索mysql数据库恢复 Oracle数据库被勒索加密一键open工具–OraFHR rose双机引起文件系统损坏导致数据库异常故障处理---惜分飞 ORA-704 ORA-604 ORA-1578故障处理 csc(0x0006.d75a14f4) higher than block scn(0x0000.00000000)--故障处理--obet ORA-600 kcratr_nab_less_than_odr和ORA-600 4193故障处理---惜分飞 aix环境10g由于控制器异常导致ORA-600 4000故障处理---惜分飞 不当恢复truncate数据导致数据库不能open处理 在生产环境错误执行dd命令破坏asm磁盘故障恢复---惜分飞 obet实现对数据文件坏块检测功能(obet dbv) obet快速修改scn/resetlogs恢复数据库(缺少归档,ORA-00308) sql server 事务日志备份异常恢复案例---惜分飞 linux异常磁盘lvm恢复---惜分飞 win平台挂起Oracle数据库启动进程 expdp dmp 导出不完整导入ORA-39059 ORA-39246 故障抢救数据 mysql drop database 无有效备份恢复思路 mysql drop database 无法备份恢复思路
Patch_SCN快速解决ORA-600 2663故障
惜分飞 · 2026-01-17 · via 博客园 - 惜分飞

一个维保客户和我说他们测试库删除了日志文件导致库无法启动,让我帮忙看看
客户现场现况
1. 磁盘空间使用100%

[oracle@We1-db_Test ~]$ df -h

Filesystem      Size  Used Avail Use% Mounted on

devtmpfs        3.9G     0  3.9G   0% /dev

tmpfs           3.9G     0  3.9G   0% /dev/shm

tmpfs           3.9G  880K  3.9G   1% /run

tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup

/dev/vda1        40G   38G   92M 100% /

tmpfs           783M     0  783M   0% /run/user/0

2. 数据库redo被删除了部分,而且是active状态的被删除

[oracle@We1-db_Test ~]$ ls -l /opt/app/oracle/oradata/orcl/redo0*

-rw-r----- 1 oracle oinstall 52429312 Jan 15 15:29 /opt/app/oracle/oradata/orcl/redo04.log

-rw-r----- 1 oracle oinstall 52429312 Jan 15 16:26 /opt/app/oracle/oradata/orcl/redo05.log

SQL> select group

    GROUP

---------- ---------- ----------------

         1       8989 CURRENT

         2          0 UNUSED

         5          0 UNUSED

         4          0 UNUSED

         3       8988 ACTIVE

SQL> select member from v$logfile;

MEMBER

-----------------------------------------------------

/opt/app/oracle/oradata/orcl/redo03.log

/opt/app/oracle/oradata/orcl/redo02.log

/opt/app/oracle/oradata/orcl/redo01.log

/opt/app/oracle/oradata/orcl/redo04.log

/opt/app/oracle/oradata/orcl/redo05.log

基于当前情况,直接open库无望,但是空间不足问题需要先解决,不然恢复过程中创建redo空间不足依旧会报错卡死,所以先清理了监听和alert等日志,系统空闲了3G多空间,可以进行恢复操作

[oracle@We1-db_Test trace]$ df -h

Filesystem      Size  Used Avail Use% Mounted on

devtmpfs        3.9G     0  3.9G   0% /dev

tmpfs           3.9G     0  3.9G   0% /dev/shm

tmpfs           3.9G  880K  3.9G   1% /run

tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup

/dev/vda1        40G   34G  3.9G  90% /

tmpfs           783M     0  783M   0% /run/user/0

恢复数据库
1. 由于active redo丢失,毫无疑问,直接强制拉库,使用_allow_resetlogs_corruption参数开干

SQL> startup mount pfile='/tmp/pfile';

ORACLE instance started.

Total System Global Area 2455228416 bytes

Fixed Size                  2255712 bytes

Variable Size             905970848 bytes

Database Buffers         1526726656 bytes

Redo Buffers               20275200 bytes

Database mounted.

SQL> recover database until cancel;

ORA-00283: recovery session canceled due to errors

ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

SQL> recover database using backup controlfile;

ORA-00279: change 311982775 generated at 12/31/2025 17:35:11 needed for thread

1

ORA-00289: suggestion :

/opt/app/oracle/fast_recovery_area/ORCL/archivelog/2026_01_16/o1_mf_1_8988_%u_.a

rc

ORA-00280: change 311982775 for thread 1 is in sequence #8988

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

cancel

Media recovery cancelled.

SQL> alter database open resetlogs;

alter database open resetlogs

*

ERROR at line 1:

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0],

[311982833], [], [], [], [], [], [], []

Process ID: 11917

Session ID: 576 Serial number: 3

alert日志报错

Fri Jan 16 21:25:31 2026

Assigning activation ID 1750515127 (0x6856bdb7)

Thread 1 opened at log sequence 1

  Current log

Successful open of redo thread 1

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

Fri Jan 16 21:25:31 2026

SMON: enabling cache recovery

Errors in file /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc  (incident=81753):

ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], []

Incident details in: /opt/app/oracle/diag/rdbms/orcl/we1db/incident/incdir_81753/we1db_ora_11917_i81753.trc

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Errors in file /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc:

ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], []

Errors in file /opt/app/oracle/diag/rdbms/orcl/we1db/trace/we1db_ora_11917.trc:

ORA-00600: internal error code, arguments: [2663], [0], [311982792], [0], [311982833], [], []

Error 600 happened during db open, shutting down database

USER (ospid: 11917): terminating the instance due to error 600

Instance terminated by USER, pid = 11917

ORA-1092 signalled during: alter database open resetlogs...

opiodr aborting process unknown ospid (11917) as a result of ORA-1092

Fri Jan 16 21:25:33 2026

ORA-1092 : opitsk aborting process

不幸数据库遇到ORA-600 2663错误,这个故障在以前的文章中描述过,基本上和ORA-600 2662的处理思路类似,这里直接使用:Patch_SCN for Linux进行恢复
2. 使用Patch_SCN处理数据库SCN

SQL> startup nomount pfile='/tmp/pfile';

ORACLE instance started.

Total System Global Area 2455228416 bytes

Fixed Size                  2255712 bytes

Variable Size             905970848 bytes

Database Buffers         1526726656 bytes

Redo Buffers               20275200 bytes

SQL>@rectl

Control file created.

SQL> recover database;

Media recovery complete.

patch_scn


SQL> alter database open;

Database altered.

SQL> SELECT CURRENT_SCN FROM V$DATABASE;

     CURRENT_SCN

       322002903

到这里完成数据库open操作,后续逻辑导出完成恢复任务