如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]
数据文件被认为是不可恢复的，如果在对象上执行不可恢复操作，该对象自从数据文件的最后一个备份一直在数据文件中，操作会变成不可恢复，如果他们没有在重做日志中记录， 这些阻止重做日志的生成的“不记录”操作，包括:
• 直接加载/SQL加载
• 从插入或合并语句中的直接路径插入结果
• ALTER TABLE命令
• CREATE和ALTER INDEX命令
• INSERT /*+APPEND*/
• 分区处理
• 使用不记录选项明确设置的数据库对象
• 在Oracle metalink 说明: 216211.1中的Oracle电子商务套件并行作业执行。
• 涉及数据库对象处理的Oracle 电子商务套件修补活动
数据库恢复操作看起来完成了，但是数据文件中的不记录对象使用的数据块在恢复时会标记为损坏，访问恢复数据库实例中的那些不记录数据对象将返回一个数据块读取错误，例如，ORA-1578和ORA-26040，数据文件中的逻辑损坏将会使数据库对象在恢复的数据库实例中不再有用。
如何检测不可恢复操作?
不可恢复数据文件是那些自从上次成功备份发生后涉及的不记录操作，有很多方法可以鉴定它们，你可以定位这些数据文件，要么使用RMAN 要么通过查询V$表。
A. 从RMAN提取不可恢复数据文件信息
RMAN> report unrecoverable database; Report of files that need backup due to unrecoverable operations File Type of Backup Required Name ---- ----------------------- ----------------------------------- 14 full or incremental +DGDATA/A1/data file/apps_ts_tx_data.286.662131793 32 full or incremental +DGDATA/A1/data file/apps_ts_tx_data.326.667991737 33 full or incremental +DGDATA/A1/data file/apps_ts_tx_data.327.667991741 … 80 full or incremental +DGDATA/A1/data file/A1_obiee_data.386.682596961 81 full or incremental +DGDATA/A1/data file/A1_obiee_data.387.682596961 82 full or incremental +DGDATA/A1/data file/A1_obiee_data.388.684801365 RMAN> exit
B. 直接从v$表提取不可恢复数据文件信息
SQL> SELECT df.name data file_name, df.unrecoverable_time
FROM v$data file df, v$backup bk
WHERE df.file#=bk.file#
and df.unrecoverable_change#!=0
and df.unrecoverable_time > (select max(end_time) from v$rman_backup_job_details
* where INPUT_TYPE in ('DB FULL' ,'DB INCR'))
DATAFILE_NAME UNRECOVERABLE_TIME
------------------------------------------------------------ -------------------
+DGDATA/A1/data file/apps_ts_tx_data.286.662131793 2010-01-08:00:13:13
+DGDATA/A1/data file/apps_ts_tx_data.326.667991737 2010-01-08:00:13:13
+DGDATA/A1/data file/apps_ts_tx_data.327.667991741 2010-01-08:00:13:10
…
+DGDATA/A1/data file/A1_obiee_data.386.682596961 2010-01-08:06:18:34
+DGDATA/A1/data file/A1_obiee_data.387.682596961 2010-01-08:06:18:34
+DGDATA/A1/data file/A1_obiee_data.388.684801365 2010-01-08:06:18:34
21 rows selected.
哪些数据对象受不可恢复操作影响?
通过使用下列脚本提取对象来定位受这些不可恢复操作影响的数据库对象:
select distinct dbo.owner,dbo.object_name, dbo.object_type, dfs.tablespace_name, dbt.logging table_level_logging, ts.logging tablespace_level_logging from v$segstat ss, dba_tablespaces ts, dba_objects dbo, dba_tables dbt, v$data file df, dba_data_files dfs, v$tablespace vts where ss.statistic_name ='physical writes direct' and dbo.object_id = ss.obj# and vts.ts# = ss.ts# and ts.tablespace_name = vts.name and ss.value != 0 and df.unrecoverable_change# != 0 and dfs.file_name = df.name and ts.tablespace_name = dfs.tablespace_name and dbt.owner = dbo.owner and dbt.table_name = dbo.object_name OWNER OBJECT_NAME OBJECT_TYPE TABLESPACE_NAME TAB TABLESPAC --------------- ------------------------------ ------------------- ---------------- --- --------- APPLSYS WF_LOCAL_ROLES_STAGE TABLE APPS_TS_TX_DATA YES LOGGING APPLSYS WF_LOCAL_USER_ROLES_STAGE TABLE APPS_TS_TX_DATA NO LOGGING APPLSYS WF_UR_ASSIGNMENTS_STAGE TABLE APPS_TS_TX_DATA YES LOGGING APPS DR$IBE_CT_IMEDIA_SEARCH_IM$I TABLE APPS_TS_TX_DATA YES LOGGING MSC MSC_TP_ID_LID TABLE APPS_TS_TX_DATA YES LOGGING MSC MSC_TP_SITE_ID_LID TABLE APPS_TS_TX_DATA YES LOGGING OBIEE_OWNER GL_DETAIL TABLE A1_OBIEE_DATA NO LOGGING OBIEE_OWNER GL_EXPENDITURES TABLE A1_OBIEE_DATA NO LOGGING OBIEE_OWNER A1_DEPARTMENT_DIM TABLE A1_OBIEE_DATA NO LOGGING OBIEE_OWNER A1_FUNCTION_CHANNEL TABLE A1_OBIEE_DATA NO LOGGING OBIEE_OWNER A1_GEOGRAPHY TABLE A1_OBIEE_DATA NO LOGGING OWNER OBJECT_NAME OBJECT_TYPE TABLESPACE_NAME TAB TABLESPAC --------------- ------------------------------ ------------------- ---------------- --- --------- OBIEE_OWNER A1_PRODUCT_CLASS TABLE A1_OBIEE_DATA NO LOGGING 12 rows selected.
因为不记录，直接知道恢复操作中受影响的对象或表可以帮助我们以及数据拥有者做出明智的决定，关于是否需要禁用不记录，基于这些表中数据的交易或分析性质。
如何修复不可恢复数据文件?
迫使这些不记录对象操作在重做日志中捕捉到的一个方法是执行FORCE_LOGGING, 这是在Oracle 9i 中引入的一个功能，这个功能使Oracle在重做中强迫记录即便执行了不记录操作。可以在数据库和表空间级别执行强制记录，在 Oracle ERP 电子商务套件中, EBS的默认安装设置数据库的FORCE_LOGGING选项为NO，该设置开始是为了增加整体的系统性能，如果该设置不改变为YES, 本节提到的所有 “nologging” 操作会阻碍重做日志的生成，和所有的不记录对象一起引起不可恢复操作问题。
在为强制记录改变数据库或表空间之前，评估强制记录比起那些不记录的好处是很重要的，一旦在数据库级别打开强制记录，会为所有的操作生成重做，急剧地增加重做的大小，此外，因为重做日志有其它捕获操作，也将会影响数据插入和更新的性能。
如果已经决定使数据库和表空间处于NO强制记录模式, 不可避免地，生意拥有者和数据库管理员需要一起保证在任何批量活动、直接载入和其它不记录操作发生之前立即采用好的备份，此外，数据库管理员应该周期性地查询数据库以确定数据文件包含不记录活动，不管什么时候，执行数据库备份以保证数据文件恢复完整性，例如，在Oracle ERP 电子商务套件情况下, 这将意味着在任何批量活动之前每次都需要执行数据库备份。
结论
如果确认数据库中有不可恢复数据文件，重要的是，数据库管理员给生意拥有者提供受影响的不可恢复不记录对象以确定这些对象是否有恢复价值，可以完全忽略不记录对象的例子，包括容易由原表生成的表或者只是暂时设计来使用的表。
重要的是，生意拥有者决定是否将数据库或表空间设置为NO强制记录获得的性能抵消了确定的不记录数据库对象的恢复性,应该决定使数据库和表空间处于NO强制记录模式–这使得数据文件不可恢复–数据库管理员和生意拥有者都需要保持警惕以保证通过频繁备份可以实现数据库的可恢复性。
Leave a Reply