Silas Mendes @ Microsoft

[SQL Server AlwaysOn AG] Required Synchronized Secondaries To Commit

Silas Mendes — Thu, 28 Jun 2018 12:44:37 GMT

O SQL Server 2017 trouxe uma novidade interessante para o AlwaysOn Availability Groups (AG); hoje vamos falar sobre a opção: Required_Synchronized_Secondaries_To_Commit. Pra entender o papel desta nova opção é importante entender como o AG se comporta quando está configurado para operar no modo síncrono. Para facilitar a nossa “prosa” vamos considerar que temos um AG com duas réplicas: "X" e "Y". Essas réplicas estão operando em modo síncrono e com failover automático habilitado. Vamos considerar também que nosso cluster está com seu witness quorum devidamente configurado. A réplica X é nossa réplica primária, nela ocorrem escritas e leituras. A réplica Y é nossa réplica secundária, se uma falha ocorrer na réplica X é esperado que a réplica Y assuma automaticamente. Como essas réplicas estão operando em modo síncrono, toda modificação realizada na réplica X só será confirmada (comitada) quando esta modificação também for registrada no t-log da réplica secundária. Em geral réplicas síncronas operam com o status “SINCRONIZED” (sincronizado).

Agora, o que acontece se a réplica secundária (Y) for desligada?

Como o cluster está com o witness quorum devidamente configurado, por padrão a réplica X continuará operando normalmente, atendendo o workload de escrita e leitura. Toda modificação efetuada nesse período ficará em uma fila na réplica primária até que a réplica secundária retorne. Quando a réplica secundária retornar, ela solicitará à réplica primária todas as modificações que ocorreram durante o período que ela ficou offline. Se essa fila for grande, a réplica secundária poderá demorar algum tempo para voltar a ficar 100% sincronizada com a réplica primária e durante esse período ela operará com o status “SINCRONIZING” (sincronizando). Se neste período a réplica primária falhar, não teremos failover automático para a réplica Y, pois como ela estava com a sincronização atrasada, não seria seguro que ela assumisse automaticamente. Nesse cenário teríamos 2 opções: “ressuscitar” nossa réplica X ou fazer um forced failover para a réplica Y para que ela assumisse o papel de réplica primária, porém, como ela estava atrasada, inevitalmente perderíamos dados nesse processo.

Como evitar que isso aconteça?

É aí que entra a nova opção Required_Synchronized_Secondaries_To_Commit. Nessa opção definimos quantas réplicas síncronas precisam persistir a transação para que esta seja confirmada na réplica primária. Se habilitarmos esta opção em nosso AG fictício, quando a réplica secundária (Y) for desligada, nenhuma nova transação ocorrerá na réplica primária. Todas as conexões na réplica primária serão encerradas e nenhuma nova conexão será estabelecida (nos bancos que fazem parte do AG) até que a réplica secundária retorne… e não somente retorne, mas que retorne ao estado SINCRONIZED (sincronizado). A seguir temos alguns exemplos de mensagens de erros que podemos encontrar nessa situação:

Remote harden of transaction 'INSERT' (ID 0x000000000002c92f 0000:000015ea) started at Jun  5 2018 12:06PM 
in database 'AdventureWorks2014' at LSN (48:944:3) failed.

Msg 988, Level 14, State 1, Line 8
Unable to access database 'AdventureWorks2014' because it lacks a quorum of nodes for high availability.
Try the operation again later.

Essa nova opção aumenta a segurança das transações, mas também aumenta a importância das réplicas secundárias síncronas, portanto é importante garantir que a infraestrutura das réplicas esteja adequada para trabalhar neste modelo (com atenção especial na latência de disco e rede). Esta opção é uma propriedade do AG e pode ser habilitada/desabilitada a qualquer momento, sem a necessidade de reiniciar o SQL Server. Referências adicionais ALTER AVAILABILITY GROUP Até + Silas Mendes

============================

The code and techniques described in this blog are presented to the reader ‘as is’, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by any of the authors or Microsoft. Further, the authors shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. Your use of the information contained in these pages, is at your sole risk.

[SQL Server: Azure VM] Como funciona o Automated Backup?

Silas Mendes — Tue, 29 May 2018 17:02:59 GMT

Olá pessoal, depois de um tempo distante estou retornando com um tópico que sempre levanta questionamentos dos clientes quando falamos sobre a automatização de backups do SQL Server em maquinas virtuais (VMs) no Azure. O Azure oferece uma vasta opção de templates de VMs com SQL Server, sem dúvidas essa é uma forma muito prática de criar um servidor SQL Server rapidamente. Quando optamos por criar uma VM a partir destes templates, o portal do Azure exibe uma série de recursos que só se aplicam para VMs com SQL Server; uma das opções é o "Automated Backup" (essa opção não está disponível para Linux VMs). A descrição desse recurso informa:

"Configure backups for databases in your virtual machine".

A idéia aqui é bem simples: ao habilitar esta funcionalidade, você passa a ter backup automatizado das bases daquela VM, sem a necessidade de criar planos de manutenção, jobs, schedules e etc; mas vamos às perguntas recorrentes:

"Qual a política desse backup automatizado?"
"Qual o papel do SQL Server Agent nesse cenário?"
"As bases de sistema são incluídas nos backups automáticos?"

Seguem alguns pontos que precisamos considerar:

Até esta data (estamos em Maio de 2018) o Automated Backup só realiza backups das bases da instância DEFAULT; ou seja, instâncias nomeadas não usufruem desse recurso;
O Automated Backup só está disponível para VMs com SQL Server 2014 ou superior;
Esse recurso não cria Jobs no SQL Server Agent; porém para que o recurso funcione o SQL Server Agent deve estar executando;
A VM precisa ter o serviço SQL IaaS agent em execução (esse serviço já vem configurado em VMs que criamos a partir de templates);
Os backups ficam armazenados na storage account indicada no momento da configuração:

No SQL Server 2014 tinhamos algumas limitações, mas se a instância default for SQL Server 2016 (ou superior) temos alguns recursos adicionais:

As bases de sistema estão incluídas na política de backup automático;
É possível determinar um período ideal para a execução do backup full; por exemplo, podemos determinar que o backup full só ocorrerá entre 1h e 5h da manhã;
É possível determinar a frequência do backup de log (de 5 a 60 minutos).

"Se não customizarmos os horários do Automated Backup, quais serão os critérios para a execução dos backups automatizados?"

Em resumo teremos um backup full semanal e um backup de log a cada 2 horas, porém isso pode mudar de acordo com o workload da instância. Quanto maior o volume de modificações, maior a probabilidade de novos backups ocorrerem; exemplo: se o espaço utilizado no transaction log for igual ou maior que 5 MB um novo backup de log ocorrerá. Se o transaction log crescer 1 GB desde o último backup full, um novo backup full acontecerá. Para evitar que um backup full execute durante horário produtivo é importante configurar o Automated Backup definindo os horários apropriados. Outro fator que pode influenciar são ações que "quebram" a sequência de backups, como uma mudança de recovery model de FULL para SIMPLE, por exemplo. Outro ponto que é importante destacar: a escolha do Recovery Model tem a mesma relevância na política do backup automatizado, portanto se sua base estiver no modo SIMPLE o Automated Backup não fará backups do t-log e consequentemente você não terá o recurso do point-in-time restore.

"Posso fazer backups sob demanda (backup manual)?"

Sim, no entanto, para evitar que o seu backup manual "quebre" a cadeia dos backups anteriores é recomendável que você faça o backup (full ou log) utilizando a procedure sp_backup_on_demand. Backups feitos a partir desta procedure serão armazenados na storage account definida no momento da configuração do Automated Backup.

"Como monitorar?"

