浅析控制文件的创建

当我们用不同方式创建控制文件的时候,可能会对控制文件中的信息产生不同的影响,下面分别介绍以noresetlogs方式、resetlogs方式创建控制文件,以查看控制文件中

    当我们用不同方式创建控制文件的时候,可能会对控制文件中的信息产生不同的影响,下面分别介绍以noresetlogs方式、resetlogs方式创建控制文件,以查看控制文件中信息的变化。

一:以noresetlogs方式创建控制文件

1  重建控制文件语句如下

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE “CRM” NORESETLOGS ARCHIVELOG

    MAXLOGFILES 16

    MAXLOGMEMBERS 3

    MAXDATAFILES 100

    MAXINSTANCES 8

    MAXLOGHISTORY 292

LOGFILE

 GROUP 1 (

    ‘/oracle/app/db1/dbs/log1CRM.dbf’,

    ‘/oracle/CRM2/CRM/redo01b.log’

 ) SIZE 200M,

 GROUP 2 (

    ‘/oracle/app/db1/dbs/log2CRM.dbf’,

    ‘/oracle/CRM2/CRM/redo02b.log’

 ) SIZE 50M,

 GROUP 3 (

    ‘/oracle/CRM2/CRM/redo03.log’,

    ‘/oracle/CRM2/CRM/redo03b.log’

 ) SIZE 200M,

 GROUP 4 (

    ‘/oracle/CRM2/CRM/redo04.log’,

    ‘/oracle/CRM2/CRM/redo04b.log’

 ) SIZE 200M,

 GROUP 5 (

    ‘/oracle/CRM2/CRM/redo05.log’,

    ‘/oracle/CRM2/CRM/redo05b.log’

 ) SIZE 200M,

 GROUP 6 (

    ‘/oracle/CRM2/CRM/redo06.log’,

    ‘/oracle/CRM2/CRM/redo06b.log’

 ) SIZE 200M

DATAFILE

 ‘/oracle/test/system1.dbf’,

 ‘/oracle/test/zxb.dbf’,

 ‘/oracle/test/sysaux01.dbf’,

 ‘/oracle/test/users01.dbf’,

 ‘/oracle/test/zxa.dbf’,

 ‘/oracle/test/test1.dbf’,

 ‘/oracle/test/zxc.dbf’,

 ‘/oracle/test/undotbs1.dbf’,

 ‘/oracle/test/zxbig.dbf’

CHARACTER SET ZHS16GBK

;

2转储 数据文件头部信息如下:

V10 STYLE FILE HEADER:

        Compatibility Vsn = 169869568=0xa200100

        Db ID=3601019238=0xd6a33166, Db

        Activation ID=0=0x0

        Control Seq=9739=0x260b, File size=640=0x280

        File Number=4, Blksiz=8192, File Type=3 DATA

Tablespace #4 – USERS rel_fn:4

Creation   at   scn: 0x0000.000027b9 10/22/2005 21:45:00

Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0

 reset logs count:0x2fac7053 scn: 0x0000.802c8c23 reset logs terminal rcv data:0x0 scn: 0x0000.00000000

 prev reset logs count:0x2fac6f51 scn: 0x0000.802c3dfd prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000

 recovered at 12/05/2012 05:28:04

 status:0x0 root dba:0x00000000 chkpt cnt: 1183 ctl cnt:1182

begin-hot-backup file size: 0

Checkpointed at scn: 0x0000.8031da6a(2150750826) 11/22/2012 19:25:50 

 thread:1 rba:(0x1e.c8f.10)

3 转储新控制文件信息如下:

—————————————————————————————————-

DATABASE ENTRY

—————————————————————————————————-

 (size = 316, compat size = 316, section max = 1, section in-use = 1,

 last-recid= 0, old-recno = 0, last-recno = 0)

 (extent = 1, blkno = 1, numrecs = 1)

 12/05/2012 05:47:51

 DB Name “CRM”

 Database flags = 0x00400103 0x00001000

 Controlfile Creation Timestamp 12/05/2012 05:47:52

 Incmplt recovery scn: 0x0000.00000000

 Resetlogs scn: 0x0000.802c8c23 Resetlogs Timestamp 11/20/2012 07:01:39

 Prior resetlogs scn: 0x0000.802c3dfd Prior resetlogs Timestamp 11/20/2012 06:57:21

 Redo Version: compatible=0xa200100

 #Data files = 9, #Online files = 9

 Database checkpoint: Thread=1 scn: 0x0000.a5aaadfd

 Threads: #Enabled=1, #Open=0, Head=0, Tail=0

