rman FUZZINESS SCN X$KCVFH

已于 2023-08-30 19:32:22 修改
阅读量156 收藏
点赞数
文章标签： 数据库
于 2023-08-30 15:49:37 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/jnrjian/article/details/132584156
版权

In Multi-tenant Database (Version 12.1.0.1.2)


(1)  Restore Database Preview reports  'RMAN-05119: recovery can not be done to a consistent state' although we have level 0/Full Database backup along with archivelogs backup to clear the Fuzziness

{ Output Truncated }
RMAN>
run {
ALLOCATE CHANNEL CH1 DEVICE TYPE sbt_tape parms 'SBT_LIBRARY=/u01/app/oracle/product/12.1.0/dbhome_1/lib/libopc.so,
ENV=(OPC_PFILE=/u01/app/oracle/product/12.1.0/dbhome_1/dbs/opcConfig.ora)';
restore database preview;  }

allocated channel: CH1
channel CH1: SID=249 device type=SBT_TAPE
channel CH1: Oracle Database Backup Service Library VER=3.16.9.21

Starting restore at 14-FEB-17
Starting restore at 14-FEB-17

List of Backup Sets
==================

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
20 Full 549.75M SBT_TAPE 06:37:35 13-FEB-17
BP Key: 20 Status: AVAILABLE Compressed: NO Tag: TAG20170212T201557
..
..

new media label is "<label>" for piece "<piece name>"
validation succeeded for backup piece
RMAN-05119: recovery can not be done to a consistent state.                                                                      <<<<<<<<<<<<<<<<<<<
Media recovery start SCN is 2819679
Recovery must be done beyond SCN 2836475 to clear datafile fuzziness
new media label is "<label>" for piece "<piece name>"
..
new media label is "<label>" for piece "<piece name>"
validation succeeded for backup piece
Finished restore at 14-FEB-17
released channel: CH1

(2)  Recover Database also errors out 'RMAN-06054: media recovery requesting unknown archived log for... starting SCN of xxxxx" during recovery

RMAN> recover database ;
allocated channel: CH1
channel CH1: SID=249 device type=SBT_TAPE
channel CH1: Oracle Database Backup Service Library VER=3.16.9.21

Starting recover at 14-FEB-17

starting media recovery
..
..

channel CH1: restored backup piece 1
channel CH1: restore complete, elapsed time: 00:00:01
archived log file name=<path>/arch/1_51_931000987.arc thread=1 sequence=51
unable to find archived log
archived log thread=1 sequence=52
released channel: CH1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/14/2017 09:49:47
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence n and starting SCN of xxxxx               <<<<<<<<<<<<<

RMAN>

CHANGES

Database upgraded to 12.1.0.1.2 and valid full database with archivelogs backup exists.

CAUSE

BUG 20315311:  RMAN-5119: RECOVERY CAN NOT BE DONE TO A CONSISTENT STATE  (Refer Note: 20315311.8)

SOLUTION

Error seems to be a wrong notification which misleads the recovery process.  Ignore the error (or apply the patch 20315311) and proceed with the 'alter database open' after the recover database.   

Sample output of the errors 

Assuming you have valid backup of database and archivelogs, Oracle recommends validating the integrity of the backup by running 'restore database preview'.

Due to a code defect, 'restore database preview' command returns the error RMAN-05119 although valid backups exist. 
 

For example:

RMAN>
run {
ALLOCATE CHANNEL CH1 DEVICE TYPE sbt_tape parms 'SBT_LIBRARY=/u01/app/oracle/product/12.1.0/dbhome_1/lib/libopc.so,
ENV=(OPC_PFILE=/u01/app/oracle/product/12.1.0/dbhome_1/dbs/opcConfig.ora)';
restore database preview;}

allocated channel: CH1
channel CH1: SID=249 device type=SBT_TAPE
channel CH1: Oracle Database Backup Service Library VER=3.16.9.21

Starting restore at 14-FEB-17
Starting restore at 14-FEB-17

