Boa tarde! Gostaria primeiro de agradecer a todos que puderam assistir a palestra que Gentile e eu demos sobre DMVs no TechEd .

Conforme prometido, segue nesse post as demonstrações efetuadas sobre a utilização de algumas das DMVs e DMFs existentes a partir do SQL Server 2005. Lembrando que algumas delas, cf mencionamos, estão disponíveis somente a partir do SQL Server 2008 R2 Service Pack 1. É isso ae, esperam que tenham curtido a palestra e as demos que disponibilizamos.

Obrigada

-- usando a sys.dm_exec_sessions para visualizar a carga da instância

select * from sys.dm_exec_sessions

-- sessões de sistema (kpid <= 50)

select * from sys.dm_exec_sessions where is_user_process <> 1

-- sessões de usuário (kpid > 50)

select * from sys.dm_exec_sessions where is_user_process = 1

-- informações sobre a origem das sessões de usuário

select session_id

, login_time

, login_name

, original_login_name

, nt_user_name

, nt_domain

, host_name

, program_name

from sys.dm_exec_sessions

where is_user_process = 1

-- opções nas sessões de usuário

select session_id

, ansi_defaults

, ansi_null_dflt_on

, ansi_nulls

, ansi_padding

, ansi_warnings

, arithabort

, deadlock_priority

, lock_timeout

, transaction_isolation_level

from sys.dm_exec_sessions where is_user_process = 1

-- informações sobre o consumo de recursos das sessões de usuário

select session_id

, cpu_time

, reads

, logical_reads

, writes

, memory_usage

, row_count

from sys.dm_exec_sessions where is_user_process = 1

-- mapeando as sessões de usuário para conexões de rede

select es.session_id

, ec.connect_time

, ec.net_transport

, ec.num_reads

, ec.num_writes

, ec.last_read

, ec.last_write

, ec.net_packet_size

, ec.client_net_address

, ec.client_tcp_port

, ec.local_net_address

, ec.local_tcp_port

from sys.dm_exec_sessions es join sys.dm_exec_connections ec on es.session_id = ec.session_id

where es.is_user_process = 1

-- mapeando as sessões de usuário para as requisições ativas

select es.session_id

, er.request_id

, er.start_time

, er.status

, er.command

, er.database_id

, er.user_id

, er.executing_managed_code

from sys.dm_exec_sessions es join sys.dm_exec_requests er on es.session_id = er.session_id

where es.is_user_process = 1

-- opções nas requisições ativas

select es.session_id

, er.ansi_defaults

, er.ansi_null_dflt_on

, er.ansi_nulls

, er.ansi_padding

, er.ansi_warnings

, er.arithabort

, er.deadlock_priority

, er.transaction_isolation_level

, er.lock_timeout

from sys.dm_exec_sessions es join sys.dm_exec_requests er on es.session_id = er.session_id

where es.is_user_process = 1

-- informações sobre o consumo de recursos das requisições ativas

select es.session_id

, er.cpu_time

, er.reads

, er.logical_reads

, er.writes

, er.granted_query_memory

, er.row_count

, er.prev_error

, er.open_resultset_count

, er.open_transaction_count

, er.transaction_isolation_level

from sys.dm_exec_sessions es join sys.dm_exec_requests er on es.session_id = er.session_id

where es.is_user_process = 1

-- informações sobre requisições bloqueadas

select es.session_id

, er.request_id

, er.blocking_session_id

, er.command

, er.wait_type

, er.wait_resource

, er.wait_time

from sys.dm_exec_sessions es join sys.dm_exec_requests er on es.session_id = er.session_id

and es.is_user_process = 1 and er.blocking_session_id <> 0

-- informações sobre os comandos das requisições ativas

select es.session_id

, er.request_id

, er.command

, er.sql_handle

, er.plan_handle

, er.statement_start_offset

, er.statement_end_offset

, er.query_hash

, er.query_plan_hash

from sys.dm_exec_sessions es join sys.dm_exec_requests er on es.session_id = er.session_id

where es.is_user_process = 1

-- porcentagem completada dos DBCCs rodando na instalação

select es.session_id

, er.request_id

, er.start_time

, er.status

, er.command

, db_name (er.database_id) as 'db_name'

, er.percent_complete

from sys.dm_exec_sessions es join sys.dm_exec_requests er on es.session_id = er.session_id

where es.is_user_process = 1 and er.command like '%DBCC%'

