ITPUB电子杂志

暂无签名

  • 博客访问: 10541367
  • 博文数量: 2
  • 用 户 组: 普通用户
  • 注册时间: 1970-01-01 08:00
个人简介

鏆傛棤浠嬬粛

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(2)

文章存档

2004年(2)

我的朋友
微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: Oracle

本文描述"2GB"的问题。它阐述了为什么2GB 是一个关键数字并且给出了如果文件大于2GB 时一些你需要知道的东西。
本文主要阐述在Unix 系统上的2GB 问题。
讨论的主题:
   为什么2GB 是一个特别的数字
   为什么使用2GB 的数据文件
   Export 和2GB
   SQL*Loader 和2GB
   ORACLE 和其他2GB 问题
   其他[@more@]

为什么2GB 是一个特殊的数字
      许多CPU 和系统调用接口(API)使用32 位的字(word)。这个32 位就在许多系统上带
来了限制。在许多情况下,标准文件操作的API 使用32 位有符号word 来指定文件大小和
在文件中的相对位置。有符号的32 位word 使用最高位为符号位,因此31 位所能表示的最
大值就是0x7FFFFFFF(+2147483647),比2GB 小1。
      2GB 或大于2GB 的文件统称“大文件”。所以在32 位环境中就会遇到许多问题。为了
克服这些问题,现在的操作系统大多使用64 位定义了新的系统调用。新版本的ORACLE
使用了这些接口但是在处理“大文件”时还是有许多问题是需要注意的。
      另一个比较特殊的数字是4GB,0xFFFFFFFF 作为无符号字所能表示的最大值就是
4294967295,比4GB 少1。加1 则造成低32 位变为0x00000000 和一个进位,在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),文件大小限制为
4194302*DB_BLOCK_SIZE。
请查看Alert [NOTE:112011.1]中的详细记录
重点注意事项:
     当允许文件自动增长时需要特别小心。对AUTOEXTEND 的文件限制MAXSIZE 小于
2GB 是明智的。否则,由于[BUG:568232],当文件增长超过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 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
Export and 2Gb
2Gb Export File Size
本文写作时大多数的export 版本使用默认的文件处理API 来创建export 文件。这意味
着在相当多的平台上,不能导出大于2GB 的文件。
以下是一些克服的方法:
通常可以导出大于2GB 的文件到裸设备上。
在Unix 上可以使用命名管道来压缩/分割文件
可以导出到磁盘上
ORACLE8i 允许导出到多个文件而不是一个大的文件
(译:方法可参考文章结尾处补充)
其他的2GB 导出问题
ORACLE 最大extent 的大小为2GB.不幸的是许多发行版本的ORACLE 中的export
都有一个问题,就是当指定compress=y 时,可能导出的文件中其Next 存储子句会出现大
于2GB 的情况。这会导致即使指定了ignore=y 时,import 也会出错。本问题可参见
[BUG:708790]和[NOTE:62436.1]
典型的2GB+时export 错误:
. . exporting table BIGEXPORT
EXP-00015: error on row 10660 of table
BIGEXPORT,
column MYCOL, datatype 96
EXP-00002: error in writing to export file
EXP-00002: error in writing to export file
EXP-00000: Export terminated unsuccessfully
在[BUG:185855]中还提到了一个问题:当导出全库时产生的create tablespace 命令会
使用bytes 作为单位。当import 时,生成的数据文件若大于2GB,可能导致ora-2237 错误。
解决办法是先创建表空间(用M 代替bytes),然后导入文件。
导出到磁带
export 中的volsize 参数最大到4GB.在一些平台上只有2GB。
8i 中已经修改了本问题。[BUG:490190]描述了本问题。
SQL*Loader and 2Gb
典型的,当SQL*Loader 打开一个大于2GB 的输入文件时会报如下错误:
SQL*Loader-500: Unable to open file (bigfile.dat)
SVR4 Error: 79: Value too large for defined data type
[NOTE:30528.1]中的例子可以修改后用于大的输入文件。
ORACLE 8.0.6 提高了对大的discard 和log 文件的支持。但最大的输入文件依平台不
同而不同。
[BUG:948460]详细描述了输入文件的限制。
[BUG:749600]介绍了最大的discard 文件大小。
ORACLE 和其他2GB 问题
下面列出了其他的2GB 问题
-从ORACLE 8.0.5 开始可以在大多数平台上使用64 位ORACLE 8.0.5 README 文件介
绍了这些。见[NOTE:62252.1]
-DBV 也许不能扫描大于2GB 的文件,并报“DBV-100”错。见[BUG:710888]
-在建立大于2GB 文件时,SQL 命令 datafile ... Size xxxxx 必须用‘M’ 或‘K’,否则
报错‘ORA-02237’:invalid file size
-在ORACLE 7.3.4 之前表空间的quotas 不能超过2GB。如:
Eg:ALTER USER QUOTA 2500M ON
reports
ORA-2187: invalid quota specification。见[BUG:425831]
解决办法是赋予unlimited tablesapace 权限。
-使用spool 时如果spool 出的文件超过2GB 也许会报错。
其他
具体各平台上文件大小限制
Platform                     See
~~~~~~~~ ~~~
AIX (RS6000 / SP)     [NOTE:60888.1]
HP                            [NOTE:62407.1]
Digital Unix                [NOTE:62426.1]
Sequent PTX             [NOTE:62415.1]
Sun Solaris               [NOTE:62409.1]
Windows NT              Maximum 4Gb files on FAT
                               Theoretical 16Tb on NTFS
                               ** See [NOTE:67421.1] before using large
                              on NT with ORACLE8
                              **2 There is a problem with DBVERIFY
                              See [BUG:1372172]
                              **3 There is a problem with 8.1.6 / 8.1. 7
                              where an autoextend to 4Gb can
                              cause a crash - see [BUG:1668488]
后记:这篇文章来自metalink.ORACLE.com。本没想全文翻译的,因为其中许多详细的介
绍都要参考该网站上的许多其他文章--我也知道读者读到一个问题,可又见不到到具体的
解决方法会很恼火,但无论时间精力都不可能让我全部找来,而且似乎也没有必要,翻译了
本文就当起个头吧。
补充:
export 大文件可以采取的方法:
1. 裸设备
比如直接倒出到/dev/rlvtest 等。
2. 命名管道(Unix 下)
mknod /tmp/imp_pipe p
compress < /tmp/exp_pipe > export.dmp.Z &
exp file=/tmp/exp_pipe userid=xxx/xxx tables=...
mknod /tmp/imp_pipe p
uncompress < export.dmp.Z>/tmp/imp_pipe &
imp file=/tmp/imp_pipe userid=xxx/xxx tables=...
3. 压缩/文件拆分:(以下只在ksh 中有效:)
echo |exp file=>(compress | split -b 1024m - expdmp-) userid=xxx/xxx tables=...
echo | imp file=<(cat expdmp- * |zcat) userid=xxx/xxx tables=...
(下面由chao_ping 补充)
4.可以直接倒出到磁带
比如exp file=/dev/rmt0 ....
5。可以在ORACLE8i+版本里面,通过使用filesize 和file 相结合,倒出生成多个文件。

阅读(2083) | 评论(0) | 转发(1) |
0

上一篇:开卷首语

下一篇:没有了

给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册