** 2Gb or Not 2Gb - File limits in Oracle **
翻译： Kamus （ Seraphim ）
校正： Bloomit
日期： 2004-1
经常会听说导入导出的时候，备份恢复的时候， SQL*Loader 导入数据的时候，文件超出了 2G 大小，结果导致错误。
本人文科毕业，什么二进制，十六进制，数据结构，操作系统等等的一概没有学过，所以对此问题一直都只有一个模糊的认识，今天在 metalink 上面闲逛，忽然发现了这篇文章，兴之所致，决定好好看看，看完以后，感觉对于此问题明白了很多，于是就顺便翻译成了中文，希望对大家也有所帮助。
对于本文中提及的所有其它 Notes 和 Bugs 也做了尽可能的整理（还未翻译，以后如果有时间再慢慢作），只是文中提到的一些 Bug 由于本人 Metalink 帐号的限制亦或是 Bug 的不公开性，并不能看到详细描述，对于这样的 Bug 就无法再作整理。
** 原文出处： ** ** http://metalink.oracle.com ** ** **
** Doc ID: Note:62427.1 ** ** 原文创建日期： ** ** 1998-9-2 ** ** 原文最后更新日期： ** ** 2003-8-6 **
**_ 介绍 _ ** **_ _ **
**_ _ **
本文阐述了 “2Gb” 问题，解释了为什么 2Gb 会是一个这样充满魔力的数字，并且如果你想在 Oracle 的应用中使用超过 2Gb 大小的文件，那么这篇文章也告诉了一些你应该知道的事情。
本文以 Unix 操作系统为基础，因为大部分的 2Gb 问题都发生在 Unix 上面，当然文中也提到了一些对于其它非 Unix 操作系统的相关资料，在本文的最后一节列出了各个操作系统自己的限制。
本文主题包括以下几点：
l 为什么 2Gb 是一个特殊的数字？
l 怎样使用超过 2Gb （ 2Gb+ ）的文件？
l 导出（ Export ）和 2Gb
l SQL*Loader 和 2Gb
l Oracle 和其它 2Gb 问题
l 不同操作系统上的 “ 大文件 ”(Large Files)
**_ 为什么 _ ** **_ 2Gb _ ** **_ 是一个特殊的数字？ _ ** **_ _ **
很多当前正在使用的 CPU 和 API 都使用了 32 位（ bit ）的字长，而正是这个字长对于很多操作产生了影响。
众多的场合下文件操作的标准 API 在对文件大小和文件中当前位置的处理都使用了有符号 32 位字（ 32-bit signed word ）。一个有符号 32 位字以最高位来表示正负，所以只剩下 31 位来存储真正的数值，而 16 进制中存储在 31 位中的最大正值就是 0x7FFFFFFF ，也就是 10 进制中的 +2147483647 ，这正是一个临近 2Gb 的值。
2Gb 或者更大的文件一般被称为“大文件”，当你在 32 位环境中使用 2147483647 甚至更大的数字时，你就很可能会碰到一些问题。为了解决这些问题，最新的操作系统已经重新定义了一系列完全利用 64 位寻址方式来操作文件大小和偏移量的系统函数。最新的 Oracle 发行版也已经使用了这些新的接口，但是如果在你决定要使用“大文件”以前，你仍然有不少的问题需要考虑。
另外一个特殊的数字是 4Gb 。也就是作为无符号字（ unaigned value ）的十六进制数字 0xFFFFFFFF （十进制是 4294967295 ），这是一个略小于 4Gb 的值。将该值加一将使低 4 位字节成为 0x00000000 ，同时产生 '1' 进位。这个进位在 32 位运算中将会失去。所以 4Gb 也是一个可能会产生问题的特殊数字。本文中对这个问题也有所提及。
**_ 对于使用 _ ** **_ Oracle _ ** **_ 这意味着什么？ _ ** **_ _ **
32bit 的问题在不少方面都影响到了 Oracle ，为了使用“大文件”，你需要满足以下条件：
1. 一个支持 2Gb+ 文件的操作系统或者裸设备（ Raw devices ）
2. 一个具有支持存取 2Gb+ 文件的 API 的操作系统
3. 一个使用了这些 API 的 Oracle 版本
今天大多数的平台都已经支持了大文件，并且对于这些文件有 64bit 的 API ， Oracle7.3 及以后版本一般已经使用了这些 API ，但是根据不同的平台，不同的操作系统以及不同的 Oracle 版本仍然有很多不一样的情况。在一些场合下默认就是支持“大文件”的，但是另外一些场合却可能必须要打一些补丁。
一直到写这篇文章的时候， Oracle 里面还有一些工具是没有更新到使用这些新的 API 的，比如众所周知的 EXPORT 和 SQL*LOADER ，不过仍然再次强调一下，由于平台和操作系统的不同，情况还是不一样的。
**_ 为什么要使用 _ ** **_ 2Gb+ _ ** **_ 的文件？ _ ** **_ _ **
在这一节中我们试着总结一下对于 Oracle 的数据文件使用大文件和设备（ "large" files / devices ）的优点以及缺点。
_ 使用大于 _ _ 2Gb _ _ 文件的优点： _ _ _
l 在大多数平台上 Oracle7 支持最多 1022 个数据文件。如果文件小于 2G ，那么也就是限制了数据库的大小只能是小于 2044Gb 。当然这对于支持了更多数据文件的 Oracle8 来说已经不再是个问题（ Oracle8 支持每个表空间中包含最多 1022 个数据文件）。
l 在现实情况中 Oracle7 的最大数据库尺寸会比 2044Gb 小，因为一般数据文件都存放在单独的表空间中，而很多数据文件就可能远远小于 2Gb 。使用大文件可以让数据库超越 2044Gb 的这个限制。
l 使用大文件意味着对于较小的数据库只需要管理较少的文件。
l 需要较少的文件处理资源。
_ 使用大于 _ _ 2Gb _ _ 文件的缺点： _ _ _
l 恢复的单位更大了。一个 2Gb 文件的备份和还原，根据备份媒体和磁盘速度的差异，会耗费 15 分钟到 1 个小时的时间，那么一个 8Gb 的文件就要花 4 倍这样的时间。
l 备份和恢复的并行操作新能将会收到影响。
l 会碰到一些平台特有的限制，比如说在超过 2Gb 以上异步 I/O 的操作就可能会变成线性操作。
l 处理 2Gb 以上的文件可能会需要补丁或者一些特殊的配置。相对于小文件来说也会有更大的风险性。比如在一些 AIX 的发行版上，超过 2Gb ，异步 I/O 就会使用线性操作。
_ 使用大于 _ _ 2Gb _ _ 文件的要点： _ _ _
l 跟操作系统提供商确认，大文件是否被支持，同时要如何去配置。
l 跟操作系统提供商确认，真正的最大文件限制是多少？
l 询问 Oracle 技术支持，确定对于你现有的平台，操作系统版本， Oracle 版本，是否需要什么补丁或者还有什么限制？
l 记住，如果你真的考虑对于操作系统或者 Oracle 要打一些补丁的话，那么就再检查一遍上面提到的这些问题。
l 确认对于所有要使用大文件读取的用户来说，操作系统的限制已经正确设定。
l 确认所有的备份脚本都能够处理大文件。
l 注意，对于使用超过 2Gb 的数据文件，对于最大文件大小还有一个限制。这个限制依赖于你的系统平台以及 Oracle 初始化参数 DB_BLOCK_SIZE 。在大多数平台上（包括 Unix, NT, VMS ）文件大小的限制在 4194302*DB_BLOCK_SIZE 这么大。
[NOTE:112011.1] 文档描述了改变文件大小中存在的问题，特别是超过了 2Gb 的时候。
_ 一般需要注意的要点： _ _ _
需要小心设置文件的自动扩展。明智的作法是在不使用“大文件”的场合下，将自动扩展的数据文件最大尺寸限制在 2Gb 以下。另外注意由于 [BUG:568232] 将有可能定义一个超过 Oracle 处理极限的 MAXSIZE 数值，这在 resize 之后将会引发一个内部错误（错误显示为 ORA-600 [3292] ）
在很多平台上， Oracle 数据文件的头部都包含着附加的数据块，所以创建一个 2Gb 的数据文件实际上需要比 2Gb 更多的磁盘空间。在 UNIX 平台上数据文件头部的附加数据块大小通常等于 DB_BLOCK_SIZE 的大小，但是在裸设备上可能需要占用更多一些的空间。
_ 2Gb _ _ 相关的 _ _ Oracle _ _ 错误 _ _ _
当 2Gb 限制到达的时候可能会发生下面这些错误，这些错误的产生没有特定的顺序。
ORA-01119 Error in creating datafile xxxx
ORA-27044 unable to write header block of file
SVR4 Error: 22: Invalid argument
ORA-19502 write error on file 'filename', blockno x (blocksize=nn)
ORA-27070 skgfdisp: async read/write failed
ORA-02237 invalid file size
KCF:write/open error dba=xxxxxx block=xxxx online=xxxx file=xxxxxxxx file limit exceed.
Unix error 27, EFBIG