We’re not looking to get an exact representation of SQL Server’s IO patterns here – we’re just trying to get a fast, one-button-click-easy measurement of how storage performs. SQL Server stores stuff on disk in 8K pages, and zooming out a little, groups of 8 8KB pages (64K extents). The more astute readers (and by that I mean you, you good-looking charmer) will notice that 4K operations don’t really measure SQL Server’s IO.
For SQL Server, this is somewhat akin to doing backups or doing table scans of perfectly defragmented data, like a data warehouse. SEQ1M Q8T1 – lots of long, sequential operations.
While it runs, here’s an explanation of each row’s results: You want to test where your data, log, and TempDB files live, and for fun, also test the C drive and your desktop or laptop for comparison.Īfter making your choices, click the All button. Keep an eye on the free space there – you don’t want to create a test file that can run your server out of drive space. Just know that the bigger the test file, the longer it takes to generate. Smaller test file sizes may look fast but don’t really reflect how a large database will work. If you’re under the gun, do a quick 1GiB test, but for real go-live prep, I like using 32GB to reduce the chances that I’m just hitting cache and getting artificially fast numbers. If you want a fast seat-of-the-pants guess, do 1, but keep in mind it can be wildly variant between passes if something else happens to be going on in the SAN.
It takes knowledge and time, and you only have one of those.
I’ve written about how to test your SAN’s performance with SQLIO, but I’ll be honest with you: that’s the hard way.
0 kommentar(er)
