我有一个2.8TB的SQL数据库(主要是数据文件,一些400GB的日志文件),目前大约需要9个小时才能还原。该数据库用于测试目的,必须在每次运行之间从备份中删除和还原该数据库,以确保我们始终从同一点开始。
我的问题是,该服务器当前具有12个核心和92GB的RAM,以及数据库所在的RAID 5磁盘子系统。哪些区域通常会导致SQL还原过程出现瓶颈?是磁盘,内存还是CPU?
3
您要从哪个备份介质还原?顺便说一下,与大多数其他RAID级别相比,RAID 5会产生沉重的写入损失,因此这可能不是性能测试的最佳选择。
—
克里斯·麦基翁
.bak(拆分成8个)位于要还原到的同一RAID 5阵列上,这确实使我意识到我将来可能会更好地处理该问题。我没有足够大的数组来容纳所有.bak,但我可以将它们拆分为不同的直接连接驱动器。另外,关于RAID 5的一点要点是,我已经知道了,但是我们还没有进行压力测试,因此,如果在实际负载测试期间当前磁盘驱动器出现瓶颈,那就很好了。一旦我们得到更远一点,我们将通过增加SAN,RAID 0或RAID磁盘性能1 + 0
—
肖恩·朗
当然,您也要还原驱动器上的备份会给您带来不适当的痛苦。您当前的RAID5中有多少个磁盘?
—
Mark Storey-Smith
我假设您正在使用压缩。您还使用其他哪些备份选项?您的数据如何分区?您是否能够跨文件组智能地分发数据(然后可以仅对更改后的数据进行文件组备份和还原)?
—
swasheck
问题在于测试涉及数据库的很大一部分,因此我们必须在多个文件组之间进行还原(测试会根据工作负载的需求和发展而变化)。因此,我们将不得不不断查看测试组成并还原特定的文件组。虽然这是一种选择,但我不确定它会为我们节省很多时间。
—
肖恩·朗