系统崩溃把重装的oracle覆盖报错:ora-00472

本文介绍了一种解决Oracle数据库中ORA-00600和ORA-00472错误的方法。通过调整数据库配置,创建新的回滚段和UNDO表空间,最终成功解决了问题。
windows系统崩溃后,oracle控制文件、数据文件、日志文件、参数文件都在,但重装系统并重装oracle数据库装,把原来的所有oracle文件覆盖后,启动oracle几分钟后就自动关闭,再重启就报错ora-00472。查看alert日志发现
ORA - 00600 : 内部错误代码, 参数:  [ 4194 ] [ 15 ] [ 8 ] [] [] [] [] []
ORA-00472: PMON 进程因错误而终止
通过查找网上
资料,得知引起原因是     A mismatch has been detected between Redo records and rollback (Undo) 
records.
ARGUMENTS:
Arg 
[a] Maximum Undo record number in Undo block
Arg 
[b] Undo record number from Redo block
解决方法:
SQL*Plus: Release 10.2.0.1.0 - Production on 星期四 5月 5 14:28:31 2011
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
已连接到空闲例程。
第一步:启动到nomount状态,创建pfile,将pfile里面的自动undo管理改为手工管理,并打开数据库
SQL> startup nomount
ORACLE 例程已经启动。
Total System Global Area  612368384 bytes
Fixed Size                  1250428 bytes
Variable Size             222301060 bytes
Database Buffers          381681664 bytes
Redo Buffers                7135232 bytes
SQL> create pfile='d:\1.ora' from spfile;
文件已创建。
SQL> shutdown immediate
ORA-01507: ??????

ORACLE 例程已经关闭。
SQL> startup mount pfile='d:\1.ora';
ORACLE 例程已经启动。
Total System Global Area  612368384 bytes
Fixed Size                  1250428 bytes
Variable Size             222301060 bytes
Database Buffers          381681664 bytes
Redo Buffers                7135232 bytes
数据库装载完毕。
SQL> show parameter undo
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management                      string      MANUAL
undo_retention                       integer     900
undo_tablespace                      string      UNDOTBS1
SQL> alter database open;
数据库已更改。
第二步:先创建一个回滚段并使用,再新建一个新的undo表空间,并将老的undo表空间drop
SQL> Create rollback segment rr ;
回退段已创建。
SQL>
SQL>  Alter rollback segment rr online ;
回退段已变更。
SQL> Create undo tablespace undotbs2 datafile 'D:\oracle\product\10.2.0\oradata\suredd\untotbs_01.dbf' size 50M;
表空间已创建。
SQL> drop tablespace UNDOTBS2 including contents and datafiles;
表空间已删除。
第三步:关闭数据库,使用spfile启动到nomount状态(其实就是让undo继续自动管理),
将undo表空间指向新创建的undo表空间,再关闭数据库再启动数据库
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup nomount
ORACLE 例程已经启动。
Total System Global Area  612368384 bytes
Fixed Size                  1250428 bytes
Variable Size             222301060 bytes
Database Buffers          381681664 bytes
Redo Buffers                7135232 bytes
SQL> alter system set undo_tablespace=undotbs2 scope=spfile;
系统已更改。
SQL> shutdown immediate
ORA-01507: ??????

ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area  612368384 bytes
Fixed Size                  1250428 bytes
Variable Size             222301060 bytes
Database Buffers          381681664 bytes
Redo Buffers                7135232 bytes
数据库装载完毕。
数据库已经打开。
SQL> select * from ff.test;
        ID NAME
---------- ----------
         1 ff
         2 jj
SQL> /
        ID NAME
---------- ----------
         1 ff
         2 jj
SQL> alter system checkpoint;
系统已更改。
SQL> alter system archive log current;
系统已更改。
SQL>  select * from ff.test;
        ID NAME
---------- ----------
         1 ff
         2 jj
SQL> /
        ID NAME
---------- ----------
         1 ff
         2 jj
SQL> show parameter undo
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management                      string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      UNDOTBS2

以上参考http://www.blogjava.net/KingKong/archive/2011/05/05/349593.html

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/27135177/viewspace-745440/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/27135177/viewspace-745440/

### 关于 EA 软件中的错误 401-19e84 EA 错误代码 `401-19e84` 并未在已知的标准数据库或常见技术文档中被具体提及。然而,通过分析类似的错误模式以及常见的企业架构 (Enterprise Architecture) 工具可能出现的问题,可以推测该错误可能涉及以下几个方面: #### 可能的原因 1. **事务管理异常**: 类似于 Oracle 数据库内部错误 ORA-00600 的情况[^1],当系统尝试提交一个已经结束的事务时,可能会触发此类错误。这表明系统的状态不一致,可能是由于并发操作或者资源释放不当引起的。 2. **配置文件损坏**: 如果 EA 使用外部配置文件来定义模型结构或其他参数,则这些文件可能存在语法错误或丢失某些必要字段。这种情况下,加载特定功能模块可能导致崩溃并抛出未知错误。 3. **插件冲突**: 当安装多个第三方插件时,如果它们之间存在依赖关系处理不当的情况,也可能引发不可预见的行为,表现为随机性的错误码显示。 4. **内存泄漏或溢出**: 长时间运行的应用程序如果没有正确清理不再使用的对象实例,最终会耗尽可用RAM空间从而造成各种奇怪的表现形式之一就是非标准退出加上自动生成但难以理解其含义的一串数字作为唯一标识符——即所谓的“错误编号”。 #### 解决方案建议 针对上述可能性提供如下几种排查方向及对应措施: ##### 方法一: 检查日志记录 查看应用程序的日志输出寻找更多上下文线索可以帮助定位根本原因所在位置。通常来说现代软件都会具备详尽的操作跟踪机制以便事后审计之需;因此应该优先关注最近时间段内的活动轨迹是否存在可疑迹象. ```bash grep -iR "error|exception" /path/to/logs/ ``` 此命令用于搜索所有包含关键词 `"error"` 或者 `"exception"` 的行在整个指定目录下的文本文件里(假设使用的是类Unix操作系统). --- ##### 方法二: 更新至最新版本 确保所部署的产品副本处于厂商发布的最稳定形态下工作往往能够有效规避很多潜在隐患因为官方团队持续改进修复已发现漏洞的同时也会优化整体性能表现减少不必要的麻烦发生几率. 访问官方网站下载补丁包按照指引完成升级流程即可实现这一目标. --- ##### 方法三: 卸载重装相关组件 对于怀疑由扩展引起干扰的情形可考虑逐一禁用现有附加项观察现象变化规律进而锁定罪魁祸首再决定是否保留还是替换替代品达到兼容目的. 另外还可以彻底移除整个环境重新构建基础框架从源头杜绝残留垃圾数据影响正常运转的可能性. --- ##### 方法四: 增加监控力度 引入专业的APM(Application Performance Management)工具实时捕获各项指标数值绘制趋势图表辅助判断瓶颈出处及时调整策略应对突发状况保持业务连续性不受损害. 例如 New Relic APM 就是一个不错的选择它支持多平台跨语言无缝集成易于上手快速见效值得推荐试用看看效果如何. ```json { "application_name": "YourAppName", "license_key": "your-license-key-here" } ``` 以上 JSON 片段展示了如何配置基本的新遗物代理设置只需修改相应占位符内容便可以直接投入使用无需额外复杂步骤困扰开发者群体. --- ### 结论 虽然目前尚无确切资料直接说明 `401-19e84` 的确切成因及其解决方案,但从以往经验出发采取综合手段逐步缩小范围直至找到症结所在不失为一种务实的做法。希望本文所提供的思路对你有所帮助!
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值