Sql serer nimble san bes practices1/4/2024 ![]() ![]() Brilliant! How do they work?įor snapshots in VMWare, the documentation is very clear: Take a snapshot of the virtual machine, apply changes, sign off that everything looks good, and remove the snapshot. Think of things like upgrades or service packs. You want to be able to quickly put the virtual machine back to the point in time created by the snapshot or checkpoint. The reason for wanting this point in time copy is simple as well: recovery. The concept of a snapshot or checkpoint is simple: to create a copy of the virtual machine at a point in time. Why the two names? To avoid confusion, of course. I’ve used them from time to time when building personal VMs for demos and I’ve seen them used sparingly in production environments. ![]() I’ve been involved with the virtualization of database servers for more than eight years now and the concept of snapshots and checkpoints are not recent revelations for me. What’s more frustrating is that sometimes the only hint of the issue is with the SQL Server error message. Often the conventional tools used to monitor the SAN don’t necessarily show the problem, as they are focusing on the overall health of the SAN and not on the health of specific applications, database servers, or end-user experience.Īnd just when I thought I had seen it all when it comes to the error message above, along comes something new for me to learn. One workload, on one particular server, causing performance pain for a seemingly unrelated server elsewhere. Turns out that when several servers share the same storage arrays you can end up being a victim to what is commonly called a “ noisy neighbor“. In my experience the true answer was almost always “shared storage” or “the nature of the beast that is known as a SAN”. I’ve seen that error message appear with little to no workload being run against the instance. In fact, this is the type of guidance that usually results in people wanting to just throw hardware at the problem. In my experience, this guidance was wrong more than 95% of time. The traditional answers you find on the internet tell you to look at your queries and try to figure out which ones are causing you the I/O bottleneck. Now, I’ve seen this error message many times in my career. But how else to explain this error? For all I know this SAN could be on Mars! No, I don’t have any idea how they got there, either. ![]() …implies that the round trip time is over 15 seconds, so using 7.5 seconds (as a minimum estimate, we really don’t know how long it is taking) we see the underlying SAN disks are over 1,396,500 miles away, or about 5.8 times as far away as the Moon. The offset of the latest long I/O is: 0x00000000000000 SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds So, therefore this common SQL Server error message number 833… It takes a radio signal just about 1.28 seconds to get to the Moon (about 239,000 miles away), and about 2.5 seconds for round trip communication between our secret moon base and Earth. ![]()
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |