ORACLE数据文件和控制文件头部

为了回答关于《深入浅出Oracle》中的一些疑问，引出本系列文章，讨论链接参考:

https://www.sodocs.net/doc/1b8218980.html,/609499.html

在上一讲中，我们说过：当我们使用file_hdrs事件来转储数据文件头信息时，Oracle会转储两部分信息，一部分来自控制文件，一部分来自数据文件，在数据库启动过程中，这两部分信息要用来进行启动验证。

在数据库open的过程中,Oracle要进行检查中包含以下两个过程:

第一次检查数据文件头中的Checkpoint cnt是否与对应控制文件中的Checkpoint cnt一致.

如果相等,进行第二次检查.

第二次检查数据文件头的开始SCN和对应控制文件中的结束SCN是否一致如果结束SCN等于开始SCN,则不需要对那个文件进行恢复.

对每个数据文件都完成检查后,打开数据库.同时将每个数据文件的结束SCN设置为无穷大.

通过以下过程我们来进一步说明一下这个内容。

我们来看以下来自控制文件部分(选取一个文件测试):

DATA FILE #4:

(name #4) /opt/oracle/oradata/eygle/eygle01.dbf

creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1

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

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

Checkpoint cnt:58 scn: 0x0000.002ac8ee 08/11/2006 09:48:29

Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

Creation Checkpointed at scn: 0x0000.0015078d 06/06/2006 09:41:54

thread:0 rba:(0x0.0.0)

................

aux_file is NOT DEFINED

这部分中包含的重要信息有:

检查点计数: Checkpoint cnt:58

检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29

数据文件Stop SCN:Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

我们再看来自数据文件头的信息:

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

Tablespace #4 - EYGLE rel_fn:4

Creation at scn: 0x0000.0015078d 06/06/2006 09:41:54

Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0 reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/10/2006 20:57:53

status:0x0 root dba:0x00000000 chkpt cnt: 58 ctl cnt:57

begin-hot-backup file size: 0

Checkpointed at scn: 0x0000.002ac8ee 08/11/2006 09:48:29

.......................

这部分中包含的重要信息有:

检查点SCN: Checkpointed at scn: 0x0000.002ac8ee 08/11/2006 09:48:29

检查点计数: chkpt cnt: 58 ctl cnt:57

这两者都和控制文件中所记录的一致。如果这两者一致，数据库启动时就能通过验证，启动数据库。那么如果不一致呢？

Oracle则请求进行恢复。

我们看，从备份中恢复eygle01.dbf文件.

首先第一部分从控制文件中获得的信息是相同的:

DATA FILE #4:

(name #4) /opt/oracle/oradata/eygle/eygle01.dbf

creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1

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

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

Checkpoint cnt:58 scn: 0x0000.002ac8ee 08/11/2006 09:48:29

Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

Creation Checkpointed at scn: 0x0000.0015078d 06/06/2006 09:41:54

...................

aux_file is NOT DEFINED

检查点计数: Checkpoint cnt:58

检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29

数据文件Stop SCN:Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

而从文件头中获得的备份文件信息则是：

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

Tablespace #4 - EYGLE rel_fn:4

Creation at scn: 0x0000.0015078d 06/06/2006 09:41:54

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

reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/10/2006 20:57:53

status:0x0 root dba:0x00000000 chkpt cnt: 53 ctl cnt:52

begin-hot-backup file size: 0

Checkpointed at scn: 0x0000.002ac5f9 08/10/2006 20:58:21

...................................

我们看到此时备份文件的信息：

检查点是：Checkpointed at scn: 0x0000.002ac5f9 08/10/2006 20:58:21

检查点计数为:chkpt cnt: 53 ctl cnt:52

这两者不再一致，首先是检查点技术不一致，当前文件的chkpt cnt为53，小于控制文件中记录的58，Oracle可以判断文件是从备份中恢复的，或者文件故障，需要进行介质恢复。

我们看如果此时我们试图打开数据库，则Oracle提示文件需要介质恢复:

执行恢复:

我们看看恢复完成之后，控制文件和数据文件的变化.

首先看控制文件的变化:

检查点计数: Checkpoint cnt:59

执行了恢复之后，检查点计数较前增加了1

检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29

数据文件Stop scn: 0x0000.002ac8ed 08/11/2006 09:48:29

数据文件Stop scn和数据文件进行了同步。

数据文件头信息:

FILE HEADER:

Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000

Db ID=1407686520=0x53e79778, Db Name='EYGLE'

Activation ID=0=0x0

Control Seq=983=0x3d7, File size=1280=0x500

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

Tablespace #4 - EYGLE rel_fn:4

Creation at scn: 0x0000.0015078d 06/06/2006 09:41:54

Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0 reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/11/2006 10:11:26

status:0x0 root dba:0x00000000 chkpt cnt: 59 ctl cnt:58

begin-hot-backup file size: 0

Checkpointed at scn: 0x0000.002ac8ed 08/11/2006 09:48:29

..........................

我们看到此时数据文件的信息：

检查点是：Checkpointed at scn: 0x0000.002ac8ed 08/11/2006 09:48:29

这个检查点和控制文件中记录的stop scn一致，数据库启动可以顺利进行。

检查点计数为:chkpt cnt: 59 ctl cnt:58

我们打开数据库:

此时数据库恢复正常运行。

控制文件信息如下：

此时stop scn被置为无穷大。

数据文件头信息如下:

FILE HEADER:

Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000

Db ID=1407686520=0x53e79778, Db Name='EYGLE'

Activation ID=0=0x0

Control Seq=984=0x3d8, File size=1280=0x500

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

Tablespace #4 - EYGLE rel_fn:4

Creation at scn: 0x0000.0015078d 06/06/2006 09:41:54

Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0 reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/11/2006 10:11:26

status:0x4 root dba:0x00000000 chkpt cnt: 60 ctl cnt:59

begin-hot-backup file size: 0

Checkpointed at scn: 0x0000.002ac8ef 08/11/2006 10:19:30

未完待续...

datafile block block size :8192

1 row created.

Start dump data blocks tsn: 17 file#: 5 minblk 10 maxblk 10

buffer tsn: 17 rdba: 0x0140000a (5/10)

//// buffer tsn:

数据文件对应的 tablespace 的 number 这只是dump文件中记录的数据而已

block 中是没有记录 tablespace 的 number 的

scn: 0x0000.0043890e seq: 0x05 flg: 0x02 tail: 0x890e0605

frmt: 0x02 chkval: 0x0000 type: 0x06=trans data

Block header dump: 0x0140000a

Object id on Block? Y

seg/obj: 0xd254 csc: 0x00.43890a itc: 2 flg: O typ: 1 - DATA

fsl: 0 fnx: 0x0 ver: 0x01

Itl Xid Uba Flag Lck

Scn/Fsc

0x01 0x0004.00c.00001850 0x00801496.07b9.01 --U- 1 fsc

0x0000.0043890e

0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc

0x0000.00000000

data_block_dump,data header at 0x87e125c

//// data_block_dump,data header at 0x87e125c

其实这个block不是直接从 data buffer 中 dump 出来的这个表示真正dump时 block 的数据区的起始位置

也就是下面这部分开始的位置

=============== //// tsiz: hsiz: pbl: bdba: 在数据文件都是没有存储的

tsiz: 0x1fa0 //// Total data area size

8k的block: 8192-20(block head)-24(Transaction Header)-24*2(一个事务条)-4(block tail)=8096(0x1fa0)

hsiz: 0x14 //// Data header size 数据块头20个字节+数据块尾4个字节=24字节(0x14)

pbl: 0x087e125c //// Pointer to buffer holding the block bdba: 0x0140000a

76543210

flag=--------

ntab=1

nrow=1

frre=-1

fsbo=0x14

fseo=0x1f9b

avsp=0x1f83

tosp=0x1f83

0xe:pti[0] nrow=1 offs=0

0x12:pri[0] offs=0x1f9b

block_row_dump:

tab 0, row 0, @0x1f9b

tl: 5 fb: --H-FL-- lb: 0x1 cc: 1

col 0: [ 1] 61

end_of_block_dump

End dump data blocks tsn: 17 file#: 5 minblk 10 maxblk 10

block 坏掉了还可以报:

ORA-600 (4519) Cache layer block type is incorrect

ORA-600 (4393) Check for Type for Segment header with free list

ORA-600 (4136) Check Rollback segment block

ORA-600 (4154) Check Rollback segment block

Ora-600[kcbzpb_1],[d],[kind],[chk] gets signaled when the block got corrupted in memory.

The only way it should be bad is if a stray store into memory destroyed the header or tail.

d = blocknumber, kind= kind of corruption detected,chk = checksum flag

ora-600[3398] and ora-600[3339]

ora-600[3398] is not in oracle 8.

ora-600[3398] means it failed a verification check before writing back to disk, so it must

be an in-memory corruption.

ora-600[3339] comes with ora-1578 and means either disk corruption or in memory corruption after read.

ora-600 [3339] has been removed from 7.2+

From 7.2+ ora-600 [3398] has become ora-600 [3374] with some checks added.

2进制存储格式

ALTER SESSION SET EVENTS '10289 trace name context forever, level 1';

ALTER SESSION SET EVENTS '10289 trace name context off';

为了回答一些疑问，引出本系列文章，讨论链接参考:

https://www.sodocs.net/doc/1b8218980.html,/609499.html

当我们使用file_hdrs事件来转储数据文件头信息时，Oracle会转储两部分信息，一部分来自控制文件，一部分来自数据文件，在数据库启动过程中，这两部分信息要用来进行启动验证。

在数据库open的过程中,Oracle要进行检查中包含以下两个过程:

第一次检查数据文件头中的Checkpoint cnt是否与对应控制文件中的Checkpoint cnt一致.如果相等,进行第二次检查.

第二次检查数据文件头的开始SCN和对应控制文件中的结束SCN是否一致如果结束SCN等于开始SCN,则不需要对那个文件进行恢复.对每个数据文件都完成检查后,打开数据库.同时将每个数据文件的结束SCN设置为无穷大.

通过以下过程我们来进一步说明一下这个内容。

我们来看以下来自控制文件部分(选取一个文件测试):

DATA FILE #4:

(name #4) /opt/oracle/oradata/eygle/eygle01.dbf

creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1

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

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

Checkpoint cnt:58 scn: 0x0000.002ac8ee 08/11/2006 09:48:29

Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

Creation Checkpointed at scn: 0x0000.0015078d 06/06/2006 09:41:54

thread:0 rba:(0x0.0.0)

................

aux_file is NOT DEFINED

这部分中包含的重要信息有:

检查点计数: Checkpoint cnt:58

检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29

数据文件Stop SCN:Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

我们再看来自数据文件头的信息:

FILE HEADER:

Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000

Db ID=1407686520=0x53e79778, Db Name='EYGLE'

Activation ID=0=0x0

Control Seq=979=0x3d3, File size=1280=0x500

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

T ablespace #4 - EYGLE rel_fn:4

Creation at scn: 0x0000.0015078d 06/06/2006 09:41:54

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

reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/10/2006 20:57:53 status:0x0 root dba:0x00000000 chkpt cnt: 58 ctl cnt:57

begin-hot-backup file size: 0

Checkpointed at scn: 0x0000.002ac8ee 08/11/2006 09:48:29 .......................

这部分中包含的重要信息有:

检查点SCN: Checkpointed at scn: 0x0000.002ac8ee 08/11/2006 09:48:29

检查点计数: chkpt cnt: 58 ctl cnt:57

这两者都和控制文件中所记录的一致。如果这两者一致，数据库启动时就能通过验证，启动数据库。

那么如果不一致呢？

Oracle则请求进行恢复。

我们看，从备份中恢复eygle01.dbf文件.

首先第一部分从控制文件中获得的信息是相同的:

DATA FILE #4:

(name #4) /opt/oracle/oradata/eygle/eygle01.dbf

creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1

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

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

Checkpoint cnt:58 scn: 0x0000.002ac8ee 08/11/2006 09:48:29

Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

Creation Checkpointed at scn: 0x0000.0015078d 06/06/2006 09:41:54 ...................

aux_file is NOT DEFINED

检查点计数: Checkpoint cnt:58

检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29

数据文件Stop SCN:Stop scn: 0x0000.002ac8ee 08/11/2006 09:48:29

而从文件头中获得的备份文件信息则是：

FILE HEADER:

Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000 Db ID=1407686520=0x53e79778, Db Name='EYGLE'

Activation ID=0=0x0

Control Seq=973=0x3cd, File size=1280=0x500

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

T ablespace #4 - EYGLE rel_fn:4

Creation at scn: 0x0000.0015078d 06/06/2006 09:41:54

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

reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/10/2006 20:57:53

status:0x0 root dba:0x00000000 chkpt cnt: 53 ctl cnt:52

begin-hot-backup file size: 0

Checkpointed at scn: 0x0000.002ac5f9 08/10/2006 20:58:21 ...................................

我们看到此时备份文件的信息：

检查点是：Checkpointed at scn: 0x0000.002ac5f9 08/10/2006 20:58:21

检查点计数为:chkpt cnt: 53 ctl cnt:52

这两者不再一致，首先是检查点技术不一致，当前文件的chkpt cnt为53，小于控制文件中记录的58，Oracle可以判断文件是从备份中恢复的，或者文件故障，需要进行介质恢复。

我们看如果此时我们试图打开数据库，则Oracle提示文件需要介质恢复:

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01113: file 4 needs media recovery

ORA-01110: data file 4: '/opt/oracle/oradata/eygle/eygle01.dbf'

执行恢复:

SQL> recover datafile 4;

Media recovery complete.

我们看看恢复完成之后，控制文件和数据文件的变化.

首先看控制文件的变化:

DATA FILE #4:

(name #4) /opt/oracle/oradata/eygle/eygle01.dbf

creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1

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

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

Checkpoint cnt:59 scn: 0x0000.002ac8ee 08/11/2006 09:48:29

Stop scn: 0x0000.002ac8ed 08/11/2006 09:48:29

Creation Checkpointed at scn: 0x0000.0015078d 06/06/2006 09:41:54 ......................

检查点计数: Checkpoint cnt:59

执行了恢复之后，检查点计数较前增加了1

检查点SCN: scn: 0x0000.002ac8ee 08/11/2006 09:48:29

数据文件Stop scn: 0x0000.002ac8ed 08/11/2006 09:48:29

数据文件Stop scn和数据文件进行了同步。

数据文件头信息:

FILE HEADER:

Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000

Db ID=1407686520=0x53e79778, Db Name='EYGLE'

Activation ID=0=0x0

Control Seq=983=0x3d7, File size=1280=0x500

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

Tablespace #4 - EYGLE rel_fn:4

Creation at scn: 0x0000.0015078d 06/06/2006 09:41:54

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

reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/11/2006 10:11:26 status:0x0 root dba:0x00000000 chkpt cnt: 59 ctl cnt:58

begin-hot-backup file size: 0

Checkpointed at scn: 0x0000.002ac8ed 08/11/2006 09:48:29 ..........................

我们看到此时数据文件的信息：

检查点是：Checkpointed at scn: 0x0000.002ac8ed 08/11/2006 09:48:29

这个检查点和控制文件中记录的stop scn一致，数据库启动可以顺利进行。

检查点计数为:chkpt cnt: 59 ctl cnt:58

我们打开数据库:

SQL%26gt; alter database open;

Database altered.

SQL%26gt; alter session set events 'immediate trace name file_hdrs level 10'; Session altered.

此时数据库恢复正常运行。

控制文件信息如下：

DATA FILE #4:

(name #4) /opt/oracle/oradata/eygle/eygle01.dbf

creation size=0 block size=8192 status=0xe head=4 tail=4 dup=1

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

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

Checkpoint cnt:60 scn: 0x0000.002ac8ef 08/11/2006 10:19:30

Stop scn: 0xffff.ffffffff 08/11/2006 09:48:29

Creation Checkpointed at scn: 0x0000.0015078d 06/06/2006 09:41:54

此时stop scn被置为无穷大。

数据文件头信息如下:

FILE HEADER:

Software vsn=153092096=0x9200000, Compatibility Vsn=134217728=0x8000000

Db ID=1407686520=0x53e79778, Db Name='EYGLE'

Activation ID=0=0x0

Control Seq=984=0x3d8, File size=1280=0x500

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

Tablespace #4 - EYGLE rel_fn:4

Creation at scn: 0x0000.0015078d 06/06/2006 09:41:54

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

reset logs count:0x232bee1f scn: 0x0000.0007c781 recovered at 08/11/2006 10:11:26 status:0x4 root dba:0x00000000 chkpt cnt: 60 ctl cnt:59

begin-hot-backup file size: 0

Checkpointed at scn: 0x0000.002ac8ef 08/11/2006 10:19:30

Oracle DBA 数据库日常维护手册 常用SQL 脚本

Oracle数据库日常维护 【版本整理日期：2011/02/26 】 版本整理人：1634068400@https://www.sodocs.net/doc/1b8218980.html, 本文档包含以下内容： 1．Oracle数据库日常维护 2．Oracle DBA 常用管理脚本 3．Oracle DB 常用SQL 语句

/******************************************************** https://www.sodocs.net/doc/1b8218980.html,(若跳转不成功，请复制到浏览器或联系Q) https://www.sodocs.net/doc/1b8218980.html,/item.htm?id=7437120468Metalink Sharing ********************************************************/

在Oracle数据库运行期间，DBA应该对数据库的运行日志及表空间的使用情况进行监控，及早发现数据库中存在的问题。 一、Oracle警告日志文件监控 Oracle在运行过程中，会在警告日志文件(alert_SID.log)中记录数据库的一些运行情况： l数据库的启动、关闭，启动时的非缺省参数； l数据库的重做日志切换情况，记录每次切换的时间，及如果因为检查点(checkpoint)操作没有执行完成造成不能切换，会记录不能切换的原因； l对数据库进行的某些操作，如创建或删除表空间、增加数据文件； l数据库发生的错误，如表空间不够、出现坏块、数据库内部错误(ORA －600)

DBA 应该定期检查日志文件，根据日志中发现的问题及时进行处理 问题 处理 启动参数不对 检查初始化参数文件 因为检查点操作或归档操作没有完成造成重做日志不能切换 如果经常发生这样的情况，可以考虑增加重做日志文件组；想办法提高检查点 或归档操作的效率； 有人未经授权删除了表空间 检查数据库的安全问题，是否密码太简 单；如有必要，撤消某些用户的系统权 限 出现坏块 检查是否是硬件问题(如磁盘本生有坏 块)，如果不是，检查是那个数据库对象 出现了坏块，对这个对象进行重建 表空间不够 增加数据文件到相应的表空间 出现ORA-600 根据日志文件的内容查看相应的TRC 文件，如果是Oracle 的bug ，要及时打 上相应的补丁 二、数据库表空间使用情况监控（字典管理表空间） 数据库运行了一段时间后，由于不断的在表空间上创建和删除对象，会在表空间上产生大量的碎片，DBA 应该及时了解表空间的碎片和可用空间情况，以决定是否要对碎片进行整理或为表空间增加数据文件。 select tablespace_name,

oracle备份控制文件

如何备份控制文件 ?1、 ?ALTER DATABASE BACKUP CONTROLFILE TO TRACE; ?ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS; ?ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS; ? ?2、 ?ALTER DATABASE BACKUP CONTROLFILE TO 文件名; ?ALTER DATABASE BACKUP CONTROLFILE TO 文件名 REUSE;（如果此文件已存在） ? ?例： ?SQL> ALTER DATABASE BACKUP CONTROLFILE TO 'c:\a'; ? ?数据库已更改。 ? ?SQL> ALTER DATABASE BACKUP CONTROLFILE TO 'c:\a'; ?ALTER DATABASE BACKUP CONTROLFILE TO 'c:\a' ?* ?ERROR 位于第 1 行: ?ORA-01580: 创建控制备份文件c:\a时出错 ?ORA-27038: skgfrcre: 文件存在 ?OSD-04010: <创建> 选项指定,文件已经存在 ? ? ?SQL> ALTER DATABASE BACKUP CONTROLFILE TO 'c:\a' reuse; ? ?数据库已更改。 ? ?SQL> ? ?3、 ?Shutdown，直接看init.ora文件中的control_files项，找到其中任意一个控制文件， ?用操作系统命令复制到备份地点即可（如：软盘、光盘、磁带等） ? ?第一种方法产生的是一个跟踪文件，里面存放的是创建控制文件的脚本，可以用记事本等文本编辑器打开 ?这个脚本可以让你重新创建控制文件， ?生成一个跟踪文件到init.ora中user_dump_dest所指的目录下（$ORACLE_HOME\ADMIN\ORADB\UDUMP\）。 ?

7损坏或丢失控制文件的恢复方法

一、损坏单个控制文件 损坏单个控制文件是比较容易恢复的，因为一般的数据库系统，控制文件都不是一个，而且所有的控制文件都互为镜相，只要拷贝一个好的控制文件替换坏的控制文件就可以了。 1、控制文件损坏，最典型的就是启动数据库出错，不能mount数据库 SQL>startup ORA-00205: error in identifying controlfile, check alert log for more info 查看报警日志文件，有如下信息 alter database mount Mon May 26 11:59:52 2003 ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl' ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) 系统找不到指定的文件。 2、停止数据库 SQL>shutdown immediate

3、拷贝一个好的控制文件替换坏的控制文件或修改init.ora中的控制文件参数，取消这个坏的控制文件。 4、重新启动数据 SQL>startup 说明: 1、损失单个控制文件是比较简单的，因为数据库中所有的控制文件都是镜相的，只需要简单的拷贝一个好的就可以了 2、建议镜相控制文件在不同的磁盘上 3、建议多做控制文件的备份，长期保留一份由alter database backup control file to trace产生的控制文件的文本备份 二、损坏全部控制文件 损坏多个控制文件，或者人为的删除了所有的控制文件，通过控制文件的复制已经不能解决问题，这个时候需要重新建立控制文件。同时注意，alter database backup control file to trace可以产生一个控制文件的文本备份。 以下是详细重新创建控制文件的步骤 1、关闭数据库

oracle及操作系统对于文件大小的限制

[ORACLE]：单个表空间的数据限制 当将表空间加到4GB的时候，系统提示表空间不足。 原因： FAT12 单文件最大支持8M Fat16单文件最大支持2G Fat32单文件不能大于4G NTFS单文件最大64GB NTFS5.0单文件最大2TB 解决方案： 增加多个数据文件，对应同一个表空间。 因为：size of a tablespace = size of each datafile * number of datafiles ======================================== Oracle中数据文件大小的限制 https://www.sodocs.net/doc/1b8218980.html,/archives/2007/07/oracle_datafile_limit.html Oracle数据文件的大小存在一个内部限制，这个限制是： 每个数据文件最多只能包含2^22-1个数据块。 这个限制也就直接导致了每个数据文件的最大允许大小。 在2K Block_size下，数据文件最大只能达到约8G 在32K的Block_size下，数据文件最大只能达到约16*8G的大小。 这个限制是由于Oracle的Rowid中使用22位来代表Block号，这22位最多只能代表2^22-1个数据块。 为了扩展数据文件的大小，Oracle10g中引入了大文件表空间，在大文件表空间下，Oracle使用32位来代表Block号，也就是说，在新的技术下，大文件表空间下每个文件最多可以容纳4G个Block。 那么也就是说当Block_size为2k时，数据文件可以达到8T 。 当block_size为32K时，数据文件可以达到128T。 上周在做2K block_size测试时，第一次遇到了这个限制： SQL> alter tablespace eygle add datafile 'f:eygle02.dbf' size 8192M; alter tablespace eygle add datafile 'f:eygle02.dbf' size 8192M * ERROR 位于第 1 行: ORA-01144: 文件大小 (4194304 块) 超出 4194303 块的最大数

oracle 数据文件、表空间、日志文件、控制文件数据库管理

实验四 oracle 数据库管理 一、试验目的 掌握对数据文件、表空间、日志文件、控制文件的常用命令，作为DBA的必要准备。 二、实验内容 2.1 数据文件的管理 （1）在安装完毕之后，在INITsid.ORA参数文件有一个DB_FILES 参数，用于设置当前实例的数据外文件的个数。如： db_files = 80 如果在INITsid.ORA文件没有该参数，则可以用下面查询语句从视图中查到。如： SQL> col name for a20 SQL> col value for a50 SQL> set lin 100 SQL> select name,value from v$parameter where name = 'db_files'; NAME V ALUE -------------------- -------------------------------------------------- db_files 1024 （2）行命令建立表空间： 例1 CREATE TABLESPACE user_stu DA TAFILE 'h:/oracle/oradata/orcl/user_stu.dat' SIZE 20M DEFAULT STORAGE ( INITIAL 10K NEXT 50K MINEXTENTS 1 MAXEXTENTS 99 PCTINCREASE 10 ) ONLINE ; 例2：建立一个新的表空间，具有两个数据文件： CREATE TABLESPACE CRM_TAB DA TAFILE 'h:/oracle/oradata/orcl/crm01.dbf' size 10 MB,'h:/oracle/oradata/orcl/crm02.dbf' size 10 MB; （3）对一个已存在的表空间追加新数据文件： 例1 ALTER TABLESPACE user_stu Add datafile 'H:/oracle/oradata/orcl/user_stu01.dbf' size 30M; 例2 为表空间增加数据文件 ALTER TABLESPACE users ADD DATAFILE 'userora1.dbf ' SIZE 10M ; （4）数据文件更名 ALTER TABLESPACE users

修改oracle实例名(sid)和数据库名(db_name)

修改oracle实例名(sid)和数据库名(db_name) 有时我们需要修改数据库的sid和dbname，除了使用rman进行备份恢复之外，也可以通过手工方式修改，主要由两个主要过程完成： 1、修改实例名（SID） 2、修改数据库名（dbname） 下面演示将数据库sid和dbname由orcl修改为cnhtm的过程： 1、修改实例名（sid） 1.1、检查原来的数据库实例名（sid） oracle@oracle[/home/oracle]> echo $ORACLE_SID orcl oracle@oracle[/home/oracle]> sqlplus / as sysdba SQL*Plus: Release 10.2.0.1.0 - Production on Sun Dec 20 11:14:49 2009 Copyright (c) 1982, 2005, Oracle. All rights reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options sys@ORCL> select instance from v$thread; INSTANCE -------------------------------------------------------------------------------- orcl 1.2、关闭数据库 注意不能用shutdown abort，只能是shutdown immediate或shutdown normal

Oracle案例：损坏控制文件的恢复方法

Oracle案例：损坏控制文件的恢复方法 一：损坏单个控制文件 损坏单个控制文件是比较容易恢复的，因为一般的数据库系统，控制文件都不是一个，而且所有的控制文件都互为镜相，只要拷贝一个好的控制文件替换坏的控制文件就可以了。1、控制文件损坏，最典型的就是启动数据库出错，不能mount数据库 SQL>startup ORA-00205: error in identifying controlfile, check alert log for more info 查看报警日志文件，有如下信息 alter database mount Mon May 26 11:59:52 2003 ORA-00202: controlfile: 'D:\Oracle\oradata\chen\control01.ctl' ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) 系统找不到指定的文件。 2、停止数据库 SQL>shutdown immediate 3、拷贝一个好的控制文件替换坏的控制文件或修改init.ora中的控制文件参数，取消这个坏的控制文件。 4、重新启动数据 SQL>startup 说明： 1、损失单个控制文件是比较简单的，因为数据库中所有的控制文件都是镜相的，只需要简

单的拷贝一个好的就可以了 2、建议镜相控制文件在不同的磁盘上 3、建议多做控制文件的备份，长期保留一份由alter database backup control file to trace产生的控制文件的文本备份 二：损坏全部控制文件 损坏多个控制文件，或者人为的删除了所有的控制文件，通过控制文件的复制已经不能解决问题，这个时候需要重新建立控制文件。 同时注意，alter database backup control file to trace可以产生一个控制文件的文本备份。 以下是详细重新创建控制文件的步骤 1、关闭数据库 SQL>shutdown immediate; 2、删除所有控制文件，模拟控制文件的丢失 3、启动数据库，出现错误，并不能启动到mount下 SQL>startup ORA-00205: error in identifying controlfile, check alert log for more info 查看报警日志文件，有如下信息 alter database mount Mon May 26 11:53:15 2003 ORA-00202: controlfile: 'D:\Oracle\oradata\chen\control01.ctl'

ORACLE控制文件损坏处理办法

ORACLE控制文件损坏处理办法 --关于ORACLE控制文件错误的处理 处理方法一．更改INIT.ORA中的参数，删除不能使用的controlFile ; 处理方法二． 先备份ORACLE安装目录和所有自定义创建的数据文件，再按照以下步骤进行试验处理。进入MS-DOS窗口，适用SVRMGRL工具； CONNECT INTERNAL/ORACLE ; STARTUP NOMOUNT; CREATE CONTROLFILE REUSE DA TABASE "ORCL" NORESETLOGS NOARCHIVELOG MAXLOGFILES 32 MAXLOGMEMBERS 2 MAXDATAFILES 32 MAXINSTANCES 16 MAXLOGHISTORY 1815 LOGFILE #此处根据实际情况处理 GROUP 1 'D:\ORACLE\ORADATA\ORCL\REDO03.LOG' SIZE 1M, GROUP 2 'D:\ORACLE\ORADATA\ORCL\REDO02.LOG' SIZE 1M, GROUP 3 'D:\ORACLE\ORADATA\ORCL\REDO01.LOG' SIZE 1M DA TAFILE #此处根据实际情况处理 'D:\ORACLE\ORADA TA\ORCL\SYSTEM01.DBF', 'D:\ORACLE\ORADA TA\ORCL\RBS01.DBF', 'D:\ORACLE\ORADA TA\ORCL\USERS01.DBF', 'D:\ORACLE\ORADA TA\ORCL\TEMP01.DBF', 'D:\ORACLE\ORADA TA\ORCL\TOOLS01.DBF', 'D:\ORACLE\ORADA TA\ORCL\INDX01.DBF', 'D:\ORACLE\ORADA TA\ORCL\DR01.DBF', 'D:\ORACLE\ORADA TA\ORCL\SDE.ORA', 'D:\ORACLE\ORADA TA\ORCL\GIS.ORA', 'D:\ORACLE\ORADA TA\ORCL\OEM_REPOSITORY.ORA' CHARACTER SET ZHS16GBK ; # Take files offline to match current control file. # 可以不执行以下DROP ALTER DATABASE DATAFILE 'D:\ORACLE\ORADA TA\ORCL\USERS01.DBF' OFFLINE DROP; ALTER DATABASE DATAFILE 'D:\ORACLE\ORADA TA\ORCL\TOOLS01.DBF' OFFLINE DROP; ALTER DATABASE DATAFILE 'D:\ORACLE\ORADA TA\ORCL\INDX01.DBF' OFFLINE DROP; ALTER DATABASE DATAFILE 'D:\ORACLE\ORADA TA\ORCL\DR01.DBF' OFFLINE

Oracle 建立控制文件

Oracle 建立控制文件 在一般情况下，如果使用了复合控制文件，并且将各个控制文件分别存储在不同的磁盘中，则丢失全部控件文件的可能性将非常小。但是，如果数据库的所有控制文件全部丢失，这时惟一的补救方法就是以手动方式重新创建控制文件。 另外，如果DBA需要改变数据库的某个永久性参数，也需要重新创建控制文件。永久性参数是在创建数据库时设置的一些参数，主要包括：数据库名称、MALOGFILES(最大的重做日志文件数)、MAXLOGMEMBERS（最大的重做日志组成员数）等。 下面介绍创建新的控制文件的命令CREATE CONTROLFILE语句的基本用法，具体步骤： （1）查看数据库中所有的数据文件和重做日志文件的名称和路径。 在创建新控制文件时，首先需要了解数据库中的数据文件和重做日志文件。如果数据库中所有的控制文件和重做日志文件都已经丢失，这时数据库已经无法打开，因此也就无法来查询数所字典获得数据文件和日志文件的信息，这时惟一的办法就是查看警告文件中的内容。如果数据库可以打开，那么可以通过执行下面的查询来生成文件列表：SQL> select member from v$logfile; SQL> select name from v$datafile; SQL> select name from v$controlfile; 如果既无法打开数据库，又无法打开可靠的文件列表，那么就只能够用手工方法通过查找操作系统文件来制作文件列表。 （2）关闭数据库。 如果数据库处于打开状态，则可能采取正常模式关闭数据库。 SQL> connect as sysdba …. SQL> shutdown immediate 数据库已经关闭。 已经卸载数据库。 ORACLE 例程已经关闭。 （3）在操作系统级别备份所有的数据文件和重做日志文件。 在使用CREATE CONTROLFILE语句创建新的控制文件时，如果操作不当可能会损坏数据文件和日志文件，因此，需要事先对其进行备份。 （4）启动实例，但是不加载数据库。 在建立控制文件时，要求实例处理NOMOUNT状态，即不打开控制文件。 SQL> startup nomount ORACLE 例程已经启动。 Total System Global Area 401743872 bytes Fixed Size 1333480 bytes Variable Size 255854360 bytes Database Buffers 138412032 bytes Redo Buffers 6144000 bytes

ORACLE数据库监控配置规范方案

ORACLE数据库配置规范和监控清单 2015年12月

目录 一、常规参数配置 (3) 1.1 数据库最大连接数 (3) 1.2 归档配置 (3) 1.3 最大文件数设置 (4) 1.4 关闭回收站 (4) 1.5 控制文件配置 (5) 1.6 白名单设置 (5) 1.7 闪回区设置 (6) 1.8 在线日志组 (6) 1.9 控制文件记录保留数 (7) 二、常用监控项 (8) 2.1 数据库在用连接数 (8) 2.2 监控数据库文件数 (8) 2.3 表空间使用率 (8) 2.4 闪回区使用率 (9) 2.5 数据库等待事件 (10) 2.6 告警日志监控 (10) 2.7 灾备DataGuard同步监控 (10) 2.8 AWR采样报告分析 (10)

一、常规参数配置 1.1数据库最大连接数 参数： processes 说明： 数据库用户最大连接数通过processes参数进行配置，默认值为 300，该值表示能够同时连接到数据库的最大会话数，当连接数达到最大值，后续新增连接均会被拒绝。 修改命令： alter system set processes=1000 scope=spfile; 生效方式： 需重启实例生效。 1.2归档配置 参数： archive log list 说明： 数据库开启归档，任何生产环境均应在归档方式下运行，从而达到可通过备份进行数据恢复要求，提高系统安全性 修改命令： 数据库启动至mount状态，执行 alter database archivelog; 生效方式：

重启数据库设置生效 1.3最大文件数设置 参数： db_files 说明： 该参数用于控制在扩容表空间时，数据文件能够达到的最大数量，默认值为 200 修改命令： alter system set db_files=800 scope=spfile; 生效方式： 重启数据库生效 1.4关闭回收站 参数： recyclebin 说明： 如果回收站未关闭，则如果表对象被删除，将进入回收站，并不会释放占用的存储 修改命令： alter system set recyclebin=’off’ scope=spfile; 生效方式：

Oracle数据库的物理存储结构之数据库控制文件详解

Oracle数据库中，数据库控制文件维护着数据库的全局物理结构，用以支持数据库成功的启动和运行。创建数据库时，同时就提供了与之对应的数据库控制文件。在数据库使用过程中，Oracle不断的更新数据库控制文件，所以只要数据库是打开的，数据库控制文件就必须处于可写状态。如果，犹豫某些原因控制文件不能被访问，那么数据库也就不能正常的工作了。 每一个控制文件只能与一个Oracle数据库相关联。数据库控制文件包含了数据库实例的启动和正常操作时，访问数据库所需的关于数据库的信息。数据库控制文件的内容只有Oralce 可以修改，数据库管理员和用户都不能对其进行编辑。 控制文件包含了以下信息： ?数据库名称 ?数据库创建的时间戳 ?相关的数据文件、重演日志文件的名称和位置 ?表空间信息 ?数据文件脱机范围 ?日志历史 ?归档日志信息 ?备份组和备份块信息 ?备份数据文件和重演日志信息 ?数据文件拷贝信息 ?当前日志序列数 ?检查点（checkpoint）信息 数据库名称和时间戳源自数据库创建之时，数据库名称或是来自DB_NAME初始化从参数，或者来自Cteate Database语句使用的名称。 每当数据文件或重演日志文件被添加内容、重新命名或者直接从数据库删除时，控制文件都要进行更新以反应物理结构的变化。记录下这些变化后，Oracle就可以：在数据库启动的时候，能够确定并打开数据文件和重演日子文件。 在必须要恢复数据库的时候，能够确定哪些文件是必须的、哪些文件是可用的。 PS：如果数据库的物理结构发生了改变（使用了Alert Database语句），用户应该立刻备份控制文件。 控制文件还记录了关于检查点的信息。每3秒，检查点进程（CKPT）就会在控制文件里记录重演日志文件的检查点位置信息。这些信息用于数据库的恢复过程，告诉数据库在这一点之前的已经记录下的重演条目不必进行恢复，因为它们已经被写入数据文件了。 由于控制文件对数据库的至关重要，所以联机存储着多个副本。这些文件一般存储在各个不同的磁盘上，以便将因磁盘试下哦引起的潜在危险降至最低程度。Oracle支持对同一个数据库并发的打开、书写多个相同的控制文件。通过为一个数据库在不同的磁盘上保存多个控制文件，可以幼小的降低对于控制文件可能发生的单点失败。例如，包含一个控制文件的磁盘崩溃了，如果Oracle试图访问这个被破坏的文件，当前实例就会失败，但是如果在不同的磁盘上保存了当前控制文件的复件，就可以重启一个实例而无需进行数据库恢复。

Oracle tablespace (表空间)的创建、删除、修改、扩展及检查等

Oracle tablespace (表空间)的创建、删除、修改、扩展及检查等 oracle 数据库表空间的作用 1.决定数据库实体的空间分配; 2.设置数据库用户的空间份额; 3.控制数据库部分数据的可用性; 4.分布数据于不同的设备之间以改善性能; 5.备份和恢复数据。 --oracle 可以创建的表空间有三种类型: 1.temporary: 临时表空间,用于临时数据的存放; create temporary tablespace "sample"...... 2.undo : 还原表空间. 用于存入重做日志文件. create undo tablespace "sample"...... 3.用户表空间: 最重要,也是用于存放用户数据表空间 create tablespace "sample"...... --注：temporary 和undo 表空间是oracle 管理的特殊的表空间.只用于存放系统相关数据. --oracle 创建表空间应该授予的权限 1.被授予关于一个或多个表空间中的resource特权; 2.被指定缺省表空间; 3.被分配指定表空间的存储空间使用份额; 4.被指定缺省临时段表空间。 select tablespace_name "表空间名称",status "状态",extent_management "区管理方式",allocation_type "磁盘扩展管理方式",segment_space_management "段管理方式" from dba_tablespaces; --查询各个表空间的区、段管理方式 --1、建立表空间 --语法格式: create tablespace 表空间名

Oracle控制文件管理和恢复

1 查看控制文件信息SYS@ prod>select * from v$controlfile; 目前三个控制文件（里面信息都一样）在同一个目录下，都在/dev/sda2磁盘上，很不安全，根据df显示的磁盘信息可以将控制文件放到test1目录下。 2 修改参数文件 1）查看参数文件的位置，当前使用spfile启动 2）SYS@ prod>alter system set control_files='/u01/oradata/prod/control01.ctl', 2 '/u01/oradata/prod/control02.ctl','/u01/oradata/prod/control03.ctl' scope=spfile; System altered. 3）修改参数文件 使用vi打开initprod.ora 文件在contol_file 后面添加‘/test/contorl04.ctl’并保存退出。4）关闭数据库SYS@ prod>shutdown immediate; 5）复制控制文件 [root@cuug ~]# cd /u01/oradata/prod [root@cuug prod]# cp ./control03.ctl /test1/control04.ctl 6）验证控制文件 7 ）注意事项： a复制控制文件时应该是数据库关闭状态，否则在启库是容易造成数据库SCN号不一致导致数据库无法mount b 复制时最好使用oracle操作，如果使用root记得更改新文件夹的属组和属主。

（一）只有一个控制文件丢失 1 删除一个控制文件 [root@cuug prod]# rm /u01/oradata/prod/control01.ctl rm: remove regular file `/u01/oradata/prod/control01.ctl'? y [root@cuug prod]# 2 关闭数据库SYS@ prod>shutdown immediate; 注：没用控制文件在关闭数据库是容易造成数据库未完全关闭重启时会报ora-01012错误，解决方法是在操作系统层杀掉数据库相关进程，重启即可。 3 重启数据库SYS@ prod>startup ORACLE instance started. Total System Global Area 523108352 bytes Fixed Size 1337632 bytes Variable Size 385877728 bytes Database Buffers 130023424 bytes Redo Buffers 5869568 bytes ORA-00205: ?????????, ??????, ??????? 重启失败报错。查看告警日志为丢失控制文件 ORA-00210: cannot open the specified control file ORA-00202: control file: '/u01/oradata/prod/control01.ctl' ORA-27037: unable to obtain file status Linux Error: 2: No such file or directory Additional information: 3 ORA-205 signalled during: ALTER DATABASE MOUNT... Fri Feb 17 07:14:08 2017 Checker run found 1 new persistent data failures 4 查看现在数据库状态 发现数据库处于nomount状态可以直接拷贝控制文件解决 5复制控制文件 [root@cuug prod]# cp /u01/oradata/prod/control02.ctl /u01/oradata/prod/control01.ctl 6 重启数据库 SYS@ prod>alter database mount; Database altered. SYS@ prod>alter database open; Database altered. （二）所有的控制文件丢失 1 为了安全期间可以先将所有的控制文件dump到trace中 SYS@ prod>alter database backup controlfile to trace; Database altered.

oracle数据库文件(控制文件、数据文件、日志文件)移动位置实验

26、数据库文件移动实验 数据库文件移动一般发生在软件硬件升级或者优化I/O性能的时候。 数据库文件包括控制文件、数据文件和日志文件 一、控制文件移动 1、查看控制文件位置 SQL>select name from v$controlfile; 2、 Alter system 命令修改控制文件位置 SQL>alter system set control_files=’c:\oracle\product\10.2.0\oradata\orcl\control01.ctl’, ‘d:\ control02.ctl’, ‘e:\ control03.ctl’ Scope=spfile; 3、关闭数据库 4、在操作系统中将控制文件拷贝到指定的位置 SQL>host copy c:\oracle\product\10.2.0\oradata\orcl\control02.ctl ,d:\ control02.ctl SQL>host copy c:\oracle\product\10.2.0\oradata\orcl\control03.ctl ,e:\ control03.ctl 5、启动数据库 6、查询控制文件位置 SQL>select name from v$controlfile; 7、删除没有用的控制文件 二、数据文件移动 1、查看数据文件位置 SQL>select name from v$datafile; 2、关闭数据库 3、在操作系统中将数据文件移动到指定的位置 SQL>host copy c:\oracle\product\10.2.0\oradata\user01.dbf, e:\user01.dbf 4、以mount模式启动数据库 5、用alter database rename file命令更改数据文件位置 SQL>alter databas e rename file ’ c:\oracle\product\10.2.0\oradata\user01.dbf’to ‘e:\user01.dbf’; 6、打开数据库 7、查看数据文件位置 SQL>select name from v$datafile; 三、日志文件移动 1、查看日志文件的位置 SQL>select member from v$logfile; 2、关闭数据库 3、在操作系统中移动日志文件位置 SQL>host copy c:\oracle\product\10.2.0\oradata\redo02.log，e:\redo02.log SQL>host copy c:\oracle\product\10.2.0\oradata\redo03.log，f:\redo03.log 4、关闭数据库 5、以mount模式启动

Oracle控制文件

Oracle控制文件 原理： 在启动数据库实例的时候，Oracle会根据初始化参数的查找控制文件，并读取控制文件中的內容，然后根据控制文件中的信息(数据库名称、数据文件、日志文件的名称和位置)在实例和数据库之间建立起联系。 控制文件一般是一个很小(大小在10M范围内)的二进制文件，含有数据库结构信息。可以将控制文件理解为物理数据库的一个元数据存储库。控制文件在数据库创建时被自动创建，在数据库发生物理变化时更新。只有Oracle进程才能够安全的更新控制文件的內容，所有任何时候都不要视图手动编辑控制文件。 控制文件记录对应数据库的结构信息和数据库当前的参数设置，其主要內容包含如下 A.数据库名称和SID标识 B.数据文件和日志文件列表（包括文件名称和对应路径信息） C.数据库创建的时间戳 D.表空间的信息 E.当前重做日志文件序列号 F.归档日志信息 G.检查点信息 H.回滚段(UNDO SEGMENT)的起始和结束 I.备份数据文件信息 为了保护控制文件:实行多路复用控制文件和备份控制文件 多路复用控制文件：指在系统不同的位置上同时存放多个控制文件的副本，在这种情况下，如果多路复用控制文件的某个磁盘发生物理损害导致其所包含的控制文件损坏，数据库将被关闭（在实例启动的情况下），此时就可以利用另一个磁盘中保存的控制文件来恢复被损坏的控制文件，然后重启数据库。 实现多路复用的两个步骤： 1.更改Control_files参数 alter system set control_files= 'F:\APP\ADMINISTRATOR\ORADATA\SMLORCL\CONTROL01.CTL', 'F:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\SMLORCL\CONTROL02.CTL', 'F:\OOOO\CONTROL03.CTL' scope=spfile; 2.复制控制文件 A.退出sqlplus环境 B.进入服务关闭OracleServiceORCL和OracleDBCConsoleORCL服务，手动停止这些服务。

Oracle丢失归档日志文件的数据库恢复方法

Oracle丢失归档日志文件的数据库恢复方法 丢失归档日志文件的数据库恢复方法，从一个不能正常打开的数据库(由于一个/多个数据库文件与其他文件不一致)中提取数据。场景：一个磁盘损坏了并且丢失了一个数据库文件。从一周前的热备转储数据文件，不幸的是丢失了几个归档日志文件。但是有问题的数据文件包含了最重要的表，如何能够挽救数据呢? 每个DBA都知道这是有问题的，一定会丢失数据，因为某些事务丢失了，问题是会丢失多少数据?Oracle 使用硬线路位置并且由于存在完整性约束问题，因此不允许正常打开数据。但是如果使用非常规的方法让Oracle删除其硬线路属性，那么应该能够提取尽可能多的数据。而通常这会比损失全部数据要好很多。 详细过程通常如果仅仅丢失了堆表的索引，或者某些能够很容易重建的数据，那么最好的方法应该是删除表空间并重建这些对象然后重新输入。但是如果丢失的数据文件包含了重要数据并且很难恢复，而且只有前一次的备份却又丢失了某些归档日志，那么用户可能希望能够尽可能多的从有问题的表空间恢复数据并且删除和重建表空间。 主要的步骤如下： 1. 对当前拥有的数据进行一个冷备; 2. 转储丢失的数据库文件备份并应用可以应用的日志; 3. 设置未文档化的初始化参数，其允许你在当前状态打开数据库; 4. 执行exp并提取全部可以从有问题的表空间提取的数据; 5. 从先前的冷备转储数据库; 6. 使毁坏的数据文件offline; 7. 执行exp并提取第4步没有提取的额外数据; 8. 在一次从冷备转储; 9. 删除有问题的表空间; 10. 重建有问题的表空间; 11. 使用第四步和第七步提取的数据重建数据; 使用案例描述：ORDTAB表空间的一个数据文件ordtab03.dbf毁坏，其包含很多ORDERS表的分区，数据文件热备于July 4，2004，July 4—至今的某些归档日志丢失。 第一步：备份数据库第一步的任务是冷备当前拥有的任何数据文件，在线重做日志，和控制文件。如果丢失了一个/多个数据文件但是数据库仍然是open的，那么对每个剩余的数据文件进行热备并确保备份期间/之后的归档被安全保存。

oracle几个重要文件位置查看

oracle参数文件、控制文件、数据文件、日志文件存放位置查看 1.参数文件和网络连接文件 SQL>show parameter spfile; NAME TYPE VALUE ----------------------------------------------------------------------------- spfile string/u01/app/oracle/product/11.2.0/db home_2/dbs/spfiledemo.ora 其他参数文件也同样位于$ORACLE_HOME/dbs目录中; 网络连接文件位于$ORACLE_HOME/network/admin目录中; 2.控制文件 SQL>select*from v$controlfile; STATUS NAME IS_RECOVERY_DEST_FILE BLOCK_SIZE FILE_SIZE_BLKS --------------------------------------------------------------------------------------- --------------------------------------------- /u01/app/oracle/oradata/demo/control01.ctl NO16384594 /u01/app/oracle/flash_recovery_area/demo/control02.ctl NO16384594 3.数据文件 SQL>select FILE_NAME from dba_data_files; FILE_NAME --------------------------------------------------------------------------------

Oracle-dataguard的3种创建方法

Oracle Dataguard的3种创建方法 一）总介： 1. 冷备法 优点：操作比较简单。 缺点：操作过程需要停止主库服务。 简介：停止主库后，直接copy主机的所有数据文件，控制文件，归档日志文件，参数文件(spfile)到备机的相同路径下，再启动主、备库，然后修改相关配置文件完成主备自动同步。 2. 热备法 优点：无需停止主库服务。 缺点：操作比较复杂，操作过程对主库性能影响比较大。 简介：在主库开启状态下把主库的数据文件一个一个热备出来，然后连同控制文件，归档日志文件，参数文件（spfile）等一起复制到备机相同路径下，再启动备库并执行recover，然后修改相关配置文件完成主备自动同步。 3. RMAN复制法 优点：无需停止主库服务，操作过程对主库性能影响比较小。 缺点：操作比较复杂。

简介：在主库开启状态下运行rman，对主库进行全库备份，然后把备份集与参数文件（spfile）一起复制到备机，再启动备库到nomount状态后利用rman 在备机上进行for standby的duplicate，然后修改相关配置文件完成主备自动同步。 无论上述何种方法，在开始之前，都必须先确认主库已正常运行，备机的操作系统，磁盘分区，oracle版本都必须与主机完全一致，备机上的oracle需要已安装好但不用建库。主、备机的网络都必须已联通，并能够在客户端使用putty 或其他远程登陆工具通过ssh方式登陆（本文内所讲的“登陆”都是指：使用putty 通过ssh方式以oracle账号登陆到主机或者备机的linux系统）。 本文假设主机ip地址是192.168.0.1，备机ip地址是192.168.0.2，oracle的数据文件，控制文件，联机日志文件的存放路径统一为：/opt/oracle/oradata/orcl/，归档日志的存放路径为：/opt/oracle/oradata/orcl/archive/，ORACLE_BASE目录为：/opt/oracle ，ORACLE_HOME目录为：/opt/oracle/product/9ir2， ORACLE_SID=orcl，分区/opt由于要存放oracle的所有文件与备份集，所以其容量要足够大。 确认主库是否开启了归档模式。 sqlplus ‘/as sysdba’ SQL> archive log list Database log mode Archive Mode Automatic archival Enabled 若如上显示，则说明已开启了归档模式，那么从现在开始到最后dataguard建立完毕的整个过程，对主库都没有任何影响，即不会影响主库的正常运行。 如果与上面所示不同，则需要手工开启归档模式。 开启归档模式方法： SQL>alter system set log_archive_start=true scope=spfile; SQL>shutdown immediate; SQL>startup mount; SQL>alter database archivelog; SQL>alter database open; 二）方法一详细操作步骤：