-- informações sobre sessões sem requisições ativas e com transações pendentes

select es.*

from sys.dm_exec_sessions es

where exists (select * from sys.dm_tran_session_transactions t

                        where t.session_id = es.session_id)

            and not exists (select * from sys.dm_exec_requests as r

                        where r.session_id = es.session_id)

-- capturando as queries e os planos de execução das requisições ativas

select es.session_id

, er.request_id

, er.command

, er.sql_handle

, st.text

, er.plan_handle

, qp.query_plan

, er.statement_start_offset

, er.statement_end_offset

, er.query_hash

, er.query_plan_hash

from sys.dm_exec_sessions es join sys.dm_exec_requests er on es.session_id = er.session_id

cross apply sys.dm_exec_sql_text (er.sql_handle) st

cross apply sys.dm_exec_query_plan (er.plan_handle) qp

where es.is_user_process = 1

-- capturando os comandos e os planos de execução das requisições ativas

select es.session_id

, er.request_id

, er.command

, er.sql_handle

, st.text

, substring (st.text, (er.statement_start_offset/2)+1,

        ((case er.statement_end_offset

          when -1 then datalength (st.text)

         else er.statement_end_offset

         end - er.statement_start_offset)/2) + 1) as 'Comando'

, er.plan_handle

, qp.query_plan

, er.statement_start_offset

, er.statement_end_offset

, er.query_hash

, er.query_plan_hash

from sys.dm_exec_sessions es join sys.dm_exec_requests er on es.session_id = er.session_id

cross apply sys.dm_exec_sql_text (er.sql_handle) st

cross apply sys.dm_exec_query_plan (er.plan_handle) qp

where es.is_user_process = 1

-- novas colunas na sys.dm_exec_query_stats

select creation_time

, last_execution_time

, plan_generation_num

, execution_count

, total_rows

, last_rows

, max_rows

, min_rows

, substring (st.text, (qs.statement_start_offset/2)+1,

        ((case qs.statement_end_offset

          when -1 then datalength (st.text)

         else qs.statement_end_offset

         end - qs.statement_start_offset)/2) + 1) 'Comando'

from sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.sql_handle) st

-- novas DMVs

-- informações sobre espaço livre nas partições usadas pela instância SQL

select * from sys.dm_os_volume_stats (6, 1)

select * from sys.dm_os_volume_stats (6, 2)

select * from sys.dm_os_volume_stats (7, 1)

select * from sys.dm_os_volume_stats (7, 2)

-- espaço livre nas partições usadas pelo banco de dados corrente

select database_id, f.file_id, total_bytes, available_bytes

from sys.database_files f cross apply sys.dm_os_volume_stats(DB_ID(), f.file_id)

-- informações sobre o sistema operacional

select * from sys.dm_os_windows_info

-- informações sobre as chaves de registry usadas pelas instância SQL

select * from sys.dm_server_registry

-- parâmetros de startup da instância SQL

select * from sys.dm_server_registry

where registry_key like 'HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQLServer\Parameters'

-- dumps gerados pela instância SQL

select * from sys.dm_server_memory_dumps

select @@SPID

dbcc stackdump (52)

-- serviços usados pela instância SQL

select * from sys.dm_server_services

-- observando onde existe contenção na instância

select *

from sys.dm_os_wait_stats

where wait_type not in ('CLR_SEMAPHORE', 'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE', 'SLEEP_TASK'

                                    , 'SLEEP_SYSTEMTASK', 'SQLTRACE_BUFFER_FLUSH', 'WAITFOR', 'LOGMGR_QUEUE'

                                    , 'CHECKPOINT_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BROKER_TO_FLUSH'

                                    , 'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE'

                                    , 'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP')

order by waiting_tasks_count desc

-- capturando as queries e os planos de execução das requisições ativas

select es.session_id

, er.request_id

, er.command

, er.sql_handle

, st.text

, er.plan_handle

, qp.query_plan

, er.statement_start_offset

, er.statement_end_offset

, er.query_hash

, er.query_plan_hash

from sys.dm_exec_sessions es join sys.dm_exec_requests er on es.session_id = er.session_id

cross apply sys.dm_exec_sql_text (er.sql_handle) st

cross apply sys.dm_exec_query_plan (er.plan_handle) qp

where es.is_user_process = 1

-- estatísticas de execução das queries com planos em cache, CPU

select creation_time

