Author: mac

SELECT * FROM table( DBMS_SPACE.OBJECT_GROWTH_TREND ( object_owner =>’SYS’, object_name =>’SIZET’, object_type =>’TABLE’, start_time =>NULL, end_time =>NULL, interval =>to_dsinterval(‘180 00:00:00’) , skip_interpolated => ‘TRUE’, timeout_seconds =>NULL, single_datapoint_flag =>’TRUE’) ) order by 1 /     SQL> SELECT * 2 FROM 3 table( 4 DBMS_SPACE.OBJECT_GROWTH_TREND ( 5 object_owner =>’BILLING’, 6 object_name =>’TBL_BACKUPSMTPFAX’, 7 object_type =>’TABLE’, 8 start_time…

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected] 目的 本文档解释了一些从有错误的数据库中从表中被drop数据的一些方法。   范围 & 应用 管理用户；要求访问Export dump 文件，Archivelogs 或SQL*Loader batch文件。   相关文档 参见Oracle Server Administration Guide获取如何执行基于时间恢复的方法。     如何从被drop表中恢复数据： =========================================   如果当前有表的EXPORT刚执行了一个该表的IMPORT。 则重建从EXPORT起添加的数据。   如果当前没有EXPORT，那么问题就变得有点复杂。   一定会有一些问题： – 表是否通过一个像SQL*Loader的批量加载填充？   – 自从可以简易重新手动输入加载，是否有对表的任何更改？   如果这些问题的答案是肯定的，则重新加载并重新输入数据。   如果这些问题的答案是否定的，则考虑以下：   – 最近是否有数据库的好的备份？   – 数据库是否在归档日志模式？如果没有且没有当前的表EXPORT，则唯一资源是从最近冷备份还原。这会导致从备份创建起数据库中所有数据的丢失。   如果数据库在ARCHIVELOG 模式，则：   –…

过去几天我使用了PRM-DUL软件(http://www.parnassusdata.com/)来恢复客户糟糕的oracle数据库。 其中一个用户的基于raid-5的存储阵列经历了十分严重的磁盘损坏，虽然有备份，但那备份作业从来没测试通过过。在恢复oracle数据库的过程中遇到了多起undo损坏的疑难问题，而且是发生在system表空间的system系统回滚段身上。剩下的只有10个月前的备份可用了。 我和另外一个工程师尝试从这个损坏的存储系统里恢复2个ORACLE数据库。针对其中一个数据库，PRM-DUL 可以读取它的system表空间上的数据字典，显然虽然undo有严重损坏，但数据字典本身ok。另一个数据库的system表空间有一些损坏，我们有尝试用PRM-DUL的字典模式dictionary-mode，后来转而使用非字典模式了。 由于有10个月前的一些rman备份，所以我们也可以基于10月前的system数据文件来重建数据字典。  但这个10月前的数据字典还是会有一些问题的， 最后还是不得不用非字典模式来处理，这意味着我们需要猜例如表的名字、列字段名和列字段类型这些基础信息。如果用户没法提供一个熟悉业务的人员的话，纯oracle数据库技术人员干这个绝对是力气活，因为如果有几百张表 ，每张表十几个字段，你可以想象一下这样做的工作量是多大的。   不幸的是我们并没有能100%恢复数据，虽然也差不离。 对于有数据字典的情况可以基于TAB$的NUM_ROWS去了解每张表大致的行数，这样我们就能知道大约丢失了多少行数据。   照理说 PRM-DUL 应当能恢复所有数据，但在这个case中部分数据文件中的block显然被物理上毁灭了。所以我们还是要强调，不仅要备份，还要定期测试你的备份。    

哪些数据维护操作，无法通过logminer捕获到更新前后的各项字段值？即使已经打开了supplemental log（database级别或table级别）。 据了解，对于使用direct path方式的sqlldr操作插入的数据，logminer无法捕获到插入的各项字段值。除此之外，还有哪些数据维护操作（包括增删改）无法通过logminer捕获到？例如data pump import？ . Note 291686.1 : LogMiner Utility Release 8i – 11g 6. Restrictions in 10.x Support for LOB and LONG datatypes in redo log files is available only for redo log files generated on a release 9.2 or later Oracle database. LogMiner does not support these datatypes and table storage…

根据2016-March-22 : http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf       每个named user plus的价格是 460美元， 每个处理器的价格是23000美元。

以下是Database 12c的OCM OCP认证的 认证路径：   12c OCP:  

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   1. 介绍 2. 测试平台 3. 示例   3.1. 从完整冷备份中完全还原数据库   3.2. 仅从完整冷备份中还原数据文件（当前控制文件可用）   3.3. 从完整（热或冷）备份中还原数据文件并完全恢复   3.4. 从完整（热或冷）备份中还原数据文件的一个子集并完全恢复   3.5. 从（热或冷）备份中还原数据文件和控制文件并完全恢复   3.6. 从（热或冷）备份中还原数据文件和控制文件并完全恢复。备份控制文件时，一个数据文件被添加。   3.7. 从（热或冷）备份中还原数据文件，当前控制文件可用，并不完全恢复   3.8. 从（热或冷）备份中还原数据文件和控制文件，并不完全恢复   3.9. 还原数据库的一个子集（在还原和恢复时跳过表空间）。当前控制文件和重做日志可用。   3.10. 将文件还原到新位置 1. 介绍   本文探讨Oracle7的恢复方案，并解释如何使用RMAN在类似情况恢复数据库。本文比较Oracle7的使用与RMAN常见恢复方案。 需要注意的术语。一个Oracle7冷备份相当于Oracle 8i/9i中的（RMAN）脱机（关闭）备份。一个Oracle7热备份相当于Oracle 8i/9（RMAN）联机（打开）备份。 本文中的例子并不详尽；仅仅是常见的还原和恢复方案。你始终应该在生产环境中实施之前，测试所有备份和恢复过程。 2. 测试平台  …

某用户10.2.0.4 ASM损坏 diskgroup mount时出现大量ORA-00600报错，该案例最终通过使用PRM-DUL工具成功恢复数据库。 PRM-DUL 下载地址:http://zcdn.parnassusdata.com/DUL5108.zip

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]     适用于： Oracle Database – Enterprise Edition – 版本11.2.0.1 及以上 本文信息适用于任何平台。   目的 使用TSPITR恢复被drop表空间。   范围 RMAN自动Tablespace Point-In-Time Recovery ( TSPITR)使你能快速恢复在Oracle数据库中一个或多个表空间到较早的时间，而不影响数据库中的其他表空间和其他对象的状态。 在11.2版本之前，TSPITR有无法恢复被drop表空间的限制。 从11.2起不再有该限制。我们可以使用TSPITR恢复被drop表空间。 以下示例显示TSPITR恢复被drop表空间的步骤和功能。   详情 示例: 1) 创建一个表空间。   SQL> create tablespace users datafile ‘D:\DATABASES\ORA11G\users01.dbf’ size 10m reuse; SQL> select tablespace_name from dba_tablespaces; TABLESPACE_NAME —————————— SYSTEM…

  如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]   适用于： Oracle Database – Enterprise Edition – 版本 8.1.7.0到 11.1.0.8 [Release 8.1.7 到 11.1] 本文信息适用于任何平台。 目标 如何使用RMAN从被drop的表空间中恢复？ 解决方案 RMAN duplicate命令无法用于一个被drop 表空间，因为被duplicate访问的当前目标控制文件不会有与被drop表空间相关的数据文件的信息。 同样在Oracle 11g 发行版本 2之前，你无法使用Tablespace Point In Time Recovery (TSPITR)来恢复被drop的表空间。 要在Oracle 11g 发行版本 2 及以上版本中恢复被drop表空间，参见 Note 1277795.1。 因此，基于你对现有数据库的要求，有两个选择： 1. 还原整个数据库并恢复到表空间被drop之前。 这会导致在数据库中的所有数据，不仅是表空间回到过去时间。 2. 将目标数据库克隆到新位置，执行时间点恢复导出表空间数据，导入原始数据库。这导致该表空间的数据被导入回生产数据库，不影响数据库其他区域的现有（当前）数据。 选项#1:  还原目标数据库并恢复到表空间被drop之前： ————— 1.…