List of Backup Sets
==================

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
20 Full 549.75M SBT_TAPE 06:37:35 13-FEB-17
BP Key: 20 Status: AVAILABLE Compressed: NO Tag: TAG20170212T201557
Handle: <piece name> Media: <name>
List of Datafiles in backup set 20
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 2819679 12-FEB-17 <path>/data/cdb/system01.dbf

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
21 Full 168.25M SBT_TAPE 01:25:44 13-FEB-17
BP Key: 21 Status: AVAILABLE Compressed: NO Tag: TAG20170212T201557
Handle: <piece name> Media: <name>
List of Datafiles in backup set 21
Container ID: 2, PDB Name: PDB$SEED
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
2 Full 1963812 24-OCT-14 <path>/data/pdb/SYSTEM01.DBF

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
9 Full 340.25M SBT_TAPE 02:23:30 12-FEB-17
BP Key: 9 Status: AVAILABLE Compressed: NO Tag: TAG20170212T201557
Handle: <piece name> Media: <name>
List of Datafiles in backup set 9
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
3 Full 2819680 12-FEB-17 <path>/data/cdb/sysaux01.dbf
...
...
....

{ Output Truncated }

...
...

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
17 Full 1.50M SBT_TAPE 00:00:36 13-FEB-17
BP Key: 17 Status: AVAILABLE Compressed: NO Tag: TAG20170212T201557
Handle: <piece name> Media: <name>
List of Datafiles in backup set 17
Container ID: 4, PDB Name: PDB2
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
15 Full 2814042 11-FEB-17 <path>/data/pdb2/DEFTBS01.DBF

BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
18 Full 1.25M SBT_TAPE 00:00:40 13-FEB-17
BP Key: 18 Status: AVAILABLE Compressed: NO Tag: TAG20170212T201557
Handle: <piece name> Media: <name>
List of Datafiles in backup set 18
Container ID: 4, PDB Name: PDB2
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
16 Full 2814042 11-FEB-17 <path>/data/pdb2/USERTBS01.DBF

List of Backup Sets
===================

BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
24 10.00M SBT_TAPE 00:00:19 13-FEB-17
BP Key: 24 Status: AVAILABLE Compressed: NO Tag: TAG20170213T033311
Handle: <piece name> Media: <name>

   List of Archived Logs in backup set 24
   Thrd Seq Low SCN Low Time Next SCN Next Time
   ---- ------- ---------- --------- ---------- ---------
   1 45 2819303 12-FEB-17 2822492 12-FEB-17
   1 46 2822492 12-FEB-17 2825162 12-FEB-17

BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
25 10.00M SBT_TAPE 00:00:21 13-FEB-17
BP Key: 25 Status: AVAILABLE Compressed: NO Tag: TAG20170213T033311
Handle: <piece name> Media: <name>
   List of Archived Logs in backup set 25
   Thrd Seq Low SCN Low Time Next SCN Next Time
   ---- ------- ---------- --------- ---------- ---------
   1 47 2825162 12-FEB-17 2828495 12-FEB-17
   1 48 2828495 12-FEB-17 2832292 13-FEB-17
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
23 10.00M SBT_TAPE 00:03:30 13-FEB-17
BP Key: 23 Status: AVAILABLE Compressed: NO Tag: TAG20170213T033311
Handle: <piece name> Media: <name>

   List of Archived Logs in backup set 23
   Thrd Seq Low SCN Low Time Next SCN Next Time
   ---- ------- ---------- --------- ---------- ---------
   1 49 2832292 13-FEB-17 2836038 13-FEB-17
   1 50 2836038 13-FEB-17 2838489 13-FEB-17                       <<<<<<<<<<<<<<<<< Archivelog 50 Available
 

BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
22 256.00K SBT_TAPE 00:03:25 13-FEB-17

BP Key: 22 Status: AVAILABLE Compressed: NO Tag: TAG20170213T033311
Handle: <piece name> Media: <name>

   List of Archived Logs in backup set 22
   Thrd Seq Low SCN Low Time Next SCN Next Time
   ---- ------- ---------- --------- ---------- ---------
   1 51 2838489 13-FEB-17 2838634 13-FEB-17                                              
   new media label is "<label>" for piece "<piecename>"
...
...
new media label is "<label>" for piece "<piecename>"
validation succeeded for backup piece
RMAN-05119: recovery can not be done to a consistent state.                                                  <<<<<<<<<<<<<<<<< RMAN-05119 reported
Media recovery start SCN is 2819679
Recovery must be done beyond SCN 2836475 to clear datafile fuzziness
new media label is "<label>" for piece "<piecename>"
new media label is "<label>" for piece "<piecename>"


