ORACLE深入 第二章 Files

ORACLE深入 第二章 Files

Alert Files,Dictionary-Managed and Locally-Managed Tablespaces,Temp Files,Control Files

Online Redo Log,Change Tracking File,DMP file

日月明王的BLOG：http://sunmoonking.spaces.live.com

INSTANCRE 的配套文件

1,Parameter files: 告诉 ORACLE 在什么地方可以找到 CONTROLFILE, 内存结构等其他的 init parameters. 还包括 listener.ora,sqlnet.ora,tnsnames.ora

2,Trace files: server process 建立

3,Alert file:

DATABASE 的配套文件

1,Data files:

2,Temp files:

3,Control files: These files tell you where the data files, temp files, and redo log files are, as well as other relevant metadata about their state.

4,Redo log files:

5,Password files:

在数据库中读取 Alert Files

可以做一个 external table 来访问我们需要监控的文本文件。

SQL> create or replace directory data_dir as 'D:/oracle/product/10.2.0/admin/orcl10/bdump/'

2 /

目录已创建。

SQL> create table alert_log (text_line varchar2(255) )

2 organization external

3 ( type oracle_loader

4 default directory data_dir

5 access parameters

6 (

7 records delimited by newline

8 fields

9 reject rows with all null fields

10 )

11 location

12 (

13 'alert_orcl10.log'

14 )

15 )

16 reject limit unlimited

17 /

表已创建。

然后就可以查找我们想要的东西了

select to_char(last_time,'dd-mon-yyyy hh24:mi') shutdown,

to_char(start_time,'dd-mon-yyyy hh24:mi') startup,

round((start_time-last_time)*24*60,2) mins_down,

round((last_time-lag(start_time) over (order by r)),2) days_up,

case when (lead(r) over (order by r) is null )

then round((sysdate-start_time),2)

end days_still_up

from (

select r,

to_date(last_time, 'Dy Mon DD HH24:MI:SS YYYY', 'nls_date_language=''american''') last_time,

to_date(start_time,'Dy Mon DD HH24:MI:SS YYYY', 'nls_date_language=''american''') start_time

from (

select r,

text_line,

lag(text_line,1) over (order by r) start_time,

lag(text_line,2) over (order by r) last_time

from ( ----得到时间和ORACLE启动的记录，20表示年的前两位，有时间记录的地方都表示在发生某件事件,这里得到时间主要是想得到Starting的时间及其前后的时间，好计算这次重起用了多长时间

select rownum r, text_line

from alert_log

where text_line like '___ ___ __ __:__:__ 20__'

or text_line like 'Starting ORACLE instance %'

)

)

where text_line like 'Starting ORACLE instance %'

)

如果 ALERT 里记录没有被删减的话，结果如下

SHUTDOWN STARTUP MINS_DOWN DAYS_UP DAYS_STILL_UP

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

06-may-2004 14:00

06-may-2004 14:24 06-may-2004 14:24 .25 .02

10-may-2004 17:18 10-may-2004 17:19 .93 4.12

26-jun-2004 13:10 26-jun-2004 13:10 .65 46.83

07-sep-2004 20:13 07-sep-2004 20:20 7.27 73.29 116.83

File system 分类

1,OS

2, Raw partitions : 未创建文件系统的磁盘分区 ( raw partition ) 或逻辑卷 ( raw logical volume) ， 如何对设备上的数据读写决定于使用它的应用程序。由于对裸设备的操作不通过 UNIX 的缓冲区，数据在 ORACLE 的数据缓冲区 (BUFFER CACHE) 和磁盘之间直接传递，所以使用裸设备在一定程度上能够提高 I/O 性能，适合 I/O 量大的系统。另外 OPS/RAC (Oracle Parallel Server/Real Application Cluster) 环境下，多个节点同时访问同一个数据库，所以 CONTROL FILE 、 DATA FILE 、 REDO LOG 都必须建在 RAW DEVICE 上。

3, 自动存储管理 (ASM) 是 Oracle 数据库 10g 新特性，它为数据库管理员提供了一个简单的存储管理界面，并且该界面在所有服务器和存储平台上都是一致的。作为专门为 Oracle 数据库文件创建的垂直集成文件系统和卷管理器，ASM 提供了异步 I/O 的性能以及文件系统的易管理性。ASM 提供了可节省 DBA 时间的功能，以及管理动态数据库环境的灵活性，并且提高了效率。