——————————————————————————–

 CHECKPOINT PROGRESS RECORDS

——————————————————————————-

 (size = 8180, compat size = 8180, section max = 11, section in-use = 0,

 last-recid= 0, old-recno = 0, last-recno = 0)

 (extent = 1, blkno = 2, numrecs = 11)

THREAD #1 – status:0x0 flags:0x0 dirty:0

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

on disk scn: 0x0000.00000000 01/01/1988 00:00:00

resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00

heartbeat: 801186341 mount id: 3609678535

————————————————————————————-

DATA FILE #4:

 (name #18) /oracle/test/users01.dbf

creation size=0 block size=8192 status=0x12 head=18 tail=18 dup=1

 tablespace 4, index=4 krfil=4 prev_file=0

 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

 Checkpoint cnt:1183 scn: 0x0000.a5aaadfd 01/01/1988 00:00:00

 Stop scn: 0x0000.a5aaadfd (2779426301)12/05/2012 05:47:52

 Creation Checkpointed at scn: 0x0000.000027b9 10/22/2005 21:45:00

 thread:0 rba:(0x0.0.0)

 

4 转储当前联机日志其最后一个记录如下

REDO RECORD – Thread:1 RBA: 0x000040.0000e490.0160 LEN: 0x0064 VLD: 0x02

SCN: 0x0000.a5aaadfb SUBSCN: 1 12/05/2012 04:52:27

CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1

 Block Written – afn: 1 rdba: 0x0040edc8 BFT:(1024,4255176) non-BFT:(1,60872)

                   scn: 0x0000.a5aaadf9 seq: 0x07 flg:0x04

 Block Written – afn: 1 rdba: 0x0040006a BFT:(1024,4194410) non-BFT:(1,106)

                   scn: 0x0000.a5aaadfa seq: 0x01 flg:0x06

 Block Written – afn: 1 rdba: 0x00400009 BFT:(1024,4194313) non-BFT:(1,9)

                   scn: 0x0000.a5aaadfa seq: 0x01 flg:0x04

END OF REDO DUMP

—– Redo read statistics for thread 1 —–

Read rate (ASYNC): 29255Kb in 41.53s => 0.69 Mb/sec

Total physical reads: 29255Kb

Longest record: 10Kb, moves: 0/92501 (0%)

Change moves: 41327/182885 (22%), moved: 10Mb

Longest LWN: 1537Kb, moves: 7/364 (1%), moved: 6Mb

Last redo scn: 0x0000.a5aaadfb (2779426299)

5总结:

Noresetlogs方式创建控制文件

数据文件头部情况

控制文件中记录数据文件信息

检查点计数值

chkpt cnt: 1183

检查点计数值

Checkpoint cnt:1183

检查点scn值

0x8031da6a

检查点scn值

scn: 0xa5aaadfd

Redo 块地址

rba:(0x1e.c8f.10)

Stop scn

Stop scn: 0xa5aaadfd

Database checkpoint: Thread=1 scn: 0x0000.a5aaadfd

Checkpoint cnt:1183 scn: 0x0000.a5aaadfd 01/01/1988 00:00:00

 

 Stop scn: 0x0000.a5aaadfd (2779426301)12/05/2012 05:47:52

 

1 控制文件中记录数据文件检查点计数值信息来自于数据文件头部。

2 控制文件中记录数据文件检查点 Scn以及stop scn 值来自于当前日志文件。

 

3 数据库检查点scn值也来自于当前日志文件。

4 重建控制文件后数据文件头部的rba地址决定了应用归档的开始(0x1e转换为10进制为30)

6 介质恢复过程:(注意红色部分)

 

执行Recover database后按提示输入auto,香港服务器,网站空间,从踪过程可看到恢复的应用归档和联机日志的过程。

 

PARSING IN CURSOR #1 len=34 dep=0 uid=0 oct=35 lid=0 tim=1322909211242292 hv=1214106442 ad=’72e77150′

ALTER DATABASE RECOVER database 真正后台恢复语句

END OF STMT

PARSE #1:c=1000,e=1470,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1322909211242288

Recovery target incarnation = 1, activation ID = 0

Influx buffer limit = 12870 (50% x 25740)

Successfully allocated 3 recovery slaves

Using 367 overflow buffers per recovery slave

Start recovery at thread 1 ckpt scn 2150750826 logseq 30 block 3215

*** 2012-12-05 06:10:32.542

Media Recovery add redo thread 1

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_30_799830099.dbf (从30号归档开始应用)

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_31_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_32_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_33_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_34_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_35_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_36_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_37_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_38_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_39_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_40_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_41_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_42_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_43_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_44_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_45_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_46_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_47_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_48_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_49_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_50_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_51_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_52_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_53_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_54_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_55_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_56_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

Media Recovery Log /oracle/archive/1_57_799830099.dbf

=====================

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

Media Recovery Log /oracle/archive/1_58_799830099.dbf

*** 2012-12-05 06:12:59.378

Recovery of Online Redo Log: Thread 1 Group 5 Seq 59 Reading mem 0

*** 2012-12-05 06:12:59.906

Recovery of Online Redo Log: Thread 1 Group 6 Seq 60 Reading mem 0

*** 2012-12-05 06:13:00.147

Recovery of Online Redo Log: Thread 1 Group 1 Seq 61 Reading mem 0

*** 2012-12-05 06:13:00.330

Recovery of Online Redo Log: Thread 1 Group 2 Seq 62 Reading mem 0

*** 2012-12-05 06:13:00.538

Recovery of Online Redo Log: Thread 1 Group 3 Seq 63 Reading mem 0

*** 2012-12-05 06:13:03.523

Recovery of Online Redo Log: Thread 1 Group 4 Seq 64 Reading mem 0

—– Redo read statistics for thread 1 —–

Read rate (ASYNC): 110780Kb in 152.42s => 0.71 Mb/sec

Total physical reads: 110780Kb

Longest record: 23Kb, moves: 0/292927 (0%)

Change moves: 113261/562625 (20%), moved: 45Mb

Longest LWN: 2004Kb, moves: 23/4514 (0%), moved: 15Mb

Last redo scn: 0x0000.a5aaadfb (2779426299)

———————————————-

*** 2012-12-05 06:13:04.986

Media Recovery drop redo thread 1

File 1 (stop scn 2779426300) completed recovery at checkpoint scn 2779426300

File 2 (stop scn 2779426300) completed recovery at checkpoint scn 2779426300

File 3 (stop scn 2779426300) completed recovery at checkpoint scn 2779426300

File 4 (stop scn 2779426300) completed recovery at checkpoint scn 2779426300

File 5 (stop scn 2779426300) completed recovery at checkpoint scn 2779426300

File 6 (stop scn 2779426300) completed recovery at checkpoint scn 2779426300

File 7 (stop scn 2779426300) completed recovery at checkpoint scn 2779426300

File 8 (stop scn 2779426300) completed recovery at checkpoint scn 2779426300

File 9 (stop scn 2779426300) completed recovery at checkpoint scn 2779426300

————————————-介质恢复到此处完成—————————————–

JTopCms建站系统 JTopCms建站系统

JTopCMS基于JavaEE自主研发,是用于管理站群内容的国产开源软件(CMS),能高效便捷地进行内容采编,审核,模板制作,用户交互以及文件等资源的维护。安全,稳定,易扩展,支持国产中间件及数据库,适合建设政府,教育以及企事业单位的站群系统。 系统特色 1. 基于 JAVA 标准自主研发,支持主流国产信创环境,国产数据库以及国产中间件。安全,稳定,经过多次政务与企事业单位项目长期检验,顺利通过

JTopCms建站系统 0 查看详情 JTopCms建站系统

 

二 resetlogs 方式创建控制文件

 

1  resetlogs方式创建控制文件语句如下:

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE “CRM” RESETLOGS ARCHIVELOG

    MAXLOGFILES 16

    MAXLOGMEMBERS 3

    MAXDATAFILES 100

    MAXINSTANCES 8

    MAXLOGHISTORY 292

LOGFILE

 GROUP 1 (

    ‘/oracle/app/db1/dbs/log1CRM.dbf’,

    ‘/oracle/CRM2/CRM/redo01b.log’

 ) SIZE 200M,

 GROUP 2 (

    ‘/oracle/app/db1/dbs/log2CRM.dbf’,

    ‘/oracle/CRM2/CRM/redo02b.log’

 ) SIZE 50M,

 GROUP 3 (

    ‘/oracle/CRM2/CRM/redo03.log’,

    ‘/oracle/CRM2/CRM/redo03b.log’

 ) SIZE 200M,

 GROUP 4 (

    ‘/oracle/CRM2/CRM/redo04.log’,

    ‘/oracle/CRM2/CRM/redo04b.log’

 ) SIZE 200M,

 GROUP 5 (

    ‘/oracle/CRM2/CRM/redo05.log’,

    ‘/oracle/CRM2/CRM/redo05b.log’

 ) SIZE 200M,

 GROUP 6 (

    ‘/oracle/CRM2/CRM/redo06.log’,

    ‘/oracle/CRM2/CRM/redo06b.log’

 ) SIZE 200M

DATAFILE

 ‘/oracle/test/system1.dbf’,

 ‘/oracle/test/zxb.dbf’,

 ‘/oracle/test/sysaux01.dbf’,

 ‘/oracle/test/users01.dbf’,

 ‘/oracle/test/zxa.dbf’,

 ‘/oracle/test/test1.dbf’,

 ‘/oracle/test/zxc.dbf’,

 ‘/oracle/test/undotbs1.dbf’,

 ‘/oracle/test/zxbig.dbf’

CHARACTER SET ZHS16GBK

;

 

2 转储数据文件头部信息如下:

 

V10 STYLE FILE HEADER:

        Compatibility Vsn = 169869568=0xa200100

        Db ID=3601019238=0xd6a33166, Db

        Activation ID=0=0x0

        Control Seq=11044=0x2b24, File size=640=0x280

        File Number=4, Blksiz=8192, File Type=3 DATA

Tablespace #4 – USERS rel_fn:4

Creation   at   scn: 0x0000.000027b9 10/22/2005 21:45:00

Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0

 reset logs count:0x2fc8ca2a scn: 0x0000.a5ac8ab7 reset logs terminal rcv data:0x0 scn: 0x0000.00000000

 prev reset logs count:0x2fc60dc2 scn: 0x0000.a5abe48a prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000

 recovered at 12/12/2012 01:00:31

 status:0x0 root dba:0x00000000 chkpt cnt: 1285 ctl cnt:1284

begin-hot-backup file size: 0

Checkpointed at scn: 0x0000.a5ad6cd4 12/11/2012 23:00:27

 thread:1 rba:(0xc.a2df.10)

 

3 转储控制文件信息如下:

———————————————————————————————-

DATABASE ENTRY

———————————————————————————————– 

 (size = 316, compat size = 316, section max = 1, section in-use = 1,

 last-recid= 0, old-recno = 0, last-recno = 0)

 (extent = 1, blkno = 1, numrecs = 1)

 12/12/2012 01:20:14

 DB Name “CRM”

 Database flags = 0x00400147 0x00001000

 Controlfile Creation Timestamp 12/12/2012 01:20:14

 Incmplt recovery scn: 0x0000.a5ad6cd4

 Resetlogs scn: 0x0000.a5ac8ab7 Resetlogs Timestamp 12/10/2012 19:08:26

 Prior resetlogs scn: 0x0000.a5abe48a Prior resetlogs Timestamp 12/08/2012 17:20:02

 Redo Version: compatible=0xa200100

 #Data files = 9, #Online files = 9

 Database checkpoint: Thread=0 scn: 0x0000.00000000

 Threads: #Enabled=1, #Open=0, Head=0, Tail=0

—————————————————————————————————

CHECKPOINT PROGRESS RECORDS

—————————————————————————————————

 (size = 8180, compat size = 8180, section max = 11, section in-use = 0,

 last-recid= 0, old-recno = 0, last-recno = 0)

 (extent = 1, blkno = 2, numrecs = 11)

THREAD #1 – status:0x0 flags:0x0 dirty:0

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

on disk scn: 0x0000.00000000 01/01/1988 00:00:00

resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00

heartbeat: 801780265 mount id: 3610283405

—————————————————————————————————

DATA FILE #4:

—————————————————————————————————-

 (name #18) /oracle/test/users01.dbf

creation size=0 block size=8192 status=0x12 head=18 tail=18 dup=1

 tablespace 4, index=4 krfil=4 prev_file=0

 unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

 Checkpoint cnt:1285 scn: 0x0000.a5ad6cd4 12/11/2012 23:00:27

 Stop scn: 0xffff.ffffffff 12/12/2012 01:20:15

 Creation Checkpointed at scn: 0x0000.000027b9 10/22/2005 21:45:00

 thread:0 rba:(0x0.0.0)

 

4总结:

resetlogs方式创建控制文件

数据文件头部情况

控制文件中记录数据文件信息

检查点计数值

chkpt cnt: 1285

检查点计数值

Checkpoint cnt:1285

检查点scn值

0x a5ad6cd4

检查点scn值

scn: 0xa5ad6cd4

Redo 块地址

rba:( 0xc.a2df.10)

Stop scn

Stop scn: 0xffff.ffffffff

Database checkpoint: Thread=0 scn: 0x0000.00000000

low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

on disk scn: 0x0000.00000000 01/01/1988 00:00:00

 

1 控制文件中记录数据文件的检查点计数值取自于数据文件头部

2 控制文件中记录的数据文件检查点scn值取自于数据文件头部

3 控制文件中记录数据文件stop scn 为空

4 数据文件头部的rba地址决定了应用归档的开始。

 

5 介质恢复过程:(注意红色部分)

 

执行recover database using backup controlfile 按提示先输入auto执行完后在输入cancel。具体跟踪步骤如下:

=====================

PARSING IN CURSOR #1 len=60 dep=0 uid=0 oct=35 lid=0 tim=1323483294217660 hv=4023293076 ad=’72ee3548′

ALTER DATABASE RECOVER database using backup controlfile 后台执行的恢复语句

END OF STMT

PARSE #1:c=2000,e=75902,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483294217651

Recovery target incarnation = 1, activation ID = 0

Influx buffer limit = 12870 (50% x 25740)

Successfully allocated 3 recovery slaves

Using 367 overflow buffers per recovery slave

Start recovery at thread 1 ckpt scn 2779606228 logseq 12 block 41695

*** 2012-12-12 01:28:13.478

Media Recovery add redo thread 1

EXEC #1:c=26995,e=202134,p=9,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1323483294419926

ERROR #1:err=279 tim=431688214

XCTEND rlbk=0, rd_only=1

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483298441740 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=829,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483298441733

*** 2012-12-12 01:28:17.604

Media Recovery Log /oracle/archive/1_12_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483299535222 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=433,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483299535218

*** 2012-12-12 01:28:18.724

Media Recovery Log /oracle/archive/1_13_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483299695183 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=1000,e=725,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483299695179

*** 2012-12-12 01:28:18.888

Media Recovery Log /oracle/archive/1_14_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483299740282 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=419,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483299740278

*** 2012-12-12 01:28:18.934

Media Recovery Log /oracle/archive/1_15_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483299786570 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=336,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483299786566

*** 2012-12-12 01:28:18.981

Media Recovery Log /oracle/archive/1_16_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483299832254 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=399,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483299832250

*** 2012-12-12 01:28:19.028

Media Recovery Log /oracle/archive/1_17_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483299876112 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=345,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483299876094

*** 2012-12-12 01:28:19.073

Media Recovery Log /oracle/archive/1_18_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483299926303 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=278,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483299926300

*** 2012-12-12 01:28:19.124

Media Recovery Log /oracle/archive/1_19_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483300165398 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=488,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483300165393

*** 2012-12-12 01:28:19.369

Media Recovery Log /oracle/archive/1_20_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483300227290 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=368,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483300227285

*** 2012-12-12 01:28:19.432

Media Recovery Log /oracle/archive/1_21_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483300279420 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=423,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483300279416

*** 2012-12-12 01:28:19.486

Media Recovery Log /oracle/archive/1_22_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483300352148 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=1000,e=326,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483300352145

*** 2012-12-12 01:28:19.560

Media Recovery Log /oracle/archive/1_23_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483300395658 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=306,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483300395655

*** 2012-12-12 01:28:19.605

Media Recovery Log /oracle/archive/1_24_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483300445677 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=354,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483300445674

*** 2012-12-12 01:28:19.656

Media Recovery Log /oracle/archive/1_25_801688106.dbf

=====================

PARSING IN CURSOR #1 len=44 dep=0 uid=0 oct=35 lid=0 tim=1323483300496386 hv=2522010750 ad=’72dc70e8′

ALTER DATABASE RECOVER    CONTINUE DEFAULT

END OF STMT

PARSE #1:c=0,e=343,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483300496382

*** 2012-12-12 01:28:19.708

Media Recovery Log /oracle/archive/1_26_801688106.dbf

=====================

PARSING IN CURSOR #1 len=30 dep=0 uid=0 oct=35 lid=0 tim=1323483300520620 hv=426209255 ad=’72dc65c0′

ALTER DATABASE RECOVER CANCEL 由于seq号为26的归档不存在所以执行此处恢复退出

END OF STMT

PARSE #1:c=0,e=362,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483300520616

—– Redo read statistics for thread 1 —–

Read rate (ASYNC): 501Kb in 6.26s => 0.08 Mb/sec

Total physical reads: 501Kb

Longest record: 11Kb, moves: 0/323 (0%)

Change moves: 198/757 (26%), moved: 0Mb

Longest LWN: 333Kb, moves: 0/12 (0%), moved: 0Mb

Last redo scn: 0x0000.a5ad6da9 (2779606441)

———————————————-

*** 2012-12-12 01:28:19.733

Media Recovery drop redo thread 1

XCTEND rlbk=0, rd_only=1

EXEC #1:c=2999,e=2842075,p=76,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1323483303362733

*** 2012-12-12 01:31:10.671

—————————————到此处auto执行完成下面为cancel——————————-

PARSE ERROR #1:len=62 dep=0 uid=0 oct=35 lid=0 tim=1323483467452187 err=905

ALTER DATABASE RECOVER database usbing backup controlfile

*** 2012-12-12 01:31:21.663

XCTEND rlbk=0, rd_only=1

=====================

PARSING IN CURSOR #1 len=59 dep=0 uid=0 oct=35 lid=0 tim=1323483478188160 hv=4034011427 ad=’72eddf60′

ALTER DATABASE RECOVER database using backup controlfile

END OF STMT

PARSE #1:c=1000,e=1252,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483478188152

Recovery target incarnation = 1, activation ID = 0

Influx buffer limit = 12870 (50% x 25740)

Successfully allocated 3 recovery slaves

Using 367 overflow buffers per recovery slave

Start recovery at thread 1 ckpt scn 2779606446 logseq 26 block 2

*** 2012-12-12 01:31:21.731

Media Recovery add redo thread 1

EXEC #1:c=15997,e=67432,p=9,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1323483478255663

ERROR #1:err=279 tim=431707036

XCTEND rlbk=0, rd_only=1

=====================

PARSING IN CURSOR #1 len=34 dep=0 uid=0 oct=35 lid=0 tim=1323483482042870 hv=3965620631 ad=’72dcaa20′

ALTER DATABASE RECOVER    CANCEL

END OF STMT

PARSE #1:c=1000,e=719,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1323483482042864

*** 2012-12-12 01:31:25.612

Media Recovery drop redo thread 1

XCTEND rlbk=0, rd_only=1

EXEC #1:c=3000,e=2929112,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1323483484972040

*** 2012-12-12 01:31:38.300

—————————————cancel恢复完成————————————————–

本文出自 “myblog” 博客,网站空间,请务必保留此出处

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 chuangxiangniao@163.com 举报,一经查实,本站将立刻删除。
发布者:程序猿,转转请注明出处:https://www.chuangxiangniao.com/p/1083320.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
够快云库怎么下载照片?够快云库下载照片的方法
上一篇 2025年12月2日 21:17:20
见证雏鸟的蜕变 《逍遥情缘》神兽凤仙长大后是真的好看
下一篇 2025年12月2日 21:17:25

相关推荐

  • MySQL服务无法启动怎么办?常见解决方法

    MySQL服务无法启动怎么办?常见解决方法MySQL服务无法启动怎么办?常见解决方法MySQL服务无法启动怎么办?常见解决方法MySQL服务无法启动怎么办?常见解决方法

    mysql服务无法启动常见原因包括配置错误、端口占用、数据文件损坏或权限问题。解决方法如下:1. 查看错误日志,定位问题根源;2. 检查配置文件是否存在语法错误或路径问题;3. 确认端口(如3306)未被占用;4. 核查数据目录的权限与完整性;5. 必要时修复或重置数据目录,甚至重新安装mysql。…

    2026年9月22日 用户投稿
    000
  • Java TreeMap如何自定义排序规则

    TreeMap默认按键的自然顺序排序,可通过构造函数传入Comparator自定义排序规则。例如字符串可按长度排序:TreeMap map = new TreeMap((s1, s2) -> s1.length() – s2.length()); 对自定义对象如Person可按年龄…

    2026年9月22日
    000
  • 如何使用MLflow训练AI大模型?模型管理与跟踪的实用教程

    如何使用MLflow训练AI大模型?模型管理与跟踪的实用教程如何使用MLflow训练AI大模型?模型管理与跟踪的实用教程如何使用MLflow训练AI大模型?模型管理与跟踪的实用教程如何使用MLflow训练AI大模型?模型管理与跟踪的实用教程

    MLflow通过实验跟踪、可复现的项目封装、标准化模型格式和集中式模型注册表,实现大模型训练的全流程管理。它记录超参数、指标和模型文件,支持分布式环境下的集中日志管理,利用远程跟踪服务器和云存储统一收集数据,并通过模型版本控制与阶段管理提升团队协作与部署效率。 ☞☞☞AI 智能聊天, 问答助手, A…

    2026年9月22日 用户投稿
    000
  • Java Collections.synchronizedList方法如何保证线程安全

    synchronizedList通过同步方法保证线程安全,使用synchronized关键字对每个操作加锁,确保单个操作的原子性;但迭代或复合操作需手动同步,否则可能引发并发异常;其性能较低,适用于读多写少、并发不高的场景,高并发下推荐使用CopyOnWriteArrayList。 Java 中 C…

    2026年9月22日
    100
  • 如何在MiniToolMovieMaker中编辑AI视频?免费AI视频剪辑的教程

    如何在MiniToolMovieMaker中编辑AI视频?免费AI视频剪辑的教程如何在MiniToolMovieMaker中编辑AI视频?免费AI视频剪辑的教程如何在MiniToolMovieMaker中编辑AI视频?免费AI视频剪辑的教程如何在MiniToolMovieMaker中编辑AI视频?免费AI视频剪辑的教程

    MiniTool MovieMaker虽无AI生成功能,但可高效编辑AI生成的MP4、MOV等格式视频或图片序列。通过导入素材后,利用其剪辑、过渡、滤镜、文字、音频处理等功能,实现AI片段的精剪、色彩统一、无缝衔接与风格化输出。支持主流视频、图片及音频格式,兼容性好,适合个人创作者进行AI内容后期整…

    2026年9月22日 用户投稿
    500
  • VSCode如何调试JavaScript代码 VSCode调试功能的实战技巧

    要在vscode中调试javascript,首先需设置断点、配置launch.json文件、选择合适的调试环境并启动调试会话;2. launch.json至关重要,常见陷阱包括program路径错误、type类型不匹配、cwd设置不当、混淆launch与attach模式以及source map配置缺…

    2026年9月22日
    000
  • PHP匿名函数怎么用_PHP匿名函数使用场景分析

    PHP匿名函数是无名函数,可作为回调或赋值给变量,常用在数组处理、事件回调、逻辑封装等场景,支持use引入外部变量及fn短语法,结合bindTo可访问对象私有成员。 PHP匿名函数,也叫闭包函数(Closure),是一种没有名称的函数,通常作为回调使用或赋值给变量。它在实际开发中非常灵活,尤其适合用…

    2026年9月22日
    100
  • 中国联通正式获得开展 eSIM 手机运营服务商用试验的批复

    感谢网友 会弹琴的九号、学士 的线索投递! 10月13日,三大运营商官方微信号相继发布消息,宣告eSIM服务进入新阶段。其中,中国联通于当日上午10:00率先发布推文《抢约!联通eSIM来了!》,动作迅速,展现出强烈的市场积极性;中国移动在傍晚19:29发布《中国移动全面上线eSIM手机办理》;而中…

    2026年9月22日
    200
  • 为什么建议手动定义Java序列化ID

    手动定义serialVersionUID可确保序列化兼容性,避免因类结构变化导致反序列化失败。Java默认生成的ID依赖类名、字段等信息,编译环境或代码微小改动均使其改变,易引发InvalidClassException。显式声明后,可在兼容性变更时主动控制ID更新,保留原ID则允许旧版本读取新对象…

    2026年9月22日
    200
  • mysql怎么使用全文索引 mysql创建全文索引的配置方法

    mysql怎么使用全文索引 mysql创建全文索引的配置方法mysql怎么使用全文索引 mysql创建全文索引的配置方法mysql怎么使用全文索引 mysql创建全文索引的配置方法mysql怎么使用全文索引 mysql创建全文索引的配置方法

    mysql使用全文索引的核心是让数据库像搜索引擎一样理解并高效检索文本内容。1. 创建全文索引:可在建表时或之后通过alter table语句为char、varchar或text字段添加fulltext索引;2. 使用match against查询:支持自然语言模式(自动过滤停用词并按相关性排序)和…

    2026年9月22日 用户投稿
    100
  • VSCode如何通过调试变量监视列表批量追踪数据变化 VSCode变量监视列表批量追踪的新颖技巧​

    VSCode如何通过调试变量监视列表批量追踪数据变化 VSCode变量监视列表批量追踪的新颖技巧​VSCode如何通过调试变量监视列表批量追踪数据变化 VSCode变量监视列表批量追踪的新颖技巧​VSCode如何通过调试变量监视列表批量追踪数据变化 VSCode变量监视列表批量追踪的新颖技巧​VSCode如何通过调试变量监视列表批量追踪数据变化 VSCode变量监视列表批量追踪的新颖技巧​

    vscode中高效批量追踪数据变化的关键是将监视列表用作表达式求值器,而非仅添加单一变量;2. 可在监视列表中添加复杂对象路径(如user.profile.address.city)、计算表达式(如(a + b) * c)、函数调用(如calculatetotal(items))或条件判断(如myv…

    2026年9月22日 用户投稿
    000
  • 在Java中如何统计List中元素出现次数

    答案是使用Map或Stream API统计List元素频次最高效。通过HashMap手动遍历统计,或用Java 8的Stream结合groupingBy和counting()实现简洁计数,Collections.frequency适用于小数据量但性能较差,推荐Stream方式兼顾性能与可读性。 在J…

    2026年9月22日
    900
  • 如何设置Linux服务超时参数 systemd服务超时配置

    如何设置Linux服务超时参数 systemd服务超时配置如何设置Linux服务超时参数 systemd服务超时配置如何设置Linux服务超时参数 systemd服务超时配置如何设置Linux服务超时参数 systemd服务超时配置

    systemd服务超时参数调整方法包括:1.使用systemctl show查看timeoutstartsec、timeoutstopsec、timeoutsec字段获取当前配置;2.通过systemctl edit编辑unit文件设置timeoutstartsec、timeoutstopsec或t…

    2026年9月22日 用户投稿
    000
  • mysql安装完如何诊断 mysql慢查询分析与优化方法

    要解决 mysql 慢查询问题,首先要开启慢查询日志,其次使用 mysqldumpslow 分析日志,再通过 explain 查看执行计划,最后根据常见优化建议改进 sql 和索引。具体步骤如下:一、修改配置文件或动态开启慢查询日志,并设置阈值和路径;二、使用 mysqldumpslow 工具分析慢…

    2026年9月22日
    100
  • 主板供电相数对CPU超频稳定性的影响:14相 vs. 20相实测

    20相供电主板在超频下表现更稳,实测显示其VRM温度更低、电压波动更小、性能输出更一致,尤其适合极限超频和高负载场景,而14相供电配合优质用料也能满足主流超频需求,普通用户无需盲目追求高相数。 主板供电相数直接影响CPU在高负载和超频状态下的电压稳定性和温度控制。很多人在选择主板时会看到“14相”或…

    2026年9月22日
    200
  • PHP如何实现视频留言评论_PHP实现视频留言评论功能

    答案:通过数据库设计、前端表单、后端处理和评论展示四步实现PHP视频留言功能。1. 创建comments表存储信息;2. 构建表单提交昵称与评论;3. 用add_comment.php接收并存入数据库;4. 在页面读取并安全输出评论,防止XSS。 要实现视频留言评论功能,PHP可以结合前端页面、数据…

    2026年9月22日
    000
  • Java中如何区分逻辑错误和系统异常

    系统异常是程序运行中由JVM抛出的RuntimeException,如空指针、数组越界,会导致程序中断并打印堆栈;逻辑错误是程序语法正确但结果不符预期,如条件写反、循环次数错误,不会崩溃但行为异常。两者区别在于是否抛出异常、是否中断执行及调试方式不同,需通过防御性编程、单元测试和日志调试加以防范。 …

    2026年9月22日
    000
  • mysql安装后怎么建表 mysql创建数据表的详细步骤

    mysql安装后怎么建表 mysql创建数据表的详细步骤mysql安装后怎么建表 mysql创建数据表的详细步骤mysql安装后怎么建表 mysql创建数据表的详细步骤mysql安装后怎么建表 mysql创建数据表的详细步骤

    安装完 mysql 后,建表的关键在于先创建数据库并选择使用,然后通过 create table 语句定义表结构。1. 创建数据库:使用 create database mydatabase; 创建数据库;2. 使用数据库:通过 use mydatabase; 选择当前操作的数据库;3. 建表语法:…

    2026年9月22日 用户投稿
    200
  • 夸克浏览器电脑网页版访问入口 夸克官网主页链接地址

    夸克浏览器电脑网页版访问入口是https://www.quark.cn/,用户可直接在浏览器地址栏输入该链接访问,其界面采用极简设计并集成智能搜索、网盘服务与跨设备同步等功能。 立即进入“☞☞☞☞☞点击夸克资源网(永久免费)入口☜☜☜☜☜”; 立即进入“☞☞☞☞☞点击夸克浏览器电脑网页版访问入口☜☜…

    2026年9月22日
    500
  • Spring Boot 应用中的单元测试、Mockito 和集成测试:最佳实践

    第一段引用上面的摘要: 本文旨在帮助初学者理解在 Spring Boot 应用中何时以及如何使用 JUnit、Mockito 和集成测试。我们将探讨这些测试框架在 Controller、Service 和 Repository 层中的应用,并提供示例说明何时使用 Mockito 模拟对象,以及何时使…

    2026年9月22日
    000

发表回复

登录后才能评论
关注微信