Eventos: SQLSaturday#424 e SQLManiacs!

Feliz sexta-feira pessoal :)

Hoje falaremos sobre eventos onde o tema central é SQL Server!

Esta semana participei de um encontro do grupo SQLManiacs! O evento foi organizado pelo Vitor Fava e quem apresentou o conteúdo foi o MVP Diego Nogare. O tema do encontro foi Business Inteligence; tudo com foco nas ferramentas de BI da Microsoft, passando desde o SSIS, até o Datazen e Machine Learning. O evento foi super bacana. Pra ficar ligado nos próximos eventos do grupo SQLManiacs, é só visitar o blog do Vitor Fava :)

O outro evento é o SQLSaturday 424! Em Setembro teremos uma nova edição deste evento em São Paulo. O evento contará com 30 sessões, todas com foco em SQL Server. Pra quem trabalha com esta tecnologia é uma oportunidade ímpar! O evento contará com grandes nomes da comunidade como os MVPs de SQL Server Nilton Pinheiro, Marcelo Fernandes e Luti :) Alguns colegas do time de PFEs da Microsoft estarão presentes e eu terei o prazer de apresentar uma destas sessões :)

O tema da minha sessão será “DBAs com a cabeça nas nuvens e os pés no chão”. Como você já deve ter deduzido, falarei sobre SQL Server e cloud computing. Falarei sobre o Azure SQL Database e sobre o papel do DBA nessa nova realidade.
Não perca essa oportunidade de se reunir, se reciclar e reencontrar os amigos!

 

SQLSaturday #424

Acontece em 26/09/2015 na UNIP-Tatuapé

Rua Antônio Macedo, 505 – Tatuapé – São Paulo – SP

 

Até +

Leia Mais

Azure SQL Database v12 – Bases com 1 TB!

O Azure SQL Database é um serviço ofertado pelo Microsoft Azure que permite utilizarmos bancos de dados relacionais na nuvem (na prática é o SQL Server na nuvem com algumas adaptações :) ), tudo de forma muito simples e com a abstração de muitas complexidades comuns nas edições on-premise.
Apesar das inúmeras facilidades, este serviço possuia uma limitação que inviabilizava (ou dificultava) a migração de bancos on-premise para o Azure SQL Database; esta limitação era o tamanho máximo por banco de dados, que até então era limitado a 500 GB.
A boa notícia é que em breve teremos a opção de ter bancos de dados com até 1 TB no Azure SQL Database. Já é possível vermos isso no site do Microsoft Azure :)

http://azure.microsoft.com/en-us/pricing/details/sql-database/

AzureSQLDatabase1TB

Outras referências:

Azure SQL Database Service Tiers and Performance Levels

Leia Mais

Feliz ano novo… adeus ano velho :)

Estamos nos últimos dias de 2014, um ano cheio de altos e baixos, mas que certamente será lembrado por muitos como um bom ano… eu me incluo neste grupo.

Além dos momentos marcantes com os protestos nas ruas, as goleadas históricas na Copa do Mundo e as reviravoltas na campanha política, considero que este foi um ano de muito aprendizado. Um ano de mudanças!

Ultrapassei meus primeiros 365 dias trabalhando na Microsoft. Estar nesta empresa é uma experiência realmente transformadora. Além do desenvolvimento profissional, você cresce como indivíduo. Pra quem trabalhou quase toda a vida profissional com SQL Server, fazer parte desta empresa e em especial, fazer parte do time de PFEs é algo realmente fantástico (e acredite, assustador, no bom sentido, claro!). Conheci pessoas fantásticas este ano; pessoas que me ajudaram a trilhar os primeiros passos dentro da Microsoft e sou muito grato a estas pessoas por isso!

Este ano desenvolvi mais habilidades e conhecimentos sobre as features de alta disponibilidade do SQL Server, bem como dei uma boa melhorada em meu troubleshooting (tudo isso com o apoio de alguns feras como Alex Rosa e Freddie Santos). Além disso ficou muito evidente pra mim o quanto os soft-skills são importantes para nós, profissionais de TI.