As one more level of check, check the FUZZINESS and FUZZINESS SCN  to clear the fuzziness by querying v$datafile_header and  x$kcvfh view.

SQL> select file#,substr(name,1,70) name, error, status,recover, fuzzy, resetlogs_change#, resetlogs_time,checkpoint_change#,checkpoint_time from v$datafile_header;

FILE# NAME                                      ERROR STATUS REC FUZ RESETLOGS_CHANGE# RESETLOGS_TIME CHECKPOINT_CHANGE# CHECKPOINT_TIME
---------- ----------------------------------------------- ----- ------- --- ---------- ----------------- ------------------- -----------------
1 <path name>/data/cdb/system01.dbf         ONLINE       YES    2746787        19-12-2016 11:23:07 2819679 12-02-2017 20:15:57                 <<<<<<<< Datafile 1 Fuzzy  
2 <path name>/data/pdb/SYSTEM01.DBF         ONLINE       NO           1         24-10-2014 15:21:02 1963812 24-10-2014 23:00:20
3 <path name>/data/cdb/sysaux01.dbf         ONLINE       YES    2746787        19-12-2016 11:23:07 2819680 12-02-2017 20:15:57                 <<<<<<<< Datafile 3 Fuzzy
4 <path name>/data/pdb/SYSAUX01.DBF         ONLINE       NO          1         24-10-2014 15:21:02 1963812 24-10-2014 23:00:20
5 <path name>/data/cdb/undotbs01.dbf        ONLINE       NO     2746787        19-12-2016 11:23:07 2819681 12-02-2017 20:15:57
6 <path name>/data/cdb/<name1>..dbf         ONLINE       NO     2746787        19-12-2016 11:23:07 2834618 13-02-2017 01:45:39
7 <path name>/data/pdb/<name1>..DBF         ONLINE       NO           1        24-10-2014 15:21:02 1963812 24-10-2014 23:00:20
8 <path name>/data/pdb/USERTBS01.DBF        ONLINE       NO          1         24-10-2014 15:21:02 1963812 24-10-2014 23:00:20
9 <path name>/data/pdb1/SYSTEM01.DBF        ONLINE       NO     2746787        19-12-2016 11:23:07 2813870 11-02-2017 14:09:09
10 <path name>/data/pdb1/SYSAUX01.DBF       ONLINE       NO     2746787        19-12-2016 11:23:07 2813870 11-02-2017 14:09:09
11 <path name>/data/pdb1/<name1>.DBF       ONLINE       NO     2746787        19-12-2016 11:23:07 2813870 11-02-2017 14:09:09
12 <path name>/data/pdb1/USERTBS01.DBF      ONLINE       NO     2746787        19-12-2016 11:23:07 2813870 11-02-2017 14:09:09
13 <path name>/data/pdb2/SYSTEM01.DBF       ONLINE       NO     2746787        19-12-2016 11:23:07 2814042 11-02-2017 14:09:10
14 <path name>/data/pdb2/SYSAUX01.DBF       ONLINE       NO     2746787        19-12-2016 11:23:07 2814042 11-02-2017 14:09:10
15 <path name>/data/pdb2/<name1>..DBF       ONLINE       NO     2746787        19-12-2016 11:23:07 2814042 11-02-2017 14:09:10
16 <path name>/data/pdb2/USERTBS01.DBF      ONLINE       NO     2746787        19-12-2016 11:23:07 2814042 11-02-2017 14:09:10

--------------------X$KCVFH;

At least one datafile has scn much lower than the rest of the database:

SQL>select distinct to_char(fhscn, '99999999999999999999') as "Stby_datafile_hdr_SCN" from X$KCVFH;

Stby_datafile_hdr_SCN
---------------------
  10571110002345
  10591313115628
  10591313133587
  10591313148383
  10591313156525
  10591313172772
  10591313186729

SQL>select min(to_char(fhscn, '99999999999999999999')) as Standby_Datafile_Header_SCN from X$KCVFH;

STANDBY_DATAFILE_HEAD
---------------------
  10571110002345
 
x$kcbfh.fhscn gives checkpoint scn for a particular datafile. Datafile recovery should start with this checkpoint scn.
If scn is too low, the redo containing this could be found in very old archive redo log which may already been deleted.
 

SOLUTION

1. Identify the datafile with lowest checkpoint scn:
  a. at standby:
  SQL>col name format a55
  SQL>select file#, name, to_char(checkpoint_change#, '99999999999999999999') from v$datafile_header where checkpoint_change# < 10571110002350;

  FILE# NAME TO_CHAR(CHECKPOINT_CH
  ---------- ------------------------------------------------------- ---------------------
  299 +<path>/datafile/sysaux.622.811623929 10571110002345

  b. at primary:
  SQL > select file#, name from v$datafile where file# = 299

2. Copy datafile identified in step 1 from primary to standby database as per instruction in:
  Note 605234.1 == > How to Copy ASM datafile From Primary Database to Standby Database on ASM using RMAN

3. Recreate standby control file from current control file at primary.
  Note 734862.1 == > Step by step guide on how to recreate standby control file when datafiles are on ASM and using Oracle Managed Files

4. Restart standby recovery.
  sql> alter database recover managed standby database disconnect;

---------------------------

SQL> select FHDBI,FHDBN,HXFIL File_num,substr(HXFNM,1,70) File_name,FHTYP Type,FHSCN SCN, FHTNM TBS_NAME,FHSTA status,FHRBA_SEQ Sequence,fhafs fuzzy_scn from X$KCVFH;
 

FHDBI      FHDBN FILE_NUM FILE_NAME                              TYPE SCN     TBS_NAME      STATUS     SEQUENCE          FUZZY_SCN
---------- --------- ---------- --------------------------------------------- ---------- ---------- ---------------- ------------------- ---------- ----------------  ---------------
3004172638 DBCDB 1  <path name>/data/cdb/system01.dbf    3   2819679 SYSTEM          8256          45            2836475     <<<<<<<<<<<<<<<  Fuzziness SCN to be cleared----
3004172638 DBCDB 2  <path name>/data/pdb/SYSTEM01.DBF    3   1963812 SYSTEM              0      1868                 0
3004172638 DBCDB 3  <path name>/data/cdb/sysaux01.dbf    3   2819680 SYSAUX          64            45           2824670
3004172638 DBCDB 4  <path name>/data/pdb/SYSAUX01.DBF    3   1963812 SYSAUX            0        1868                 0
3004172638 DBCDB 5  <path name>/data/cdb/undotbs01.dbf   3   2819681 UNDOTBS1          0           45                0
3004172638 DBCDB 6  <path name>/data/cdb/<name1>.dbf    3   2834618  <ts name>            0           49                0
3004172638 DBCDB 7  <path name>/data/pdb/<name1>.DBF    3   1963812 <ts name>            0         1868                0
3004172638 DBCDB 8  <path name>/data/pdb/USERTBS01.DBF   3   1963812 USERTBS           0         1868                0
3004172638 DBCDB 9  <path name>/data/pdb1/SYSTEM01.DBF   3   2813870 SYSTEM            0           43                0
3004172638 DBCDB 10 <path name>/data/pdb1/SYSAUX01.DBF   3   2813870 SYSAUX            0           43                0
3004172638 DBCDB 11 <path name>/data/pdb1/<name1>.DBF   3   2813870 <ts name>             0           43                0
3004172638 DBCDB 12 <path name>/data/pdb1/USERTBS01.DBF  3   2813870 USERTBS           0           43                0
3004172638 DBCDB 13 <path name>/data/pdb2/SYSTEM01.DBF   3   2814042 SYSTEM            0           43                0
3004172638 DBCDB 14 <path name>/data/pdb2/SYSAUX01.DBF   3   2814042 SYSAUX            0           43                0
3004172638 DBCDB 15 <path name>/data/pdb2/<name1>.DBF   3   2814042 <ts name>             0           43                0
3004172638 DBCDB 16 <path name>/data/pdb2/USERTBS01.DBF  3   2814042 USERTBS           0           43                0




As per x$kcvfh to clear the fuzziness , recovery should go beyond "2836475".  The same is suggested in RMAN's 'restore database preview'.  I.e:
"Recovery must be done beyond SCN 2836475 to clear datafile fuzziness"

To find which archivelog sequence has scn "2836475" information, run the sql below: 
 

SQL> select thread#,dest_id,sequence#, name,applied ,first_time, first_change#,status ,deleted
from gv$archived_log where 2836475 between first_change# and next_change#;

