Author: mac

PRM-DUL ORACLE 数据恢复软件总贴PRM-DUL 是一个基于JAVA语言编写的DUL类软件，其引入了图形化界面GUI和DataBridge特性。 全程GUI使得用户无需大量时间去学习命令行操作，直接可操作PRM-DUL从受损的ORACLE数据库中抽取数据。 DataBridge特性让抽取到的受损数据库的数据可以直接导入到目标库中，像DBLINK一样简单，而不需要使用sqlldr 或者 exp/imp来操作。PRM-DUL目前有2个版本： 社区版： 在完全免费的社区版中，数据抽取和数据搭桥的行数限制是一万行。ASM文件克隆功能在社区版中全面可用。企业版： 购买企业版意味在一套数据库(一个license对应一套数据库)内完全使用PRM的所有功能，没有任何限制购买PRM-DUL，请联系我们：国内热线号码： 13764045638      备用电话：13764045638 ORACLE技术专家服务邮箱：　[email protected] PRM-DUL 最新版本下载地址： https://zcdn.parnassusdata.com/DUL5108.zip   PRM-DUL 中文版用户手册： http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database用户手册%20v0.3.pdf PRM-DUL For Oracle Database中文介绍： http://www.parnassusdata.com/sites/default/files/PRM%20–%20PARNASSUSDATA%20RECOVERY%20MANAGER%20For%20Oracle%20Database介绍手册.pdf PRM-DUL FOr Oracle Database 英文版使用手册： Oracle PRM-DUL User Guide V0.3 PRM-DUL成功案例： PRM-DUL成功案例：帮助北京某政府机构恢复硬盘损坏的Windows服务器上的oracle数据库 PRM-DUL成功案例:帮助华东某银行恢复被truncate掉的表 PRM-DUL成功案例：为东北某企业恢复了10多T的Oracle数据 PRM-DUL成功助力安徽某乙方恢复了用户数据库 PRM-DUL成功案例之一：恢复ORA-600[25027]错误的多张千万行级别的表 PRM-DUL成功案例：为某电信运营商恢复了误truncate的一百多张表 PRM-DUL成功案例：恢复了700GB损坏严重的Oracle数据库 诗檀软件成功使用PRM为某西南电信运行商恢复多张千万级别表 PRM-DUL成功案例：成功为某券商机构从受损的ASM Diskgroup中恢复出数据文件和归档日志 PRM-DUL成功帮助某移动厂商恢复被DROP掉的业务核心表 PRM-DUL成功案例：成功为中原某客户从断电损坏严重的数据库中恢复出十多万张表 Oracle PRM-DUL成功帮助安徽某政府机关恢复数据   PRM ORACLE数据恢复视频教学：…

D 公司的DBA由于误操作删除了TS$数据字典基表导致数据库无法启动   Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options     INSTANCE_NAME —————- ASMME   SQL> SQL> SQL> select count(*) from sys.ts$;   COUNT(*) ———- 5   SQL> delete ts$;   5 rows deleted.   SQL> commit;…

