Oracle 10g大文件表空间(转)

 

简单介绍

 

Oracle 10g 的存储能力有了显著的增强。这表现在很多方面，下面介绍 10g 新增的表空间类型：大文件 (Bigfile) 表空间。

 

大文件表空间从某种角度来说提高了 Oracle 在 VLDB 上的管理能力。只有自动段空间管理的 LMT (Locally Managed Tablespaces ) 支持 BIGFILE 表空间。大文件表空间只能包含一个文件，但是文件可以达到 4G 个数据块大小。(以下用 BFT 指代 BIGFILE Tablespace。)

 

BFT 可以和以下存储技术结合使用：

 

·         自动存储管理(ASM)

 

·         LVM

 

·         OMF

 

理论上的 BFT 可以达到下面所列的值：

 

数据块大小(单位：K)	BFT 最大值(单位：T)
2k	8T
4k	16T
8k	32T
16k	64T
32k	128T

 

在实际环境中，这还受到操作系统的文件系统的限制。

 

BFT基本操作

 

10g 数据库在创建的时候，会指定默认的表空间类型。如果不特殊指定的话，默认为 SMALLFILE 类型的表空间。

 

SQL> SELECT *

  2    FROM database_properties               

  3   WHERE property_name = 'DEFAULT_TBS_TYPE';

 

PROPERTY_NAME        PROPERTY_VALUE  DESCRIPTION

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

DEFAULT_TBS_TYPE     SMALLFILE       Default tablespace type

 

这种情况下，如果我们创建表空间的时候不指定类型，那么默认创建的都是 SMALLFILE 类型的表空间。可以通过 ALTER DATABASE 命令来修改数据库默认的表空间类型：

 

SQL> ALTER DATABASE SET DEFAULT bigfile TABLESPACE;

 

Database altered.

 

SQL> SELECT *

  2      FROM database_properties               

  3     WHERE property_name = 'DEFAULT_TBS_TYPE';

 

PROPERTY_NAME        PROPERTY_VALUE  DESCRIPTION

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

DEFAULT_TBS_TYPE     BIGFILE         Default tablespace type

 

SQL>

SQL> ALTER DATABASE SET DEFAULT smallfile TABLESPACE;

 

创建 BIGFILE 类型的表空间，只需指定额外的一个参数 BIGFILE 即可，其他和原有创建表空间语法类似：

 

CREATE BIGFILE TABLESPACE bftbs

    DATAFILE '/u01/app/oracle/oradata/DEMO/bftbs01.dbf' SIZE 5M;

 

DBA_TABLESPACES (USER_TABLESPACES)与 V$TABLESPACE 这两个视图可以查看 BIGFILE 表空间的相关信息。先看看 DBA_TABLESPACES 在 10g 中有了什么变化：

 

SQL> desc DBA_TABLESPACES

 Name                                      Null?    Type

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

 TABLESPACE_NAME                           NOT NULL VARCHAR2(30)

 BLOCK_SIZE                                NOT NULL NUMBER

 INITIAL_EXTENT                                     NUMBER

 NEXT_EXTENT                                        NUMBER

 MIN_EXTENTS                               NOT NULL NUMBER

 MAX_EXTENTS                                        NUMBER

 PCT_INCREASE                                       NUMBER

 MIN_EXTLEN                                         NUMBER

 STATUS                                             VARCHAR2(9)

 CONTENTS                                           VARCHAR2(9)

 LOGGING                                            VARCHAR2(9)

 FORCE_LOGGING                                      VARCHAR2(3)

 EXTENT_MANAGEMENT                                  VARCHAR2(10)

 ALLOCATION_TYPE                                    VARCHAR2(9)

 PLUGGED_IN                                         VARCHAR2(3)

 SEGMENT_SPACE_MANAGEMENT                           VARCHAR2(6)

 DEF_TAB_COMPRESSION                                VARCHAR2(8)

 RETENTION                                          VARCHAR2(11)

 BIGFILE                                            VARCHAR2(3)

 

SQL>

 

和 9i 相比， DBA_TABLESPACES 视图多了两列：RETENTION 和 BIGFILE。其中 BIGFILE 列说明该表空间是否为 BFT：

 

SQL> SELECT tablespace_name, bigfile

  2    FROM dba_tablespaces;

 

TABLESPACE_NAME                BIG

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

SYSTEM                         NO

UNDOTBS                        NO

SYSAUX                         NO

TEMP                           NO

USERS                          NO

EXAMPLE                        NO

TEST                           NO

BFTBS                          YES

 

8 rows selected.

 

V$TABLESPACE 视图相对 9i 也增加了新的列：

 

SQL> desc V$TABLESPACE

 Name                                      Null?    Type

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

 TS#                                                NUMBER

 NAME                                               VARCHAR2(30)

 INCLUDED_IN_DATABASE_BACKUP                        VARCHAR2(3)

 BIGFILE                                            VARCHAR2(3)

 FLASHBACK_ON                                       VARCHAR2(3)

 

其中 FlASHBACK_ON 和 BIGFILE 列都是新增的。

 

BFT 属性

 

BFT有一些特有的属性。

 

1.每个表空间只能包含一个数据文件。如果试图添加新的文件，则会报告 ORA-32771 错误：

 

SQL> ALTER TABLESPACE bftbs

  2  ADD DATAFILE '/u01/app/oracle/oradata/DEMO/bftbs02.dbf' SIZE 5M;

ALTER TABLESPACE bftbs

*

ERROR at line 1:

ORA-32771: cannot add file to bigfile tablespace

 

2.只有自动段空间管理的 LMT (locally managed tablespaces ) 支持 BFT

 

SQL> CREATE BIGFILE TABLESPACE bftbs02

  2      DATAFILE '/u01/app/oracle/oradata/DEMO/bftbs02.dbf' SIZE 5M

  3  EXTENT MANAGEMENT DICTIONARY;

CREATE BIGFILE TABLESPACE bftbs02

*

ERROR at line 1:

ORA-12913: Cannot create dictionary managed tablespace

 

 

SQL> CREATE BIGFILE TABLESPACE bftbs02

  2          DATAFILE '/u01/app/oracle/oradata/DEMO/bftbs02.dbf' SIZE 5M

  3      SEGMENT SPACE MANAGEMENT MANUAL;

CREATE BIGFILE TABLESPACE bftbs02

*

ERROR at line 1:

ORA-32772: BIGFILE is invalid option for this type of tablespace

 

 

3.相对文件号(RELATIVE_FNO)为1024 ( 4096 on OS/390)

 

因为BFT只有一个数据文件，所以其相对文件号也是固定的:1024

 

SQL> SELECT tablespace_name, file_id, relative_fno

  2    FROM dba_data_files;

 

TABLESPACE_NAME                   FILE_ID RELATIVE_FNO

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

USERS                                   4            4

SYSAUX                                  3            3

UNDOTBS                                 2            2

SYSTEM                                  1            1

EXAMPLE                                 5            5

TEST                                    6            6

BFTBS                                   7         1024

 

7 rows selected.

 

SQL>

 

4.rowid的变化

 

在 BFT 上存储的表的 ROWID 与 smallfile 表空间上的 rowid 结构有些不同的。要正确得到 rowid 信息，dbms_rowid 包增加了一个新的参数　ts_type_in　来解决这个问题。参考这个范例：

 

SQL> SELECT DBMS_ROWID.rowid_block_number (ROWID, 'BIGFILE')

  2    FROM foo;

 

DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID,'BIGFILE')

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

                                            24

 

SQL>

 

你可以创建多大的表空间?

 

我们在前面提及，BFT 还受到操作系统的文件系统的限制。下面我们以 Linux 操作系统为例：

 

SQL> SHOW parameters db_block_size

 

NAME                                 TYPE        VALUE

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

db_block_size                        integer     8192

SQL>

 

也就是说，理论上我们可以创建最大 32T (4G*8K) 的表空间。我们可以做到么?

 

SQL> CREATE BIGFILE TABLESPACE bftbs02

  2      DATAFILE '/u01/app/oracle/oradata/DEMO/bftbs02.dbf' SIZE 20T reuse;

CREATE BIGFILE TABLESPACE bftbs02

*

ERROR at line 1:

ORA-01119: error in creating database file '/u01/app/oracle/oradata/DEMO/bftbs02.dbf'

ORA-27059: could not reduce file size

Linux Error: 27: File too large

Additional information: 2

 

SQL>

 

注意我们得到的操作系统信息(黑色部分)：File too large 。这说明超出了操作系统允许值。我所用的环境是Fedora Core Linux, 内核的版本是2.6.9，文件系统是 EXT3 。2.4以后的版本的内核都是支持 LFS (Large File Support)的。

 

文件系统(块)	文件大小限制	文件系统大小限制
ext2/3 (2K)	256G	8T
ext2/3 (4K)	2T	16T
ext2/3 (8K)	64T	32T
ReiserFS 3.6	1E	16T

 

我们检查一下OS文件系统块大小：

 

[root@FC3 ~]# tune2fs -l /dev/hda7 | grep Block

Block count:              2621440

Block size:               4096

Blocks per group:         32768

[root@FC3 ~]#

 

也即，我们可以在操作系统上创建不大于 2T 的文件。虽然我们没有那么大的存储空间，不妨也测试一下：

 

SQL> CREATE BIGFILE TABLESPACE bftbs02

  2      DATAFILE '/u01/app/oracle/oradata/DEMO/bftbs02.dbf' SIZE 1800g;

 

在另外一个终端中，观察该目录的变化情况：

 

[root@FC3 DEMO]# ls -ltr

total 1159048

-rw-------  1 oracle oracle       5251072 Nov 28 20:05 bftbs01.dbf

-rw-------  1 oracle oracle 1932735291392 Nov 28 20:49 bftbs02.dbf

[root@FC3 DEMO]#

 

哇，我们真的能观察到Oracle在创建“超大”文件呢，接近1.8T 的文件 :-) 要过一会儿，Oracle 才会报告错误(毕竟1800G 的大文件):

 

CREATE BIGFILE TABLESPACE bftbs02

*

ERROR at line 1:

ORA-19502: write error on file "/u01/app/oracle/oradata/DEMO/bftbs02.dbf",

blockno 898048 (blocksize=8192)

ORA-27072: File I/O error

Additional information: 898047

 

可见，在本例中，由于操作系统文件系统的限制，我们只可以创建2T以下的 BFT。

 

你需要BFT么?

 

应用 BFT 的话，优点缺点都存在。根据 Oracle 官方的文档，DB_FILES 和 MAXDATAFILES 这两个参数的值给 SGA 带来的压力会减轻(原来的压力就很大么?)。数据库中最大数据文件数是有限的 (64K files)，BFT 的出现的确对海量数据库有一定的积极意义。从一定程度上来说，BFT 简化了管理多个数据文件的复杂性，但是在恢复的时候可能是一场灾难。

 

在笔者看来，至少我们现在在大多数情况下不需要用 BFT 。"你要把鸡蛋都放到一个篮子里么? "