THREAD# DEST_ID SEQUENCE# NAME                                          APPLIED    FIRST_TIM FIRST_CHANGE# S DEL 
-------- ----- ------- ------------------------------------------- ---------    --------- ------------- - --- 
1           1   50       <path>/arch/1_50_ NO931000987.arc 13-FEB-17  2836038                 A NO         


From the above output, we understand, to clear the fuzziness and open the database, we need to apply the archivelog sequence 50 which has scn 2836475. 

Now, we proceed with RECOVER DATABASE. 

In this example: 
As per expectation, RMAN should recover the database until the archivelogs which known to controlfile . i.e untill archivelog sequence 50 (51-1) RMAN should apply to clear the fuzziness and RMAN should end its recovery. 

But RMAN expecting archivelog sequence 52 which does not exist in the backup and actually NOT needed for recovery.

RMAN> run {
ALLOCATE CHANNEL CH1 DEVICE TYPE sbt_tape parms 'SBT_LIBRARY=/u01/app/oracle/product/12.1.0/dbhome_1/lib/libopc.so,
ENV=(OPC_PFILE=/u01/app/oracle/product/12.1.0/dbhome_1/dbs/opcConfig.ora)';
recover database;
}
allocated channel: CH1
channel CH1: SID=249 device type=SBT_TAPE
channel CH1: Oracle Database Backup Service Library VER=3.16.9.21

Starting recover at 14-FEB-17

starting media recovery

new media label is "LABEL" for piece "<piece name >"
new media label is "LABEL" for piece "<piece name >"
..
..
channel CH1: restoring archived log
archived log thread=1 sequence=45
channel CH1: restoring archived log
archived log thread=1 sequence=46
channel CH1: reading from backup piece <piece name >
channel CH1: piece handle=<piece name > tag=TAG20170213T033311
channel CH1: restored backup piece 1
channel CH1: restore complete, elapsed time: 00:00:01
archived log file name=<path>/arch/1_45_931000987.arc thread=1 sequence=45
archived log file name=<path>/arch/1_46_931000987.arc thread=1 sequence=46
channel CH1: starting archived log restore to default destination
channel CH1: restoring archived log
archived log thread=1 sequence=47
channel CH1: restoring archived log
archived log thread=1 sequence=48
channel CH1: reading from backup piece <piece name >
channel CH1: piece handle=<piece name > tag=TAG20170213T033311
channel CH1: restored backup piece 1
channel CH1: restore complete, elapsed time: 00:00:01
archived log file name=<path>/arch/1_47_931000987.arc thread=1 sequence=47
archived log file name=<path>/arch/1_48_931000987.arc thread=1 sequence=48
channel CH1: starting archived log restore to default destination
channel CH1: restoring archived log
archived log thread=1 sequence=49
channel CH1: restoring archived log
archived log thread=1 sequence=50
channel CH1: reading from backup piece 0nrsem3o_1_1
channel CH1: piece handle=0nrsem3o_1_1 tag=TAG20170213T033311
channel CH1: restored backup piece 1
channel CH1: restore complete, elapsed time: 00:00:03
archived log file name=<path>/arch/1_49_931000987.arc thread=1 sequence=49
archived log file name=<path>/arch/1_50_931000987.arc thread=1 sequence=50
channel CH1: starting archived log restore to default destination
channel CH1: restoring archived log
archived log thread=1 sequence=51
channel CH1: reading from backup piece 0prsem3o_1_1
channel CH1: piece handle=0prsem3o_1_1 tag=TAG20170213T033311
channel CH1: restored backup piece 1
channel CH1: restore complete, elapsed time: 00:00:01
archived log file name=<path>/arch/1_51_931000987.arc thread=1 sequence=51
unable to find archived log
archived log thread=1 sequence=52
released channel: CH1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/14/2017 09:49:47
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 52 and starting SCN of 2838634                <<<<<<<<<<<<<

RMAN>


Ignore the above RMAN-06054 error and proceed to open the database with resetlogs option.   If the source and target databases' online redo file location is different, rename all the redo log files using 'alter database rename...' and proceed with the open as below:

     SQL> alter database rename file '<old path/redo01.log'> to '<new path/redo01.log'>;

     SQL> alter database open resetlogs;