在真正的海量数据库环境中， DBA 可能会花费很多的时间来作磁盘管理，比如一个表空间将占满整个磁盘， DBA 就需要再添加一块磁盘到操作系统中，然后再在新的磁盘上创建新的数据文件，如果是单个磁盘这倒不是很繁琐，问题是如果原先我们使用的是 RAID 或者说是 LVM ，那么现在大量的数据仍然是分布在以前的那些磁盘上，如果我们想让这些数据均匀地分布在以前的磁盘和新增加的磁盘上，我们可能就要耗费一天甚至几天的时间来作原先数据的导出导入。那么如果有一种方法，能实现我们就把一块磁盘加到系统里，然后告诉 Oracle 我们要用这块盘了，剩下的工作全部由 Oracle 来完成，该是多好的一件事情！幸运的是， Oracle10g 已经提供了这个功能，这就是 ASM （ Automatic Storage Management ）。我们称为 “ 自动存储管理 ” 。 Oracle10g 的 ASM 不但帮助 DBA 从繁琐的磁盘空间管理中解脱出来，而且更值得关注的是 ASM 同时提供了条带和镜像的功能，而这些功能原先需要通过单独地配置 RAID 来实现。

4. Oracle Cluster File System (OCFS)

Storage Hierarchy in an Oracle Database

ORACLE 的 STORAGE HIERARCHY 在很多书上都有提及，这里不详细说明，只是说些需要注意的地方。

TABLESPACE

SEGMENT

一个 CREATE语句可以产生0个，1个或多个SEGMENT， 比如 CREATE TABLE T ( x int primary key, y clob ) 或建立 four segments: 一个是 TABLE T , 一个是 primary key 的 , 两个是 CLOB ( 一个 LOB 一个 LOB data).

而 CREATE TABLE T ( x int, y date ) cluster MY_CLUSTER 连一个 segment 也不会建立 .

Extents

一个 segment 由一个或多个 extents 组成。

BLOCK

BLOCK 是 ORACLE 读写的最小单位（ I/O 单元）。

注意： BLOCK_SIZE 不一定必须 设置成 2 的整倍数。可以设置成 5k ， 7k 等。

Dictionary-Managed and Locally-Managed Tablespaces

dictionary-managed tablespace. 用数据字典进行管理。当需要空间时， ORACLE 会 recursive SQL 访问数据字典，发现 SPACE ，然后更新字典表中一 ROW 。对 dictionary 的 UPDATE 必须顺序进行，而不能同时进行。而这些 recursive sql 会消耗 temporary tablespaces

local-managed tablespace 用每个 data files 上的 bitmap 来管理 extents 。凡是使用的都设置为 1 ，没使用的设置成 0 。所以，我们不需要再在 DATABASE 级别顺序请求空间，而只需要在 TABLESPACE 级别顺序请求空间

EXTENT MANAGEMENT LOCAL AUTOALLOCATE 表示由ORACLE 自己管理EXTENTS 的大小。

EXTENT MANAGEMENT LOCAL UNIFORM SIZE 512K 表示EXTENTS 的大小都是512K ，每512K 占BITMAP 一个BBIT 。

9i 及以上版本，如果 SYSTEM 表空间是 locally managed ，那么其他的表空间都只能是 locally managed ，而不能是 dictionary-managed 。

SQL> select tablespace_name||' '||EXTENT_MANAGEMENT from dba_tablespaces;

TABLESPACE_NAME||''||EXTENT_MANAGEMENT

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

SYSTEM LOCAL

UNDOTBS1 LOCAL

SYSAUX LOCAL

TEMP LOCAL

USERS LOCAL

EXAMPLE LOCAL

MSSM LOCAL

7 rows selected.

SQL> create tablespace dicman datafile 'd:/oracle/product/10.1.0/oradata/wwmdb/dicman.DBF'

2 size 10M extent management dictionary;

create tablespace dicman datafile 'd:/oracle/product/10.1.0/oradata/wwmdb/dicman.DBF'

*

ERROR at line 1:

ORA-12913: Cannot create dictionary managed tablespace

Temp Files

TEMPORARY 表空间和文件

http://sunmoonking.spaces.live.com/blog/cns!E3BD9CBED01777CA!165.entry

Control Files

Parameter file 告诉 instance controlfile 在什么地方， controlfile 告诉 instance 什么地方存放 database 和 redo log file 。

Control file 也会提供一些其他的信息，比如 checkpoint ， database 的名字， database 创建的时间， archive redo log history ， RMAN 的信息等等。

Redo Log Files

