Fui informado de que nossa SAN (Hitachi) lida com dados em blocos de 42 MB. É um armazenamento em camadas, de modo que cada bloco é avaliado quando o diretor toma decisões sobre quando deve promover/rebaixar o armazenamento para um armazenamento mais rápido/mais lento. Na ausência de peso político para "fixar" determinados LUNs em determinados níveis, estou tentando fazer tudo o que posso para configurar minha instância do SQL Server (2008 R2 Enterprise) para obter sucesso.
Como tal, eu queria saber se haveria algum benefício/prejuízo em alterar meus tamanhos de arquivo e tamanhos de crescimento de arquivo para múltiplos de 42? Um banco de dados de exemplo seria SIZE=57886MBcom um arquivo FILEGROWTH=5124MB.
Vejo o potencial para leituras extras (já que (42*1024)/8 = 8601,6, mas (42*1024)/64 = 672), mas não tenho certeza se estou compreendendo totalmente todos os conceitos aqui.
A unidade de 42 MB (a Hitachi também chama isso de página, que conveniente). é a unidade de alocação básica na qual o espaço é alocado para um LUN. Portanto, com o provisionamento dinâmico, um LUN sempre crescerá em etapas de 42 MB. Essas páginas Hitachi de 42 MB são retiradas de diferentes grupos Array em um pool.
Portanto, sempre que mais espaço for necessário para o LUN, uma nova página Hitachi de 42 MB será alocada. Quando você gravar sua primeira página de dados SQL de 8 KB em um arquivo, uma página Hitachi de 42 MB será alocada. As gravações subsequentes das páginas de dados SQL vão para essa área de 42 MB, até que esteja cheia.
Agora, o que é importante entender é que uma página de 42 MB vai para um grupo de raid de paridade. Se você tiver pequenos grupos de RAID, por exemplo: RAID-1+0: 2D+2P (2+2) (4 discos) e seu acesso aos dados for principalmente sequencial, isso pode ser um problema quando você tiver um arquivo.
Digamos que você tenha 4 grupos RAID10, cada um com 4 discos. Acontece que você tem apenas 1 tabela importante com 1 índice clusterizado com 168 MB de tamanho.
Quando você começar a inserir nesta tabela, a primeira página de alocação de 42 MB será colocada em um dos grupos de RAID, quando esses 42 MB estiverem cheios, a segunda página de alocação será alocada em outro grupo de RAID, provavelmente todas as 4 páginas de alocação de 42 MB serão divididos nos 4 GRUPOS RAID. (estamos excluindo camadas para simplificar neste momento).
O que é importante entender é que qualquer coisa que você fizer sequencialmente na ordem da chave agrupada terá apenas 4 discos a qualquer momento para lidar com o IO. (2 discos se você estiver gravando...) mesmo que toda a tabela esteja espalhada por 16 discos...
Se você quiser usar todos os 16 discos. você teria que criar 4 arquivos (em 4 LUNS separados) em um grupo de arquivos e criar a tabela nele. Pelo menos agora você sabe que o SQL está "distribuindo os dados em 4 páginas de alocação de 42 MB"
Isso pode ser mais problemático com o arquivo de log de transações. É apenas 1 arquivo e sequencial. O único "ajuste" que você pode fazer aqui é tornar os grupos de RAID usados nesse pool tão grandes quanto possível. Contraditório, um grupo de matriz concatenada RAID5 14+2 OU RAID5 28+4 pode ser o mais rápido, embora seja RAID5 em oposição ao RAID 10, pois, até onde eu sei, o maior grupo RAID no RAID 10 que pode ser criado é 4+4 é 8 discos.
Esteja ciente de que isso se torna muito menos importante se você estiver executando um servidor com vários bancos de dados com vários LUNS, todos compartilhando o mesmo pool, ou ainda mais servidores múltiplos genéricos, todos com LUNS no mesmo pool. Visto que, obviamente, a carga geral seria distribuída uniformemente por todos os grupos de ataque.
Em relação ao tiering, eu não ficaria muito preocupado com isso de um objetivo de desempenho. (se você não tem permissão para fixar..) Páginas de alocação pesadas de 42 MB são movidas para uma camada de alto desempenho, portanto, você pode ter a situação em que uma tabela está espalhada por três camadas diferentes. Aparentemente, você tem partes de sua mesa que são intensivas em IO e partes que não são...
preocupe-se com a combinação de pequenos grupos de ataques E arquivos únicos (na verdade, LUNs únicos) E (altas inserções incrementais OU atualizações/exclusões localizadas em tabelas pesadas OU leituras sequenciais pesadas)
Espero que isso ajude um pouco..
leitura adicional:
Guia de design Hitachi Tiering
Prática recomendada do Hitachi SQL Server
Postagem no blog sobre 42 unidades alloc