Author: mac

ORA-1410 invalid rows错误是与ORA-8103相似的Oracle数据库逻辑层面的讹误。   如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]   了解ORA-1410逻辑坏块问题的成因，以及有效的解决手段十分重要。 解决方案之一： 可以通过如下PL/SQL过程将健康数据复制到新建表中，对于问题数据块中的数据将被跳过，对于能够容忍数据丢失的场景可以考虑这样恢复，之后truncate 原表/分区并将健康数据加载进去。 具体的脚本见下面的链接： 【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题   oerr ora 1410 01410, 00000, “invalid ROWID” // *Cause: // *Action: 如果对ORA-1410做errorstack 一般会看到下面的LOG: OBJD MISMATCH typ=6, seg.obj=%d, diskobj=%d, dsflg=%d, dsobj=%d, tid=%d, cls=%d   触发ORA-1410错误的stack call一般都是：  kcbgtcr=>kcbzib=>kcbz_check_objd_typ，即在对数据块做逻辑读时运行到kcbz_check_objd_typ函数时，检测到OBJD 不一致的问题。由于seg.obj和diskobj不一致，而10g以后的kcbz_check_objd_typ函数负责验证块上的objd是否mistmatch，若不一致则触发ORA-1410错误。 造成objd mimatch的主要可能有几种： 1、 写丢失 Lost Write， 写丢失造成相关数据块没有为现有对象正常格式化，导致虽然该数据块的checksum是正确的,但对应数据字典却是不一致的。 写丢失也可能由磁盘或卷组镜像同步软件的不完整复制造成。…

