sql server是如何使用 同文件组里mdf/ndf的？

[haitao]

sql server是如何使用 同文件组里mdf/ndf的？
一直以为，mdf如果设置了最大空间，而且满了，系统会自动使用ndf来存放新的数据的
即 某个表的一部分数据在mdf，新增的记录在ndf，无须人来操心
但是，这几天发现，mdf满了之后，ndf并没有被使用，而是直接报错了：
消息
The transaction log for database 'xxx' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

[haitao]

哦，是日志满了？ 不过ndf一直是最初设置的字节数，也是很不踏实。。。。

[LongRui888]

引用 1 楼 sz_haitao 的回复:

哦，是日志满了？ 不过ndf一直是最初设置的字节数，也是很不踏实。。。。

可能是这样的，因为一般的表 在创建时默认是存储在 主文件组的，而如果 ndf文件不在主文件组中，那么 存满后，就不会存储到ndf文件中。

[Tiger_Zhao]

仔细阅读联机帮助中关于文件组、分区、分区函数部分吧。
分区函数定义数据怎么分段。
分区（利用分区函数）定义怎么把各段存放到不同的文件组上。
最后创建的表或索引才可以使用分区，它们的数据最终才会存放到不同的文件中。

[haitao]

引用 2 楼 yupeigu 的回复:

[quote=引用 1 楼 sz_haitao 的回复:] 哦，是日志满了？ 不过ndf一直是最初设置的字节数，也是很不踏实。。。。

可能是这样的，因为一般的表 在创建时默认是存储在 主文件组的，而如果 ndf文件不在主文件组中，那么 存满后，就不会存储到ndf文件中。[/quote] 只有一个文件组（primary） 因为现有的硬盘 空间迟早不足以放，所以增加了一个硬盘，把主文件组的ndf建在新硬盘，原来的数据库文件设置了最大字节数 希望原来的硬盘的占用量不再增加，只增加对新硬盘的占用

[haitao]

引用 3 楼 Tiger_Zhao 的回复:

仔细阅读联机帮助中关于文件组、分区、分区函数部分吧。 分区函数定义数据怎么分段。 分区（利用分区函数）定义怎么把各段存放到不同的文件组上。 最后创建的表或索引才可以使用分区，它们的数据最终才会存放到不同的文件中。

已有的分区表是只使用一个文件组的 现在也仍然只有一个文件组，只是同组下面多了ndf，希望新增的数据不再增加mdf的容量，只利用ndf 没分区的表，是自动利用ndf的吧？

[haitao]

上午发现cpu一直被占了13%，才发现这个报错 同时，每天凌晨的备份（由代理执行），也一直卡着，把日志文件的限额由500M改到5G了，但备份任务还是一直在进行。。。 13%也一直保持着 【 日期 2015/6/27 2:50:23 日志 作业历史记录 (xxx 备份) 步骤 ID 1 服务器 WIN-xxxxx 作业名称 xxx 备份 步骤名称 第 1 步 持续时间 00:32:44 SQL 严重性 0 SQL 消息 ID 3014 已通过电子邮件通知的操作员 已通过网络发送通知的操作员 已通过寻呼通知的操作员 重试次数 0 消息 已以用户 NT AUTHORITY\SYSTEM 的身份执行。 已处理百分之 10。 [SQLSTATE 01000] (消息 3211) 已处理百分之 20。 [SQLSTATE 01000] (消息 3211) 已处理百分之 30。 [SQLSTATE 01000] (消息 3211) 已处理百分之 40。 [SQLSTATE 01000] (消息 3211) 已处理百分之 50。 [SQLSTATE 01000] (消息 3211) 已处理百分之 60。 [SQLSTATE 01000] (消息 3211) 已处理百分之 70。 [SQLSTATE 01000] (消息 3211) 已处理百分之 80。 [SQLSTATE 01000] (消息 3211) 已处理百分之 90。 [SQLSTATE 01000] (消息 3211) 已为数据库 'xxx'，文件 'xxx' (位于文件 1 上)处理了 23928088 页。 [SQLSTATE 01000] (消息 4035) 已为数据库 'xxx'，文件 'yyy' (位于文件 1 上)处理了 272 页。 [SQLSTATE 01000] (消息 4035) 已处理百分之 100。 [SQLSTATE 01000] (消息 3211) 已为数据库 'xxx'，文件 'xxx_log' (位于文件 1 上)处理了 2654 页。 [SQLSTATE 01000] (消息 4035) BACKUP DATABASE 成功处理了 23931014 页，花费 1963.550 秒(99.841 MB/秒)。 [SQLSTATE 01000] (消息 3014). 该步骤成功。 】 但是后面的自动rar压缩没有执行。。。