Neste ano tive a oportunidade de ministrar treinamentos oficiais de SQL Server para 7 turmas repletas de alunos interessados em se desenvolver mais profissionalmente. Nestas ocasiões tive a oportunidade de fazer novos amigos e além de ensinar, aprender mais sobre SQL Server (é incrível o quanto aprendemos com a experiência das outras pessoas!).

Pra fechar bem, no fim deste ano ganhei um novo lar (literalmente): sai do aluguel pra uma casa própria. Para nós brasileiros esta talvez seja uma das grandes metas pessoais… penso que isso não deveria ser tão difícil, mas essa é a nossa realidade atual e creio que nós brasileiros, aos poucos estamos mudando e nos posicionado para tornar, este, um país melhor pra se viver.

Metas para 2015? Muitas! Algumas delas:

  • Me livrar de 10 quilos (meta muito ousada?!);
  • Ter uma frequência média de 1 post por mês neste blog (meta mais ousada ainda?!);
  • Concluir a certificação MCSE;
  • Turbinar o inglês;
  • Tirar férias decentes com a minha família;
  • Etc, etc, etc…

Existem muitas predições de que 2015 não será um ano fácil para nós brasileiros; apesar disso, estou confiante e desejo que 2015 seja um ano fantástico e transformador para todos nós.

Continuaremos por aqui… feliz ano novo!

Leia Mais

SQL Server – Eventos que impedem a reutilização do t-log

Você já teve problemas com arquivo de log cheio ou problemas para liberar espaço em um arquivo de log no SQL Server? Se sim, provavelmente você se deparou com algum evento que impedia a reutilização do arquivo. Podemos citar alguns deles: a falta de backups de log para bases com recovery model <> SIMPLE, replicação com comandos pendentes, transações abertas, etc.
Uma forma simples de identificar o motivo que impede a reutilização do arquivo de log é consultar o valor da coluna log_reuse_wait_desc na sys.databases; “NOTHING” significa que nenhum evento está impedindo a reutilização do arquivo.

Uma situação bastante comum que impede a reutilização do log é ter uma longa transação aberta no banco. Isso faz sentido: se existe uma transação não concluída, o SQL Server não pode simplesmente ignora-la; dessa forma, o arquivo de log “segura” estes registros até que a transação seja finalizada (neste caso com um COMMIT ou um ROLLBACK), independente de quantos CHECKPOINTs ocorram durante o processo.

Aproveitando o exemplo do post anterior, podemos simplesmente adicionar uma nova linha no código: antes do “while @i<10000” adicione um BEGIN TRAN (sem COMMIT); assim teremos uma transação aberta que impedirá a reutilização do arquivo.

Executando este código em meu ambiente tive o seguinte resultado no Perfmon:

Log não reutilizavel

O arquivo não cresceu pois estava limitado a 1MB (da mesma forma que o post anterior); só que por conta da transação aberta o SQL Server não consegue reutilizar o arquivo de log; dessa forma o espaço disponível dentro do arquivo é consumido totalmente (linha azul) e sem espaço no arquivo de log o SQL Server não pode prosseguir com as alterações. Observe que a base está com recovery model SIMPLE e que durante a execução do código o SQL Server executou CHECKPOINTs automáticos mas estas questões não surtem efeito porque temos uma transação aberta impedindo a reutilização do arquivo de log. Numa situação dessas temos o erro:

Msg 9002, Level 17, State 4, Line 44
The transaction log for database ‘databasename’ is full due to ‘ACTIVE_TRANSACTION’.

Agora reflita: qual seria a solução para este caso? Ter um arquivo de log maior? Deixar a função de auto-crescimento habilitada para o arquivo de log? Ter uma transação menor?

Até a próxima :)

Leia Mais

SQL Server – T-Log, um arquivo circular

Todas alterações realizadas em um banco de dados SQL Server são efetuadas em memória e no arquivo de log; posteriormente os dados serão gravados nos arquivos de dados (existem algumas poucas exceções para este comportamento, mas falaremos sobre este tema em um outro post).

Quando as alterações são persistidas nos arquivos de dados, em geral, o SQL Server pode remover estes registros do arquivo de log e liberar espaço para que este arquivo seja reutilizado; isto explica o termo “circular” utilizado para descrever o arquivo de log.

Agora proponho um teste para comprovarmos isto.

No script abaixo criamos um banco de dados com recovery model “Simple”. Note que o arquivo de log deste banco é criado com tamanho de 1MB, sem opção de auto-crescimento:

USE master
GO
CREATE DATABASE [TesteLogFile]
  ON  PRIMARY
( NAME = N'TesteLogFile',
  FILENAME = N'C:\DataSQL\TesteLogFile.mdf' ,
  SIZE = 3072KB )
 LOG ON
( NAME = N'TesteLogFile_log',
  FILENAME = N'X:\log\TesteLogFile_log.ldf' ,
  SIZE = 1MB , FILEGROWTH = 0 )
GO

ALTER DATABASE [TesteLogFile]
  SET RECOVERY SIMPLE
GO
USE [TesteLogFile]
GO
CREATE TABLE testeCarga
  (id bigint, texto char(4000))
GO

Você poderá abrir seu Perfmon e adicionar os seguintes contadores para ter algumas evidências:

  • Buffer Manager: Checkpoint pages/sec – Monitorar eventos de checkpoints na instância
  • Databases: Log File(s) Size (KB) – Monitorar tamanho do arquivo de log do banco
  • Databases: Log File(s) Used Size (KB) – Monitorar espaço utilizado no arquivo de log

O script que realizará a carga segue abaixo. Inicie a execução e observe o comportamento dos contadores no Perfmon:

set nocount on 

declare @i int = 0
 while @i < 10000
 begin
   waitfor delay '00:00:00:200'
  insert into testeCarga
    values (50000, 'teste carga')
  set @i = @i + 1
 end

Observe na imagem abaixo que o tamanho do arquivo de log não é alterado durante a carga ( Log File(s) Size (KB) representado na linha verde); porém notamos na linha azul que o espaço utilizado neste arquivo tem uma variação constante (Log File(s) Used Size (KB)). Note que no meu gráfico, quando o processo inicia, o arquivo de log já estava ocupando quase 500 KB. O espaço vai sendo consumido até ocupar quase 800 KB e depois este número baixa para aproximadamente 600 KB e este comportamento se repete algumas vezes. Observe que o quando o arquivo de log está próximo de 80% de utilização o SQL Server executa um CHECKPOINT automático (linha vermelha) com o propósito de descarregar as alterações nos arquivos de dados que poderá liberar espaço no arquivo de log e possibilitar sua reutilização.

Reutilização do log

Alguns eventos podem impedir a reutilização do arquivo de log mas isso também é assunto para um próximo post :)

Até a próxima.

Leia Mais

SQL Server – Arquivos de log

Vimos nos posts anteriores (post1 e post2) que nos arquivos de dados o SQL Server balanceia a escrita de forma proporcional ao tamanho de cada arquivo. Hoje vamos ver como isso se aplica para arquivos de log.

O cenário é o seguinte: um banco de dados com 1 arquivo de dados e 2 arquivos de log. Estes 2 arquivos de log estão configurados sem crescimento automático e tamanho limitado em 1MB.

Executaremos uma carga de alguns registros neste banco e vamos observar através do Perfmon como o SQL Server está escrevendo nestes 2 arquivos de log.

Abaixo segue o script para criação do banco e da tabela de teste; observe que criei os 2 arquivos de log em discos diferentes para facilitar a monitoria no Perfmon:

USE master
GO

CREATE DATABASE [TesteLogFile]
  ON  PRIMARY
( NAME = N'DataFile',
  FILENAME = N'C:\Temp\TesteLogFile.mdf' ,
  SIZE = 3072KB )
 LOG ON
( NAME = N'LogFile1',
  FILENAME = N'X:\log\TesteLogFile_log.ldf' ,
  SIZE = 1MB ,
  FILEGROWTH = 0),
( NAME = N'LogFile2',
  FILENAME = N'Y:\log\TesteLogFile_log2.ldf' ,
  SIZE = 1MB ,
  FILEGROWTH = 0)
GO

USE TesteLogFile
go
create table testeCarga
  (id bigint, texto char(4000))
go

