原文出处：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
导出（Export）和2Gb
2Gb导出文件的大小
当编写大部分版本的Export时，在创建导出文件上都是使用了默认的文件操作API。这就意味着在很多平台上根本就没有可能导出2Gb或者大于2Gb的文件系统文件（file system file）。
但是仍然有一些可选项可以用于在Export时解决2Gb的限制：
ü 将大于2Gb的文件导出到裸设备上基本上是没有问题的，当然这首先要求裸设备的大小必须能够容纳整个导出文件。
ü 导出到一个允许压缩或者切割的命名管道中（适用Unix平台）。
参看“在Unix平台上导出大于2Gb文件的快速参考”一文 [NOTE:30528.1]。
ü 导出到磁带（适用大多数平台）
参看“在Unix系统中导出到磁带”一文[NOTE:30428.1]。（这篇文章同时页详细描述了如何导出到Unix管道和远程shell中）
ü Oracle8i允许导出到多个小文件中，以替代单一的大文件。
其它的2Gb导出问题
Oracle允许区（extent）的尺寸最大为2Gb。但是不幸的是，在大多数的Oracle发行版中Export都存在这样一个问题，当你Export一个大文件，并且指定了COMPRESS=Y，那么就有可能在导出文件的NEXT存储子句中包含了一个大于2Gb的值。这样将会导致Import失败，即使是在Import时候指定了IGNORE=Y。Oracle已经在在[BUG:708790]中报告了这个问题，并且在[NOTE:62436.1]中提出了警告。
当Export碰到2Gb限制的时候，会报类似下面的错误：
. . 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为单位，如果文件大小超过2Gb，那么在导入的时候就会产生一个ORA-2237错误。这个问题可以通过在导入之前先以M为单位而不是BYTES为单位来创建表空间这样的方法来解决。[BUG:490837]也指出了相类似的问题。
导出到磁带
导出的时候VOLSIZE参数限制在4Gb以下，在有些平台上可能只有2Gb。
在Oracle8i中已经修正了这个问题。[BUG:490190]中对此问题有所描述。
SQL*Loader和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]中的例子可以稍作修改以使在SQL*Loader中使用大的输入文件。
Oracle 8.0.6在SQL*Loader中已经对discard file和log file实现了大文件支持，但是对于输入的data file在各个平台上仍然时不一样的。[BUG:948460]中记录了输入文件大小限制的详细信息。[BUG:749600]则记录了最大的discard file文件大小。
Oracle和其它的2Gb问题
这个章节列举了其它各色2Gb问题。
l Oracle 8.0.5版本以后在大部分的平台上Oracle都提供了64位的版本。从8.0.5的README文件中可以看到相应的介绍－[NOTE:62252.1]
l DBV（数据库验证程序）可能无法扫描超过2Gb的数据文件，并会报DBV-100错误。在[BUG:710888]中报告了此错误。
l 如果要在Oracle中创建大于2Gb的文件， SQL命令行的"DATAFILE ... SIZE xxxxxx"子句部分必须以M或者K作单位来指定，否则将会报"ORA-02237: invalid file size"错误。在[BUG:185855]中报告了此错误。
l 在Oracle 7.3.4发行版以前表空间的限额不能超过2Gb。比如：
ALTER USER QUOTA 2500M ON
这样将会报" ORA-2187: invalid quota specification."错误。
在[BUG:425831]中报告了此错误。解决方法是如果一个用户需要超过2Gb的限额，那么就给他赋予UNLIMITED TABLESPACE权限。
l 如果spool的输出文件达到了2Gb，那么会出现错误。比如：SQLPLUS的命令spool。
l 在Oracle工具中的一些CORE函数不支持大文件。[BUG:749600]中报告了此错误，在Oracle 8.0.6和8.1.6版本中已经修正了。但是要注意在Oracle 8.1.5和别的任何补丁中都没有修改这个错误。另外即使已经有修正，但是仍然还会有大文件限制因为不是所有的代码都使用了这些CORE函数。
注意：[BUG:749600]虽然阐明了CORE函数，但是代码的某些部分仍然有问题。比如：SQL*Loader中输入文件的读取就没有使用CORE。
l UTL_FILE包使用了上述的CORE函数，所以在没有修正的Oracle版本中仍然有2Gb限制。是一个允许在PL/SQL中进行文件存取的PL/SQL包。
特定平台中的大文件
下面是一些特定平台中关于大文件支持的参考资料。虽然我们已经努力使这些文章的资料始终保持更新，但是仍然建议在存取大文件时对每一个操作要小心谨慎地测试。
平台参考
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 NTFAT文件系统支持最大4Gb的文件
NTFS文件系统理论上支持最大16Tb的文件
1．在NT的Oracle8上使用大文件之前请先参考[NOTE:67421.1]
2．Oracle8.1.6的DBVERIFY程序有问题（参考[BUG:1372172]）
3．在8.1.6 / 8.1.7中自动扩展到4Gb时会出现问题导致数据库崩溃。（参考[BUG:1668488]）
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
导出（Export）和2Gb
2Gb导出文件的大小
当编写大部分版本的Export时，在创建导出文件上都是使用了默认的文件操作API。这就意味着在很多平台上根本就没有可能导出2Gb或者大于2Gb的文件系统文件（file system file）。
但是仍然有一些可选项可以用于在Export时解决2Gb的限制：
ü 将大于2Gb的文件导出到裸设备上基本上是没有问题的，当然这首先要求裸设备的大小必须能够容纳整个导出文件。
ü 导出到一个允许压缩或者切割的命名管道中（适用Unix平台）。
参看“在Unix平台上导出大于2Gb文件的快速参考”一文 [NOTE:30528.1]。
ü 导出到磁带（适用大多数平台）
参看“在Unix系统中导出到磁带”一文[NOTE:30428.1]。（这篇文章同时页详细描述了如何导出到Unix管道和远程shell中）
ü Oracle8i允许导出到多个小文件中，以替代单一的大文件。
其它的2Gb导出问题
Oracle允许区（extent）的尺寸最大为2Gb。但是不幸的是，在大多数的Oracle发行版中Export都存在这样一个问题，当你Export一个大文件，并且指定了COMPRESS=Y，那么就有可能在导出文件的NEXT存储子句中包含了一个大于2Gb的值。这样将会导致Import失败，即使是在Import时候指定了IGNORE=Y。Oracle已经在在[BUG:708790]中报告了这个问题，并且在[NOTE:62436.1]中提出了警告。
当Export碰到2Gb限制的时候，会报类似下面的错误：
. . 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为单位，如果文件大小超过2Gb，那么在导入的时候就会产生一个ORA-2237错误。这个问题可以通过在导入之前先以M为单位而不是BYTES为单位来创建表空间这样的方法来解决。[BUG:490837]也指出了相类似的问题。
导出到磁带
导出的时候VOLSIZE参数限制在4Gb以下，在有些平台上可能只有2Gb。
在Oracle8i中已经修正了这个问题。[BUG:490190]中对此问题有所描述。
SQL*Loader和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]中的例子可以稍作修改以使在SQL*Loader中使用大的输入文件。
Oracle 8.0.6在SQL*Loader中已经对discard file和log file实现了大文件支持，但是对于输入的data file在各个平台上仍然时不一样的。[BUG:948460]中记录了输入文件大小限制的详细信息。[BUG:749600]则记录了最大的discard file文件大小。
Oracle和其它的2Gb问题
这个章节列举了其它各色2Gb问题。
l Oracle 8.0.5版本以后在大部分的平台上Oracle都提供了64位的版本。从8.0.5的README文件中可以看到相应的介绍－[NOTE:62252.1]
l DBV（数据库验证程序）可能无法扫描超过2Gb的数据文件，并会报DBV-100错误。在[BUG:710888]中报告了此错误。
l 如果要在Oracle中创建大于2Gb的文件， SQL命令行的"DATAFILE ... SIZE xxxxxx"子句部分必须以M或者K作单位来指定，否则将会报"ORA-02237: invalid file size"错误。在[BUG:185855]中报告了此错误。
l 在Oracle 7.3.4发行版以前表空间的限额不能超过2Gb。比如：
ALTER USER QUOTA 2500M ON
这样将会报" ORA-2187: invalid quota specification."错误。
在[BUG:425831]中报告了此错误。解决方法是如果一个用户需要超过2Gb的限额，那么就给他赋予UNLIMITED TABLESPACE权限。
l 如果spool的输出文件达到了2Gb，那么会出现错误。比如：SQLPLUS的命令spool。
l 在Oracle工具中的一些CORE函数不支持大文件。[BUG:749600]中报告了此错误，在Oracle 8.0.6和8.1.6版本中已经修正了。但是要注意在Oracle 8.1.5和别的任何补丁中都没有修改这个错误。另外即使已经有修正，但是仍然还会有大文件限制因为不是所有的代码都使用了这些CORE函数。
注意：[BUG:749600]虽然阐明了CORE函数，但是代码的某些部分仍然有问题。比如：SQL*Loader中输入文件的读取就没有使用CORE。
l UTL_FILE包使用了上述的CORE函数，所以在没有修正的Oracle版本中仍然有2Gb限制。是一个允许在PL/SQL中进行文件存取的PL/SQL包。
特定平台中的大文件
下面是一些特定平台中关于大文件支持的参考资料。虽然我们已经努力使这些文章的资料始终保持更新，但是仍然建议在存取大文件时对每一个操作要小心谨慎地测试。
平台参考
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 NTFAT文件系统支持最大4Gb的文件
NTFS文件系统理论上支持最大16Tb的文件
1．在NT的Oracle8上使用大文件之前请先参考[NOTE:67421.1]
2．Oracle8.1.6的DBVERIFY程序有问题（参考[BUG:1372172]）
3．在8.1.6 / 8.1.7中自动扩展到4Gb时会出现问题导致数据库崩溃。（参考[BUG:1668488]）
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/756652/viewspace-242275/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/756652/viewspace-242275/
扫一扫
3184
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
