ORACLE: 什么是不可恢复的数据文件?

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638    QQ号:47079569    邮箱:service@parnassusdata.com

数据文件被认为是不可恢复的,如果在对象上执行不可恢复操作,该对象自从数据文件的最后一个备份一直在数据文件中,操作会变成不可恢复,如果他们没有在重做日志中记录, 这些阻止重做日志的生成的“不记录”操作,包括:
• 直接加载/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强制记录模式–这使得数据文件不可恢复–数据库管理员和生意拥有者都需要保持警惕以保证通过频繁备份可以实现数据库的可恢复性。

 

关注刘相兵的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

Speak Your Mind

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569