首页 > 数据库 > Oracle > 正文

Oracle 10g新增表空间类型:大文件表空间

2024-08-29 13:52:56
字体:
来源:转载
供稿:网友
这篇论坛文章针对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。


发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表