原始分区是没有利用FAT32或者NTFS格式格式化的磁盘分区。也就是说，只是对硬盘进行了分区，而没有进行格式化。这种原始分区，若在微软的操作系统下，是不能够进行读取的。其实，任何操作系统，包括Linux等等，若要对硬盘进行读取，都必须要先利用格式化工具把磁盘分区格式化为一定的格式。

    但是，微软SQL Server数据库却另辟捷径，支持使用原始分区创建数据库文件。微软数据库专家之所有要如此设计，这是因为在原始分区上创建的数据库，往往可以获得比FAT32 或者NTFS分区上创建数据库文件更高的性能。所以说，这也是提高数据库性能的一种方法。通常情况下，如果数据库管理员专业只是比较强，而且企业对于数据库性能要求也比较高，则可以采用原始分区的方式来提高数据库的性能。

    其实，在原始分区中创建数据库文件步骤也是比较简单的。最困难的是，SQL Server数据库管理员需要了解，在什么情况下适合在原始分区上建立数据库文件，在什么情况下则是禁止的。这个判断，对于数据库管理员来说，可能是一个考验其能力的关口。数据库官员理员只有了解在原始分区上建立数据库文件的一些限制条件，才能够根据企业的实际情况做出正确的选择。

    根据笔者的了解，在原始分区上建立数据库文件，主要受到以下的限制。

    限制一：某些文件管理动作无法在原始分区上直接使用。

    有时候，数据库管理员往往需要对某些数据库文件进行复制或者删除等等。如对于一些事务日志，数据库管理员有时候需要对其进行手工管理。如在数据库交付使用之前，数据库管理员有可能需要手工的清空相关事务日志，保证交付给客户的是一个干净的数据库管理系统。此时，手工的把相关的事务日志删除是一个比较快捷的方法。

    但是，如果是在原始分区上建立数据库文件，则管理员就不能够像删除普通文件那样删除事务日志。因为原始分区不是微软所能够支持的分区格式，所以，微软操作系统的一些删除、复制命令在这里是无效的。也就是说，像删除、重命名、剪贴等常规文件操作，不能够在原始分区上使用。

    这是采用原始分区作为数据库文件存储地的第一个限制。

    限制二：不能够使用Windows操作系统自带的备份工具。

    有些数据库管理员希望利用Windows操作系统自带的备份工具来备份数据库系统的相关文件，如事务日志等等。当在同一个应用服务器中，同时配置有多个应用服务的话，这个微软自带的备份工具会非常的有用。因为它可以在一个统一的平台上，管理各个应用服务器关键文件的备份。而可以不采用各个应用服务器自带的备份还原工具。也就是说，微软自带的备份工具，可以不区分应用服务的出身（应用服务器供应商），而给企业系统管理员提供一个统一管理的平台，从而简化系统管理员的工作量。简单的来说，如果利用微软操作系统的备份还原工具，则即使企业没有专业的数据库管理员，系统管理员就可以通过微软自带的备份工具完成数据库的备份工具。

    但是，正如上面所说的，微软操作系统的工具（包括文件备份与还原工具），也无法读取原始分区的数据。所以，原始分区上的数据库文件（如事务日志）不能够使用Windows操作系统自带的备份使用工具进行备份。不过，数据库管理员仍然可以通过数据库服务器自带的数据库备份工具进行数据文件的日常备份，包括进行差异备份与完全备份等等。

    限制三：在一个逻辑分区上，只能够建立一个数据库文件。

    有时候，数据库管理员为了提高数据库的性能，往往会建立多个数据库文件。就像磁盘阵列一样，如此设计不但可以提高数据库的安全性。而且还可以有效降低硬盘的输入输出，从而提高数据库的性能。所以，为一个数据库建立多个数据库文件，是管理员常用的提高数据库性能的手段。

    但是，如果管理员采用的是原始分区的话，则在这方面会有所限制。此时，数据库管理员仍然可以为一个数据库建立多个数据库文件。但是，此时一个逻辑分区必须对应一个数据库文件。这主要是因为原始分区上没有文件系统可以来管理数据文件。

    在正常情况下，即在FAT32或者NTFS的分区下，数据库管理员可以把多个数据文件存放在同一个逻辑分区中，如D盘。但是，在原始分区下，一个逻辑分区只能够保存一个数据库文件。也就是说，如果数据库系统有十个数据库文件，就要建立十个原始分区。

    在通常情况下，微软操作系统最多只支持26个分区。但是，如果微软数据库系统采用原始分区的话，则没有这个限制。也就是说，数据库管理员可以把数据库设置为36个独立的数据库文件。同时，也把硬盘分为36个独立的分区。从而一个数据库文件对应一个原始分区。而没有微软操作系统的最大26个分区的限制。

    限制四：原始分区不能够自动扩充数据库。

    在通常情况下，数据库系统总是随着时间的推移而不断的增长。如用户一年后的数据与三年后的数据相比，就可以会有成倍的增长。为了节省磁盘空间，提高数据库性能，数据库管理员在起初的时候，往往不会把数据库设置的很大。在以后，可以通过数据库系统的自动扩充功能，来扩大数据库的容量。毕竟，数据库性能与数据库容量呈反向关系。

    在SQL Server数据库中，可以根据在创建数据库时所定义的增长参数，在数据库容量快满时自动扩展数据库。如默认情况下，需要事务日志会自动扩充。因为在数据库运行过程中，无法预料事务日志所需要使用的空间。而且，随着时间的推移，事务日志的容量也会越来越大。所以，如果用户成批的更改数据时，事务日志就可能会用满原有的空间。为此，数据库就会自动扩展数据库。

    但是，如果在原始分区上建立数据库文件，则不能够使用自动扩充功能。为此，数据库管理员不得不在初始化数据库的时候，就考虑其最大所需要采用的空间。或者通过手工扩充数据库文件。可见，虽然原始分区可以提高数据库性能，但是，其同时也带来了维护工作量的在增加。

    限制五：在原始分区下创建数据库文件与其他方式的不同。

    由于原始分区没有FAT32 或者NTFS文件系统，所以在这个上面建立数据库文件，跟其他文件系统上建立数据库文件略有所不同。

    如在原始分区下创建数据库文件时，数据库管理员不用指定该数据库的额外年间的物理名称，只需要指定要在其上创建数据库文件的磁盘的驱动器号。也就是说，通过空文件夹来管理原始分区。如数据库管理员先在系统分区或者其他NTFS（FAT32）分区格式上建立一个空文件夹；然后把这个空文件夹指向本地的一个驱动器；而这个本地驱动器又指向一个原始分区。如此的话，Windows系统就会给这个本地驱动器分配一个驱动器路径，而不是传统的驱动器号。如此设置后，数据库系统就可以像本地驱动器那样进行相关的操作。当然，其操作会受到以上的几个限制。在使用过程中，也需要注意一个比较小的差异。就是在为数据库系统指派路径的时候，需要注意后面加入一个反斜线符号。如数据库管理员建立了一个空文件夹BackUp，并且已经把这个文件夹指向一个原始分区。此时，管理员准备利用这个原始分区用来存放数据库备份文件，此时在进行备份作业配置时，需要填写备份路径。数据库管理员需要填入D: BackUp。后面这个反斜线符号不要忘记，不然会出现错误。

    所以，如果采用原始分区的话，其管理方式跟普通的分区格式没有多少区别。而只是某些功能上受到了限制。从笔者的使用情况来看，笔者认为采用原始分区最大的不利因素是数据库自动扩充功能受到了影响。数据库管理员要手工的扩充数据库，这无疑增加了不少的工作量。为了解决这个问题，笔者是通过SQLServer的自动监控与报警机制，当数据库相关容量如事务日志用到80%左右的时候，通过邮件等方式告知。如此笔者可以不用老是盯着数据库。故管理员要综合利弊，然后确定是否最终需要采用原始分区。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。