Month: October 2014

  • about db_lost_write_protect

    SQL> create table lost_write(t1 int) tablespace users; Table created. SQL> SQL> insert into lost_write values(1); 1 row created. SQL> commit; Commit complete. SQL> alter system checkpoint; System altered. select dbms_rowid.rowid_block_number(rowid),dbms_rowid.rowid_relative_fno(rowid) from lost_write; DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) ———————————— ———————————— 222 6 alter system set db_lost_write_protect=typical; SQL> select name from v$datafile where file#=6; NAME ——————————————————————————– /s01/oradata/PDPROD/datafile/o1_mf_users_b2wgb20l_.dbf update lost_write set…

  • 11g以后的space preallocation特性和SMCO/W00N

    11g以后oracle引入了智能空间预分配space preallocation的新特性,该新特性涉及3个领域: 表空间的预分配和扩展 数据段segment的预分配和扩展 LOB chunk的预分配和扩展   以下是一个tablespace 预分配和扩展的例子,可以看到某个表空间对应的FILE#=3的数据文件,由于在一段时间内的空间使用情况预估,所以在几个小时内扩展了不少的空间:   Sat Oct 04 06:07:46 2014 Resize operation completed for file# 3, old size 706560K, new size 716800K Sat Oct 04 08:00:03 2014 www.askmac.cn Thread 1 advanced to log sequence 60 (LGWR switch) Current log# 2 seq# 60 mem# 0: /s01/oradata/PDPROD/onlinelog/o1_mf_2_b2wgc3rf_.log Current log# 2 seq# 60…

  • 12c RMAN新特性restore/recover from service远程恢复

    12c中提供了基于网络的RMAN Restore和recover功能:   About Restoring Files Over the Network RMAN restores database files, over the network, from a physical standby database by using the FROM SERVICE clause of the RESTORE command. The FROM SERVICE clause provides the service name of the physical standby database from which the files must be restored. During the restore operation,…

  • 为12.1 DataGuard配置DGMGRL遇到ORA-16698

    为12.1.0.2 DataGuard配置DGMGRL时遇到了ORA-16698错误:     BANNER CON_ID —————————————————————————————— ———- Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 – 64bit Production 0 PL/SQL Release 12.1.0.2.0 – Production 0 CORE 12.1.0.2.0 Production 0 TNS for Linux: Version 12.1.0.2.0 – Production 0 NLSRTL Version 12.1.0.2.0 – Production 0 DGMGRL> DGMGRL> [oracle@PD009 ~]$ oerr ora 16698 16698, 0000, “LOG_ARCHIVE_DEST_n parameter set…

  • PRM-DUL成功案例:为某电信运营商恢复了误truncate的一百多张表

    PRM-DUL成功案例:为某电信运营商恢复了误删truncate的一百多张表。东南某电信运营商生产系统数据库部分数据表被误删除的问题,现场工作内容:采用PRM-DUL工具将所需要的共121张表恢复出来。 整个数据库大小在25T左右,由于还原的新环境存储空间有限,还原整个数据库不够现实。初步决定还原方案为先还原SYSTEM和data表空间,然后使用PRM-DUL直接读取数据文件,将数据导出。 实际这个case用户在带库里是由完整备份和归档的,但是实际情况所制约没有那么多空间和时间去从备份里恢复数据了,如果真的那么做,可能至少需要几天时间,而实际恢复业务要求在1天内。所幸的是业务对这些表的完整性要求不高,而且从后期来看在truncate后插入数据的量很少,所以这个case在协商后使用了PRM-DUL成功scan database字典模式下恢复truncate功能来恢复了。   最新版PRM-DUL下载地址: http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip 免费的PRM-DUL License :http://www.parnassusdata.com/zh-hans/node/122 

  • PRM-DUL成功案例:恢复了700GB损坏严重的Oracle数据库

    PRM-DUL成功案例:恢复了700GB损坏严重的Oracle数据库。 某中原企业存储断电重启后发现其700GB大小的数据库,存在十几万个坏块,数据库无法正常打开使用。   用户自行尝试采用ORACLE DUL做恢复,但是由于ORACLE DUL对于该超过500万个col$记录的数据字典出现DC_COLUMNS过大导致的coredump segmentfault,导致ORACLE DUL无法正常使用。   该场景中数据块的损坏模式主要是fracture断裂。诗檀软件工程师Biot.wang 通过修改checksum+ tailchk , tailchk=低2位的bas_kcbh+type_kcbh+seq_kcbh,伪装了大部分数据块为可用。此场景中之后exp可以导出大部分数据,但是由于数据字典严重损毁,所以可能出现表上字段混乱或者缺失数据等问题, 大部分情况可以用PRM-DUL的非字典模式(NON-DICT)来解决。   在这个案例中由于用户的表和索引过多,导致数据字典异常庞大,ORACLE原厂的DUL在加载数据字典时由于其内存分配方式直接导致出现了coredump segmentfault,而COL$.DAT又过大了,很难处理分片。   在这个问题上PRM-DUL由于采用了内置一个derby数据库,所以即便数据字典再大也不会有问题,而且内置数据库中的数据也做了索引,这保证了PRM-DUL能迅速处理字典操作。 另由于此例子中需要恢复的数据表实在太多,达到了几十万张,所以充分利用了PRM-DUL的schema-level Databridge功能。 仅仅花了2天时间就基本处理完这个case了。   最新版PRM-DUL下载地址: http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip 免费的PRM-DUL License :http://www.parnassusdata.com/zh-hans/node/122 

  • 诗檀软件成功为某西南大型企业从不完整的备份中恢复了数据

    诗檀软件成功为某西南大型国企从不完整的备份中恢复了数据; 某西南大型企业数据库的ASM因为加盘意外损坏,用户自行重建ASM DISKGROUP并restore了热备份,由于丢失了归档,数据库无法打开。 诗檀软件工程师biot.wang 通过特殊恢复方案打开了该并不一致的数据库备份,大致经过为:手动修改bootstrap对象 ,commit事务;修改datafile header绕过已经不存在的archivelog,之后打开数据库exp导出数据并重建数据库。但是由于丢失部分redo,导致部分表exp时出现了ORA-600错误,这部分表通过PRM-DUL工具的DataBridge特性来特殊恢复了。   最新版PRM-DUL下载地址: http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip 免费的PRM-DUL License :http://www.parnassusdata.com/zh-hans/node/122 

  • 诗檀软件成功为某电力企业恢复大量坏块的核心数据库

    诗檀软件成功为某电力企业恢复大量坏块的核心数据库,某东北电力企业的核心数据库在存储意外断电后出现大量FRACTURED块断裂损坏,且数据库无任何形式备份。   SQL> select * from v$database_block_corruption; FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO ———- ———- ———- —————— ——— 1 3119 1 0 FRACTURED 1 142239 1 0 FRACTURED 1 11567 1 0 FRACTURED 1 79919 1 0 FRACTURED 1 87535 1 0 FRACTURED 1 88447 1 0 FRACTURED 1 89871 1 0 FRACTURED 1 89999 1…