jnrjian
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
RMAN 关于恢复到过去的时间点
11-19
8. **恢复到特定SCN** (`RMAN> recover database until scn 1588623;`)：恢复到之前记录的SCN。 9. **打开数据库** (`RMAN> alter database open resetlogs;`)。 10. **验证结果** (`SQL> select * from test4;`)。 ...
实战Oracle rman还原和恢复
04-22
Oracle RMAN（Recovery Manager）是Oracle数据库管理系统中用于备份、恢复和维护的重要工具。它提供了全面的数据保护功能，能够帮助管理员在发生数据丢失或系统故障时迅速恢复数据。本篇将详细介绍Oracle RMAN的还原...
oracle强制拉库跳过recovery,Oracle 基于 RMAN 的不完全恢复(incomplete recovery by RMAN)
weixin_36105745的博客
04-07 458
Oracle 数据库可以实现数据库不完全恢复与完全恢复。完全恢复是将数据库恢复到最新时刻，也就是无损恢复，保证数据库无丢失的恢复。而不完全恢复则是根据需要特意将数据库恢复到某个过去的特定时间点或特定的SCN以及特定的Sequence。我们可以通过基于用户管理的不完全恢复实现，也可以通过基于RMAN方式来实现。本文主要描述是基于RMAN的不完全恢复的几种情形并给出示例。有关数据库备份恢复，RMAN备...
validate命令---rman进行备份和回复的验证
ezbit
11-07 7200
rman作为oracle备份与恢复工具，为我们提供了强大的功能，其中包括对数据文件的物理和逻辑检测以及备份文件的有效性检测。 首先，来看一下rman对数据文件的检测。我们知道，rman在备份数据时，会将数据读入读缓存，然会将数据从读缓存写入写缓存并最终写入数据库。在从读缓存到写缓存的过程中，rman会进行物理一致性的检测（db_block_checksum未true）和逻辑一致性检测（使用了ch
Oracle 10g 中 X$KCVFH 说明
David Dai -- Focus on Oracle
10-30 9838
一. X$表说明 之前整理了一篇有关动态性能视图的blog：Oracle 动态性能视图http://blog.csdn.net/tianlesoftware/article/details/5863191 Oracle 参数分类 和 参数的查看方法http://blog.csdn.net/tianlesoftware/article/details/5583655  The fixed X$tab
Oracle10g中XKCVFH说明
rede
03-28 1095
原 Oracle 10g 中 X$KCVFH 说明https://blog.csdn.net/tianlesoftware/article/details/6919280版权声明： https://blog.csdn.net/tianlesoftware/article/details/6919280 一. X$表说明 之前整理了一篇有关动态性能视图的blog： Oracle 动态性能视图...
[转]X$KCVF相关的数据恢复的时间点
mygodhome的专栏
11-13 318
Reference: https://www.askmaclean.com/archives/打开oracle数据库出错-数据文件需要还原更多以保持一.html Oracle数据库–企业版–版本9.2.0.1及更高版本 本文档中的信息适用于任何平台。 ***于2015年2月27日检测相关性*** 目的 本文的目标是在打开数据库遇到以下错误时帮助数据库管理员： ORA-119...
Which one is the last archivelog we need for recover?
zhou1862324的专栏
12-30 864
对事务量大的DB执行恢复时，recover一直要求next archivelog： recover database using backup controlfile until cancel; but it always ask us to apply the next archivelog. Specify log: {=suggested | filename | AUTO | C
rman.zip_oracle_rman
09-23
Oracle RMAN（Recovery Manager）是Oracle数据库管理系统中一个强大的备份和恢复工具，它提供了全面的数据保护方案。在Oracle环境中，RMAN能够执行各种备份操作，包括冷备份和热备份，以确保数据的安全性和可恢复性...
RMAN.rar_oracle_rman
09-24
Oracle RMAN，全称为Recovery Manager，是Oracle数据库系统中一个强大的备份和恢复工具。它提供了全面的数据保护功能，包括数据库备份、增量备份、表空间备份、归档日志管理以及数据库恢复等操作。在Oracle数据库...
Oracle rman 增量备份
08-02
Oracle RMAN（Recovery Manager）是Oracle数据库管理系统中一个强大的备份和恢复工具，它提供了多种备份策略，其中增量备份是企业级数据保护的关键组成部分。在Oracle数据库环境中，增量备份允许数据库管理员只备份...
webjs 数据库 离线读取本地数据库源码-SAAS 本地化及未来之窗行业应用跨平台架构
cybersnow精通 28 门计算机语言，凭借其超凡的技术能力，成功开发过上万个应用，广泛涉及政府、商业、个人等众多领域，甚至在检察院、环保局、公安局等专业场景中也大放异彩。不仅熟练掌握单片机和物联网开发，在软件架构设计方面更是独树一帜，自创了跨平台软件
08-15 142
【代码】webjs 数据库 离线读取本地数据库源码-SAAS 本地化及未来之窗行业应用跨平台架构。
[Qt][Qt窗口][下]详细讲解
SnowK博客
08-13 3524
[Qt][Qt窗口][下]详细讲解
mysql介绍
weixin_57763462的博客
08-14 286
丰富的存储引擎：MySQL 提供了多种存储引擎，如 InnoDB、MyISAM、Memory 等，每种存储引擎都有其特定的应用场景和优势。多语言支持：MySQL 支持多种编程语言，包括 C、C++、Python、Java、Perl、PHP 等，并提供了相应的 API。安全性：MySQL 提供了灵活的权限和密码系统，支持基于主机的验证，并且所有的密码传输都采用加密形式，确保了数据的安全性。管理工具：MySQL 提供了丰富的管理工具，如命令行客户端、图形界面管理工具等，方便用户进行数据库的管理和维护。
MySQL索引的性能优化
最新发布
2302_79993788的博客
08-15 516
在数据库调优中，我们的目标就是响应时间更快，吞吐量更大。利用宏观的监控工具和微观的日志分析可以帮我们快速找到调优的思路和方式。
Mybatis XML 数据源为 Oracle 之批量插入或更新 Merge Into 的具体介绍与使用
欢迎来到 ABin-阿斌的博客：写一生代码，创一世佳话，筑一览芳华。
08-12 650
由于近期在所开发的项目中，对于数据入库，有存在即更新，不存在则插入的需求，因此发现了 Oracle中的 MergeInto 命令。本文将对MergeInto的用法进行介绍并将 MergeInto 和批量插入进行结合，同时还会对在 MergeInto 开发中遇到的问题进行总结。MergeInto 命令是 Oracle9i 中新增的命令，有了 MergeInto 语句，我们对数据能够不仅仅只做单一的插入或单一的更新，而是可以将更新与插入一起操作。
基于JAVA生产制造执行系统设计与实现(源码+论文+讲解等)
程序员阿龙的博客
08-13 891
当下，如果 还依然使用纸质文档来记录并且管理相关信息，可能会出现很多问题，比如原始文件的丢失，因为采用纸质文档，很容易受潮或者怕火，不容易备份，需要花费大量的人员和资金来管理用纸质文档存储的信息，最重要的是数据出现问题寻找起来很麻烦，并且修改也困难，如果还这样操作会造成很大的资源浪费和经济损失。所以，对于本课题研究的产品生产制造信息的管理就需要有一款软件来代替手工操作，因此MES生产制造执行系统就应运而生。MES生产制造执行系统运用的工具包括Eclipse，Tomcat以及Navicat等。
基于vue框架的NBA球星管理系统1878g（程序+源码+数据库+调试部署+开发环境）系统界面在最后面。
h2345678的博客
08-12 1003
随着互联网的普及和体育产业的蓬勃发展，篮球运动在全球范围内拥有庞大的粉丝群体，NBA（美国职业篮球联赛）作为其中的佼佼者，其球星更是备受关注。传统的球星信息管理方式往往依赖于纸质文档或简单的电子表格，这种方式不仅效率低下，难以实现数据的即时更新与共享，也无法满足球迷和媒体对球星信息深度挖掘的需求。因此，开发一套基于Vue框架的NBA球星管理系统，通过信息化手段整合球星信息，实现数据的快速录入、存储、查询与分析，对于提升管理效率、满足用户需求具有重要意义。，处理前端请求并提供业务逻辑。
rman 基于scn recover
05-23
RMAN是Oracle数据库自带的备份与恢复工具，它可以在备份数据时生成备份集，并且在需要恢复数据时可以使用...因此，可以说RMAN和基于SCN的恢复是两个不同的概念，但是在实际的数据库备份与恢复中，它们常常会结合使用。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值