sql server单个数据文件大小的疑问

[lei_zeng]

各位大神：
最近某客户sql server 2012数据库，采用always on 三台服务器同步。
发现很多insert ，update操作超时，30多秒以上才能执行完成，即时表数据才几千行，都会超时。
检查问题时发现。单个数据文件已经达到了 750G.
后来将always on从同步改为异步，超时问题消失了。
我怀疑是三台服务器同时写750G文件，在并发量大时，响应来不及的问题。
在此，问问大神，你们用过这么大的数据库文件吗？问题是文件太大引起的吗？

[吉普赛的歌]

首先， 你的版本不太好， 2012 是首个使用 alwayson 的版本， 不够成熟。 其次， 不要认为 insert, update 就只有几千行， 你觉得只是一个小操作， 但 alwayson 需要同步的并只有你关注的操作， 还有其它处理过的数据也需要同步。 再次， 同步模式对性能的影响是显著的， 无论你数据库是大是小。 总体来说， 主要还是同步模式引起的。 几点建议： 1. 升级到 sqlserver 2014+； 2. 测试下硬盘IO, 注意是要测试数据库所在盘 https://download.csdn.net/download/yenange/9402028 如果太差， 换硬盘。 3. 一般情况下， 不要用同步模式。 另外， 你的内存多大？

[lei_zeng]

感谢答复。 1.硬盘是存储阵列柜。还有SSD作为缓存，磁盘IO当时做过检测，不是瓶颈。 2.内存64G。

引用 1 楼 吉普赛的歌 的回复:

首先， 你的版本不太好， 2012 是首个使用 alwayson 的版本， 不够成熟。 其次， 不要认为 insert, update 就只有几千行， 你觉得只是一个小操作， 但 alwayson 需要同步的并只有你关注的操作， 还有其它处理过的数据也需要同步。 再次， 同步模式对性能的影响是显著的， 无论你数据库是大是小。 总体来说， 主要还是同步模式引起的。 几点建议： 1. 升级到 sqlserver 2014+； 2. 测试下硬盘IO, 注意是要测试数据库所在盘 https://download.csdn.net/download/yenange/9402028 如果太差， 换硬盘。 3. 一般情况下， 不要用同步模式。 另外， 你的内存多大？

[吉普赛的歌]

引用 2 楼 lei_zeng 的回复:

感谢答复。 1.硬盘是存储阵列柜。还有SSD作为缓存，磁盘IO当时做过检测，不是瓶颈。 2.内存64G。

内存小了点。 这么大的库， 如果业务繁忙， 缓存都要占用很多内存， 用于同步就少了。 有些不用的历史数据， 如果能归档， 放到归档库是最好的。 改成异步， 只是不卡了而已。 如果业务繁忙， 内存小或其它（比如网络等）跟不上的情况下 延迟是必然的（其实即使是同步也会有延迟）， 你可以在 alwayson 面板上查一下延迟的情况。 当然， 如果只是做报表， 延迟几个小时也无所谓的话， 那就不怕。

[lei_zeng]

十分受教。 我准备开始限制单个数据文件的大小。先创建n个32G的小文件，让新数据写到一个不超过32G的小文件上。这样应该会更好些吧。毕竟单个750G的文件操作比32G的文件操作要慢一些吧？ 加内存花钱的事情先报领导批准一下，你懂的。

[lei_zeng]

by the way，单表超过1亿条，是不是要做表分区了？还是多建立几张表？表分区和分表效果有何差异？

[吉普赛的歌]

同步是通过日志传输、固化来完成， 并不是数据文件。 分更多文件不会让同步更快。 但对于较大数据库来说， 配置好文件组， 增加对应的数据文件会让后续的管理维护更加方便。 较大的表， 最好是分区， 分区字段一般是时间字段。 表分区与分表，当然表分区更方便，做了分表你必须用定时任务定期将历史记录放到分表。 分区表还可以将某个分区的记录一次性移到其它表， 这在归档是非常有用的。 如果没多块硬盘，并配置为相关的分区表的数据文件，分区效率不会有提高，更多的也只是方便而已。 关于分区， 三两句说不完的， 你自己必须学习相关知识。

[lei_zeng]

感谢版主持续的答复，按照您的观点是同步引起的，但这个同步已经用了2年很正常，而最近才发生timeout，
尽管是通过日志文件同步，但背后的逻辑我觉得是750G的数据文件写变慢了，造成三台同步变慢。您觉得呢？

[吉普赛的歌]

影响的因素比较多，猜测也没意思。
DBA 最好的方式就是动手， 既然你觉得是数据库文件太大造成， 何不一试？

[lei_zeng]

多谢版主，我不是dba，只是个开发菜鸟，见笑了。 在always on同步机制下，成功用过多大的数据库文件？