February 19, 2021 at 7:35 pm
I'v not done much in the cloud because of all the crippling restrictions it imposes on SQL Server. Especially Azure SQL. Are you saying that the backend storage in Azure (or possibly AWS) is not striped across many spindles as it is with an on-prem SAN?
February 19, 2021 at 8:47 pm
It is not. They have high end storage available, but limited paths for each set of disks. Therefore, this will apply.
February 20, 2021 at 1:58 am
a bit out of topic, but sometimes you want to investigate /correct an issue on a big table in production. But you don't want to do a backup restore to another environment because of disks pace and settings you need to correct first. So I read somewhere that it is possible to move that table to anther file group, create a backup of that file group and restore that on the uat environment. It would be nice to have some blog about that to learn more.
February 22, 2021 at 1:59 pm
Steve,
Why not just create a new permanent filegroup with the required number of files in it; and move the data once? It seems like a lot of work to move the data twice to balance it. The only advantage I see would be to keep it under the default primary file group.
Thanks,
Bob McCormick
February 22, 2021 at 2:32 pm
Creating a new filegroup for everything does not always work. Space constraints are one reason for this.
This isn't to imply the solution is the only one or the one that should always be used, but to show a way to balance out your files if needed.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply