SQL Server:仅用于系统表的文件组?


11

我们的公司标准之一是为用户表/索引提供单独的文件组/文件。这被设置为默认值,因此不需要限定CREATE TABLE语句。

所以看起来像这样

  • fileid 1 =系统表,MDF
  • fileid 2 = t-log = LDF
  • fileid 3 =用户资料= NDF

在座的任何人都可以帮助我理解为什么要这样做的原始理由吗?


我会干净的说我是伏都教徒。上午错了......?

编辑:我知道如何使用文件组来分离索引/分区/档案,以及如何恢复零碎的文件。这个问题是关于在同一卷上仅对系统表使用单独的文件组。

Answers:


9

Microsoft的70-432培训书说:“不将任何对象放置在主文件组上的主要原因是在I / O中提供尽可能多的隔离。系统对象中的数据不会像数据那样频繁地更改通过最大程度地减少对主数据文件的写入活动,可以减少由于硬件故障而导致损坏的可能性,此外,由于主文件组的状态还决定了数据库的状态,因此可以提高可用性数据库的最大程度地减少了对主文件组的更改。”

因此,请尽可能采取该措施。其他人则说,在某些情况下这不是必需的,当然还有更多的维持。只是以为我会提供微软的理由。


合理的,一些书面证明。我会接受
gbn

1
另一个原因是,PARTIAL数据库还原允许还原PRIMARY文件组以及选定的其他文件组,从而可以更快地还原正确设计的VLDB。允许稍后恢复已存档/辅助文件组。
MartinC 2012年

@MartinC:我知道部分还原等,但是我从不理解显式分离系统表的逻辑。用于执行,归档,维护,分区等的文件组。但是系统表呢?贾里德提供了最好的解释迄今..
GBN

如果数据库整体很大,则主文件组的备份可能比主数据更常规。由于文件组备份加上尾部,因此还原仅需要尾部日志备份以及主文件组和事务日志的还原。由于系统表较小,因此与整个数据库相比,这将是一个更快的恢复过程,因此可以在发生问题时减少停机时间。
MartinC 2012年

12

这不是性能上的提高,而是可以恢复的。如果系统表中发生文件损坏,则数据库将丢失。如果将用户数据保存在一个或多个单独的文件组中,则可以仅还原那些在还原过程中保持数据库其余部分联机的文件(假设此处为Enterprise Edition)。

如果这就是为什么他们这么说,我不能说,但这是将多个文件组与PRIMARY文件组中的仅系统对象一起使用的好处。

但是,您应该踢一下垃圾,说应该启用自动收缩功能。


要了解有关此内容的更多信息,可以在联机丛书中搜索“在线零碎还原”。
布伦特·奥扎尔

1
我一直认为这也是巫毒,因为2个文件组在同一卷上(在SAN上)。腐败的风险很高吗?(实际操作的DBA设置自动收缩假)
GBN

如果存在损坏,则很可能会在一个文件中只有一个页面,因为存储在将页面写入磁盘时会出现故障。诸如99.9999%的数据库损坏之类的问题是存储问题。其余问题的1/2是内存不足,其余是SQL错误。随着数据库变大(多TB),这变得越来越重要,因为恢复多TB数据库将需要几天的时间。
mrdenny

如果系统对象仅在主文件组中,您将来是否需要这样做,我是否会认为是正确的?在另一个文件组中创建x个其他文件。通过从现有数据文件中迁移数据来按比例填充这些文件?
Ally Reilly 2012年

4

不确定我是否理解,您是否正在要求某人证明您的公司标准合理?我认为,只要是为您的公司编写标准文档的人,就可以阐明为什么要这样做。

话虽如此,对于某些商店来说,要从用户数据中分解系统数据并不罕见。而且,如果与专用磁盘集结合使用,则可以提高性能。


谢谢。不为其辩解,而是对其进行解释。这与说“自动收缩”的DB工程团队相同。给定的系统表占用了几MB,并且无论如何都会在内存中,您是否相信任何性能提升?
gbn
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.