, last_execution_time

, execution_count

, plan_generation_num

, total_worker_time

, last_worker_time

, max_worker_time

, min_worker_time

, substring (st.text, (qs.statement_start_offset/2)+1,

        ((case qs.statement_end_offset

          when -1 then datalength (st.text)

         else qs.statement_end_offset

         end - qs.statement_start_offset)/2) + 1) 'Comando'

from sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.sql_handle) st

where qs.sql_handle = 0x020000007D48FC13E49DCC58F2B9B99424B54C8FCCCB1DBF

-- estatísticas de execução das queries com planos em cache, leituras lógicas

select creation_time

, last_execution_time

, plan_generation_num

, execution_count

, total_logical_reads

, last_logical_reads

, max_logical_reads

, min_logical_reads

, substring (st.text, (qs.statement_start_offset/2)+1,

        ((case qs.statement_end_offset

          when -1 then datalength (st.text)

         else qs.statement_end_offset

         end - qs.statement_start_offset)/2) + 1) 'Comando'

from sys.dm_exec_query_stats qs

cross apply sys.dm_exec_sql_text(qs.sql_handle) st

where qs.sql_handle = 0x020000007D48FC13E49DCC58F2B9B99424B54C8FCCCB1DBF

-- estatísticas de execução de stored procedures

select ps.database_id

, ps.object_id

, ps.sql_handle

, st.text

, ps.plan_handle

, qp.query_plan

from sys.dm_exec_procedure_stats ps

cross apply sys.dm_exec_sql_text(ps.sql_handle) st

cross apply sys.dm_exec_query_plan (ps.plan_handle) qp

where database_id not in (1, 2, 3, 4, 32767)

-- identificando os índices não encontrados pelo otimizador

select gs.group_handle, id.*

from sys.dm_db_missing_index_group_stats gs

inner join sys.dm_db_missing_index_groups ig on gs.group_handle = ig.index_group_handle

inner join sys.dm_db_missing_index_details id on ig.index_handle = id.index_handle

where database_id = 7

TechEd2011 Demos.sql

“Qual recovery model que devo utilizar na minha base de dados?” ou ainda “Qual a diferença entre eles?” são dúvidas ainda frequentes para muitos DBAs. No entanto, antes de responder, é necessário explicar um pouco melhor como o log funciona.

Um banco de dados é formado por arquivos de dados e de log. Para entender o que o arquivo de log armazena, é importante falarmos sobre transação. Para cada alteração de dados solicitada, é efetuada uma transação. No início de uma transação, o SQL Server obtém os dados que o usuário deseja trabalhar dos arquivos físicos de dados (datafiles) e os armazena na memória (buffer cache). Uma vez que a transação é confirmada (COMMIT), os dados são confirmados em memória e em um segundo momento, esses dados são alterados no disco (checkpoint). Esse processo é realizado dessa maneira pois o acesso à memória é muito mais rápido que o disco. Portanto, o arquivo de log (transaction log) armazena as instruções Transact-SQL executadas até o momento do checkpoint.

O recovery model é uma configuração realizada para cada banco de dados. O tipo de recovery model utilizado, determina como os dados transacionais daquela base de dados serão protegidos e recuperados, quando necessário. Com isso, é possível recuperar as transações, tanto no momento de backup e restore, quanto durante o processo de recovery do SQL Server.

Existem três tipos de recovery model: simple, full, bulk-logged. A seguir, seguem os principais critérios para escolha de cada um deles. É importante lembrar que o tipo de backup e restore interfere diretamente na opção escolhida.

Quando utilizar Simple Recovery Model

Utilize se os itens a seguir forem verdadeiros:

• Se o banco de dados for perdido ou danificado, você está disposto a perder todas as atualizações que ocorreram no período entre a falha e o backup anterior.
• Estiver disposto a perder alguns dados no log.

• Prefere exclusivamente os backups full e diferenciais, não efetuando backups ou restores de log de transações.

Quando utilizar Full Recovery Model

Utilize o full, ou também o bulk-logged recovery model, se os itens a seguir forem verdadeiros:

• É necessário a recuperação de todos os dados, inclusive os da transação
• Se o banco de dados contém diversos filegroups e deseja-se restaurar os filegroups Read/Write secundários e, opcionalmente, os filegroups read-only
• É necessário recuperar os dados até o ponto de falha
• Deseja-se restaurar páginas de dados individuais