[Tiger_Zhao]

如果已经在primary文件组中，会自动利用的。
你做完全备份截断日志啊，不会一天的日志就500M吧。

[haitao]

UPDATE STATISTICS 各个表 居然快24小时了，还未完！日志文件扩张到2.8G了！

[haitao]

40个小时了。。。。不得不中止了 怀疑某个库的文件所在的磁盘（固态硬盘）是不是有问题了 因为对该库的某个查询，在23日突然慢了，本来几秒钟出结果的，现在就再也出不来了 27日重启数据库服务，这个查询就正常了 但是，半天之后，它又出不来！——sql server一直占13%的cpu 于是 更新此库的状态，但40小时了还没完，不得不中止 现在分离此库，复制库文件到另一个磁盘，试一试。。。 分离完，sql管理器都死了：没提示 无响应，但是点击没反应，界面无更新，但也不是白屏。。。 重新运行一个管理器，可以正常使用 现在，那个查询也正常了，但不知道 会不会像上次一样：没多久，又变慢。还有待观察

[Tiger_Zhao]

这倒也有可能。
固态硬盘是靠着空闲扇区轮换着写来提高寿命的，你把空间几乎占满了，写就频繁集中在小部分扇区上，容易坏。

[Tiger_Zhao]

查询慢大多是索引的问题。
重建索引或者根据查询重新设计索引。

[haitao]

引用 13 楼 Tiger_Zhao 的回复:

查询慢大多是索引的问题。 重建索引或者根据查询重新设计索引。

关键是以前很快，现在每次重启数据库服务，内存占用降下来之后，也很快 上午重启后也很快，刚刚内存占用涨上去了（同时伴随一个现象：cpu也开始长期占用13%），查询的确慢了4:30都不出来了。。。 这种是什么原因呢？ 更新此库的表状态，也是一直很慢，上次几十个小时都出不来 mssql很好用，就是遇到这种怪事（不符合常理、很难解释）就难办了 另外几个同结构的库，记录数比它多，都没出现这种情况。。。 现在查询它们，仍然3、4秒就出结果

[Tiger_Zhao]

怀疑数据碎片太多。
上大杀器了：
数据库完整备份，删除（包括文件），重建空白数据库（预开足够的空间），恢复数据库。
这时是数据碎片最少的。

[haitao]

引用 10 楼 Tiger_Zhao 的回复:

这倒也有可能。 固态硬盘是靠着空闲扇区轮换着写来提高寿命的，你把空间几乎占满了，写就频繁集中在小部分扇区上，容易坏。

那个500G的固态，还剩60G 应该还不至于这种情况 （另外，如果固态硬盘的驱动能让非空闲的数据区也参与轮转，就没这个问题了——不知道什么时候能这样实现） 今天一来，发现换了硬盘的库，又慢了，那个查询需要104秒！ 赶紧重启了一下数据库，再执行，13秒，再执行，3秒。。。可能那10秒是硬盘到内存的费时 今天的依然慢，应该证明了不是硬盘坏的原因。 那会是什么原因呢？

[枕戈待旦勇往直前]

支持9楼，学习了