当你插入，删除一条数据，则相应的行会写入 REDO LOGS 的。但是，当你 DROP 的时候，只会把 DROP 这个操作写入 REDO ，会删除一条记录从 sys.obj$ 等，而不会写入数据，这就是为什么 DDL 操作无法恢复的原因。

一些特定操作会记录很少的 REDO ，比如 CREATE TABLE 的时候用 NOLOGGING （但是 recursive SQL 还是会记录的，所以只能减少 REDO 而不能完全没有 REDO ），

Online Redo Log

先来了解下面几个重要的概念

Database buffer cache ：是 SGA 的一部份，当 BLOCKS 被读到，则 BLOCKS 会被临时保存在 BUFFER CACHE 中，以后再读到这些 BLOCK 就不需要从 DISK 读了，这时，当我们修改 BLOCK 的时候，这些修改操作会发生在 BUFFER CACHE 里，同时这些信息也会保存在 REDO LOG BUFFER 里，当我们 COMMIT 的时候， ORACLE 并不必须马上写 BUFFER CACHE 中的信息到 DISK 内，仅需要将 ONLINE REDO LOGS 的信息写到 REDO FILE 里，如果在这个时候（ BUFFER CACHE 中的信息没有 DISK 内，但是 COMMIT 已经发生）系统 DOWN 机，那么在重起的时候就需要 ONLINE REDO LOG 而不需要 BUFFER CACHE 来提供恢复的数据。 REDO 的数据足够我们再做一遍 UPDATE 操作并且 COMMIT 。所以，只要 BLOCK 被读到 CACHE 里并且被修改后没有写入 DISK ，此时 REDO LOG FILE 是不能再被使用的。

为了防止以上情况下导致 REDO LOG FILE 一直被占用而导致 process suspended ， DBWn 需要时常写 BUFFER CACHE 到 DISK 内，而大多数情况下是 CHEKCPOINT 触发 DBWn 的，而大多数情况下 CHECKPOINT 又是由 REDO LOG SWITCH 触发的。

再串起来一下，当从 REDO GROUP 1 切换到 REDO GROUP 2 的时候，发生 CHECKPOINT 。此刻， DBWn 开始把被 REDO FILE 1 保护的 BUFFER CACHE 的 DIRTY BLOCKS 写入到 DISK 中，在 DBWn 没有全部写完之前， ORACLE 不能 REUSE REDO GROUP 1 。如果此时已经开始又要使用 REDO GROUP 1 的话 ALERT.log 会记录如下错误：

Thread 1 cannot allocate new log, sequence 66

Checkpoint not complete

Current log# 2 seq# 65 mem# 0: c:/ORACLE/ORADATA/ORA10G/REDO02.LOG

出现如上错误的时候就表示 process suspended 。

防止上面的问题可以通过增加足够多的 ONLINE REDO LOG FILES ，或增大 REDO LOG FILE 的大小，或加快 DBWR 的速度。

不同的应用使用 REDO LOG 的量差别很大，比如 Decision Support System(DSS,query only) 或 DW 系统会比 OLTP(transaction processing) 系统少很多。 BLOG 也会用很多，还有用户数也会倒是 REDO 的使用是非线性的。

做出对 REDO LOG 的调整还要考虑 mean time to recover

Change Tracking File

是 Oracle 10g Enterprise Editionk 可选组件，目的就是跟踪自上一次 RMAN incremental backup 后的所有 block 的改变。在此之前的 incremental backup 都必须读完全库以发现变化的块，比如你有 1T 的数据库，每天增加 500M ，那么 RMAN incremental backup 就会读完 1T500M 来得到这 500M 的 BLOGK ，所以此时的 incremental backup 虽然能存储比全备要少很多的数据来实现备份，但是必须读整个数据库的全部数据。为了让 ORACLE 不全读已有的 1T ， ORACLE 提供了 change tracking file 去告诉 RMN 那些 BLOCK 被改变了。

可以通过如下方法启用。

alter database enable block change tracking

using file

'/home/ora10gr1/product/10.1.0/oradata/ora10gr1/ORA10GR1/changed_blocks.bct';

任何额外的工作都要消耗资源，所以在应用到生产环境前要做好测试。

通过如下命令来取消

alter database disable block change tracking;

DMP Files (EXP/IMP Files)

因为 9.2 比 9.1 多了 COMPRESS 的 DDL 参数，所以在 EXP 的时候也会带出，那么此时如果 IMP 到 9.1 的时候就会有问题。这就是为什么 EXP 的版本要低于或等于将要使用的 IMP 的版本。

DMP 文件有平台无关性 . 也就是说 WIN 的 DMP 可以用在 UNIX 上 .