• Está disposto a suportar os custos administrativos relacionados ao backup de log

Quando utilizar Bulk-Logged Recovery Model

O bulk-logged recovery model é recomendado para utilização apenas nos períodos em que estiver executando operações de carga, além de não ser necessário recuperar os dados no exato ponto de falha. Recomendamos que ao finalizar as operações de carga, o recovery model da base de dados seja alterada imediatamente para full novamente.

Espero ter ajudado!  Até o próximo post

Maiores informações:

Recovery Model Overview
https://msdn.microsoft.com/en-us/library/ms189275(v=SQL.100).aspx
Choosing the Recovery Model for a Database
https://msdn.microsoft.com/en-us/library/ms175987(v=SQL.100).aspx
Backup Under the Simple Recovery Model
https://msdn.microsoft.com/en-us/library/ms191164(v=SQL.100).aspx
Backup Under the Full Recovery Model
https://msdn.microsoft.com/en-us/library/ms190217(v=SQL.100).aspx

Essa semana enfrentei um desafio interessante. Sempre que eram realizadas atualizações de SP, HOTFIX ou CU em determinados servidores, a atualização falhava. Ao consultar os logs do setup, era verificado o erro abaixo:

%ProgramFiles%\Microsoft SQL Server\90\Setup Bootstrap\LOG\Summary.txt

Error Number              : 1635

Error Description         : Unable to install Windows Installer MSP file

%ProgramFiles%\Microsoft SQL Server\90\Setup Bootstrap\LOG\Hotfix.txt

MSP returned 1635: This patch package could not be opened. Verify that the patch package exists and is accessible, or contact the application vendor to verify that this is a valid Windows Installer patch package.

Queríamos nos precaver de alguma maneira para evitar que o mesmo problema ocorre na próxima atualização. Resolvi então executar o comando abaixo no servidor. Com isso, pude analisar se essa falha era realmente devido a arquivos .msp e .msi que não estavam no servidor ou se a causa do problema era outra.

Para minha surpresa, ao executar o script verifiquei que diversos arquivos estavam faltando. Como o Windows utiliza um sistema de cache - onde a instalação é realizada a partir do arquivo anterior existente no servidor - se o mesmo não encontra esses arquivos nas pastas de instalação, ou pelo menos no C:\Windows\Installer, o setup falha.

Cscript FindSQLInstallsOnly.vbs %computername%_sql_install_details.txt

O script acima gera um arquivo de output no mesmo diretório do script. Neste arquivo de output, se buscarmos pela frase “Package does not exist in the Installer cache”, iremos localizer os arquivos que estão faltando de uma determinada instalação.

   Patch Key under:

   HKEY_CLASSES_ROOT\Installer\Patches\8A5D5E904D89C9F4689C77B438F2164E

        DisplayName = Service Pack 2 for SQL Server Tools and Workstation Components 2005 (64-bit) ENU (KB921896)

 The both Last Used Source should have same values:

        Last Used Source = n;1;h:\d96b2f512a03053d9135\HotFixTools\Files\

        Last Used Source = n;1;h:\d96b2f512a03053d9135\HotFixTools\Files\

        Install Date = 20070911

        Installer Cache File Path = C:\WINDOWS\Installer\38c58d7.msp

        Package does not exist in the Installer cache.

Para corrigir esse problema, é necessário copiar os arquivos que faltam novamente para o recurso C:\Windows\Installer. A questão é onde encontrar o arquivo 38c58d7.msp?

No exemplo acima, percebemos que o arquivo 38c58d7.msp não foi localizado na pasta de instalação e que o mesmo é associado à instalação do KB921896.

A partir de então, basta efetuar o download do setup deste KB referente à sua plataforma e salvar em um diretório qualquer. Após isso, execute o comando abaixo para que seja extraído os arquivos de instalação desse fix:

C:\pastaqualquer\SQLServer2005SP2-KB921896-x64-ENU.exe /extract

No diretório selecionado para extração, localize o arquivo sqlrun_sql.msp extraído. Renomeie o mesmo para o nome do arquivo que está faltando (no nosso exemplo 38c58d7.msp). Após renomear, copie para o diretório C:\WINDOWS\Installer\.

Execute novamente o comando abaixo e caso não encontre nenhum outro arquivo faltando, poderá efetuar a instalação novamente.

Cscript FindSQLInstallsOnly.vbs %computername%_sql_install_details.txt

