1753505
Members
5146
Online
108794
Solutions
just to throw in a couple more things...
All of the suggestions about upgrading controllers and RAID sets is good, but I am convinced that the single most important thing you could do is to add enough drives to physically separate your OS, data, and transaction logs.
Ideally you would have 3 arrays, each with their own single disk volume, and each of them set up as a 2 drive RAID 1. Another option wuold be to combine the OS and data onto a single RAID 1 array (2 drives) with 2 volumes.
However, the MOST important thing for database performance - especially with heavy writes - is to dedicate a physical array (2 drives in RAID 1) with a single volume.
Think about it this way... the ACU allows you to set up multiple volumes within an array of physical drives. This is nice for convenience of assigning LUNs, but it can be a performance killer for databases.
OS and data volumes are characterized by random read/write I/O. So combining them (with 2 volumes) on a single physical 2 drive array is no big deal - it's going to do random I/O anyways.
But the transaction logs are characterized by sequential writes - that's it. By combining the volume containing the logs on the same physical array as the random I/O of the OS and data, you really reduce the write performance of the transaction log (which is already very busy because you are in a write intensive environment). It all comes down to head movement in the physical drives themselves. With random I/O the heads are moving all over the place, back and forth. With sequential writes, the heads IDEALLY only move in teeny little increments to do the next sequential write. By combining them, you have 2 opposite performance requirements - the large amount of head movement back and forth across the disk platters is in direct competition with the teeny little movements of the sequential writes.
As a side note, having a Smart Controller with a relatively large BBW Cache will also do wonders for performance, but this will have less of an effect than separating the log files (you should really do both!)
Check out these white papers for more info:
http://h71019.www7.hp.com/ActiveAnswers/Render/1,1027,5108-6-100-225-1,00.htm
http://h71019.www7.hp.com/ActiveAnswers/Render/1,1027,5264-6-100-225-1,00.htm
http://h71019.www7.hp.com/ActiveAnswers/Render/1,1027,5265-6-100-225-1,00.htm
Thanks,
Doug
All of the suggestions about upgrading controllers and RAID sets is good, but I am convinced that the single most important thing you could do is to add enough drives to physically separate your OS, data, and transaction logs.
Ideally you would have 3 arrays, each with their own single disk volume, and each of them set up as a 2 drive RAID 1. Another option wuold be to combine the OS and data onto a single RAID 1 array (2 drives) with 2 volumes.
However, the MOST important thing for database performance - especially with heavy writes - is to dedicate a physical array (2 drives in RAID 1) with a single volume.
Think about it this way... the ACU allows you to set up multiple volumes within an array of physical drives. This is nice for convenience of assigning LUNs, but it can be a performance killer for databases.
OS and data volumes are characterized by random read/write I/O. So combining them (with 2 volumes) on a single physical 2 drive array is no big deal - it's going to do random I/O anyways.
But the transaction logs are characterized by sequential writes - that's it. By combining the volume containing the logs on the same physical array as the random I/O of the OS and data, you really reduce the write performance of the transaction log (which is already very busy because you are in a write intensive environment). It all comes down to head movement in the physical drives themselves. With random I/O the heads are moving all over the place, back and forth. With sequential writes, the heads IDEALLY only move in teeny little increments to do the next sequential write. By combining them, you have 2 opposite performance requirements - the large amount of head movement back and forth across the disk platters is in direct competition with the teeny little movements of the sequential writes.
As a side note, having a Smart Controller with a relatively large BBW Cache will also do wonders for performance, but this will have less of an effect than separating the log files (you should really do both!)
Check out these white papers for more info:
http://h71019.www7.hp.com/ActiveAnswers/Render/1,1027,5108-6-100-225-1,00.htm
http://h71019.www7.hp.com/ActiveAnswers/Render/1,1027,5264-6-100-225-1,00.htm
http://h71019.www7.hp.com/ActiveAnswers/Render/1,1027,5265-6-100-225-1,00.htm
Thanks,
Doug
I am an HPE employee
