jwcolby
jwcolby at colbyconsulting.com
Mon Jun 15 21:57:27 CDT 2009
Hmmm... Notice in the following that this only helps if the disk is translated as 64 sectors / track. It is unclear how to determine that. http://technet.microsoft.com/en-us/library/aa995867.aspx https://www.equallogic.com/uploadedFiles/Resources/Tech_Reports/tr-ms-sector-align_TR1012_v2-0.pdf John W. Colby www.ColbyConsulting.com Jim Lawrence wrote: > Hi John: > > That is an excellent piece of information. If there is some way to qualify > the performance gains and they show positive results, that would definitely > be the way to go. > > Good research John. I will see if I can find out some more info on this. > > Jim > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby > Sent: Monday, June 15, 2009 2:32 PM > To: Access Developers discussion and problem solving > Subject: [AccessD] This just in... > > I just found this: > > It is highly recommended that all partitions are configured by using the > DISKPAR (Windows 2000) or > DISKPART (Windows 2003) commands. When using DISKPAR, adjust the alignment > by 512 bytes, and when > using DISKPART, the disk should be aligned to 64. The reason for this is due > to the original master > boot record design of WinTel based systems. The master boot record for all > drives is 63 blocks (1 > block = 512 bytes). > > The physical disks want to read and write data in 64 block chunks. Because > the master boot record is > only 63 blocks, this puts the first block of actual data in block location > 64, where it should be in > block location 65. That forces the disk to read 128 blocks for each 64 > blocks read to the disk, > thereby increasing the work needed to be done and decreasing performance. > > It is so highly recommended that volumes be created with this 64 block > offset that Microsoft is > including this procedure as the standard when creating partitions starting > in Microsoft Windows 2008 > Server. There are no published figures on what sort of performance > improvement will be seen by > creating your disks using this method. It's because any numbers would be > relevant to only the system > they were taken against, as all databases are different. Unfortunately, once > a partition has been > created without the alignment offset, there is no easy way to change the > offset. The only method for > doing that is to create a new volume and partition with the offset, take > down the SQL Server and > manually migrate the files to the new drive in an offline manor. > > here: > > http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1262122_mem1,00. > html >