Agora damos carga na tabela com o script abaixo (como a operação é muito rápida coloquei um “waitfor delay” para deixar a carga mais lenta propositalmente, assim conseguiremos visualizar melhor o comportamento do SQL Server):

use TesteLogFile
go
declare @i int = 0
begin tran
  while @i < 285
    begin
      waitfor delay '00:00:00:200'
      insert into testeCarga values (50000, 'teste carga')
      set @i = @i + 1
    end

-- commit

Resultado: observe no gráfico abaixo que ao contrário dos arquivos de dados, o SQL Server não balanceia a escrita nos arquivos de log. Veja que o SQL Server inicia a escrita no primeiro arquivo de log e quando este arquivo está preenchido o SQL Server começa a escrever no arquivo seguinte:Escrita em dois arquivos de log

A linha vermelha representa as atividades na unidade X: onde colocamos o logfile1 e na linha verde temos a unidade Y:\ onde colocamos o logfile2. Note que a imagem acima é bem diferente desta que demonstra a escrita em 2 arquivos de dados.

A explicação para este comportamento é que a escrita num arquivo de log é sequencial.

Agora… você já ouviu dizer que o arquivo de log é um arquivo circular? O que seria este “circular”? Algum palpite?

Até o próximo post :)

Leia Mais

SQL Server – Arquivos de dados com tamanhos diferentes

Dando sequencia ao ultimo post, vamos falar um pouco mais sobre arquivos de dados do SQL Server.

No último post criamos um base de dados com 3 arquivos de dados, sendo que 2 deles faziam parte de um mesmo filegroup, que foi configurado como filegroup default deste banco.

Um ponto importante é que ao criar os 2 arquivos de dados em questão, o tamanho de ambos era o mesmo.

A pergunta de hoje é a seguinte: e se os tamanhos destes 2 arquivos fossem diferentes? Isso influenciaria na forma como o SQL Server escreve nestes arquivos?

Vamos dar uma olhada de perto nisso.

Os script são os mesmos do último post, no entanto na cláusula SIZE do arquivo TesteDataFile1 colocamos metade do tamanho (SIZE = 5120KB) e mantemos a configuração para o TesteDataFile2. Para monitorar a escrita optei por criar cada arquivo em um disco diferente.

Em seguida executei a inserção que da carga de 4MB no novo banco e emiti o relatório “Disk Usage”:

Tamanho dos datafiles de um banco de dados

Com o resultado acima concluímos que o SQL Server escreveu nos 2 arquivos, no entanto, como o arquivo TesteDataFile2 tem o dobro do tamanho do TesteDataFile1, o SQL Server escreveu proporcionalmente nos dois arquivos.

Monitorando os dois discos com o Perfmon temos o seguinte resultado:

Escrita nos discos lógicos A linha vermelha representa a quantidade de bytes escritos no disco que armazena o arquivo TesteDataFile2 (que é o maior arquivo) e a linha azul representa a atividade no disco do arquivo TesteDataFile1.

Se analisarmos a média de bytes escritos por segundo, teremos:

  • TesteDataFile1: 380.478
  • TesteDataFile2: 499.133

Enfim, podemos concluir que o tamanho do datafile irá influenciar na forma como o SQL Server escreve nos arquivos. O SQL Server escreverá em ambos datafiles de forma proporcional ao tamanho do arquivo.

Pra ficar no radar :)

Leia Mais

SQL Server – Arquivos de dados

Um banco de dados no SQL Server sempre terá pelo menos 2 arquivos: 1 arquivo de dados (normalmente com extensão .mdf) e 1 arquivo de log (geralmente com extensão .ldf).

Você poderá a qualquer momento adicionar mais arquivos a um banco de dados, seja de dados ou de logs.

Quando falamos em arquivos de dados, adicionar mais arquivos pode ter inúmeras finalidades, como: facilitar o gerenciamento, alocar mais espaço no banco de dados, melhorar desempenho, etc.

É interessante notar que quando você tem um banco com mais de um arquivo de dados, o SQL Server distribui a escrita entre os arquivos. Observe este comportamento na demonstração abaixo:

Criaremos um banco de dados para nossos testes. Este banco terá 3 arquivos de dados, sendo que 2 deles farão parte de um filegroup diferente e este será o filegroup default, dessa forma, todas as tabelas que criarmos neste banco serão automaticamente criadas neste filegroup:

USE master
GO

CREATE DATABASE TesteDataFile
 ON  PRIMARY
( NAME = 'TesteDataFile',
  FILENAME = 'C:\temp\TesteDataFile\TesteDataFile.mdf' ,
  SIZE = 4096KB
),
 FILEGROUP fg_data DEFAULT
( NAME = 'TesteDataFile1',
  FILENAME = 'C:\temp\TesteDataFile\TesteDataFile1.ndf' ,
  SIZE = 10240KB
),
( NAME = 'TesteDataFile2',
  FILENAME = 'C:\temp\TesteDataFile\TesteDataFile2.ndf' ,
  SIZE = 10240KB
)
 LOG ON
( NAME = 'TesteDataFile_log',
  FILENAME = 'C:\temp\TesteDataFile\TesteDataFile_log.ldf' ,
  SIZE = 1024KB
)
GO

Depois da criação, a partir do SSMS podemos extrair o relatório “Disk Usage” deste novo banco através das seguintes opções de menu:

Como acessar relatório "Disk Usage"
Como acessar relatório “Disk Usage”

O resultado é o seguinte:

Espaço utilizado pelos datafiles
Espaço utilizado pelos datafiles

No relatório acima identificamos que os arquivos TesteDataFile1 e TesteDataFile2 possuem 10MB reservados e que deste espaço somente 64KB está sendo utilizado em cada arquivo.

Agora, criamos uma tabela e inserimos aproximadamente 4MB de dados:

use TesteDataFile
go

create table testeCarga
(id bigint, texto char(4000))
go

insert into testeCarga
values (50000, 'Teste de carga')
go 1000

Atualizando o relatório “Disk Usage” temos o seguinte resultado:

Espaço utilizado pelos datafiles
Espaço utilizado pelos datafiles

Note que o SQL Server distribui a escrita dos dados e que os dois arquivos cresceram de forma simétrica. Sendo assim, podemos concluir que os dados da tabela testeCarga estão distribuídos entre os dois arquivos: testeFileData1 e testeFileData2.

Isso é para arquivos de dados. E no arquivo de log? Isso se aplica da mesma forma?

Até +

Leia Mais

AlwaysOn AG e backups nas réplicas secundárias

No SQL Server 2012 AlwaysOn Availability Group (AG) temos a opção de executar backups nas réplicas secundárias. Esta é uma possibilidade interessante para muitos ambientes, considerando que assim podemos aumentar nossa janela de manutenção e tirar a carga dos backups da réplica primária.

Na figura abaixo é possível entender como configurar as réplicas preferenciais para backup:

AG_properties_backup

Percebam que podemos configurar os backups das bases que participam do AG das seguintes formas: executar preferencialmente nas réplicas secundárias (Prefer secondary), somente nas réplicas secundárias (Secondary only), somente na réplica primária (Primary) ou em qualquer réplica (Any Replica).

Observe que na imagem da tela sublinhei a palavra “automated”. Porque? Porque estas configurações só são aplicáveis para backups automatizados; logo isso não se aplica para backups ad-hoc. Sendo assim, se configurarmos um AG como “Secondary only” mas precisarmos de um backup a partir da réplica primária, basta executar um backup ad-hoc na réplica primária; esta configuração nunca te impedirá de realizar backup de suas bases.

Agora, o que o AG entende como “automated backup”? Aqui compreende-se um backup feito a partir de um plano de manutenção (com a opção abaixo desmarcada) ou um comando de backup em conjunto com a função sys.fn_hadr_backup_is_preferred_replica.

AG_properties_backup_task

Por fim, lembre-se que nas réplicas secundárias somente poderão ocorrer backups FULL com COPY_ONLY e backups de log; além disso a réplica secundária deve estar com sincronia ativa com a réplica primária (SYNCHRONIZED ou SYNCHRONIZING).

Até +

Referências:
http://technet.microsoft.com/en-us/library/hh245119.aspx
http://technet.microsoft.com/en-us/library/hh710053.aspx
http://technet.microsoft.com/en-us/library/hh213235.aspx

Leia Mais