之前接触的项目表空间最大也不超过10G,所以导入数据库时一直使用导入本地的oracle数据库文件的方法,即根据dmp文件大小设置一个数据文件,设定表空间最大值。
--创建表空间,数据文件为'F:\app\zang\oradata\orcl\charge_zang.dbf',初始大小50M,递增10M,最大递增到2G create tablespace charge_zang datafile 'F:\app\zang\oradata\orcl\charge_zang.dbf' size 50M autoextend on next 10M maxsize 2048M;
生产环境考虑到数据库可能一直增加信息,所以放开表空间大小限制,语句如下:
--改变用户表空间容量限制,不做限制 ALTER USER ankangreli QUOTA UNLIMITED ON ankangrelir_data;
但是今天开会讨论了一个问题,公司接手了一个项目,新客户原先使用的系统,数据库大小有2T,现在需要对他的数据库信息进行整理和迁移,首先的步骤是把客户的数据库导入我们的服务器,为此公司特地买了块8T的外接硬盘(不到2000块!),这按我之前的方法导入,即使放开容量限制,也会到达oracle的容量限制,因此需要换种方法来导入。
导入之前了解一些概念:
表空间数据文件容量与DB_BLOCK_SIZE有关,在初始建库时,DB_BLOCK_SIZE要根据实际需要,设置为 4K、8K、16K、32K、64K等几种大小,ORACLE的物理文件最大只允许4194304个数据块(由操作系统决定),表空间数据文件的最大值为 4194304×DB_BLOCK_SIZE/1024M。
sql查看DB_BLOCK_SIZE值
查看INITIAL_EXTENT值是DB_BLOCK_SIZE的整数倍
截取的更多DB_BLOCK_SIZE作用如下:【来源】
回到该问题,通过上面的信息我们得出:在本机单个表空间文件大小超过32G时,表空间容量就达到了最大值,数据库就不能继续增加信息了,那么该采取什么措施呢?
将表空间存储为多个数据文件,每个文件不大于32GB(精确的值为32768M)
语法如下:(不够的话继续添加数据文件)
create tablespace JC_DATA logging datafile 'F:\app\oracle\oradata\orcl\JC_DATA01.dbf' size 50m autoextend on next 50m maxsize 32767m extent management local; --为表空间增加数据文件 alter tablespace JC_DATA add datafile 'F:\app\oracle\oradata\orcl\JC_DATA02.dbf' size 50m autoextend on next 50m maxsize 32767m;
根据oracle的算法,我们很容易想到这个解决方法。数目衡定,但是db_block_size可以更改(db_block_size的最大大小为32KB)。如果把db_block_size扩大到32KB,那么我们的系统就可以支持单个数据文件最大128GB。
这个方案听起来好像很迷人,但是实际上并不是那么回事。因为要修改db_block_size并不是很容易的事。因为这个db_block_size在创建实例的时候就要指定。而且不能通过简单修改参数来指定db_block_size。db_block_size的默认值为8192 bytes,是不能被用户修改的。因为db_block_size对应于一个实例,所以意味着在数据库创建(建库)以后是不能修改的,如需修改,可行的方式是重新建库并把原库的数据export到新库。当然最好的方式是在建数据库之前就规划好,一般如果是OLTP系统,可以保持默认值;OLAP环境可以考虑适当调大。
在oracle11g中引进了bigfile表空间,他充分利用了64位CPU的寻址能力,使oracle可以管理的数据文件总量达到8EB。单个数据文件的大小达到128TB,即使默认8K的db_block_size也达到了32TB。
创建bigfile的表空间使用的sql语句和创建表空间的语句使用基本相同。
create bigfile tablespace···
需要注意的是使用bigfile表空间,它只能支持一个数据文件。也就是说这个文件的最大大小就是表空间最大大小,你不可能通过增加数据文件来扩大该表空间的大小。
参考:
http://blog.sina.com.cn/s/blog_4b1c9e12010006vj.html
https://www.cnblogs.com/gavanwanggw/p/6714388.html
https://blog.csdn.net/zhangzheng0413/article/details/8271322