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。