在我以前的文章中，我解释了它如何在某些特定情况下，从一个完整备份恢复单个表，以节省时间，使恢复过程更简单。现在的情况更糟糕，因为我们没有备份或备份恢复过程不起作用。我如何恢复已删除的行？ 我们将根据之前帖子中相同的例子，所以我们需要从表“salaries”中删除员工10008的记录。“意外”删除行之后，你应该停止MySQL，获取salaries.ibd的副本，并再次启动它。稍后，我们将从ibd文件提取这些被删除的行，并导入到数据库中。删除行和数据库停止之间的时间是至关重要的。如果页被重用，你无法恢复数据。 我要通过四个步骤解释全过程，以便更清晰明了：     从表空间提取所有InnoDB页：   首先我们需要下载Percona数据恢复工具并使用“make”命令编译所有工具。在本例中，我要在/root/recovery-tool文件夹安装工具，数据如表空间和被恢复行在/root/recovery-tool/data。 编译后，我们需要将salaries.ibd表空间复制到恢复工具的数据目录。为了提取的所有页，我们将使用page_parser工具。该工具会找到并将表空间的所有页提取到输出目录。我们只需要指定行格式（-5），以及表空间位置（-f） The row format can be -4 (REDUNDANT) or -5 (COMPACT). From 5.0.3 the default format is COMPACT. More information about row format on the following link: 行格式可以是-4（冗余）或-5（COMPACT）。从5.0.3起，默认格式是COMPACT。       你也能从Information Schema获取表行格式：     mysql (information_schema) > SELECT ROW_FORMAT from TABLES WHERE TABLE_SCHEMA=’employees’    AND TABLE_NAME=’salaries’;…

    c_parser 是工具包中的一个命令行工具，它能读取 InnoDB 页面并从中获取记录。虽然它可以扫描任何字节流，但恢复质量比你将属于表的PRIMARY索引的页面提供给 c_parser 更高。所有InnoDB索引有自己的标识符，又名index_id。InnoDB字典储存表名和index_id之间的对应关系。这是第一个原因。 另一个原因是InnoDB字典能恢复表结构。当一个表被删除，MySQL删除相应的.frm文件。如果你既没有备份，又没有表schema，恢复该表结构就有相当大的困难。这个话题需要我哪天再写一篇单独的文章来讲。 假设你对以上足够确信，我们就能继续InnoDB字典的恢复了。   拆分 ibdata1 InnoDB 字段储存在 ibdata1中，所以我们需要分析它并获取存放字典记录的页面。使用 stream_parser 。     # ./stream_parser -f /var/lib/mysql/ibdata1 … Size to process: 79691776 (76.000 MiB) All workers finished in 1 sec stream_parser 找出在ibdata1 中的InnoDB 页面，将它们以页面类型(FIL_PAGE_INDEX 或FIL_PAGE_TYPE_BLOB) ， index_id.的顺序储存。 索引如下：       SYS_TABLES [root@twindb-dev undrop-for-innodb]# ll pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page -rw-r–r– 1 root root 16384 Jun 24 00:50 pages-ibdata1/FIL_PAGE_INDEX/0000000000000001.page SYS_INDEXES…

人为错误是不可避免的。错误的 “DROP DATABASE” 或 “DROP TABLE” 可能会破坏MySQL 服务器上的重要数据。备份是有帮助的，但不总是可用。这种情况是可怕的，但不至于没有希望的。在许多情况下，恢复几乎所有在数据库或表中的数据是有可能的。 我们来看看如何能做到这一点。恢复计划取决于InnoDB将所有数据储存在单个ibdata1还是每个表都有自己的表空间。在这篇文章中，我们考虑innodb_file_per_table= OFF的情况下。此参数假定所有表都保存在一个公共文件中，通常位于位于/var/lib/mysql/ibdata1。   错误操作 – 表删除 在这个情况下，我们使用测试数据库sakila 以及附带的工具。 假设我们错误删除了表actor：   mysql> SELECT * FROM actor LIMIT 10; +———-+————+————–+———————+ | actor_id | first_name | last_name | last_update | +———-+————+————–+———————+ | 1 | PENELOPE | GUINESS | 2006-02-15 04:34:33 | | 2 | NICK | WAHLBERG | 2006-02-15 04:34:33…

我们介绍了在innodb_file_per_table 设为OFF，意外删除了表时，使用恢复工具包进行恢复的情况。 在这篇文章中，我们将展示在innodb_file_per_table 开启的情况下如何恢复 MySQL 表或数据库。假设mysql 服务器的设置为innodb_file_per_table=ON，这个参数告诉InnoDB 将用户表储存在单独的数据文件中。 在恢复测试中我们使用与之前文章中相同的数据库sakila。     root@test:/var/lib/mysql/sakila# ll total 23468 drwx—— 2 mysql mysql 4096 Jul 15 04:26 ./ drwx—— 6 mysql mysql 4096 Jul 15 04:26 ../ -rw-rw—- 1 mysql mysql 8694 Jul 15 04:26 actor.frm -rw-rw—- 1 mysql mysql 114688 Jul 15 04:26 actor.ibd -rw-rw—- 1 mysql mysql 2871 Jul…

