Author: mac

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   应用于: Oracle数据库- 企业版- 10.2.0.1版到11.1.0.7版[发行10.2版至11.1版] 本文档中的信息适用于任何平台。 ***于2013年6月3日检测相关性*** 症状 4个节点中的两个被逐出集群。这两个节点返回集群后，一些磁盘组被安装，但特定的磁盘组安装出错。在未受影响的节点上，所有的磁盘组都被安装。 尝试安装磁盘组时，会出现这些错误： SQL> alter diskgroup datadg1 mount; alter diskgroup datadg1 mount * ERROR at line 1: ORA-15032: not all alterations performed ORA-15063: ASM discovered an insufficient number of disks for diskgroup “DATADG1″ ORA-15038: disk ” size mismatch with diskgroup [1048576]…

  如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   实际: Oracle Server – 企业版 7.3.4 症状: 启动数据库失败 症状: ORA-00205: 确认控制文件中出现错误，为获取更多信息检查警告日志 症状: ORA-09782: “sfifi:其他实例有安装好的相同的数据库 原因: 可能是实例崩溃，也可能是其他原因 没有其他实例打开数据库，检查了ORACLE_HOME ，检查了 ORACLE_SID ，也检查了符号连接等等，都没有帮助。 修复: 重建控制文件参考文献:Note:1012929.6 How to Recreate the Controlfile   ORA-00205: 标识控制文件时出错, 有关详细信息, 请查看预警日志 oerr ora 205 00205, 00000, “error in identifying control file, check alert log for more…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   摘要 PRO * C代码从损坏表中提取数据。 产品名称, 产品版本 RDBMS, 8.1.5 – 9.2.0 平台 UNIX 创建日期 24-MAY-2000 引言 执行环境: PRO*C 需要安装的或静态连接的Pro*C传输可执行文件 注意：对于Windows NT/ 2000 ======================== 它可以使用Visual C ++为Windows成功地（预）编译的可执行文件为Windows使用Visual C ++，连接到远程数据库设置TWO_TASK到SQLNET数据库别名，请使用以下批处理文件： REM Salvage8i.bat – wrapper for salvage8i.exe TITLE Salvage8i REM Set TWO_TASK to the database alias defined in tnsnames.ora : REM…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]     从Oracle7的表中挽救数据 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 本文是 Note:28814.1的延伸，讨论了应对 Oracle中块损坏的可用选择，这里我们讨论在 Oracle7版本中如何从包含一个损坏块或若干损坏块的表中提取数据。 *** 本文不涵盖Oracle8 – 如需要，请参考 Note:61685.1*** 为了使用这些步骤，在这里需要列举表中所有的损坏文件和损坏块，最好能获取下列信息： – Original Error – File# – Referred to as <AFN> in this article – Block# – Referred to as <BL> in this article – Object Type – eg: TABLE or CLUSTER – Object Owner.Name…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected] 目的 本文讨论了快损坏的原因 范围和应用 适用于想要了解导致数据库中块损坏的原因的用户 相关文献 Note 77587.1 通常损坏发生后，组织管理处想要从数据库管理员获取有关损坏是如何发生的，可以采取哪些办法预防的信息。 损坏发生的原因很多，概括如下： 1. 硬件故障 最常见的硬件故障是硬盘上块的物理损坏或者磁盘控制器故障。在磁盘发生故障的情况下，磁盘可能完全损坏或者可能会损坏盘片个别点，通常，该损坏仅限于磁盘文件上，常见的原因有电涌，运行时系统的移动，硬件的年限或制造上的缺陷。该磁盘的OS级别的系统调用通常也会受到影响(文件的写入和读取)。 在磁盘控制器发生故障的情况下，可能会出现和磁盘故障相同的表现，但通常仅限于一个磁盘，控制器可能有时出现读取和写入失败，或者镜像磁盘间读取和写入的协调出现问题，控制器也会完全损坏。 在任何情况下，你通常会看到OS相关的错误和/或故障。 2. 软件故障 在出现软件故障的情况下，通常会收到一个不在 OS级别表现的错误 Oracle错误，它们往往都伴随着内部错误、核心转储或特定的错误，表示不能向文件读取和写入，通常不伴有OS 错误，不蓄意删除或复制已成功完成的文件。 通常，这些错误由若干已知的原因导致，数据库或操作系统到了极致不佳的严重状态，该数据库性能很差或反复崩溃，数据库打开时，终止后台进程，对任何涉及从磁盘或存储读取和写入的正常的内核级别活动的处理不当，已经或尚未被认定为错误。 软件损坏的原因在频谱上各不相同，通常不表现为一致的原因，除非它是与错误有关的。 3. 硬件和软件故障 这些是最难以区分的，它们可能以任何数量的方式表现，通常，需要硬件专家、软件专家和开发商共同努力，找出问题的根源。 如何准备应对损坏 a. 准备故障应急预案. b. 保持补丁版本最新. c. 调优. 头号解决方案是做好最坏的打算 定期执行备份和导出，保持数据库和操作系统调优，另一个考虑是研究硬件的寿命，在受这些寿命确定的周期的基础上，规划迁移到新系统的资金预算。 总之，没有完全消除损坏风险的方法，只能相应地减少风险，做出规划。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   问题描述 ——————- 使用execute dbms_utility.analyze_schema(‘SCHEMA’,’COMPUTE’)分析架构时; 产生了下列错误: ORA-01410:invalid ROWID ORA-06512: at “SYS.DBMS_DDL”, line 161 ORA-0 6512: at”SYS.DBMS_UTILITY”, line 254 ORA-06512: at line 1 分析架构估计成功完成。 方法描述 ——————– 估计统计实施的好这一事实有助于确定该DBMS_UTILITY 工作正常，并真实存在一个损坏的ROWID。 要解决这个问题最简单的办法就是通过导出/导入重新生成ROWID 1.备份数据库 2.导出schema 3.丢弃schema对象 4.利用导出文件重建对象 如果因为其他原因该方法不可行，请参考 note:18815.1获取更多解决该问题的方法。 解释 ———– 该案件是由专为较旧版本的Oracle设计的第三方应用程序所致，将数据加载到数据库中，有时会在进程中破坏领域。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   本文的信息适用于: 任何平台的Oracle RDBMS ，通常由一些硬件问题引起实例崩溃之后。 症状 ~~~~~~~~~~ 启动期间实例崩溃，会收到下列错误和DBWR终止实例： *** Corrupt block relative dba: 0x02c31d6a (file 11, block 204138) Bad header found during preparing block for write Data in bad block – type: 100 format: 101 rdba: 0x1e010101 last change scn: 0x0000.0c117747 seq: 0x2 flg: 0x20 consistency value in…