A boa notícia é que para o SQL Server 2008, o BPA (Best Practices Analyzer) já efetua esse tipo de validação, sem a necessidade de executarmos o script .vbs :)

Download do BPA 2008

https://www.microsoft.com/download/en/details.aspx?id=15289

Arquivo fonte do script FindSQLInstallsOnly.vbs disponibilizado no site:

https://support.microsoft.com/default.aspx?scid=kb;en-us;2015100&sd=rss&spid=2855

Pois bem, a ferramenta de monitoração do cliente gerou alguns alarmes acusando “erros e warnings” no Cluster Log. O primeiro passo a partir daí foi gerarmos uma saída do Cluster Log em formato legível para analisarmos.

Para tal fomos ao prompt de comando cmd.exe com privilégios elevados “run as administrator” e digitamos o comando a seguir para gerarmos o Cluster Log dos nós:

cluster.exe log /gen /copy:C:\Temp\ClusterLog

Para mais informações sobre Cluster Log no Windows 2008, consulte:

https://blogs.technet.com/b/askcore/archive/2010/04/13/understanding-the-cluster-debug-log-in-2008.aspx

Após gerarmos o cluster log dos nós, fomos ao diretório C:\Temp\ClusterLog - conforme solicitado - e editamos os arquivos, usando o notepad ou wordpad.

Fomos até o fim do arquivo para identificar o último evento e procuramos pela string “ERR” ou “WARN”.

Na primeira parte deste artigo vou discutir como interpretar o Cluster Log de forma amigável. Vejamos a mensagem abaixo:

00004728.000025b8::2011/06/18-14:24:12.026 ERR   [RES] Physical Disk <Databases\User\Log\Disk01(CORP01)>: VerifyFS: Failed to open file \\?\GLOBALROOT\Device\Harddisk17\Partition1\DBLOG.LDF Error: 5.

Pois bem, vamos discutir de maneira segregada cada item que está colorido na mensagem acima:

1. A primeira parte, em verde, refere-se ao número do processo (PID) no Windows;
2. A segunda parte, em amarelo, é o número da thread (TID) aberta pelo processo;
3. A terceira parte, em roxo, é o timestamp da operação, sempre em GMT;
4. A quarta e a última partes, em vermelho, é a mensagem referente ao erro da operação, neste caso Error 5;
5. A quinta parte, em cinza, refere-se ao componente onde ocorreu a falha, neste caso um Resource [RS];
6. A sexta parte, em azul, é a operação em que ocorreu este erro, para este caso específico foi VerifyFS (Verify File System);

Muito bem, tendo estes itens esclarecidos vamos agora interpretar esse tal Error 5; para algumas pessoas pode parecer simples, pois realmente é para este caso. Porém, para outras, sem a interpretação acima pode ser uma “sopa de letrinhas”.

Vamos abrir um prompt de comando: cmd.exe

Digite: net helpmsg 5 – conforme exemplo:

Agora que descobrimos o significado do erro falta descobrirmos o por quê deste problema ter ocorrido e, obviamente, confirmarmos se realmente é este o problema. Para isso vou utilizar a ferramenta Process Explorer da sysinternals.

Com o process explorer (usando o módulo file manager) conseguimos confirmar que o Cluster tenta acessar esses arquivos, porém recebe acesso negado. A figura abaixo é apenas ilustrativa de como utilizar o process explorer e não se refere ao erro citado.

Agora, com essa informação confirmada, podemos tomar uma ação; entretanto ainda não respondemos o por quê disso ter ocorrido tendo em vista que anteriormente o cluster estava funcionando normalmente. Para responder tal questão recorremos ao console do SQL Server 2008 e, com a seguinte query, verificamos os arquivos de bancos de dados existentes:

Confirmamos que não existiam arquivos criados com este nome para nenhum dos bancos de dados da instância e infelizmente o ERRORLOG não registra operação de “detach”; então fomos verificar com a equipe de DBA’s se haviam feito um “detach” de algum banco de dados e a resposta foi “SIM”.

A partir deste momento identificamos a causa e a solução para o problema:

Causa

Ao efetuarmos um “detach” do banco de dados pelo SSMS as permissões para o arquivo foram "reiniciadas”, deixando apenas o usuário do DBA responsável pela operação com acesso a estes arquivos de dados e log.

Solução

Reatribuir as permissões para permitir acesso aos arquivos pelo Cluster e, consequentemente, seus componentes.

