Oracle管理中的2GB问题精选.doc

Oracle管理中的2GB问题 本文描述2GB的问题。它阐述了为什么2GB 是一个关键数字并且给出了如果文件大于2GB 时一些你需要知道的东西。 本文主要阐述在Unix 系统上的2GB 问题。 讨论的主题： 为什么2GB 是一个特别的数字 为什么使用2GB 的数据文件 Export 和2GB SQL*Loader 和2GB ORACLE 和其他2GB 问题 其他 为什么2GB 是一个特殊的数字 许多CPU 和系统调用接口(API)使用32 位的字（word）。这个32 位就在许多系统上带来了限制。在许多情况下，标准文件操作的API 使用32 位有符号word 来指定文件大小和在文件中的相对位置。有符号的32 位word 使用最高位为符号位，因此31 位所能表示的最大值就是0x7FFFFFFF（+），比2GB 小1。 2GB 或大于2GB 的文件统称“大文件”。所以在32 位环境中就会遇到许多问题。为了克服这些问题，现在的操作系统大多使用64 位定义了新的系统调用。新版本的ORACLE使用了这些接口但是在处理“大文件”时还是有许多问题是需要注意的。 另一个比较特殊的数字是4GB，0xFFFFFFFF 作为无符号字所能表示的最大值就是，比4GB 少1。加1 则造成低32 位变为0x 和一个进位，在32 位体系中这个进位会被丢掉，因此4GB 是另一个可能会发生问题的数字。 32 位影响着ORACLE 的许多方面。为了使用大文件，你需要： 1.操作系统支持2GB+的文件或裸设备 2.操作系统具有支持操作2GB+文件IO 的API 3.ORACLE 使用这些API 这对ORACLE 意味着什么？ 现今，大多数平台支持大文件并且有64 位的API。从ORACLE 7.3 开始通常就使用这些API 了，但是这依赖于平台、操作系统和ORACLE 的版本。在多数情况下大文件支持是可行的，但在某些情况下需要一个专门的patch。在本文写作时，在ORACLE 中还有一些工具没有使用这些新的64 位API，比如export，SQL*LOADER，当然这是依赖于平台的具体操作系统数据库版本的。 为什么使用2GB+的数据文件 这里我们总结出使用大文件/设备作为ORACLE 的数据文件的好处和缺点： 好处： 在大多数平台上，ORACLE7 最大支持1022 个数据文件。每个文件如果小于2GB，那数据库最大也超不过2044GB。（在ORACLE8 上这不是问题，ORACLE8 支持每个表空间1022 个文件）。大文件的使用可以突破2044GB 的限制。对相对小的数据库来讲，大文件意味着更少的文件。也就意味着较少的文件处理及所需资源。 缺点： 恢复的单位更大。一个2GB 的文件需要15 分钟到一个小时的备份/恢复时间（依赖于备份介质和磁盘速度）。一个8GB 的文件需要此时间的4 倍。 并行备份/恢复操作会受影响。可能有操作系统特殊的限制：比如大于2GB 的部分，也许异步IO 只能串行(serialised)操作了。 操作大于2GB 的文件也许需要补丁（patch），特殊的配置等，相对小文件来讲无形中引入了许多不可测因素，比如在一些AIX 中。 使用大文件时需要注意的几点： 向操作系统厂商确认是否支持大文件并且如何配置他们 向操作系统厂商确认可支持的最大实际文件大小 向ORACLE 支持确认是否需要补丁或在你的平台上（硬件、操作系统、ORACLE） 是否有什么限制 当你升级操作系统或ORACLE 时，检查以上所提。 确认是否正确的设置了系统以允许所有用户能使用大文件 确认备份脚本能处理大文件 注意还有一个使用大文件的限制。文件大小的具体数值依赖于数据库的 DB_BLOCK_SIZE 和平台。在大多数平台上（Unix， NT ，VMS），文件大小限制为 *DB_BLOCK_SIZE。请查看Alert [NOTE:.1]中的详细记录 重点注意事项： 当允许文件自动增长时需要特别小心。对AUTOEXTEND 的文件限制MAXSIZE 小于 2GB 是明智的。否则，由于[BUG:]，当文件增长超过ORACLE 不能处理时可能会出现ORA-600[3292]等错误。 大多数平台上ORACLE 的数据文件包含一个特殊的头数据块，所以创建一个2GB 的文件，实际需要大于2GB 的空间。在Unix 平台上，这个头大小通常DB_BLOCK_SIZE， 但在裸设备上可能会更大。 2GB 的相关ORACLE 错误： ORA-01119 Error in creating datafile xxxx ORA-27044 unable to write header block of file SVR4 Error: 22: Invalid argument ORA-19502 wr