Ask Maclean

Maclean’s Oracle Database Tech Blog Archives

  • 【Oracle数据恢复】ORA-00704: 引导程序进程失败 ORA-39700: 必须用 UPGRADE 选项打开数据库错误解析一例

    如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638    QQ号:47079569    邮箱：[email protected] $ oerr ora 704 00704, 00000, “bootstrap process failure” // *Cause: Failure in processing bootstrap data – see accompanying error. // *Action: Contact your customer support representative. $ oerr ora 39700 39700, 00000, “database must be opened with UPGRADE option” // *Cause: A normal database open…

  • enq: TA – contention 等待事件

    enq: TA – contention 等待事件   This enqueue is used when undo tablespace operations are being performed. Some examples of such operations are: When dropping an undo tablespace we acquire the enqueue in exclsuive mode to stop other sessions using the undo tablespace at that point. If we cannot acquire the enqueue because the undo…

  • latch: undo global data Oracle等待

    latch: undo global data Oracle等待: This latch is taken out when we need to search or manipulate the array of rollback (undo) segments used by the instance (this is pointed to by the fixed SGA variable “ktugd” of type “struct ktugt”). We need to search / manipulate the array to locate the rollback segment for…

  • 诗檀软件成功为某汽车企业恢复Oracle数据库中超过2亿行数据

    诗檀软件成功为某汽车企业恢复Oracle数据库中超过2亿行数据。 该数据库由于误操作导致大量DROP 业务表，超过300张业务表被意外DROP，诗檀软件通过自主研发的PRM-DUL工具成功恢复超过2亿行数据。                   如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected] ORACLE PRM是诗檀软件独立研发的ORACLE数据库灾难恢复软件，其具有全程图形化界面、简单高效等特点。 欢迎下载使用ORACLE PRM。 下载地址：http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip PRM用户使用手册。http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C%20v0.3.pdf  

  • 【Oracle数据恢复】数据块损坏/坏块诊断

    如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638   QQ号:47079569    邮箱：[email protected]   在ORACLE中形成 数据块损坏/坏块诊断corruption多种多样，但其症状大致为如下几种： ORA-01578错误 ORA-600[61xx]错误 ORA-600[3339]或者ORA-600[3398] ORA-600[2130],ORA-600[2845],ORA-600[4147]错误等等 SELECT 查询出讹误的数据   应当该类ORACLE数据块损坏/坏块诊断的问题 有这么几个三板斧的步骤： 1、如果数据库仍然是打开状态，则需要判断该块损坏/坏块所在的 数据文件号、块号 并定位到具体的对象(可能是表或者索引)。 结合ORA-1578错误或者ORA-600报出的变量信息，采取如下SQL来定位   SELECT tablespace_name, segment_type, owner, segment_name FROM dba_extents WHERE file_id = &fileid and &blockid between block_id AND block_id + blocks – 1;   2、取决于上一步获得的SEGMENT_TYPE， 如果是以下的SEGMENT_TYPE是可以重建的： index 数据可以重新获得的表，或者可以重建的表 回滚段，除了SYSTEM这个回滚段 排序段 , sort…

  • 【Oracle性能优化】从10.2.0.5升级到11.2出现LOG FILE SYNCS等待事件显著增长的性能问题

    如果 你遇到从10.2.0.5升级到11.2出现LOG FILE SYNCS等待事件显著增长的性能问题，那么有必要读一下这篇文章了。   在以往的经验中如果遇到这种场景 ，那么 优先考虑设置 “_use_adaptive_log_file_sync”=false, adaptive log file sync是 11.2中提出的一个优化重做日志写的新特性， 在11.2.0.3以后默认为TRUE。 有客户在将”_use_adaptive_log_file_sync”=false后，log file sync等待事件的平均等待时间从10ms 下降到 1~2ms的案例。   _use_adaptive_log_file_sync造成性能下降的原因可能是其导致LGWR使用了polling 方式来取代 post/wait，并且polling的间隔是10ms，这个间隔是在代码里写死的。   此外如果使用了Veritas/symantec 的ODM的话也需要特别注意：你可能遇到了Bug 13551402  High “log file parallel write” and “log file sync” after upgrading 11.2 with Veritas/Symantec ODM，这个BUG已经确认在11.2.0.3和11.2.0.2上存在。 对于该bug的内部讨论最后确认是由于 11.2中lgwr的 IO使用了一种批量同步I/O接口，导致当配合Veritas/symantec 的ODM一起使用时会导致性能下降。 目前该BUG已经在多个Unix/Linux平台上提供补丁：        

  • 【Oracle数据恢复】ORA-00600[4000]错误解析

      如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   ORA-00600[4000]是Oracle 内核事务undo模块的一个内部报错信息，一般来说ORA-00600[4000]错误会附带一个argument ， 该arg[a]表示Undo segment number USN。 早期版本中当使用表空间传输且对传输后的表有DML时可能因为BUG而引起该错误，可以参考文档1371820.8。 到9i以上如果遇到该ORA-00600[4000]错误，则一般是 存储/OS等断电或者故障导致Oracle的undo segment的损坏， 常见于没有正常关闭实例 之后打开数据的场景中。 以下是ORA-00600[4000]的BUG 列表：   NB Bug Fixed Description 16761566 11.2.0.4, 12.1.0.2, 12.2.0.0 Instance fails to start with ORA-600 [4000] [usn#] 13910190 11.2.0.3.BP15, 11.2.0.4, 12.1.0.1 ORA-600 [4000] from plugged in tablespace in Exadata 14741727 11.2.0.2.9,…

  • 【Oracle备份】RMAN备份如何备份完不删除归档并不重复备份归档日志

    11.2.0.3数据库环境，使用rman进行归档日志备份，想实现： （1）每天备份归档日志，备份完并不删除归档日志 （2）归档日志备份成功一次之后，下次再备份的时候rman就自动不会再次备份这个归档日志   这个需求可以通过 backup archivelog all not backed up; 语法来实现。 使用该命令如果遇到 满足 not backed up xx times 的归档才会备份，否则即便该归档仍在DISK上未被删除 也不会重复备份， 避免了重复备份带来的问题，也无需每次备份均删除磁盘上的归档文件。   RMAN> backup archivelog all not backed up; Starting backup at 30-NOV-13 current log archived using channel ORA_DISK_1 channel ORA_DISK_1: starting archive log backupset channel ORA_DISK_1: specifying archive log(s) in backup set input…

  • 【Oracle database 12c】12c官方Note信息汇总

    【Oracle database 12c】12c官方Note信息汇总：   DB 12.1 Information Centers Master Note For Oracle Database 12c Release 1 (12.1) Database/Client Installation/Upgrade/Migration Standalone Environment (Non-RAC) [Document 1520299.1] Master Note for the Oracle Multitenant Option [Document 1519699.1] Master Note for Oracle Data Mining 12c [Document 1523136.1]       DB 12.1 knowledge documents created in last 60 days After…

  • 新しいディスクへ交換したあとASMインスタンスでORA-15196が発生することがある(KROWN:167540)

    [起こりうる現象] Exadata環境でディスク障害が発生し、そのディスクの交換を行ったあと、ASM インスタンスの XDWK プロセスで ORA-15196 が発生することがあります。 ASMインスタンスのアラートログの例: ———————————————————————————- Wed Jan 01 00:00:00 2014 Errors in file /u01/app/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_xdwk_1111.trc: ORA-15196: invalid ASM block header [kxdam.c:7032] [endian_kfbh] [0] [0] [0 != 1] Errors in file /u01/app/oracle/diag/asm/+asm/+ASM1/trace/+ASM1_xdwk_1111.trc: SQL> /* Exadata Auto Mgmt: ADD ASM Disk in given FAILGROUP */ alter diskgroup DATA add failgroup CEL11 disk ‘o/192.168.0.111/DATA_CD_11_CEL11’ name…