老托的Oracle 数据库Patch概念性小常识，初学者可以参考该图 来了解Oracle中 补丁的分类知识， 感谢Oracle ALLSTARS群中的老托同学的分享。 也可以点击这里下载老托的Oracle 数据库Patch概念性小常识   名称 说明 Release ¤ 标准产品发布。如Oracle Database 10g Release 2的第一个发行版本为10.2.0.1,可以在OTN、edelivery等站点上公开下载 Patch Set Release ¤ 就是早期大家常说的PSR。这是在主版本号上发布的补丁集，修复了较多的Bug，可能会包含一些增强功能（Enhancement）。比如11.2.0.1是一个主版本，那么11.2.0.2、11.2.0.3就是2个不同的Patch set。这种补丁集经过了严格的集成测试，也是累积型的。所以推荐安装最新的Patch Set。 Patch Set Update ¤ 就是DBA&DMA们常论道的PSU。Oracle 选取在每个季度用户下载数量最多，并且得到验证具有较低风险的补丁放入到每个季度的PSU中，修复比较严重的一些问题，包含每个季度的CPU，是累积型的。虽然在描述PSU的时候会用到数据库版本第5位，比如Database PSU 11.2.0.3.5，但实际上打完PSU后并不会真正改变数据库的版本，从v$version中看到的版本还是4位的(11.2.0.3.0)，第5位仍然是0。 ¤ 注意 (1)Windows上没有CPU和PSU，对于Windows和Exadata，Oracle使用Bundle Patch代替PSU，Bundle Patch会包含PSU的内容 (2)从11.2.0.2版本开始，一个新的补丁策略被引入，11.2.0.1之后发布的Patch Set本身就是一个完整的安装包，不再需要基础的Release 版本安装。 Critical Patch Update ¤ 这个指的就是CPU补丁。每季度发布一次，用来修复安全方面的一些补丁，是累积型的。目前(2012年10月）已经更名为Security Patch Update (SPU) ¤ 这类问题本来不属于软件错误,在正常使用中不会出现任何问题。但是别有用心的人可以通过运行非常精巧设计的代码 ，绕过数据库系统的安全管理机制,达到非授权存取的目的。 ¤ 重要补丁公告参见这里. Interim…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected] Versions 9.2, 10.1, 10.2, 11.1, 11.2, 12.1 Error: ORA-01172 recovery of thread %s stuck at block %s of file %s ————————————————————————— Cause: Crash recovery or instance recovery could not apply a change to a block because it was not the next change. This can happen if the block…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   适用于： Oracle Database – Enterprise Edition – 版本9.0.1.0 及以上 本文信息适用于任何平台。 症状 问题描述 ——————- 你还原了热备份并尝试进行时间点恢复。 当你尝试打开数据库时收到以下错误： ORA-01195: online backup of file <name> needs more recovery to be consistent 原因  ORA-01195: online backup of file <name> needs more recovery to be consistent 原因：一个不完全恢复会话被启动，但使文件一致而应用的重做日志数量不足。被报告的文件是必须恢复到备份结束时间的联机备份。 操作：应用更多重做日志直到文件一致或从一个较旧备份中还原文件并重复恢复。 解决方案 前提是进行的热备份完成无差错且有效。 继续应用请求的日志直到所有数据文件一致且不模糊 然后，你可以打开数据库。 说明…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]     适用于： Oracle Database – Enterprise Edition – 版本10.2.0.1 及以上 本文信息适用于任何平台。 目的 强调控制文件的重要性和在重建它之前你需要考虑的问题。 故障排除步骤 在重建控制文件前… 控制文件对于数据库非常重要。一些信息仅被存储在控制文件，而不是数据字典中。元数据包括闪回日志，块更改跟踪，RMAN备份和数据文件的位置。经常有可用的解决方法或解决方案，所以控制文件并不需要被重建。 如果你真的必须重建控制文件，或者当Oracle指示时，请考虑以下… 1. 无法访问/脱机的数据文件 首先如果所有的数据文件不在磁盘上，你将无法重新控制文件。 如果数据文件在磁盘上，确保没有脱机的数据文件： select distinct(status) from v$datafile where status not in (‘ONLINE’,’SYSTEM’); select name, ts#, online$, contents$ from ts$ where online$ =2; 否则，一旦使用resetlogs重建了控制文件，所有脱机的数据文件无法被添加回数据库。你可能遇到以下错误： RMAN> sql ‘alter database datafile 6…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]     适用于： Oracle Database – Enterprise Edition – 版本9.0.1.0 及以上 本文信息适用于任何平台。 目标 至少需要进行多少恢复量才能使从备份中还原的数据库被打开？ 在执行RESTORE / RECOVER后，我们需要执行快速验证以确保数据库一致并准备好OPEN RESETLOGS。 这种主动检查有助于防止在OPEN RESETLOGS期间或之后出现的几个问题。 本文通篇假设你正在从有效的备份中进行还原。 可能有这里没有讨论到的情况。如有疑问请咨询Oracle Support。 解决方案 对于冷/脱机备份，无需归档日志/恢复。你只要使用resetlogs打开数据库。 但对于热/联机备份，必须应用从备份开始到结束的所有归档日志才能打开数据库 – 这是恢复最低需要的数量。 要确定在备份完成时哪些日志是当前的，记下数据库备份的完成时间 – 从备份日志中获取。 如果这个是一个RMAN 备份，你也可以查询RMAN 元数据。确保在调用rman之前设置环境变量 NLS_DATE_FORMAT ，使得时间戳和日期同时返回： 对于unix：     % export NLS_DATE_FORMAT=’dd-mon-rr hh24:mi:ss’ % rman target / 对于windows： > set…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   适用于： Oracle Database – Enterprise Edition – 版本10.2.0.4 及以上 本文信息适用于任何平台。 症状 当尝试打开数据库时，显示以下错误。 ORA-01190: control file or data file 37 is from before the last RESETLOGS ORA-01110: data file 37: ‘O:\ORADATA\ADMP\ADM_HIR_50GIG.DBF’ ORA-19729: File 37 is not the initial version of the plugged in datafile 原因 可传输表空间在过程中失败并导致相关数据文件与Oracle控制文件不同步。因此之后重启导致以下问题。 解决方案 由于失败的可传输表空间操作导致该问题，解决方法是：…

  如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   目标：如何将本地管理的临时表空间整合到备份策略 适用于：Oracle Server – Enterprise Edition 8.1.7.2 修正： 本地管理的临时表空间不需要备份。在Note 167056.1 – “Alter Tablespace Begin Backup” on a Temporary Tablespace Fails with ORA-03217一文中描述。 然而，有理想的情况在备份策略中包括临时文件。 例如： 试想一个新的DBA需要从热备份中还原数据库。没有临时表空间，所以他需要重建它们。不过他不知道创建的大小。如果根据用户需要，临时表空间已被调整大小，可能会有问题。 因此可以如下操作： 备份本地管理的临时文件，无需将它们置于热备份模式。（即只要复制它们）。可以这样操作，因为Oracle从不会尝试匹配这些文件的scn且没有信息会永久储存在其中。 然后，在要返回到热备份的事件中，还原与热备份同时进行的临时文件副本restore the copy of the tempfile/(s) that was taken at the same time as the hotbackup. 在还原临时文件的副本可能遇到的问题是不同大小的文件被还原。这会显示下错误： ORA-01187: cannot…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected] 在本文中 症状 原因 解决方案 适用于： Oracle Server – Enterprise Edition – 版本：10.2.0.1 到 10.2.0.5 – Release: 10.2 到 10.2 本文信息适用于任何平台。 症状 在只读模式下打开备用数据库时，在警报日志可能看到以下错误 ORA-01187: cannot read from file 201 because it failed verification tests ORA-01110: data file 201: ‘/u02/oradata/PROD_PSB/temp_prod_01.dbf’ 原因 任何临时文件都未物理显示或可能损坏。 解决方案 当你在主数据库上添加临时文件时，新的临时文件不会自动添加到物理备用数据库上。 你可以使用以下语句添加到备用数据库上：  SQL> alter database open read only. SQL> alter tablespace temp add tempfile ‘<name>’ size .. 如果临时文件物理显示，仍错误错误： 则drop 临时文件并重建它们。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]       ORA-8103是我们Database Consultant 经常要遇到的一个问题，了解ORA-8103的成因非常重要。 【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题 简单来说ORA-8103 的主要成因有2类: 数据块的 block type 类型 是 无效的 或者读出来的块类型与Oracle期望的不一致。  例如 Oracle 认为该数据块的类型为data(type=6)，但实际却不是。 数据块中的data_object_id 和 数据字典中的data_object_id不匹配   针对ORA-8103问题 我们优先推荐一些措施： ORA-08103问题的诊断最好是能生成8103错误的ERROR STACK TRACE， 在TRACE中会记录具体引发8103的对象的OBJ和OBJD，这便于我们定位可能存在corruption的对象。 问题在于往往前台进程遇到ORA-08103错误不会在后台生成TRACE文件，这需要我们手动设置8103 触发ERRORSTACK的EVENTS: ALTER SYSTEM SET EVENTS ‘8103 TRACE NAME ERRORSTACK LEVEL 3’; 解决思路包括： 1. 通过OBJD和DBA定位到具体的表名和块号 2. 有条件的情况下对该表做一个analyze ..…