2Gb or Not 2Gb - File limits in Oracle (Part I)
2024-08-29 13:30:52
供稿：网友
2gb or not 2gb - file limits in oracle
翻译：kamus（seraphim）
校正：bloomit
邮件：[email protected]
日期：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
