我们的数据库目前只有一个FileGroup PRIMARY,其中包含大约8GB的数据(表行,索引,全文目录)。
何时将其拆分为辅助数据文件?我应该注意哪些标准?
我们的数据库目前只有一个FileGroup PRIMARY,其中包含大约8GB的数据(表行,索引,全文目录)。
何时将其拆分为辅助数据文件?我应该注意哪些标准?
Answers:
这个问题有两个部分:何时添加新的FILEGROUP,以及何时在文件组中添加新的FILE。首先让我们谈谈理论:
马克(Mark)认为最重要的原因是表现。
第二个原因是灾难恢复。使用SQL Server 2005及更高版本,可以执行文件组还原。当灾难袭来时,您可以先仅还原主文件组,然后使数据库部分联机以进行查询。在还原其他文件组时,用户可以运行查询。这对于不需要立即使用大量历史数据的数据库或需要将数据加载到当前表而无需访问历史数据的数据仓库很有用。
另一个原因是数据组的读/写配置文件。如果您有一些数据要不断写入,而其他数据却需要大量读取活动,则可以构建不同类型的存储来满足这些需求。您可以将大量写入的内容放到突袭10中,而将偏读的内容放到更便宜的突袭5中。
现在,让我们谈谈文件与文件组。在SQL Server中放置对象时,必须将它们放置在文件组级别。您可以在文件组中放置表或索引,但不能选择特定文件。因此,到目前为止,我们讨论的所有内容都与何时添加文件组有关-但是何时添加文件?
如果您正在设计存储,并且有80个硬盘驱动器,则可以通过以下几种方法进行拆分:
不同的存储子系统具有不同的性能配置文件。我曾使用过一些性能最好的SAN,这些SAN在12-16个驱动器阵列中表现最佳,而任何大于它的性能都没有改善。另一个示例是具有多路径的SAN:如果您有多个将服务器连接到存储的HBA,并且多路径软件不是真正的主动/主动,那么每个路径可能需要一个阵列才能分配负载。四个路径,四个驱动器池将在这些类型的驱动器上获得更好的性能。
在这种情况下,您最终将得到四个不同的阵列,Windows下的四个不同的驱动器(除非您使用安装点,甚至是不同的文件夹),并且SQL Server中将需要四个单独的文件。这些单独的文件可以在同一文件组中。
我还要指出,这个问题还有可恢复性/数据可用性方面。通过使用多个文件组,而不在主文件组上放置任何用户定义的对象,您可以更灵活地启用联机还原。这允许在文件组级别进行零碎还原。
2005年之后的SQL Server企业版和开发人员版中提供了联机还原
想到的另一个想法是将只读静态参考数据与事务数据分开。对于较大的数据库,这可以减少执行备份所需的时间和/或空间。