SQL Server GPT Disk Partition Alignment Best Practices

SQL Server GPT Disk Partition Alignment Best Practices

'The performance question here is not did we pick the correct allocation (unit size of the NTFS default of 4,096 bytes or has it been explicitly defined at 64 KB, which is a best practice for SQL Server), but do we have our disk partition alignment correct with every number ending in a whole complete integer .'
Partition_StartingOffset ÷ Allocation_Unit_Size  -- should be a whole complete integer

Example:

Let's look at Computer Management > Storage > Disk Management
Here we will look at GPT Disk 3 which is 4.5TB presented from a SAN and labeled as the "V" drive

Now we will open command prompt as an Administrator and run the following
" fsutil fsinfo ntfsinfo v:  "  were we update the drive letter as needed
Here we look at the Allocation Unit or  "Bytes per Cluster" and see we have 64KB or (65536 bytes)

 Finally we will use the following as it provides more detailed results than diskpart and list disk.  We will use " WMIC Partition get BlockSize, StartingOffset, Name, Index "  where we can capture the Starting Offset.

 This is enough information that we can now plug values into are formula and see that in this example we are correctly aligned.

 135266304 ÷ 65536 =   2064 -- and this is a whole complete integer

 The final answers to everything you have ever wondered about your underlying disk subsystem still may not be answered if your data is presented as a LUN from a SAN then you still need to ask so many more questions about what tier your data is in and are they configured to best SQL Server practices.  This will at least get you to a starting point to perform disk IO tests.

Comments

Post a Comment

Popular posts from this blog

How to mass update all or some sql server agent job step commands

How to mass update all or some sql server agent job step and commands using TSQL.   This will use the built-in Replace function to search text in SQL agent jobs  SQL Agent Job information is stored in MSDB and can reviewed using some of the following queries: SELECT * FROM msdb.dbo.SysJobs SELECT * FROM msdb.dbo.SysJobSteps -- OR SELECT a.name as job_name, b.step_name, b.subsystem, b.command, b.database_name, a.enabled       ,a.description, a.date_created, b.job_id, b.step_id   FROM [dbo].[sysjobsteps] as b   INNER JOIN sysjobs as a ON a.job_id = b.job_id Since I will be focusing on the Commands column I will look at using this query to extract data into a temp table so that I can test any updates with the replace step before doing an update to MSDB. This would be your opportunity to archive or save any commands as needed.  Some people may prefer to generate all the syntax necessary to use EXEC sp_update_jobstep so you a...
Read more

SQL Monitoring for Blocking and Locking Capture and Log to table with sp_WhoIsActive or sp_BlitzWho

Image
You can use  sp_WhoIsActive or sp_BlitzWho and log the capture data to a table.   In my example I will use sp_whoisactive as I am more familiar with its use and data collection, however I will look at creating a future post using BlitzWho.  I will provide a few examples that were used to determine that the paid SQL monitoring products can be fancy tools but can be useless if you don't understand the basic concepts or even an understanding of how we capture similar data or in some cases more finely tuned to a specific scenario or use case.  Sometimes these paid solutions are incorrect or things can simply go wrong (Services Fail to start or the data is aggregated and misses something like the query commands and SQL Fragments) and it's always good to plan ahead and be prepared.   Sp_WhoIsActive is a procedure written by Adam Machanic. It can be found here:  sp_whoisactive downloads Sp_BlitzWho is a procedure written by the Brent Ozar team....
Read more

SQL Server General Index Naming Convention

SQL Server General Index Naming Convention  easy to follow:  PK_ for primary keys PK_  Primary Keys, which are logical constructs and not necessarily physical constructs, get tagged with a PK_ prefix. In most systems that I design the PK_ isn’t a clustered index.  IX_ for non clustered non unique indexes IX_  standard single or even multi-column indexes used for seeks or intersection just get prefixed with an IX_ (for  I nde X ). In cases where I need a composite index (i.e., multiple columns) but still explicitly ‘tolerate’ key/bookmark lookups, I’ll still call my seek/intersection/composite indexes IXes. UK_ for unique keys UK_  for unique key index UX_ for unique indexes UX_  for unique index. CLIX_ for Clustered Index (non PK) CLIX_  (non-PK) Clustered Index name is prefixed with CLIX (for  CL ustered  I nde X ) Additionally, I like to code all Create Indexes in SQL 2012 and above with an if not ...
Read more