Você pode visualizar todo o histórico de backups através do SSMS (ex: Reports > Standard Reports > Backup and Restore Events) ou através das views de catálogo na MSDB. Além disso é possível utilizar a procedure sp_get_backup_diagnostics que retorna informações mais detalhadas de todas as ações do Automated Backup:

É possível configurar o Automated Backup em uma Azure VM que não foi criada a partir de um template?

Sim. O primeiro passo é garantir que o serviço SQL IaaS agent esteja configurado e executando. Para verificar o processo de configuração do SQL IaaS agent consulte este link. Referências adicionais: Automated Backup v2 for Azure Virtual Machines SQL Server Managed Backup to Microsoft Azure Até+ Silas Mendes

============================

The code and techniques described in this blog are presented to the reader ‘as is’, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by any of the authors or Microsoft. Further, the authors shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. Your use of the information contained in these pages, is at your sole risk.

[Azure] SQL Server Stretch Database Overview

Silas Mendes — Mon, 11 Dec 2017 12:30:17 GMT

O Stretch Database é uma feature disponível a partir do SQL Server 2016 que permite armazenarmos parte dos dados de um banco SQL Server no Azure. Com o Stretch Database temos um exemplo de solução híbrida, onde parte dos dados estão on-premises (local) e parte no Azure. Atualmente é possível armazenar até 240 TB no Azure com dados de tabelas Stretch. Apesar do nome da feature ser Stretch Database, na prática, a configuração é por tabela. A forma mais simples de habilitar o Stretch Database é através do SSMS: botão direito no banco > Tasks > Stretch > Enable. Neste wizard podemos escolher quais tabelas configurar e o wizard dirá se a tabela atende todos os pré-requisitos. Importante frisar que é necessário ter uma assinatura no Azure e que por hora, nem todas as regiões do Azure oferecem este serviço. Se o cliente desejar, ele pode deixar parte dos dados de uma tabela on-premises e parte dos dados na nuvem (como em um particionamento). Para aplicar este "particionamento" é preciso definir uma função T-SQL com a regra do que deve ser enviado para o Azure; na hora de habilitar o stretch para a tabela, informamos o nome da function como um filter_predicate. Exemplo:

-- função com a lógica do "particionamento"
create function dbo.fn_filtro_stretch(@dt datetime)
returns table
with schemabinding  
as  
return select 1 as linha_elegivel
       where @dt < '20170701 00:00:00'
go

-- habilitar o stretch na tabela com a lógica de particionamento:
alter table t1 set ( remote_data_archive = on (
   filter_predicate = dbo.fn_filtro_stretch(data_pedido),
   migration_state = outbound
) );

Os dados enviados para o Azure não podem ser modificados. Depois de enviar os dados para o Azure é possível traze-los de volta para o on-premises, mudando o migration_state para inbound:

alter table t1
   set ( remote_data_archive = on ( migration_state = inbound ) ) ;
go

Para mensurar o espaço utilizado por uma tabela Stretch, podemos utilizar o comando sp_spaceused com a opção remote_only:

-- espaço utilizado no Azure:
exec sp_spaceused 'Pedidos', 'true', 'remote_only';
go

Para monitorar a sincronização dos dados para o Azure temos a DMV sys.dm_db_rda_migration_status que exibe os 200 ciclos mais recentes de sincronização dos dados. Essa DMV também será útil para identificar problemas de conectividade. O Stretch Database é interessante para o armazenamento de cold data, ou seja, dados que precisam ser armazenados por longos períodos, mas que serão consultados raramente. Com essa abordagem o cliente pode reduzir significativamente o custo de armazenamento e também reduzir o tamanho do banco de dados, o que refletirá na redução do custo de operações de backup, reindex, etc. Os dados armazenados no Azure são criptografados, possuem backup automático e HA/DR. Tabelas que participam de replicação, In-Memory OLTP, change tracking, CDC, filestream, não suportam o Stretch Database. Para ter acesso a mais conteúdo, consulte a documentação da feature: https://docs.microsoft.com/en-us/sql/sql-server/stretch-database/stretch-database Até + Silas

============================

The code and techniques described in this blog are presented to the reader ‘as is’, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by any of the authors or Microsoft. Further, the authors shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. Your use of the information contained in these pages, is at your sole risk.

[SQL Server 2017] Novidades no In-Memory OLTP

Silas Mendes — Wed, 27 Sep 2017 18:36:48 GMT

O SQL Server 2017 traz uma série de melhorias para o In-Memory OLTP. Destaco algumas a seguir:

Não há mais limitação de 8 índices por tabela memory-optimized;
Suporte para colunas computadas;
CASE, TRIM, TRANSLATE, CONCAT_WS, TOP (N) WITH TIES, OPENJSON, FOR JSON, CROSS APPLY agora são suportados em procedures natively compiled;
SP_RENAME agora é suportado para tabelas memory-optimized e procedures natively compiled;
SP_SPACEUSED agora informa o espaço utilizado por uma tabela memory-optimized;
Os filegroups de tabelas in-memory agora podem ser armazenados no Azure.

Além disso, há melhorias no tempo de rebuild dos índices durante o processo de recovery (lembre-se que os índices das tabelas in-memory são recriados a cada restart do banco/instância). Para ver mais novidades do SQL Server 2017, consulte o conteúdo deste link: https://docs.microsoft.com/en-us/sql/database-engine/whats-new-in-sql-server-2017 Silas Mendes

============================

[Replicação] SQL Server Comandos DDL

Silas Mendes — Fri, 28 Jul 2017 09:15:17 GMT

Essa semana me deparei com um cenário bem particular em um de nossos clientes. O cliente utiliza replicação transacional e desabilitou nas propriedades da publicação a opção "Replicate Schema Changes", conforme imagem abaixo: Para habilitar ou desabilitar esta propriedade, podemos utilizar o SSMS, conforme imagem acima, ou utilizar a procedure sp_changepublication como no script abaixo:

DECLARE @publication AS sysname SET @publication = N'ReplTesteDropColumn' USE AdventureWorks2016 EXEC sp_changepublication @publication = @publication, @property = N'replicate_ddl', @value = 0 -- disable GO

Por padrão esta opção é "true" e quando esta propriedade está habilitada, comandos DDL como ALTER TABLE, ALTER PROCEDURE e ALTER FUNCTION são replicados para os assinantes. Como essa opção estava desabilitada (false) o cliente esperava que nenhum comando DDL fosse replicado, porém, eles notaram que um ALTER TABLE com DROP COLUMN foi sincronizado para os assinantes. Analisando a documentação da propriedade "Replicate Schema Changes" verificamos que o ALTER TABLE com DROP COLUMN é uma excessão; portanto, independente dessa propriedade estar habilitada ou não, o ALTER TABLE com DROP COLUMN será replicado para os assinantes. Pra ficar no radar :) Referência adicional: https://docs.microsoft.com/en-us/sql/relational-databases/replication/publish/replicate-schema-changes Silas

============================ The code and techniques described in this blog are presented to the reader ‘as is’, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by any of the authors or Microsoft. Further, the authors shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. Your use of the information contained in these pages, is at your sole risk.

[SQL Server 2017] SELECT INTO FILEGROUP

Silas Mendes — Fri, 14 Jul 2017 08:05:12 GMT

Uma das novidades do SQL Server 2017 é a possibilidade de utilizar o SELECT INTO, criando a nova tabela em um filegroup diferente do filegroup default. O comando é bem simples:

SELECT * INTO PedidosTemp ON FG1 from Pedidos;

No meu cenário a tabela Pedidos está no filegroup [PRIMARY], porém, a tabela PedidosTemp que foi criada a partir da tabela Pedidos está no filegroup FG1: Silas

[Administração] SQL Server Instant File Initialization

Silas Mendes — Thu, 29 Jun 2017 17:44:51 GMT