D公司的SA系统管理员误删除了某数据库的SYSTEM表空间所在数据文件，这导致数据库完全无法打开，数据无法取出。 在没有备份的情况下，可以使用PRM恢复接近100%的数据。   此场景中启动PRM后，进入Recovery Wizard后 选择《Non-Dictionary mode》非字典模式:       No-dictionary模式下需要用户指定 字符集和国家字符集，这是因为丢失了SYSTEM表空间后，数据库的字符集信息无法正常获得，所以需要用户的输入。 只有输入正确的字符集设置以及安装了必要的语言包才能保证No-Dictionary模式下正常抽取多国语言。     与场景演示1类似，输入用户目前可得的所有数据文件(不包括临时文件)，并设置正确的Block Size和OFFSET:     之后点击SCAN，SCAN的作用是扫描所有数据文件上的Segment Header，并记录到SEG$.DAT和EXT$.DAT中；在ORACLE中一个非分区表或者一个分区表的分区都对应着一个SEGMENT HEADER数据段头，只要能找到SEGMENT HEADER就可以获得整个表数据段的盘区EXTENT MAP 信息，通过EXTENT MAP可以获得该表上的全部记录。   通常存在这样一种情况，例如一张非分区的单表存放在某个由2个数据文件组成的表空间上，其SEGMENT HEADER以及一半的数据存放在A数据文件上，另一半数据存放在B数据文件上。但是由于某些原因，SYSTEM表空间和存放有SEGMENT HEADER的A数据文件均丢失了，只剩下B数据文件了，此时若希望仅仅恢复B数据文件上该表的数据，则不能依赖于SEGMENT HEADER，而只能依赖于从B数据文件上扫描盘区图EXTENT MAP信息了。   为了同时满足 基于SEGMENT HEADER和EXTENT MAP数据的NO-Dictionary模式恢复需要，所以SCAN操作在这里会填充SEG$.DAT和EXT$.DAT2个文件(文本文件仅仅为了便于诊断，所有程序实际依赖于PRM自带嵌入数据库DERBY的数据)，并记录到DERBY数据库中。     完成SCAN 后，主界面左侧出现数据库图标。   此时可以选择2种模式：   Scan Tables From Segments，此模式适用于 丢失了SYSTEM表空间，但是所有的应用数据表空间均存在 Scan Tables From Extents 不适用于Dictionary模式的Truncate表数据恢复 丢失了SYSTEM表空间，而且丢失了SEGMENT…

D公司的SA由于误操作将在线业务数据库的SYSTEM表空间上的数据文件，以及部分应用表空间数据文件意外删除了。   此场景中由于部分应用表空间数据文件被删除了，这其中可能包括含有数据表的SEGMENT HEADER的数据文件，所以使用Scan Tables From Segment Header可能不如使用Scan Tables From Extents来的合适。   其简要步骤如下：   进入Recovery Wizard ，选择No-Dictionary模，加入所有可用的数据文件，执行Scan Database 选中数据库，并右键Scan Tables From Extents 对于PRM主界面上生成的对象树形图中的数据进行分析和导出/数据搭桥 其余操作与恢复场景4中一样  

SCALABLE LGWR是12cR1中引入的一个令人激动的特性， 这是由于在OLTP环境中LGWR写日志往往成为系统的主要性能瓶颈， 如果LGWR进程能像DBWR(DBW0~DBWn)那样多进程写出redo到LOGFILE那么就可能大幅释放OLTP的并发能力，增长Transcation系统的单位时间事务处理能力。   在12cR1 中真正用SCALABLE LGWR实现了这个目的， 也可以俗称为多LGWR进程。     select * from opt_12cR1 where name like ‘%log%’ _use_single_log_writer ADAPTIVE Use a single process for redo log writing _max_outstanding_log_writes 2 Maximum number of outstanding redo log writes   SCALABLE LGWR主要受到隐藏参数_use_single_log_writer的控制，  该参数默认值为ADAPTIVE 。   该参数主要有三个可选值 true， false， adaptive， 默认值为ADAPTIVE。 对于ADAPTIVE 和False 如果CPU个数大于一个则会有多个lg0n进程 对于true 则不会生成多个lg0n进程，而如同12.1之前那样仅有单个LGWR    …

An ORA-1578 on startup is usually bad news and relates to either a corrupt rollback segment header, or a corrupt block being referenced during bootstraping of the instance. eg: Database mounted. ORA-01578: ORACLE data block corrupted (file # 11, block # 2) ORA-01110: data file 1198: ‘/tmp/RPrbcor.dbf’ SVRMGR> ( Recovery does not fail if a…