Links úteis

Para maiores informações sobre como analisar Cluster Log e identificar seus componentes seguem alguns artigos e blogs disponíveis:

https://msdn.microsoft.com/en-us/library/aa949696(BTS.10).aspx

https://msdn.microsoft.com/en-us/library/aa949696(BTS.10).aspx

https://blogs.technet.com/b/askcore/archive/2009/11/23/resource-hosting-subsystem-rhs-in-windows-server-2008-failover-clusters.aspx

https://technet.microsoft.com/en-us/library/cc962184.aspx

Espero que este post possa ser útil a vocês.

Obrigado e até a próxima!

Rodrigo Souza

SELECT
CAST(FULLTEXTSERVICEPROPERTY('IsFullTextInstalled') AS bit) AS [IsFullTextInstalled],
@LogPath AS [MasterDBLogPath],
@MasterPath AS [MasterDBPath],
@ErrorLogPath AS [ErrorLogPath],
@SmoRoot AS [RootDirectory],
CAST(case when 'a' <> 'A' then 1 else 0 end AS bit) AS [IsCaseSensitive],
@@MAX_PRECISION AS [MaxPrecision]
...

Hehehe.. genial!!! A solução é simples e direta.

Quais os tipos de Backup que podem ser executados simultaneamente no SQL 2008? (Ex: posso executar um Backup Diferencial junto com um Backup Log?)

Para descobrir a resposta, levantamos os Locks adquiridos por cada um dos comandos:

• Backup Full
• Backup File
• Backup FileGroup
• Backup Log

Todos as sessões que utilizam o comando BACKUP DATABASE (Full, File, FileGroup) obtém um Lock BULKOP_BACKUP_DB no modo UPDATE. Somente o comando de BACKUP LOG adquire um Lock BULKOP_BACKUP_LOG no modo UPDATE.

Exemplo:

• SPID 52: Backup Full (BACKUP DATABASE db00 TO DISK=…)
• SPID 53: Backup File (BACKUP DATABASE db00 FILE=’primary’ TO DISK=…)
• SPID 55: Backup Full (BACKUP DATABASE db00 TO DISK=…)
• SPID 57: Backup Log (BACKUP LOG db00 TO DISK='…)

A conclusão é que as sessões 52 e 53, correspondente a dos comando de BACKUP DATABASE, ficaram bloqueadas pela sessão 55 durante a realização de um Backup Full. O backup de Log foi realizado de forma concorrente sem problema de bloqueios.

Conclusão: Backup Database não bloqueia o Backup Log, nem vice-versa.

Nesse post irei comentar sobre a importância de se fazer o alinhamento dos discos para obter melhor performance com o volume de dados no SQL Server.
Antes de falar sobre a importância do alinhamento de discos, precisamos antes saber algumas nomenclaturas importantes.

Abaixo adicionei uma foto de um disco para podermos entender melhor.

Nomenclaturas:

Sectors: representa o menor pedaço de dados que pode ser lido ou escrito em um disco físico. A maioria dos discos possuem setores (sectors) de 512 bytes. Discos novos podem oferecer setores com tamanhos 1KB, 2KB, ou 4KB.

Clusters: são conhecidos por muitos como unidade de alocação de arquivo (file allocation unit). Seu tamanho é determinado quando a partição é formatada pelo Sistema Operacional. Cluster é definido por um grupo de setores (sectors) , seu tamannho ira depender do valor que foi definido para o file alocation unit. A maioria dos discos utilizam o tamanho de um setor de 512 bytes, considerando um file alocation unit de 64k então, 64K/512 bytes teremos 128 setores por cluster. Lembrando que Cluster = file alocation unit.

Track: cada lado de um disco (Platter) possui milhares de trilhas (tracks) onde são inseridos os setores (sectors) e por sua vez os clusters

Platters: são um ou mais pratos (Platters )de formato circular e de metal (quantidade depende do Hard Disk) onde são armazenadas as informações na superfície.

Stripe Unit Size: define o tamanho que os dados serão distribuídos entre os discos de um grupo RAID-0, RAID-10 ou RAID5.

Agora que entendemos as nomenclaturas podemos começar a falar sobre a importância de se alinhar um disco. O alinhamento de discos deve ser considerado para os volumes que são utilizados pelos arquivos de dados e transaction log do SQL Server.
Outra consideração importante é que o alinhamento deve ser considerado no Windows Server 2003 que não faz o alinhamento do disco por default. No Windows Server 2008 o alinhamento de discos é feito de forma automática, no entanto eu quero deixar um alerta devido ao que tenho visto em meus clientes aqui nos EUA que estão utilizando Windows Server 2008 e mesmo assim não estão com os discos alinhados. Em caso de migrações de Windows Server 2003 para Windows Server 2008, geralmente a storage é apresentada para o novo Sistema Operacional, no caso o Windows Server 2008, sem precisar redefinir os particionamentos. Mesmo sabendo que no Windows Server 2008 o alinhamento é feito por default, nesse caso não será feito porque as partições foram criados enquanto estavam no Windows Server 2003. O alinhamento é feito durante a criação da partição.

Para entendermos o porquê é necessário o alinhamento de um disco, devemos entender que todo disco usa algum espaço para armazenar informações sobre a partição, que então irão utilizar alguns setores ocultos (hidden sectors). Especialmente no Windows Server 2003 são reportados 63 setores ocultos por default. Considerando que cada setor possui 512 bytes então temos que 63 * 512 = 31.5 K que o disco ira utilizar para armazenar informações sobre a partição.

Tendo esse numero em mente vamos entender porque o disco fica desalinhado. Guarde bem em sua memória esses numeros.

Se você precisar consultar a nomenclatura acima novamente, sinta-se a vontade. Para refrescar a sua memória o Stripe Unit Size é determinado pela equipe de Storage no momento de criação das Luns, vamos considerar 64K para o nosso exemplo. Stripe Unit Size é o tamanho do “pedaço” de dados que será distribuído entre os discos de um Array da Storage.

Temos a seguinte configuração para usarmos como exemplo.

Stripe Size = 64K
Alocation Unit Size ou Cluster Size = 64K

Exemplo de um disco desalinhado.

No exemplo acima podemos ver uma situação de disco desalinhado, o Stripe Unit Size definido pela equipe de storage, possui um tamanho de 64k e esta representado na cor Azul na primeira linha da figura. O Stripe Unit Size define os limites fisicos de armazenamento para o Array.
Na segunda linha em amarelo podemos ver os setores que são utilizados para armazenar informações sobre a partição. Lembre-se que no Windows Server 2003 por default é utilizado 63 setores, considerando que o tamanho do setor é 512 bytes então teremos 31.5 K. Eu disse para você memorizar esse número. Repare que esse valor não preenche totalmente o tamanho definido pelo Stripe Unit Size que é 64K, deixando um espaço a ser preenchido. Então imagina o que irá acontecer quando os dados de usuário começar a ser gravado no disco.

Como exemplificado na linha 3 os dados de usuário, representado na cor verde, que nesse caso possui tamanho de alocação de 64K, definido pelo Alloc Unit Size, ira ser inserido entre dois espaços definidos no disco pelo Stripe Unit Size. Sempre que um dado de usuário ser inserido nos próximos espaços estará desalinhado em relação ao Stripe Unit Size definido para o Array.

Então como podemos resolver esse problema? Imagine se de alguma forma você reservasse um espaço para armazenamento de informações sobre a partição, onde o dado representado em amarelo preenchesse os 64K ao invés de 31.5K e então utilizar todo espaço definido pelo Stripe Unit no nosso exemplo a area em azul. Aconteceria que o próximo dado de usuário a ser inserido, representado em verde, iniciaria a partir do segundo Stripe Unit de 64K, evitando que a alocação feita pelo usuário não estaria entre dois espaços definidos pelo Stripe Unit. Consequentemente evitando o IO em dois lugares distintos onde precisaria apenas um.

Vamos ver agora como ficaria um exemplo utilizando um alinhamento onde reservaremos todo o espaço de 64K definido pelo Stripe Unit.

Nesse exemplo acima ao inves de usar o alinhamento default do Windows Server 2003 e  utilizar apenas 31.5K, fizemos diferente e definimos o parametro align para 64K que esta representado em amarelo.
Isso irá preencher todo o espaço de 64K definido pelo parametro Stripe Unit, então as próximas alocações de dados de usuários, iniciara e terminara dentro do espaço definido pelo Stripe Unit.
Mesmo se for definido o Alloc Unit size/Cluster Size que é o bloco de dados gravado pelo usuário de 4K, estara ainda assim dentro do limite de 64K. Nesse caso serão necessarios 16 blocos de alocação de dados para preencher um Stripe Unite. Repare 16 * 4 = 64K portanto ainda estara alinhado.

Após entender essa teoria concluímos que o parâmetro Align dividido pelo Stripe Unit Size devera ser um numero inteiro sempre.

Como não se sabe a quantidade de espaço necessário para armazenar informações sobre a partição para os diferentes discos existentes no mercado, então a Microsoft recomenda utilizar o valor de alinhamento como 1024k ou 1MB.
Isso significa que assim como fizemos com 64k reservando espaço para dados de partição para garantir que os dados de usuário sejam gravados de acordo com o Stripe Unit, que nesse exemplo é 64K, podemos fazer o mesmo usando o valor 1024K recomendado pela Microsoft.

Se pegarmos o exemplo que usamos anteriormente usando um alinhamento de 64k ao invés de 31.5K (Windows Server 2003 Default) e um Stripe Unit Size de 64K temos o seguinte:

64K / 64K = 1   onde o resultado é igual a 1 bloco de Stripe Unit.  Representado em amarelo, usamos 1 unidade para setores ocultos, para então iniciar a gravação dos usuários de acordo com os limites fisicos definidos pelo parametro Stripe Unit Size.

Podemos fazer o mesmo com o parametro de alinhamento 1024K e Stripe Unit Size de 64k

1024K / 64K = 16 o resultado aqui é também um numero inteiro, que significa que antes de iniciar a gravação de dados de usuários, iremos preencher 16 unidades de amarelo para setores ocultos, para então iniciar a gravação dos dados de usuário. Isso irá resultar que serão preenchidos 16 unidades de 64K para iniciar a gravação dos dados de usuário, que por sua vez estará alinhado com os limites fisicos definidos por Stripe Unit Size

Considerações

Align value : Stripe Unit Size deve ser um numero inteiro para que o disco grave de forma alinhada.
Allocation Unit Size que são blocos de dados de usuário, recomenda-se ser o mesmo valor de Stripe Unit Size.

Espero que tenham gostado do Post sobre alinhamento de discos e aguardo comentários caso tenham alguma dúvida. Em um outro post mostrarei como fazer o alinhamento de discos.

Para maiores informações e detalhes recomendo a leitura do Whitepaper Disk Partition Alignment Best Practices for SQL Server https://msdn.microsoft.com/en-us/library/dd758814(v=sql.100).aspx

André Hass – Premier Field Engineer – US East Region

Olá, sou Rodrigo Souza, faço parte do time de Premier Field Engineers (PFE) na Microsoft.

Neste post vou compartilhar com vocês um caso interessante que temos acompanhado em alguns clientes, que trata-se da exaustão de portas efêmeras TCP/IP, quando usamos o Data Collector no SQL Server 2008.

Constatamos tal problema a partir de mensagens como estas no ERRORLOG:

Logon Error: 17806, Severity: 20, State: 2. 2011-03-14 08:31:40.72 Logon SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed.

Logon Error: 18452, Severity: 14, State: 1. 2011-03-14 08:31:40.72 Logon Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Observamos também diversas mensagens no Event Viewer, como as seguintes:

Error # 5719 NETLOGON N/A N/A This computer was not able to set up a secure session with a domain controller in domain CONTOSO due to the following: The RPC server is unavailable. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator. ADDITIONAL INFO If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain.

Audit Failure SRV1.contoso.microsoft.com 18456 MSSQL$INST1 Logon CONTOSO\SERVER1$ Login failed for user CONTOSO\SERVER2$'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors.

SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed.

Com a ajuda do Network Monitor (Netmon) conseguimos visualizar que o serviço Data Collector causou exaustão nas portas efêmeras TCP/IP, fazendo com que a comunicação com os servidores de domínio parasse.

Após esta constatação, iniciamos alguns Workarounds sem sucesso efetivo; então resolvemos desativar temporariamente o serviço Data Collector do SQL Server 2008 e iniciamos uma investigação interna junto ao time de Escalação e Desenvolvimento.

Caso se depare com alguma das mensagens acima em seu servidor SQL Server 2008 e o serviço Data Collector esteja habilitado, analise a possibilidade de desativá-lo e verifique se a comunicação com os servidores de domínio é restabelecida ou contacte o serviço de Suporte Microsoft para mais informações.

Um abraço e até a próxima!

Rodrigo Souza