Quando atribuimos a permissão de Perform Volume Maintenance Tasks para a conta que inicia o serviço do SQL Server (em Local Security Policies do Windows), permitimos que o SQL Server aloque espaço para arquivos de dados quase que instantaneamente; esse recurso é conhecido por "Instant File Initialization" (IFI). Na prática isso facilita muito o processo de criação ou crescimento de arquivos de dados, restauração de backups, etc; mas o IFI não tem efeito em arquivos de log. Muitos clientes perguntam o motivo do IFI tornar o processo de alocação de espaço tão rápido e o motivo é que, por padrão, quando o SQL Server precisa alocar espaço para um arquivo, ele preenche o novo espaço com zeros. Quanto maior é a alocação de espaço, mais zeros o SQL Server tem que escrever, portanto, maior a espera. Quando o IFI está habilitado o SQL Server não preenche o novo espaço com zeros e assim o processo é concluído quase que instantaneamente. Para visualizar o comportamento do IFI podemos utilizar um pequeno disco e criar nele um grande arquivo .txt com algum conteúdo; no meu cenário, criei um arquivo com a frase "O Rato Roeu a Roupa do Rei de Roma" inúmeras vezes. Em seguida podemos apagar o .txt. Se verificarmos o conteúdo do disco com um editor hexadecimal, veremos que apesar de termos apagado o arquivo .txt, o conteúdo do arquivo ainda está gravado lá: Agora com o Instant File Initialization habilitado, criamos um banco SQL Server nesse disco. O editor hexadecimal mostrará (para espanto de muitos) que o novo .mdf parece estar preenchido com milhares de "O Rato Roeu a Roupa do Rei de Roma". Como o IFI estava habilitado o SQL Server não teve o trabalho extra de preencher o espaço alocado com zeros no novo .mdf, portanto os dados do antigo .txt não foram sobrescritos. Conforme o SQL Server começar a receber novos dados nesse banco, os dados antigos serão sobrescritos. Se repetirmos o mesmo teste com o IFI desabilitado, veremos que a criação do banco demora mais e no editor hexadecimal veremos que o SQL Server preencheu com zeros o novo espaço alocado: Pontos adicionais

Após conceder a permissão Perform Volume Maintenance Tasks é necessário reiniciar o serviço do SQL Server;
Para instâncias clusterizadas é preciso conceder essa permissão em todos os nós;
No SQL Server 2016 é possível conceder essa permissão durante o setup:

Update em 06/10/2017 A partir do SQL Server 2016 SP1 e SQL Server 2012 SP4 é possível validar se o IFI está habilitado na instância consultando a DMV sys.dm_server_services. A DMV não considera se o serviço foi reiniciado. Referências adicionais Database Instant File Initialization: https://docs.microsoft.com/en-us/sql/relational-databases/databases/database-instant-file-initialization SetFileValidData function: https://msdn.microsoft.com/en-us/library/aa365544(VS.85).aspx Silas ============================ The code and techniques described in this blog are presented to the reader ‘as is’, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by any of the authors or Microsoft. Further, the authors shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. Your use of the information contained in these pages, is at your sole risk.

[Administração] Permissões para manter Jobs do SQL Server Agent

Silas Mendes — Fri, 26 May 2017 17:02:46 GMT

Recentemente um cliente solicitou apoio para limitar as ações dos usuários que podem visualizar os jobs do SQL Server Agent. O objetivo do cliente era permitir que esses usuários somente pudessem visualizar, iniciar ou parar os jobs de uma instância. O SQL Server Agent possui 3 database roles no banco MSDB. Segue um resumo dos principais acessos de cada uma delas:

SQLAgentUserRole: permite criar/modificar/apagar/visualizar/executar/parar/habilitar/desabilitar os jobs que o usuário é owner;
SQLAgentReaderRole: permite criar/modificar/apagar/executar/parar/habilitar/desabilitar jobs que o usuário é owner. Permite também a visualização dos jobs de outros owners, porém não é possível editar/executar/parar/alterar schedule dos jobs de outros owners;
SQLAgentOperatorRole: permite criar/modificar/apagar/executar/parar/habilitar/desabilitar jobs que o usuário é owner; além disso permite executar/parar/habilitar/desabilitar/alterar schedule dos jobs de outros owners.

