oracle元数据存储在表空间,oracle db中数据和元数据的概念

本帖最后由 warehouse 于 2014-8-10 11:58 编辑

02年研究dw相关的产品和业务时第一次听说了元数据的概念，很多资料上是这样描述元数据的概念的：元数据是定义或者描述数据的数据。言外之意是先有元数据再有数据。在构建数据仓库前期建模的过程其实就是定义元数据的过程。如果说oltp的产生是源于业务驱动的，那么olap的产生完全是由数据驱动最终为业务服务的，他们其实最后是一个圆周，根本就没有终点，所以搞信息化，db和dw是没有尽头的，我觉得是一个闭环

闲言少叙，下面看看oracle中数据和元数据的概念，oracle中其实把数据和元数据分的非常清楚，只是没有明确的用这2个概念界定出来，在11.2版本中参数deferred_segment_creation的出现更是把元数据和数据分的非常清楚了。

--===============================

C:\>sqlplus test/test

SQL*Plus: Release 11.2.0.1.0 Production on 星期日 7月 29 19:08:15 2012

Copyright (c) 1982, 2010, Oracle.  All rights reserved.

连接到:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

With the Partitioning option

SQL> show parameter def

NAME                                 TYPE        VALUE

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

deferred_segment_creation            boolean     TRUE

SQL> create table t(id int ,name varchar2(10)) tablespace users;

表已创建。

SQL> select object_id,data_object_id from dba_objects where owner='TEST' and object_name='T';

OBJECT_ID DATA_OBJECT_ID

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

21030          21030

SQL> select count(*) from dba_segments where owner='TEST' and segment_name='T';

COUNT(*)

----------

0

--create table之后发现数据段并不存在，这就是deferred_segment_creation的作用，段被延迟创建了，正常都是在插入数据时创建的，这里发现move之后段也随即被创建了，其实表里这时候还是没有数据的，之所以move一下，主要是我观查到dba_objects中段的id在创建表的时侯已经分配好了，而并没有在创建段的时侯再分配，所以在段不存在的时侯move一下我是想验证move之后data_object_id是否会发生变化，结果是move之后data_object_id确实和段存在的情况下move的结果一样，发生了变化。

SQL> alter table t move;

表已更改。

SQL> select object_id,data_object_id from dba_objects where owner='TEST' and object_name='T';

OBJECT_ID DATA_OBJECT_ID

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

21030          21031

SQL> select count(*) from dba_segments where owner='TEST' and segment_name='T';

COUNT(*)

----------

1

SQL>

--=================================

这里大家注意create table...定义的就是元数据，元数据是存放着system表空间里的，数据是保存在我们create table时指定的表空间users里，下面简单举个例子来帮助我们理解数据和元数据：

--=================================

SQL> insert into t values(1,'a');

已创建 1 行。

SQL> insert into t values(2,'b');

已创建 1 行。

SQL> commit;

提交完成。

SQL> select * from t;

ID NAME

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

1 a

2 b

SQL> alter tablespace users offline;

表空间已更改。

SQL> select * from t;

select * from t

*

第 1 行出现错误:

ORA-00376: 此时无法读取文件 4

ORA-01110: 数据文件 4: 'E:\ORACLE\ORADATA\TEST\USERS01.DBF'

SQL> drop table t;

表已删除。

SQL>

--================================

这里清楚的看到tablespace users被offline之后，不能查询t表里面的数据，但是缺可以drop table t,原因就是drop table的时侯oracle只是删除了t的元数据，而并不会去修改表里的数据。

--================================

有关锁的情况也是一样的，用户在修改一条数据的时侯会在表上同时加上tx和tm锁，其中tm锁锁定的就是元数据，tx锁定的是数据，要想锁定数据首先要锁定元数据。防止在修改数据的时侯其它session把元数据修改了。可见在oracle里把数据和元数据的概念也是体现的淋漓尽致。E.F.CODE在提出RDBMS理论的时侯不知道是否已对这2个概念了然于胸，在他提出olap概念的时侯不知道他老人家是否对oracle熟悉，但是我们真的很敬佩这位2次获得图灵奖的关系型数据库的鼻祖是根据什么理论能够提出这么精髓的概念。我们也不知道oracle的设计者又是参照什么理论能在olap概念之前就把元数据和数据运用的如此之精妙。

真是让人震撼。

--=================================

set unused column其实也是这个道理，首先把元数据删除了(其实是重命名)，然后空闲的时侯再删除数据。

--=================================

external table的话更是做到了极致，把metadata放在db里，data直接在os上，有关external table doc上有清晰的描述：

An external table is a read-only table that is defined within the database but exists

outside of the database. In more technical terms, the external table’s metadata is

stored inside the database, and the data it contains is outside of the database.