Oracle的硬件辅助恢复数据(H.A.R.D)举措 ————————————————————— 数据损坏问题会导致长时间的中断，现在，用于检测由Oracle之外的硬件或软件，如I/O子系统，引起的损坏的主要方法是Oracle检验和，Oracle确实提供了不同级别的块检验和保护，当数据从Oracle SGA 或 sessions’ PGA读取和向Oracle SGA 或 sessions’ PGA写入时， 当 Oracle检验和启用（默认从 Oracle 9i真正开始），因为每个块被修改，检验和被计算和存储在该块中，随后，在接下来对该块的读取时，该检验和被验证。(更多关于Oracle检验和功能的信息，请参考Note:30706.1和Note:32969.1.）。 此外, 使用 Oracle 恢复管理器时，该工具也可能帮助检测损坏，因为该检验和也为备份和恢复而得以计算和验证，但是，一旦离开 Oracle后，损坏发生，目前没有可替代的机制验证 Oracle 数据、防止损坏写入到永久存储，一旦块通过卷管理器被传递给操作系统，和到磁盘上，Oracle本身不再提供任何检查该块被写入仍然是正确的，因此，Oracle本身不能防患于未然，为了防止潜在的损坏，Oracle现在与存储供应商合作，提供Oracle数据的检查和验证。 参与该计划的供应商都使用相同的校验算法在被写入磁盘之前来验证块，这避免了将损坏带入到永久存储。 为使用 HARD 验证, 所有的数据文件和日志文件都放置在兼容的硬盘存储上，同时，用户必须使用供应商提供的接口在存储上启用HARD验证功能。 当 Oracle向该存储写入数据时，该存储系统验证数据，如果，似乎发生了损坏，写入被拒绝，并报错。 HARD处理的数据损坏类型 ——————————————- HARD 程序定义了很多级别的保护。Oracle存储合作伙伴可以选择实施固件或硬件检查，以防止下列类型的损坏： – 损坏块的写入 在Oracle写入数据之后，到达磁盘之前，由一些干预操作系统或硬件成分引起损坏的数据 这些成分可能包括操作系统、文件系统、卷管理器、设备驱动、主机总线适配器和SAN交换结构，虽然Oracle可以在向后读取数据时检测损坏，但是Oracle可能无法读取数据，直到几天或几个月后，到那时，可能恢复该数据的备份不可用了。 – 块写入到不正确位置 Oracle 写入到磁盘的特定位置，不知怎么的，操作系统或存储系统将块写入到错误的位置，这会造成两种损坏：磁盘上有效数据的损坏和从已提交事务中丢失数据。 – 由除Oracle以外的其他程序向Oracle数据错误的写入 Oracle数据文件可能被非Oracle应用所覆盖 非Oracle进程或程序可能会意外地覆盖Oracle数据文件的内容。这可能是因为应用软件、操作系统上的错误，也可能因为人的错误。 (例如, 偶尔越过Oracle数据文件复制了一个正常的操作系统文件）。 – 损坏的第三方备份 当备份复制到磁带时，数据损坏会发生。这种损坏特别严重，因为该备份用于修复数据损坏，所以，如果该备份也损坏了，那么，就没有其他的方法来恢复丢失的数据，这尤其适用于第三方备份（磁盘存储单元不经过Oracle直接复制数据到备份设备。） 可能的 HARD检查 ———————— 在一个实施Oracle HARD功能的存储系统中，Oracle服务器可以用很多检查来验证…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   目标 这篇文章的目的是帮助Oracle客户了解ORA-600[729] UGA内存泄露问题。本文将帮助你了解内存泄漏问题是什么以及内存泄露时应当怎么做。 解决方案 什么是空间（内存）泄漏？ 当Oracle试图释放被分配给进程的内存时，常出现内存泄漏。当Oracle释放被分配给用户进程的堆时，会话注销过程中会发现内存泄漏。 当用户连接到Oracle，创建一个用户进程同时分配堆。每个进程都将有自己的内存堆。 内存被分成若干堆，每堆由一个或多个扩展组成。每个扩展包含一系列连续的存储块，这些块可以是自由的也可以是被分配的。通用堆管理器在FREE LISTS 和 LRU LISTS的帮助下，分配并释放内存块，。 块类型如下: FREE 2. FREEABLE 3. RECREATABLE 4. PERMANENT 5. FREEABLE WITH MARK并不强制每个扩展只能包含一种类型的组块。扩展区可以包含不同类型的块。当进程需要内存块时，根据需要将它们进行分配。Oracle在内部跟踪分配给进程的内存量。 进程终止时，所有分配给进程的内存会自动释放。内存被释放时，被分配的堆也被释放。一般情况下，当堆被释放，进程判定为被分配的块只有 PERMANENT块和自由列表上的FREE块。如果该进程发现仍有剩余FREEABLE 或RECREATABLE 块存在，则该进程没有正常释放内存。这种情况被认为是空间泄漏。 Oracle通常为SGA堆，UGA堆，Large Pool堆和PGA堆执行内存泄露检查。内存泄漏错误会导致在BACKGROUND_DUMP_DESTINATION或USER_DUMP_DESTINATION中生成跟踪文件。 空格泄漏问题一般会捕获跟踪信息和堆转储。 在alert.log中，该错误会被报告为: Errors in file d:\oracle\admin\testdb\bdump\yourfilenamehere.trc: ORA-00600: internal error code, arguments: [729], [560], [space leak], [], [],…

  如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   本文讨论了内部错误“ORA-600[3020]”，这错误是什么以及针对此错误可能执行的操作。本文档中的信息仅适用于列出的版本，且只用于指导。 错误: 形式: ORA-600 [3020] [a] [b] [c] [d] [e] 版本: 6.0版本及以上 描述: 这就是所谓的“Stuck Recovery“。 redo中存储的信息与被恢复的数据库块中存储的信息不一致。 参数: 对于Oracle 9.2 以及更早版本: Arg [a] Block DBA Arg [b] Redo Thread Arg [c] Redo RBA Seq Arg [d] Redo RBA Block No Arg [e] Redo RBA Offset. 对于Oracle 10.1…