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

haitao 2015-07-27 10:22:04

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

...全文

358 点赞收藏 15

写回复

15 条回复

切换为时间正序

当前发帖距今超过3年，不再开放新的回复

发表回复

fengsuiyingdong 2015-07-30

支持9楼，学习了

回复赞

haitao 2015-07-30

引用 10 楼 Tiger_Zhao 的回复:

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

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

回复赞

Tiger_Zhao 2015-07-30

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

回复赞

haitao 2015-07-30

引用 13 楼 Tiger_Zhao 的回复:

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

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

回复赞

Tiger_Zhao 2015-07-30

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

回复赞

Tiger_Zhao 2015-07-29

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

回复赞

haitao 2015-07-29

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

回复赞

haitao 2015-07-28

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

回复赞

Tiger_Zhao 2015-07-27

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

回复赞

haitao 2015-07-27

上午发现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压缩没有执行。。。

回复赞

haitao 2015-07-27

引用 3 楼 Tiger_Zhao 的回复:

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

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

回复赞

haitao 2015-07-27

引用 2 楼 yupeigu 的回复:

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

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

回复赞

Tiger_Zhao 2015-07-27

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

回复赞