Para ver todas os detalhes e permissões de cada uma das database role citadas, consulte a documentação: https://docs.microsoft.com/en-us/sql/ssms/agent/sql-server-agent-fixed-database-roles No cenário do cliente a role SQLAgentOperatorRole era a mais adequada; porém o cliente não queria que os usuários desta role tivessem permissão para executar qualquer outra operação (por exemplo: habilitar/desabilitar/criar/etc). A solução mais simples nesse cenário foi manter o usuário na role SQLAgentOperatorRole e negar a permissão de execução nas procedures sp_update_job, sp_update_schedule e sp_purge_jobhistory no banco MSDB; dessa forma o usuário continuou com as permissões necessárias para acessar o Job Activity Monitor, visualizando o status de qualquer job da instância e se preciso iniciar/parar a execução dos jobs, porém, sem a possibilidade de habilitar/desabilitar/alterar schedule/etc. Silas

============================ The code and techniques described in this blog are presented to the reader ‘as is’, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by any of the authors or Microsoft. Further, the authors shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. Your use of the information contained in these pages, is at your sole risk.

[SQLAudit] Como visualizar mais de 1000 registros no Audit Log Viewer

Silas Mendes — Fri, 28 Apr 2017 17:40:34 GMT

Recentemente um cliente questionou se era possível aumentar o volume de registros retornados pelo Audit Log Viewer. Por padrão essa tela só retorna os 1000 registros mais recentes. É possível aumentar esse número; no entanto a opção fica um pouco "escondida" no Management Studio. Além disso é preciso considerar que se você definir um número muito alto, isso poderá impactar o desempenho dessa tela. Para aumentar o número de linhas retornadas, basta acessar o menu Tools > Options > opção "SQL Server Object Explorer" > sub-opção "Audit Log Viewer Options": Outra abordagem para recuperar dados de auditoria é utilizar a função de sistema: sys.fn_get_audit_file. No comando abaixo, leremos todos os arquivos de auditoria do endereço 'E:\LogAuditoria\', recuperando todos os eventos que ocorreram no dia 26-04-2017:

SELECT *
FROM sys.fn_get_audit_file ('E:\LogAuditoria\*',default,default)
WHERE event_time BETWEEN '2017-04-26 00:00:00' and '2017-04-26 23:59:59'; 
GO

Silas

============================ The code and techniques described in this blog are presented to the reader ‘as is’, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by any of the authors or Microsoft. Further, the authors shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. Your use of the information contained in these pages, is at your sole risk.

[Administração] Novidades no plano de manutenção de índices no SQL Server 2016

Silas Mendes — Wed, 15 Mar 2017 17:03:26 GMT

O plano de manutenção (maintenance plan) é uma ferramenta que facilita muito a criação de rotinas para manter os bancos de dados SQL Server, com ele podemos configurar rotinas periódicas para CHECKDB, manutenção de índices e estatísticas, backups, etc; porém, utilizar o plano de manutenção para manter índices de grandes bases nem sempre era viável, porque não era possível definir regras para evitar que o plano fizesse a manutenção de todos os índices (independente se o índice estivesse fragmentado); para evitar o rebuild/reorganize de todos os índices o DBA tinha que criar uma rotina customizada. A partir do SQL Server 2016 temos algumas melhorias: veja na imagem abaixo que agora, por padrão, o plano de manutenção de rebuild de índices vem com uma configuração onde o rebuild só afetará índices com mais de 30% de fragmentação e com mais de 1000 páginas (~8MB): Temos o mesmo recurso para o reorganize, mas nesse caso o valor do campo %Fragmentation é 15%. Silas Mendes

============================ The code and techniques described in this blog are presented to the reader ‘as is’, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by any of the authors or Microsoft. Further, the authors shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. Your use of the information contained in these pages, is at your sole risk.